Re: Supporting multiple keyboard

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

> If you plug in a PS/2 keyboard (and the i8042 kbd port is active,
> there is going to be some changes to better support hot-plugging PS/2
> keyboards and mice) then the atkbd.c module initializes it and registers
> it with the input subsystem. evdev.c gets offered the input device, and
> accepts it, because it accepts any input device. It creates
> /dev/input/event0. keyboard.c doesn't get offered the device, because
> it's not compiled in when ve don't have VT's.

I understand it now. What I was wondering was is thier a switch between
data goingt to eventX or to the VT for the keyboard. If someone opens a
eventX that is a keybaord and belongs to a VT will the data automaticallly
flow to eventX instead of the console system.

> >   I'm using struct vt_struct to represent each physical VT (a display and
> > a physical keyboard).
> 
> Btw, can this approach handle two displays with one keyboard?

I'm going to take heat for this but no. The reason being is linus is a
strict about what things are defined as. Evstack attempted to bend the
rules to what a tty was with multi keyboards and multiple displays. Linus
did not like it. What will be accepted is a tty is one display and one
keyboard. It also makes the design much simpler. Now I would like to see
such features as well. So it accomplish this we need to make userland
flexiable to be able to do this.

> Maybe it'd be better to use struct input_handle *handle as the keyboard
> identifier in the vt_struct.

Okay.

> Searching is not nice. A better way would be to set up the handle->private
> pointer to point to the VT struct - this way you don't have to search
> for anything.

We might have to do this. 

> Well, it needs to be rethought what's is going to be in struct
> vt_struct, struct kbd_struct and others and where we can have what
> pointers to avoid searching. I think almost all searching could be
> avoided except when adding/removing VTs, consoles, keyboars, mice.

I have nearly done this. The old fly in the onitment is the way the
keyboard talks to the tty layer. I have right now:

struct tty_struct #1 -> struct vc_data -----|
					    |	
struct tty_struct #2 -> struct vc_data --------------> struct vt_struct
					    |	
struct tty_struct #3 -> struct vc_data -----|

> By the way, does console switching work for you in the last version on
> vgacon?

I haven't tried it. I have to make a second tree to test what we have now. 
I have the next generation of code in my tree right now.