Suspend-to-ram kills touchpad

[John O'Hagan <johnohagan@iprimus.com.au>]

Hi all,

I've made some progress on this; I'm running Sarge with a lot of Etch
upgrades on a "whitebox" (unbranded) laptop with a 855GM chipset. Since
kernel 2.6.12, suspend-to-disk (S4) has worked well, simply using the KDE
klaptop applet.

However, suspend-to-ram (S3), which I think most laptop users find very
useful, has proved more difficult. If I simply use the KDE applet, the system
resumes with a blank screen - a common problem with this chipset. I can get
around it using vbetool, which reinitialises the graphics device (there is a
handy packaged script called hibernate which walks you through this);
however, the touchpad does not work on resume. Occasionally, neither does the
keyboard.

Some digging has revealed that somehow the entries in /proc/bus/input have
been shuffled around on resuming, so that the device node once used by the
touchpad (/dev/input/event1) is now handled by the pc-speaker, or the
(non-exitent) joystick! Leaving the touchpad out in the cold...regardless of
which touchpad driver I use.

So, my questions are: why does S3 suspend (and not S4) shuffle the devices
around, and how can it be prevented? For example, is there a way of ensuring
that the touchpad is always /dev/input/event1? Is udev involved? Or is there
a better solution?

Thanks,

John O'Hagan

P.S. please CC me