3

I have a dirty solution that is to plug a USB keyboard in and execute the following command:

setxkbmap -rules evdev -layout us -model evdev

Afterward my keyboard will work.

This solution only works if I have a usb keyboard handy which is seldom the case and I am forced to reboot my laptop. I have tried to have the command auto execute when the system wakes by adding:

set -e

if [ "${1}" = "resume" ] && [ "${2}" != "standby" ]; then
        setxkbmap -rules evdev -layout us -model evdev
fi
exit 0

to: /etc/apm/event.d/enable_xkb But this does not work. I am guessing because it is not run by the appropriate user.

So there are two possible answers to this question: 1) How do I get the above script to execute after my system wakes up. If I can get this to work I can simply put my computer to sleep and wake it back up and have the keyboard working again. 2) (preferred) How do I actually fix this probelem.

More details about situation that my be needed to answer 2) Due to the randomness of this problem I do not know when this issue first started. I do know that it exists on Debian Unstable, and Testing but not Stable. It also exists on curret Arch linux but not before November 2012. My system is a Lenovo w520.

Also note: This is a bit of a heisenbug, as such I would not be able to accept a response until it has worked for a few days.

Further clarification: When this happens I am unable to switch to any of the tty#s so no console does not work. I have also tried the "Raising Skinny Elephants is Utterly Boring" combo and this does not work either... After I post I will check if this works when my keyboard is functional. It is very random, sometimes it will be fine for a couple days and bam my keyboard doesn't work.

Gilles 'SO- stop being evil'
  • 829,060
kporter
  • 131
  • CRON-job it, bro. Simply export DISPLAY=:0 and run your command above. Run it once every second if you'd like, or even once every 15 to 30 seconds. – Naftuli Kay Apr 05 '13 at 00:26

1 Answers1

2

The reason your script doesn't work from the resume hook is that it doesn't know which X server to talk to. You need to set the DISPLAY environment variable, and perhaps XAUTHORITY as well. See Can I launch a graphical program on another user's desktop as root? for more explanations.

Here's a shell snippet that runs the desired command on all active displays.

if [ "${1}" = "resume" ] && [ "${2}" != "standby" ]; then
  for p in $(ps -C Xorg -o pid=); do
    </proc/$p/cmdline awk -v RS='\0' '/^:[0-9]$/ {print} $0=="-auth" {getline; print}' | {
        read DISPLAY; export DISPLAY
        read XAUTHORITY && export XAUTHORITY || unset XAUTHORITY
        setxkbmap -rules evdev -layout us -model evdev
     }
  done
fi
Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060
  • Thanks, I hope this works... I actually haven't had the issue in a couple days since I updated to the latest kernel. But it wouldn't be the first time the problem came back after a few days. If it happens again and this works I will accept. If it doesn't happen in about a week, I will accept on faith :). – kporter Apr 10 '13 at 05:40
  • Well, it seems it didn't work... The issue happened again and I couldn't recover the keyboard.... It may be that your script is correct but /etc/apm/event.d/enable_xkb isn't being called when I close the lid. I will look into it some more. – kporter Apr 17 '13 at 00:43
  • I now have a solution that definitely calls the script upon resuming... So it appears I was reading some stale documentation for my original hook. – kporter Apr 17 '13 at 02:05
  • Well the above script is being executed each time I resume but it doesn't fix the issue. I know if I plug a usb keyboard and execute setxkbmap -rules evdev -layout us -model evdev It will fix the issue. – kporter Apr 22 '13 at 00:20