Subject: Re: wsmux changes
To: Nathan J. Williams <nathanw@MIT.EDU>
From: Lennart Augustsson <lennart@augustsson.net>
List: tech-kern
Date: 10/14/2001 01:40:49
Well, I my intention is that it should work on macs with X as well.
I have an iMac to test on now (well, I'm away from it for a while)
so it will work eventually.  But I think it requires a few more changes.

    -- Lennart




"Nathan J. Williams" wrote:

> 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