Ikke's Blog

Some time ago my ACPI-driven laptop keyboard buttons (volume control, music player controls,...) stopped working. I'm using the acpi-support package (although not running a Debian derivate) driven by acpid.
Today I decided I wanted my buttons back, so I started to find out what was going wrong.

The issue: acpi_fakekey checks all /dev/input/eventX devices whether or not it's a keyboard device, and if it finds one, it writes the necessary scancode to this device. Since some recent kernel, /dev/input/event0 is no longer my AT keyboard, but one of these ACPI buttons, so writing scancodes to the device won't work: my X server keyboard driver won't see them.

/proc/bus/input/devices told me I need event4 (or use this command: hal-get-property --udi `hal-find-by-capability --capability input | grep KBD` --key input.device | sed "s:/dev/input/event::g"
). Patching acpi_fakekey.c is pretty trivial:

--- acpi-support-0.94/acpi_fakekey.c.orig       2007-04-28 18:09:37.078953488 +0200
+++ acpi-support-0.94/acpi_fakekey.c    2007-04-28 18:09:49.578470914 +0200
@@ -13,7 +13,7 @@
         char filename[32];
         char key_bitmask[(KEY_MAX + 7) / 8];
 
-        for (i=0; i<32; i++) {
+        for (i=4; i<32; i++) {
                 snprintf(filename,sizeof(filename), "/dev/input/event%d", i);
 
                 fd = open(filename, O_RDWR);

Replace the 4 with the correct number on your system.

Now my buttons "work" again. Patching acpi_fakekey so it uses HAL to figure out the correct device to write to might be somewhat more reasonable though :-)

Ikke • Linux, Desktop, Coding Corner 1 comment