Jason Thorpe wrote:

> [ I'll apologize now if I'm a little sharp in this message, because I am
>   utterly frustrated that my Alpha kernels now longer build due to wsmux
>   lossage, while I'm in the middle of tracking down a UVM bug... of course
>   I had to update my source tree to get a couple of different fixes, sigh ]

Could you tell me what your configuration is?  It might be some
combination of ws* that I've not tested.


>         (1) wsdisplay requires wsmux to function.  I wouldn't care about
>             this so much except for wsmux is a needs-count device (which
>             it should not be, IMO; the softcs themselves are dynamically
>             allocated, so the wsmuxdevs[] array should be as well, growing
>             as necessary as new wsmuxdevs are opened).

I've just fixed this problem.  I'll commit it as soon as I've tested it.
I didn't realize that the needs-count would force a needs-count on wsdisplay
as well.


>         (2) The console keyboard can't be added to the mux.  This makes
>             me scratch my head and wonder "What was the point?!"  The
>             most common usage for this that I can see is the following:
>
>                 * Laptop user running X (on console keyboard, obviously)
>                   goes into office, plus in nice, full-size USB keyboard,
>                   continues to use X.
>
>                 * Laptop user unplugs USB keyboards and leaves office,
>                   continues to use X.
>
>                 (I, in fact, know someone who falls into this category.)
>
>             Given that the console keyboard can't be added to the mux, this
>             won't work.  So, how is this useful for most people?

Every wsdisplay has an implicit mux, even if you don't have any other
muxes in the kernel.  This mux will get fed from the console keyboard
regardless of how you set up things.  I.e., the console keyboard is "glued"
to the display.  Any further keyboard can either be attached directly to
the wsdisplay (using wsconscfg -k N) or by first feeding them into
another mux (probably using the mux locator) which is then attached
to the wsdisplay (using wsconscfg -m N).

So your scenario works just fine, in fact that's how I use it.  You just plug
and unplug your USB keyboard at will.  It will work and so will the console
keyboard.



>         (3) Console display doesn't take input from a mux, but only from a
>             console keyboard.  It'd be nice if, when the mux device wasn't
>             open (i.e. X isn't running), that console events could come
>             from the laptop keyboard or the USB keyboard plugged into the
>             laptop.

See above.


>         (4) No apparent notion of "event focus".  For example, if you're
>             using something which uses keyboard events (i.e. X server on
>             non-i386 [XFree86's keyboard code is terrible in this regard]),
>             it looks like if you press <SHIFT-DOWN> on keyboard A, and
>             <G-DOWN> on keyboard B, your Xterm would get "G", whereas it
>             should get "g", because the <SHIFT-DOWN> event's source was not
>             the same as the <G-DOWN> event's source.

Well, that can be debated.  Right now all keyboard are connected in
parallel and key presses on one is equivalent to key presses on another.
If you want to do something fancier I guess the wsevent structure
needs more information so you can see where the event came from.
I've considered this, but it's not there.


--

        -- Lennart