Re: [linux-fbdev] fbdev 2.4.0 cleanups

From: Petr Vandrovec (VANDROVE@vc.cvut.cz)
Date: Tue Mar 14 2000 - 02:59:04 EST


On 13 Mar 00 at 12:13, James A Simmons wrote:
> > > > 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'm going to now that 2.4.X is coming out. I'm going to work on the new
> API at the linuxconsole project. This time we will be ready as soon as
> 2.5.0 is out. Also the code well be well test and somewhat stable when it
> will be time to intergrate it into 2.5.0.
So we agree that 2.3.51 fbcon/fbmem patches will be backed out?
> > 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.
> Think mulithead. You are VT 1 which is mapped to your workstations.
> Someone else is on another real seperate head. In a office situation you
> could have a machine in one room with monitor and keyboard extension
> cables running into seperate office. You shouldn't be able to VT switch to
> the second head. Especially if someone is using it in another office down
For multihead you have one more mapping. Currently you have only
con2fb. For multihead you'll also have per-keyboard ALT-Fx -> global
system VT number mapping. So that on keyboard #2 ALT-F1 selects
VT274 and not VT1... Except VT-up/VT-down (ALT-LARROW/ALT-RARROW) you
can do it even now through keyboard mappings, if you make them per-keyboard
(and you should; at least per keyboard, per-VT is better).
It is all about policy. I'm root and I want to take over my coworker
console because of he forgot to drink cofee and is now typing only
bugs instead of code... Why kernel should prevent me from doing that?
> > 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.
> I like to see VT features moved from fbdev to the console system.
> It doesn't matter now. 2.4.X is coming out and I'm already looking to
> develope a branch to merge with 2.5.0 when it comes out.
Moving VT feature from fbdev is not same as removing 'if (con == currcon)'
from fbdev source, silently expecting that con == currcon. You have
to ensure that fbcon will not call fbdev with con != currcon...
> > We have working system. Migrating to your changes moves system to nonworking
> > state. Sorry.
> Things do break in development branches. Mostly for good reasons. Well now
> that its 2.4.0 these changes can't happen its to late in the ball game.
> Next branch it will. This will give people time to adjust their code.
If it happens for good reason, then why not. I do not know whether
current in-kernel vfb.c does same thing as your vfb.c, but size of output
from preprocessor says, that your code is bigger...
> > 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 soluion. Maybe I'm too tied to
> > database systems, but if you have duplicated information, you cannot
> > have it right.
> For a bunch of VTs (pool) only one VT is active. Well thats the way it
> should be. You can think of it as a console context switch. On a context
> switch you save the current state and restore another state.
And why saving/restoring state should copy data?
> > 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.
> No. If you set the colormap via fbdev its sets the colormap of the current
> terminal. Use VT ioctl to change colormap of another terminal not fbdev.
> I don't ask to copy data in this case. Copying data around happens only on
> VT switch. Please read what I stated in vfb.c very carefully.
Then it is change of userspace semantic... And it should be discussed also
with application programmers.
> > Yes. So add wrappers into fbcon - and if you prove that you must change
> > fbdev interface, lets go.
> Yet more code added instead of removed :(
You can remove this code from fbdev then. Look at every function in
every fbdev. It each start with
if (con == currcon) {
    /* do real work */
} else {
    /* do some work more or less copied from another driver
       and if someone fixed/changed it in one driver, other
       are left intouch... */
}
> > 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.
> You want VT mode info for a non active VT use the ioctl in vt.c to
> get this info. Look at the vt.c for ioctl avaliable now.
I do not see which currently available ioctl allows me to get/set
underlying fbdev informations.
> NO MORE ARUGING!!! I think I have made my point.
Well.
                                        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:26 EST