Messages in this thread | | | Date | Mon, 13 Mar 2000 11:00:46 -0500 (EST) | From | James A Simmons <> | Subject | Re: [linux-fbdev] fbdev 2.4.0 cleanups |
| |
> > What's wrong with removing the `con' argument from the get/set functions and > > moving the VC dependant part to fbcon? > Nothing. But there are no such checks in fbmem/fbcon just now. Although > for example for FBIOGET_VSCREENINFO it is trivial. But this abstraction > (as I think it should be done) is going just in opposite way than current.
Yeah you want to move all or most of the VT stuff into fbdev. I think this is the wrong direction. Use the VT ioctl interface.
> I think that it should look (fbmem.c:fb_ioctl): > i = PROC_CONSOLE(info); > ... > case FBIOGET_VSCREENINFO: > struct fb_var_screeninfo *pvar; > > if (con2fb_map[i] != fbidx) > return -EXDEV; > if (i < 0) { > pvar = &info->disp->var; > } else { > pvar = fb_display[i].var; > } > return copy_to_user((void *)arg, pvar, sizeof(*pvar)) ? -EFAULT : 0; > See? You got rid of get_var AT ALL.
You just don't get it. con2fb_map crap is going to go away. In theory fbdev can support up to 256 framebuffer devices. Right now we limit it to 32. We have only 64 VT. Its not going to work. What are we going to do expand it. Then when new technology allows for more framebuffer device then we push again the boundries. Make a dynamic solution that can last years and years into the future. Their are alot of problem with the mapping crap as I have pointed out time and time again. Also your mixing up fbdev too much with VT code. I'm sorry but if you want the video mode of a VT thats not active then use a VT ioctl not fbdev.
> > You think it doesn't make the code smaller? A lot of comments were added to > > vfb.c. > Yes, but last time I checked vfb, I started adding > if (currcon == con) > at the start of each function. Then I gave up... So it does not bring > nothing, except that instead of managing fb_display[i] structure
Thats the point. You don't care about fb_display. Fbcon handles it. All the fbdev driver cares about is its current hardware state. If you want to know/change the colormap of a none active VT then use a VT ioctl for this. That what the point of those VT ioctl calls are. See the difference between you and me in design is that I want the things to affect the console like change a colormap of a non active VT handled by the console system itself. Not fbdev directly. You seem to want the VT ioctl handling code to migrate to fbdev. In this case we might as well allow things like echo -e "[33]hfhd" > /dev/fb instead of /dev/tty. I don't know the ESC command off the top of my head.
> I have to copy it from fb_display[] to fbinfo->var/fix on each switch,
Yeah its saves the current hardware state. Does fbdev really need to worry about inactive VTs to make sure the current hardware state functions properly. The answer is no.
> copy it back on each switch, add special code for handling this instead > of simple example of FBIOGET_VSCREENINFO above (you must do: > if (con < 0) use info->disp->var > else if (con == currcon) use info->var > else use fb_display[i].var > It is not shorter in any way I can see. It is longer, it adds dependency > of currcon on place where it is not needed.)
Because you want VT functionality in fbdev. Use the VT ioctls instead. Use /dev/fb to grab the current video mode information. /dev/fb is meant to talk to the video hardware directly. Its for finding out about the current hardware state. Changing the current hardware state. Use VT ioctl to grab or change the current or non foreground console state. Their is a big difference between video hardware state and console state.
"Look its a text editor, no its a OS, no its Emacs" James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |