9.1: no wsmouse events...sometimes.

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

I'm working on a turnkey product under 9.1.  Among other things, it
uses X for output and for keyboard input, but reads mouse input events
semi-directly (mostly because it wants deltas, whereas X insists on
integrating deltas into absolute locations, then clipping those
locations to the screen limits).

In order to make this work, the kernel config specifies "mux 2" for all
mouse attachments.  The X server then uses muxes 0 and 1 as usual for
the mouse and keyboard, but no real mice ever feed events to either
(because mice always attach using "mux 2").  The application then opens
/dev/wsmux2 to get mouse input events.

When I test this on a general-purpose kernel running a multi-user
system, on the dev machine, it all works fine.  I start the
application, it puts up its UI, and mouse input works.

But the application is a turnkey system.  In normal production
operation, the application is /sbin/init and it forks the X server
itself.  Everything works fine, except mouse input - it never receives
any input events.  Never, that is, until I unplug and replug the (USB)
mouse, at which point it starts to work.

This baffles me.  It is possible to capture /kern/msgbuf through the
application; based on that, I can see that (in a test run I just did)
the mouse attached at boot time as

[   3.5523123] uhidev0 at uhub1 port 1 configuration 1 interface 0
[   3.5523123] uhidev0: vendor 0000 (0000) USB OPTICAL MOUSE (0x538), rev 1.10/1.00, addr 1, iclass 3/1
[   3.5543123] uhidev0: 1 report ids
[   3.5543123] ums0 at uhidev0 reportid 1: 3 buttons and Z dir
[   3.5543123] wsmouse0 at ums0 mux 2

This version didn't work.  When I unplug and replug the mouse, the
tracks left in /kern/msgbuf read

[  26.0064375] wsmouse0: detached
[  26.0064375] ums0: detached
[  26.0064375] uhidev0: detached
[  26.0064375] uhidev0: at uhub1 port 1 (addr 1) disconnected
[  29.3614375] uhidev0 at uhub1 port 1 configuration 1 interface 0
[  29.3614375] uhidev0: vendor 0000 (0000) USB OPTICAL MOUSE (0x538), rev 1.10/1.00, addr 3, iclass 3/1
[  29.3634375] uhidev0: 1 report ids
[  29.3634375] ums0 at uhidev0 reportid 1: 3 buttons and Z dir
[  29.3634375] wsmouse0 at ums0 mux 2
[  29.3644375] wsmouse0: detached
[  29.3644375] ums0: detached
[  29.3644375] uhidev0: detached
[  29.3644375] uhidev0: at uhub1 port 1 (addr 3) disconnected
[  30.2314375] uhidev0 at uhub1 port 1 configuration 1 interface 0
[  30.2314375] uhidev0: vendor 0000 (0000) USB OPTICAL MOUSE (0x538), rev 1.10/1.00, addr 4, iclass 3/1
[  30.2334376] uhidev0: 1 report ids
[  30.2334376] ums0 at uhidev0 reportid 1: 3 buttons and Z dir
[  30.2334376] wsmouse0 at ums0 mux 2

and the mouse starts to work.  (The application is not restarted and
continues using the same fd, opened at startup, on /dev/wsmux2.)

What's baffling me is, I am having trouble seeing why.  I'm writing to
ask if anyone has any thoughts on why the boot-time attachment doesn't
work but the later (re)attachment does.  The only thing I can think of
is the time delay between the X server starting and the application
opening /dev/wsmux2.  In a development run, this time is relatively
long (multiple seconds minimum, possibly minutes).  In a production
run, this time is relatively short (typically less than a second from
the time the X server starts accepting connections to the time the
application opens /dev/wsmux2).  But I have trouble seeing why that
would make any difference, especially since the X server doesn't use
/dev/wsmux2 (that's why I have mice attaching with "mux 2", so the
application, rather than the X server, will get their events).  If the
application were reopening /dev/wsmux2, that might make some sense to
me, but it's not.  It's not that PID 1 is special, either, because the
process that opens and reads from /dev/wsmux2 is a forked child, not
the main PID-1 process.

I can of course provide more information if anyone can tell me what
information is relevant.

I will be trying to chase this down with various debugging techniques,
but I expect that to be a slow slog; even a pointer as vague as "I
suspect it may be related to <thing>" would be appreciated.

Any thoughts anyone would care to share would be most welcome.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B