On Mon, 13 Mar 2000, Petr Vandrovec wrote:
> 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'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.
> 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
the hall. If you do then will you feel like running into another office
when you VT switch to a display thats not in front of you. So you have to
add another layer of checking. If each head had its own seperate VT pool
you don't need to work about migrating to another head. No eaxtra layer of
checking. No need to run to another head, especially if its in a
seperate room. Also if one head is vgacon and another head is fbcon
this is okay. They are seperate vidoe cards.
> 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.
> Then alloc con2fb_map by kmalloc. Or use pointer in vc_cons and do
> if (vc_cons[i]->fb_info != info) return -EXDEV;
Yuk!!!
> 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.
> 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.
> > 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?
Because /dev/fb is NOT /dev/tty.
> 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.
> 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 :(
> 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.
That is full of crap and you know it. Well all I have to say is thsi API
will be in the devleopement branch and people can see for themselves how
much easier it will be.
> Please face to it. We have FBIOGET_VSCREENINFO. FBIOGET_VSCREENINFO is
> VT aware.
For now. No reason for it be that way.
> 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.
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.
NO MORE ARUGING!!! I think I have made my point.
-
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:25 EST