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