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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
