While hotkeys via ACPI are well supported by acpid and its ilk it is no longer the best way to handle these types of keys. Generally, the drivers for the mainstream laptops (ibm/lenovo, hp) have moved over to the input framework to communicate these key presses, usually displaying as an extra input device under /dev/input. These input devices can be handled by HAL and notifications of key presses send over the dbus allowing for desktop environments such as GNOME to handle these events without any strange hackery and fakekeys calls.

Thanks to the previous work of the asus-laptop developers there’s a patch that exists to disable the existing ACPI events and provide a input device for the extra keys, I’ve managed to hack together a version of the eeepc-acpi module using the Debian 1.01 source to export the “Asus Extra Buttons” input device.

After you have the inputs available, it’s a simple matter of producing a FDI for HAL to identify the device and map the scan codes to the actual keys. After the initial FDI was created I could use the volume keys without any extra software and also map the two application buttons (marked as VGA switch, and AP button) in GNOME to call scripts. The wifi key (Fn+F2) presented more of a problem, while it was mapped to “wifi” HAL didn’t know how to actually switch off the Atheros card. The killswitch for the card would need to be implemented as a program that listens to dbus, something a little outside my skill set.

The other buttons on the keyboard (sleep, brightness) are pure ACPI calls. This presents a problem that the keys produce events via the input layer and the ACPI layer at the same time, so for example you hit the brightness down button and HAL will pickup the notification and display the brightness OSD, but it quickly goes out of sync as what HAL sees and what the ACPI are doing are completely separate. Again, this is outside my skill set but I’d probably approach it by filtering out the keys in the kernel and let the ACPI events do their work.

The guys over at Fedora have a similar idea of moving over to an input based module, but for the moment no source has been produced. Due to the numerous little issues I’ve had I’ve decided to put this little project on the back-burner until I see what the Fedora people have produced, after all they’ll have people that are more experienced in this type of thing, whereas I am not.

I’ll get round to posting the source deb for the modified eee-acpi tonight or tomorrow.