S3 Suspend input devices problem with 2.6.12

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

Hi all,

I've been trying to figure out if this is a kernel related problem...the folks 
on other lists are divided, so I guess I'll just ask & hope:
 
I'm running Debian testing on a "whitebox" (unbranded) Centrino 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 or the 
regular command, 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. 
Lately, as I have fiddled with the hibernate settings,  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-existent) joystick, or is absent altogether! Leaving the touchpad out in 
the cold...regardless of which touchpad driver I use. Reloading the relevant 
modules - or even all modules - has no effect.

So, my questions are: why does S3 suspend (and not S4) shuffle the devices 
around, and how can it be prevented? I notice that the keyboard and touchpad 
are initialized early in the boot process. Is udev involved? Or is there a 
better solution?

Thanks,

John O'Hagan

P.S. please CC me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/