Matthias Drochner wrote:

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

Yes, that's a point.  And it's easy to do with the wsmux, just put
all events into one mux.  But I'll leave it to someone else to
rewrite the X server.


> (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".)

Well, ``wsmux'' at least indicates that it is something to do
with wscons.  Do you have a better name in mind?


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

There is no extra complexity really, maybe 5 or 10 lines.


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

If I boot with a USB keyboard connected I want it to work
even in single user mode.  I really don't think ``mux'' is such
an ugly locator.  It's in the same category as ``console''.


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

That's quite possible.  And then I guess the you can do it
the same way as today.  The code that deals with different
kinds of serial mice is really hairy and I'd rather leave it
out of the kernel.

--

        -- Lennart