Lennart Augustsson <lennart@augustsson.net> writes:

> First change:

> Ever since the wsmux device was added each wsdisplay has had a wsmux
> to which all its associated keyboards attach.  The mux was
> anonymous, but with this change it can also be one of the regular
> wsmuxes.  A good pick is wsmux1, which is where all keyboards
> normally send their events.  The result of this is that no wsconscfg
> command needs to be issued to connect the non-console keyboards to
> the wsdisplay, i.e., they will work even in single user mode.  To
> select which mux to use the wsdisplay device has a new locator,
> kbdmux, which identifies it.  Using kbdmux=-1 will give the old
> behaviour.

Okay, this associates non-console keyboards with a mux attached to the
default display. What about console keyboards? I tried this on by
iBook, and got:

wsdisplay0 at ofb0 kbdmux 1: console (std, vt100 emulation)
...
akbd0 at adb0 addr 2: PowerBook G3 keyboard
wskbd0 at akbd0 (mux 1 ignored for console): console keyboard, using wsdisplay0
ams0 at adb0 addr 3: EMP trackpad <tpad> 2-button, 400 dpi
wsmouse0 at ams0 mux 0

Is the console keyboard not associated with a mux at all? The problem
I'd like to deal with is that of X on a machine without virtual
consoles, like the Mac. I had hoped that with this change, all the
keyboards would go to wsmux1, the X server could take over wsmux1, and
I would be able to use both the console and secondary keyboards in X.

> 
> Second change:

> Before keyboards and mice that were connected to a mux could not be
> opened; they were regarded as busy.  With this change the opened
> keyboard or mouse will be disconnected from the mux and the open
> will succeed.  This means that it is harmless to have devices send
> their events to a mux as the default setup.  Right now there is no
> userland program (but the ioctl()s exist) to reconnect a device.

The flip side of this change seems to be that if the conole display
has the keyboard, the X server can't get it (it gets EBUSY opening
/dev/wskbd0, and the /dev/wskbd mux doesn't work due to the previous
issue).

> Comments?

It sounds like a step in a useful direction, though I'm never quite
sure that I understand how this stuff works.

Unfortunately, when I exited the X server (having discovered that it
had opened /dev/wskbd, which had no keyboards attached to it), I got a
panic "free: addr 0x0 not within kmem_map". The ddb traceback was:

panic + 158
free + 64
wsevent_fini + 14
wskbddoclose + 38
wsmuxdoclose + 70
wsmuxclose + 30
spec_close + 1a8
ufsspec_close + 190
VOP_CLOSE + 40
vn_close + 60
vn_closefile + 20
closef + 204
fdfree + 88
exit1 + d0
sys_exit + 14
trap + 5c4

        - Nathan