Keyboard Doesn't Work After Resuming from Suspend to Ram
 

I hope someone has an answer as I've Googled this and can't seem to find anything specific to Slackware.
Last weekend, the video in my Compaq Presario 3240 died. I had ran Slack 12.1 & 12.2 successfully and both suspend to ram and suspend to disk worked just fine. I've since upgraded to a new HP Pavilion DV7-1130us laptop, running Slack 12.2 and the ATI 8.12 drivers. My remaining problem: the laptop suspends to ram just fine. However, on wakeup, the keyboard does not work. If I have my USB mouse plugged in; that works, but, the keyboard or the touchpad does not respond to any touch or keystrokes.
Any suggestions ?

Thanks

http://www.linux-laptop.net
There isn't a page yet for your model. There are dv6, dv8. etc. They do have (Remarkably familiar looking) discussion pages, and they used to have a mailing list (run from vger.kernel.org) but I'm probably just giving my age away here.

You could do worse than examine the power saving options in your kernel config. A rebuild there might sort it.

Thanks, Business Kid, that link could help.

However, I hope I may be onto something here. I tried a suspend to ram and resumed again. Same problem. But - in /var/log/kdm.log at the end I get this:

"The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning Duplicate shape name ""
Using last definition
- I get a series of these, followed by a series of -

> Error Section defined without a name
Definition ignored

- followed by a series of -

> Warning Multiple doodads named ""
Using first definition

- and finally, it ends with -

Errors from xkbcomp are not fatal to the X server.
(EE) Error compiling keymap (server-0)
(EE) XKB: couldn't compile keymap"

On to a Google search of resume + suspend + "couldn't compile keymap"

The XKB goose chase was no help....
....s2disk (and resume) works fine, however.

Still no clues on the the keyboard and resume from s2ram.

http://www.google.ie/search?q=%22War...ient=firefox-a

A search on the exact error message is more rewarding . . .

That particular error has to do with the Num Lock modifier in /etc/kde/kdm/kdmrc. I uncommented the appropriate line and changed it to "Keep". I no longer get the error in the log, but, it had (has) nothing to do with my keyboard problem on resume from the s2ram script ("echo -n mem > /sys/power/state"). I had hoped it was the problem and/or would lead me to the fix, but, it did not.
I do appreciate your looking, though. Other googles seems to reveal this is some sort of a bug in the various 2.6.27 flavors (and others), but, I've really found no solutions. I suppose what's left is to download, configure, and install a new kernel.....in the absence of other suggestions.

suggestions:

1. Post in the forums in linuxquestions and/or linux-laptop.net.

2. Rebuild your existing kernel with a careful look at the acpi options. This is much less pain as slackware provide the config as config-<version> in /boot

Rebuilding the stock kernel should be necessary, but no promises. Either way, I don't think that should be your first option.

Look at /var/log/pm-suspend.log and see if anything jumps out at you (feel free to post it here if you'd like). Have a look in /usr/doc/pm-utils-1.2.3/README.SLACKWARE for the debugging instructions, particularly the website links. If all else fails, ask on the pm-utils mailing list - the maintainer and several distribution packagers (including me) are active there.

Thanks for the advice, Robby. I visit your site frequently. I'm not all that familiar with pm-utils, but, I did look through the supplied documentation and the pm-suspend script before running it. I then ran pm-suspend and had the same results. I looked through the log (attached) afterwards, nothing is really jumping out at me.
If there's a module responsible for driving the keyboard; it would seem if there's an option to reload it coming out of suspend - that could take care of the problem (?).

There should be a /var/log/pm-suspend.log (not pm-powersave.log) - there will be a list of the modules in use written to that log file.

If you do see a particular module that might be causing a problem, then you can tell pm-utils to unload that module when suspending and then reload it on wakeup. To do so, you create an /etc/pm/config.d/default file with this content:
If you're interested in more about the format and such, and what else you can do with that file, see /usr/lib/pm-utils/default

I can't believe I posted the pm-powersave log ! I must be getting old. Here's the pm-suspend log.

Hrm, nothing stands out as important to me either :/
Something you might try: after resuming, log in to the box via ssh, and then try unloading/reloading various modules (start with usbhid & hid) to see if anything changes wrt the keyboard.
I looked through the -stable ChangeLogs at kernel.org, and I didn't see any patches addressing anything similar to this.
You'll probably want to go ahead and post a mail to the pm-utils list.