On 13 Mar 00 at 11:00, James A Simmons wrote:
> > > 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.
Unless there is new API, leave old in place.
> > I think that it should look (fbmem.c:fb_ioctl):
> > if (con2fb_map[i] != fbidx)
> > return -EXDEV;
> > 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
Why it is not going to work? I told you couple of times that without
migrating VT from one framebuffer to another your system does not bring
nothing. And btw, all my proposed changes REMOVE 'con' parameter from
fbdev functions - I think that it is removing VT-awareness from fbdev,
not removing features from fbdev you are doing.
> 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
Then alloc con2fb_map by kmalloc. Or use pointer in vc_cons and do
if (vc_cons[i]->fb_info != info) return -EXDEV;
> 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.
We have working system. Migrating to your changes moves system to nonworking
state. Sorry.
> > > 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
And why we should manage current state in info->var? Why not in
info->currhw->var? I do not believe that copying data from one place
to another and then back is correct solution. Maybe I'm too tied to
database systems, but if you have duplicated information, you cannot
have it right.
> 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
> 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.
How you come to this strange idea? I want to remove calling
fb_set_cmap driver function if con != currcon. Your patches do not
address it. Your patches address that I must copy data from one
area to another on set_var.
> > 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.
Yes. So add wrappers into fbcon - and if you prove that you must change
fbdev interface, lets go. But you are still trying to put some strange
interface which brings nothing, but now even breaks source compatibility
between 2.2 and 2.4 lines. Without reason. I.e. features are missing,
interface is more complicated.
> > 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.
Please face to it. We have FBIOGET_VSCREENINFO. FBIOGET_VSCREENINFO is
VT aware. Couple of applications believes that it is right thing to have
FBIOGET_VSCREENINFO VT aware. If you want to remove it, please add
vt ioctl for 2.4. And then you can talk about removing FBIOGET_VSCREENINFO
in 2.6. But in any case you cannot change FBIOGET_VSCREENINFO semantic!
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-
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:24 EST