wskbd and wsmouse do very similar things, at least from the viewpoint
of an X server. So it surely makes things easier if all kind of
"input events" comes from one device.
One possibility where it would be better to keep mouse and keyboard
stuff seperate: It would be possible to shortcut mouse events
into cursor motion within the kernel eventually. The X server
still would have to be notified, but at least the mouse would
look better. I don't know yet whether this is really practical.

(I wouldn't call it "mux" however - this is too much namespace
pollution, all kinds of things can be multiplexed. I'd prefer
something what looks like "console events" or something like
"workstation".)

What is the benefit of allowing to chain multiplexers?
If only event streams are funneled into one stream, then
a single node has the same effect. I'd avoid needless
complexity if possible.

The locator for the mux to choose is ugly, as was already said.
I'd say we don't need it. If it is for dynamically added
devices, then I'd prefer a user level daemon which deals
with this. Other devices, network adapters come to mind,
need userlevel configuration anyway, so it might be
useful to have a "configuration manager" which is invoked
everytime a device is added or removed.

For the serial mice: What's better, a daemon or a
line discipline dealing with the mouse protocol.
Mice already tend to be "jumpy" under system load, so the
daemon might require too many context switches.


just some quick notes... I have to leave for the weekend now.

best regards
Matthias