On 29 Jul 1998, Chris G. Demetriou wrote:
> Keyboards may be Hard.
> 
> X still likes getting raw key data (scan codes), right?  What happens
> if you have two keyboards, which have different scan codes (or the
> equivalent)?  You can't easily mux those things, because then X (or
> any application that wants raw, uninterpreted data) needs to know how
> to demux them.
> 
> Similarly, what if you try to mux a relative-motion mouse and an
> absolute-position device that presents itself as a "mouse-like"
> device?

You write a userland process that opens the relevant devices, gets the raw
scan codes, frobs them in some clever way, and pumps the frobbed codes
back into the kernel through some loopback interfaces (along similar lines
to the tun* network interfaces).  Then you tell your X server to open
loopbackmouse0 and loopbackkeyboard0, from which it receives stuff that it
thinks are raw scan codes from a single real mouse and keyboard.  (I
believe that FreeBSD's "moused" does something similar to this, including
converting mouse scan codes from one protocol to another, but for only one
mouse at a time.) 

> In general, I think the only sane way to handle this is to have the
> ultimate consumer of the data be responsible for interpreting and
> combining separate input streams.  I.e., I still think that putting
> the machinery into X is the right way to go.

I think that there's a scaling problem with this approach.  You have to
put the (possibly complicated) multiplexing code in every consumer of data
(and the X server might not be the only one of these). 

--apb (Alan Barrett)