The input device saga continues... On Sat, 20 Jan 2001, Sergio Brandano wrote:
> the system uses > /dev/input/mouse0 as core-pointer, and > /dev/input/mouse1 as external USB pointer. This conflicts with the system boot messages below: mouse1 is tied to input0 which is the mouse button emulation code, mouse0 is tied to input3 which I assume is the trackpad device. I fail to see the USB mouse device show up at all, but it's probably there somewhere (otherwise we'd not get input3). Disclaimer: no kernel source was read in the preparation of this message. I'm quoting kernel features from memory here. On my system, mouse1 was button emulation if the input device code was used. I think mouse0 was the trackpad and mouse2 the USB mouse, but I've not used the input stuff without backing it up by the old ADB mouse driver in a while. > Both devices are active and working at boot time, infact: > > >input0: Macintosh mouse button emulation > >ADB mouse at 3, handler set to 4 (trackpad) > >mouse0: PS/2 mouse device for input3 > >mouse1: PS/2 mouse device for input0 > >mice: PS/2 mouse device common for all mice mouse1 corresponds to the emulation hook, mouse0 corresponds to whatever registered input3. input3 is most likely the last input device in the list, which becomes important in a second. > At wake-up, the core pointer is unable to move. > As root, I stop gdm, then restart it. XF4 is not > able to restart, and /var/log/XFree86.0.log > reports the following error: > > > (EE) xf86OpenSerial: Cannot open device /dev/input/mouse0 > > No such device. > > (EE) Mouse1: cannot open input device > > (EE) PreInit failed for input device "Mouse1" > > I believe pmud does not wake up /dev/mouse0. pmud does nothing at all to wake up devices (except in cases where broken hardware requires things like ethernet being stopped before sleep, and restarted after wakeup). Device sleep and wakeup is handled by the kernel. In this case, the kernel apparently fails to reinitialize the mouse emulation 'device' (since this one isn't a real device and needs neither sleep nor wakeup notify, or so the theory goes). Now here's where it gets entertaining: after wakeup, the three 'real' input devices re-registered with the input layer making input0-2. Conspicuously missing: our input3. (None of this is in the log so I rely on my own experience with this horrible input mess here.) What do we learn from this? The correspondence between devices and /dev/input nodes may change over sleep. It's dangerous to rely on a particular order of detected devices. For all I know, nothing in the kernel enforces a particular probe order at this time (for this you'd have to first enumerate all input devices present, determine some information about them, then register them in a well defined order to ensure mouse0 remains mouse0). This isn't a bug in itself. On something like ADB, probe order of multiple devices of the same type is inherently random (by design) and you cannot rely on getting the same device ordering each time. The correspondence between input nodes and mouse / keyboard device nodes apparently isn't changed (you can test all that by checking the output of cat /dev/input/mouse0 and so on to see what device it reponds to, both before and after sleep) Devices may even go missing like in this case (this one is a kernel bug but someone might just have unplugged the USB mouse which was input1 before wakeup and you'd get the same effect). Again, it's dangerous to assume a given device will remain at its particular node. > It does seem to wake up /dev/mouse1, as from the log. It does find a device attached to mouse1 which in turn is attached to input0 which may or may not be a mouse now (for all I can tell it may be a keyboard, or maybe your missing USB mouse). > When using /dev/input/mice I had no such problems. So? /dev/input/mice is the recommended interface anyway. Perhaps for the very reason described above. XFree86 can't cope with its core pointer moving around so make sure the core pointer is present at all times if you insist on not using /dev/input/mice (and I'd bet input0 and the corresponding mouse1 is a safe bet here). You can have multiple Core Pointer entries in your screen layout (the first working one will be used, others ignored). Just add mouse1 as another core pointer, plus add it as additional pointer. That should take care of the X restart problem. This isn't a pmud bug, rather a kernel issue. Talk to BenH about the sleep/wakeup notify stuff, maybe it just takes adding the mouse emulation code to the call chains. Or report this feature to linuxppc-dev or some input device related mailing list. pmud doesn't interact with the input device code at all so I'll close this bug or reassign it to the PPC kernel. Michael