[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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,


Reply to: