> > 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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:26 EST