linuxconsole-dev

Supporting multiple keyboard

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

y
   I have completed most of the changes needed to make the console system
not depend on currcon. I also seperated the VT emulation code from vt.c.
Also console_macro is almost gone :) Now for some problem I came across.
  
   First and less important problem is blanking the screen. How do tell
which screen is the one we want blank? Any ideas anyone? I had a chessy
hack right now but when true multihead comes into play we need to find a
right solution. 
  
   To get multihead working I need support for multiple keyboards to the
console system. I need to be able to tell which keyboard is doing the VT
switching. Vojtech while looking threw your code I noticed you have a
keybdev.c in the input directory which has code that is in keyboard.c.
Also you don't have it enabled. What I was thinking is have keybdev.c as
the raw keyboard driver. This way when a user uses /dev/input we can send
raw packets their. Otherwise it send the packets to the console system.
This way keyboard.c becomes more of a translator from raw keyboard mode to 
a tty keyboard. A first move might be to move the keybaord tasklet into  
keybdev.c. What do you think Vojtech? 

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

Re: Supporting multiple keyboard

[Vojtech P. <vo...@su...>]

On Wed, Jun 07, 2000 at 10:46:33AM -0400, James Simmons wrote:

> Vojtech while looking threw your code I noticed you have a
> keybdev.c in the input directory which has code that is in keyboard.c.
> Also you don't have it enabled. What I was thinking is have keybdev.c as
> the raw keyboard driver. This way when a user uses /dev/input we can send
> raw packets their. Otherwise it send the packets to the console system.
> This way keyboard.c becomes more of a translator from raw keyboard mode to 
> a tty keyboard. A first move might be to move the keybaord tasklet into  
> keybdev.c. What do you think Vojtech? 

No. It works a little differently:

1) Current 2.4 way for AT keyboards:

pc_keyb.c -(raw)-> keyboard.c -(raw)-> pc_keyb.c -->
>--(cooked)-> keyboard.c -(chars)-> tty

2) Current 2.4 way for USB keyboards (uses keybdev):

usb.c -(usb)-> hid.c -(events)-> input.c -(events)-> keybdev.c -->
>--(raw)-> keyboard.c -(raw)-> pc_keyb.c -(cooked)-> keyboard.c -->
>--(chars)-> tty

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

Basically keybdev.c is a module that takes input events, and emulates an AT
keyboard, passing appropriate raw mode bytes to the original AT keyboard
driver. This was the easiest way how to connect USB keyboards. But it's far
from clean. There is no reason to converts the AT scancodes from, to and
from raw again.

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

keyboard.c doesn't receive any raw scancodes, however, unfortunately, the
tty layer has three modes - Cooked, MediumRaw, and Raw. 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. MediumRaw
is seldomly used - and is event numbers again. 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.

So, what I see keyboard.c should be doing:
	* receiving events
	* generating a tty keyboard using keymaps
	* generating medraw/raw mode for apps that use that

Perhaps I mean the same as you originally did - it's just that the rawmode
driver is atkbd.c and not keybdev.c.

-- 
Vojtech Pavlik
SuSE Labs

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

Re: Supporting multiple keyboard

[Vojtech P. <vo...@su...>]

On Wed, Jun 07, 2000 at 09:13:01PM -0400, James Simmons wrote:

> 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?

None. Actually the correct name for the devices is:

/dev/input/event0
/dev/input/event1
/dev/input/event2
/dev/input/event3

and so on. Input being the subdirectory in /dev for the eventX, mouseX
and jsX devices.

-- 
Vojtech Pavlik
SuSE Labs