>> In particular, I note that [the "broken" boot attaches devices in a >> different order from the "working" boot] > This is not it. [...]
This morning I finally tracked this down. It was something entirely unexpected, at least to me. I had somehow (a) failed to install /dev/wsmouse when setting up the standalone system's /dev and (b) failed to notice that fact despite repeated checks on what was in the standalone /dev. /dev/wsmouse is normally an alias for /dev/wsmux0 (as in, they have the same major/minor numbers). The X server normally opens /dev/wsmouse, aka /dev/wsmux0, and reads events from there. But, as it turns out, if /dev/wsmouse doesn't exist (and probably if it exists but can't be opened, though I didn't test that), the X server tries /dev/wsmouse0 instead - and I _did_ install /dev/wsmouse0. This of course then takes the wsmouse instance away from its mux (mux2), giving events to the X server directly, rather than any mux. Unplugging and replugging leaves the X server with a now-useless fd open on the now-moribund former wsmouse0, with the new wsmouse instance feeding events to mux2 exactly as desired. I created /dev/wsmouse in the standalone /dev and it now works fine. My apologies for bothering everyone with something this sloppy and for raising doubts about a piece of the kernel that appears to be working perfectly well. /~\ 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
