Re: Supporting multiple keyboard

[James S. <jsi...@ac...>]

> 3) Ruby way for AT keyboards:
> 
> i8042.c -(raw)-> atkbd.c -(events)-> input.c -->
> >--(events)-> keyboard.c -(chars)-> tty
> 
> 4) Ruby way for USB keyboards:
> 
> usb.c -(usb)-> hid.c -(events)-> input.c -->
> >--(events)-> keyboard.c -(chars)-> tty

> keyboard.c, now, is a translator from events (which are compatible across
> all architectures and all input device types) to characters for the TTY.

Much cleaner :) So keybdev.c is basically outdated now. I was
confussed in its purpose. Actually I though you where using it to create a
future /dev/kbd like you have a /dv/mouse now. 

> keyboard.c doesn't receive any raw scancodes, however, unfortunately, the
> tty layer has three modes - Cooked, MediumRaw, and Raw. 

   I have noticed those modes :( Hacks for "graphics" programs. These apps
don't want a text console so they first set the console to KD_GRAPHICS to
disable most of the console system. Then they set the keyboard to raw mode
to stop the keyboard data from being cooked by the console layer. Since
the keyboard data is cooked the console doesn't know how to VT switch.
Then the app has to use a userland api to VT switch.  
   What should be done? Have the system go from console to graphics mode.
In graphics mode the application access the raw hardware devices via
/dev/fb and /dev/input or /dev/event. This disables the console system.
Once the devices are done and they close the console system is restored. 

   I have talked to Geert about changing the behavior of VT switching
anyways. Having the kernel totally manage the VT switch instead of having
userland using some ioctl api to handle it. A big reason is when a
userland app can access these raw devices and they ignore the VT switching
api then can see the hardware's data. So if you open /dev/fb and mmap the
vidoe memory then VT switch. What you type on that text console will be
present in the framebuffers memory that another process can see. Big
security hole.

> Cooked mode is OK, it goes through a keymap. Event numbers can be used
> in the keymap. This has a nice effect that keymaps will be architecture
> independent, too. 

This is really nice :) This makes support for different emulations much
easier. Will loadkeys have to be updated? 

> MediumRaw is seldomly used - and is event numbers again. 

Do you think we can get ride of it? I vote to get ride of it.

> Raw is used namely by XFree and SVGAlib - and because keyboard.c doesn't
> get rawmode data, it has to emulate it. The emulation has to be done
> somewhere, and best done closest to the app.

See above. This means patches will have to be made for XFree86. 

Thank you for the clarification. Actually I have anothe question for
you but this email has become to long so I will post another message. The
next question is what is difference between /dev/input and /dev/event?

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net