Re: Frozen touchpad after resume
Ritesh Raj Sarraf wrote:
> John O'Hagan wrote:
>>[....] I suspect that the root of the problem is the process by which
> > the devices in /dev/input are recreated (by udev, I guess?) after a
> > suspend-to-ram; this is still a mystery to me, but I have a few leads.
>
> AFAIK, module loading/unloading isn't related to PID at all. Hence I don't
> think udev should be the problem. What does confuse me is that if it really
> has to be unloaded then how does it allow on my notebook.
What does PID mean (in this context)?
Yes, I share your confusion: similarly, I find it strange that the keyboard,
for example, which uses /dev/iput/event0, is unaffected by a suspend, but the
touchpad, which I would have thought only differs by a digit, behaves so
differently. On your notebook, do any changes occur in your /dev device files
during a suspend?
>[...] From your first post, I presume your hardware is very identical to
>mine. You can double check it at the documentation at my website.
They are very similar; some of your subsystems are branded Hewlett-Packard
where mine are "First International", and some memory addresses vary a
little; but all the power management references are identical. One question;
which hardware item refers to the touchpad?
> [...] When the kernel loads the acpi subsystem it will tell you what modes
>your hardware supports. You can find it in your`dmesg`.
>Also /sys/power/state can tell you what modes are supported.
Thanks! The modes are S0, S3, S4 and S5, so it should be possible.
There is no mention of power management in the BIOS, which is a Phoenix one.
From reading my X log after a resume, I learn that the graphics device is
actually re-initialized, rather than restored, presumably by vbe-tool
(without that the screen remains blank); perhaps something similar needs to
happen to the touchpad: the log also says that the touchpad could not be
found and that there is no such device as /dev/input/event1.
Thanks again for your advice,
John
Reply to: