Subject: wsmux problems
To: None <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 07/30/1999 13:27:18
[ 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 ]
(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).
(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?
(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
(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.
-- Jason R. Thorpe <firstname.lastname@example.org>