Subject: Multiple keyboards and mice
To: None <tech-kern@netbsd.org>
From: Lennart Augustsson <lennart@augustsson.net>
List: tech-kern
Date: 05/26/1999 22:57:13
I've been thinking on and off on how to handle multiple keyboards
and mice in NetBSD to make it both versatile and simple to use.

I've not come up with any definite answer but here are some thoughts.
Let's look at keyboards first.

It should be possible to have multiple keyboards connected to the
same display (forming a "console").  Furthermore the keyboards
can be added and removed while the system is up (consider adding
a USB keyboard to a laptop while it is stationary).  I don't find
it acceptable if any deamon has to be running for this to work
since we might be in single user mode (the usbd deamon is going
to go away!) and no user commands should be required.
So we need some way to tell keyboards where they belong.  This can
be handled by a locator on the wskbd device, so in the config
file we might have
  wskbd0 at pckbd? display 0
  wskbd* at ukbd? display 0
which would tell the kernel to glue these keyboards to display 0.
If you leave out the display locator the wskbd will remain unglued.

This way any new USB keyboard will get glued to the display (#0).
The internal API between wsdisplay and wskbd would have to be changed
so that the keyboard can take the initiative to glue/unglue itself
to a display (since it is the keyboard driver that knows when the
keyboard is attached and detached).

The keyboard multiplexor (in wsdisplay) would just merge the events
from all the keyboards and fan out commands for the LEDs to all of
them.  Just multiplexing the events could cause funny event sequences,
e.g. two release events for the same key after each other, but I
assume Xfree doesn't get too confused by that.


OK, let's move on to mice.  We would like to be able to plug and
unplug mice as well as keyboard.  This could be handled entirely
inside the X server.  The X server would have to be notified when
a mouse is attached or detached so it can open/close the right
device node for it.  This can be done, but would require some
work in the X server (and in the kernel too).

An alternative would be to use similar code as for merging keyboard
events to merge mouse events.  We could then have a special virtual
mouse device which the real mouse send their events to.  This virtual
mouse should also be accessible from userland to inject events into,
that way we could have a /dev/mouse that would work for all mice.
Serial mice would inject their events into it via moused, a userland
program (which we can borrow from FreeBSD).
A locator on the wsmouse device would tell the mouse where to
send its events.

An extension of this idea is to make the event merger into its own
device, a multiplexor device.  Input to this multiplexor could come
from either mice or keyboard (or both).  A mux device could then
serve a /dev/mouse and another mux device could send events to
the display.  A locator would be used to tell the device which
mux to use.

To sum up, I've proposed three alternatives:

   1) Merge keyboard events in wsdisplay.  Merge mouse events in the
      X server.

   2) Merge keyboard events in wsdisplay.  Merge mouse events in kernel;

      in a virtual mouse driver.

   3) Make a mux device that handles merging, use it for both keyboard
      and mouse events.  (I've mostly implemented this and I'm using
      it for my mice.)

I'm sure there are more options.  What do you think?


--

        -- Lennart