What makes netbook hotkeys tick!

One weakness of Linux on laptops and netbooks is that not all hot keys and buttons work as intended. This seemed surprising since I had expected it to have become a non-issue by now. Hardware vendors have standardised around ACPI - Advanced Configuration and Power Interface. Well, my expectation changed after I read the following comment in http://www.columbia.edu/~ariel/acpi/acpi_howto.html

“ One developer [fn1] is pretty sure that ACPI was designed by a bunch of monkeys on LSD, but if it had, it would at least be visually appealing. And this ain't.”

Linux systems will normally handle a hotkey in one of two ways. The bios may raise an ACPI event. Kernel will interpret the AML (ACPI Machine Language). AML interpreter “singlehandedly added around 72000 lines of code to the kernel” (acpi_howto quoted above).

The kernel will raise an acpi event to be handled by an application monitoring acpi events and execute appropriate distribution/user defined action. However, as we now suspect, a laptop specific acpi driver is needed for most of the hotkeys to be detected and interpreted correctly.

Further complications are the WMI (Windows Management Instrumentation) events. As described in http://lwn.net/Articles/391230/ about writing a WMI driver, “WMI objects can be embedded within ACPI, a configuration which Microsoft recommends. Like ACPI, WMI is not really standardized and vendors still implement their own custom interfaces.”

If the hardware vendors supply the drivers, as for windows, this is a non-issue. However, if developers have to reverse-engineer and implement these drivers, one can imagine the pain of the developers and the frustration of the users.

The second way is that an xevent will be raised and an action tied to a keycode will be executed. Ubuntu's acpi scripts often raise a fakekey so that an acpi event is finally handled as if it were an xevent.

Ideapad as an Example

As yet the Linux kernel does not include an acpi driver for Lenovo Ideapad, whose bios is different from Thinkpads. (The 2.6.36 kernel, now included with Arch Linux, includes the ideapad-laptop driver.)

We will experiment with a Lenovo S10-3 to get an idea of what makes hotkeys so hard to handle. I had managed to mess up my wifi in the netbook so that it would not work without some jugglery (http://sethanil.blogspot.com/2010/10/lenovo-wifi-behaviour-still-magical.html). I wanted to learn and see if I could solve my problem using Linux only and, thus, got interested in the hotkey issues.

Common events like sleep button, power button may be handled by power management application, e.g. GNOME's gnome-power-manager and KDE4's powerdevil; others may need custom scripts to be handled by the acpi daemon - acpid. The scripts would be needed if some of the events need to be handled when a gui session is not running or if we are using a light-weight desktop environment which does not have a power management application.

Currently, the default acpi scripts included with acpi daemon for handling hotkeys are dependent upon the distribution.

The most comprehensive acpi scripts are available with Ubuntu distributions. Fedora handles the power button but relies upon the GUI to handle the rest. Hence, sleep button works from a GUI but not in init 3 state. Arch Linux does not handle the power button but handles the sleep button! The unfortunate consequence is that a Linux system can appear to behave inconsistently across distributions or desktop environments.

If we use 'acpi_listen', we can know about the acpi commands which get triggered. We can also include the log option in the acpi-daemon to log the event and the action taken on each event. We find that for Lenovo S10-3, Fn+F1 triggers the SLPB event and the power button triggers the PWRF event. The sleep button event is handled well by Ubuntu, Arch Linux, Meego, Smeegol and Fedora, even if differently. Pressing the power button after we have pressed the sleep button wakes up the system on each of the os's.

Although KDE4 handles the acpi events very well and is highly configurable, it did not work with the plasma-netbook workspace in both Arch Linux and Fedora 14. This is likely to be a bug and will hopefully be sorted out soon.

Closing the lid, triggers the LID event and functions like the sleep button. This though is not mandatory. In KDE4's powerdevil's performance profile, it just turns off the monitor.

Volume up and down hotkeys raise the xevents and function as expected. However, on Fedora, these hotkeys raise acpi hotkey events.

All the other hotkeys neither raise an x-event nor an acpi event. So, the solution was to try and find a Ideapad laptop driver included with the 2.6.36 kernel. Experimenting with it on Arch Linux showed a few more of the function keys, e.g. brightness increase/decrease, raise acpi events and worked. The command 'rfkill list' showed information for both bluetooth and wireless lan, which it did not earlier. Any remaining issues will also be ironed out. Most importantly, I could enable wifi so that wifi worked without having to resort to any magical steps.

Although I personally could not solve the problem, as the saying goes – 'Time is a great healer!' My goal to fix the wifi issue using only Linux was achieved thanks to the driver created by Ike Panhc and David Woodhouse.

Nov 2010