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

	(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 <thorpej@nas.nasa.gov>