> So we agree that 2.3.51 fbcon/fbmem patches will be backed out?
For the last patch yes. Their are to many brain dead programs out their
using the way current fbdev works.
> For multihead you have one more mapping. Currently you have only
> con2fb.
head0 -> bunch of VTs you can switch between (pool 1)
head1 -> bunch of VTs you can switch between. (pool 2)
You should not be able to go from pool one to pool 2.
> 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).
This was just being discussed on linuxconsole. I was told by the standards
you are REQUIRED to have keymaps per VC.
> 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?
Right.
> 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...
Thats a matter of patching fbcon.c to make sure.
> 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...
One I added modedb support. Two the default var and fix are __initdata so
thats deallocted after boot time :)
> > 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?
Because most low end video hardware can't save the current hardware state
in hardware :( Also if you don't save the state of the VT your switching
from you don't know what your state is when you switch back.
> > 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.
If you mean using the console ioctl calls. Well their are prpoblem with
it. In fact a patch will be posted very shortly here to fix many of the VT
emulation bugs. For 2.5.X the console system will be far more complanent
with VT standards.
> > > 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.
I don't have source in front of me. If this is the case then the console
system is broken. Console mode stuff should be done via VT ioctl calls. If
you want to find tune your console sthen fine open fbdev and change a few
things. This will change any VTs linked to this vidoe card. Every VT
benifiets.
> > NO MORE ARUGING!!! I think I have made my point.
> Well.
I reached the point where I don't care. Leave the system as it is. Its to
late to fix it anyways. But this time I learned my leason and I'm going to
start working on 2.5.X the minute 2.4.X is out. By the time 2.5.0 comes
out the code we will develope will be able to be dropped in and it will
be very stable. I was hoping to change fbdev enough so the latering of the
console code wouldn't effect every fbdev driver or every input driver.
Well this is not going to be the case. This means the CVS tree we have
will be big. Oh wells. But as I said I will be ready for 2.5.0 :)
"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:27 EST