Comment 100 for bug 59867

@Surak: I believe you are correct for the most part, but the difference here between suspend to RAM and suspend to disk is that in suspend to disk the hardware is physically shut off, versus put to sleep in suspend to RAM. The power is not off in suspend to RAM, some devices are powered off, but most devices are powered low or suspended until resume (note: no hardware power down so state registers may be preserved). I do agree that a reset of the hardware should fix the problem, but all the methods of software device reset known have been tried and still fail. I do agree it is possible to resolve this issue somehow, since it works in other non-linux OSs. I suspect there is a resume command that needs to be sent to the PS/2 port chip once the OS is loaded to repower the chip before the OS GUI is up for those that the touchpad reset doesn't solve (like mine). I am not certain, but I think there are possible three different problems happening here on this bug.
1) The touch pad needs a reset command and comes back up (most devices this works)
2) The PS/2 port chip is still off during resume and needs a resume command (possibly my case) which may not need a touchpad reset if the touchpad was power off. Touchpad reset does nothing in this case, however a suspend and resume fixes it because state registers are changed.
3) The touchpad needs a suspend command and doesn't receive one, so when the system goes into suspend it is left hanging. (maybe my case)
I am by no means a hardware excpert, but I work with low-level hardware involvement daily and write software to make the hardware work and this is what I think I am seeing.