Re: Bug#82976: pmud 0.7-3 (powerpc)
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
Reply to: