One weakness of Linux on laptops and netbooks is that not all hotkeys 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 — the Advanced Configuration and Power Interface. Well, my expectations changed after I read the following comment on an ACPI how-to: “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. The kernel will interpret the AML (ACPI Machine Language). The AML interpreter “ singlehandedly added around 72,000 lines of code to the kernel ” (from the ACPI how-to 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 this LWN article with regard to writing a WMI driver, “WMI objects can be embedded within ACPI, a configuration that Microsoft recommends. Like ACPI, WMI is not really standardised, 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 problems for the developers, and the frustration of the users.
The second way is that an xevent will be raised, and an action tied to a key-code 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 the 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 Wi-Fi in the netbook, so that it would not work without some jugglery. I wanted to figure out if I could solve my problem using Linux only — and thus, got interested in the hotkey issues.
Common events like the Sleep and Power button may be handled by a power-management application, like GNOME’s gnome-power-manager and KDE 4’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 the 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, the Sleep button works from a GUI, but not in the 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 will get to know about the ACPI commands that 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 os.
Although KDE 4 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 of the laptop, triggers the LID event, and functions like the Sleep button. This, however, is not mandatory. In KDE 4’s powerdevil performance profile, it just turns off the monitor.
The volume-up and -down hotkeys raise xevents and function as expected. However, on Fedora, these hotkeys raise ACPI hotkey events.
All the other hotkeys raise neither an xevent, nor an ACPI event. So, the solution was to try and find an Ideapad laptop driver included with the 2.6.36 kernel. Experimenting with it on Arch Linux showed that a few more of the function keys, like brightness increase/decrease, etc., raise ACPI events, and they 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 Wi-Fi, so that it 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 Wi-Fi issue using only Linux, was achieved, thanks to the driver created by Ike Panhc and David Woodhouse.
