Ubuntu Wiki

• Launchpad Entry: ubuntu-hotkey-madness

• Created: SteveLangasek

• Contributors: SteveLangasek, TimoAaltonen, BryceHarrington, MarioLimonciello, MattZimmerman, MartinPitt, ScottJamesRemnant

• Packages affected: acpi-support, acpid, hal, hotkey-setup, udev, linux, X

Summary

The Ubuntu 8.10 process highlighted the fact that we do not have a consistent architecture for how hotkeys work across different hardware in Ubuntu, and many of the developers do not have a clear understanding - or may have different understandings - of how the system is intended to work. This is intended to be the authoritative architecture description that developers can refer to when interacting with Ubuntu packages, to identify whether a given component is operating as intended.

Release Note

Hotkey handling in Ubuntu has been consolidated in the latest release, leading to removal of the acpid and acpi-support packages from the base system and moving most functionality out of the hotkey-setup package to the hal package.

Rationale

This spec documents the cross-platform architecture that hotkey handling is intended to use in Ubuntu, serving as a guide for debugging hotkey problems. It should be kept up-to-date if this architecture changes.

Design

Kernel

• There are two possible architectures at the kernel level:
  • all keypress-related ACPI events translated to keycodes in the kernel, or
  • *no* ACPI events are translated in the kernel, so modules that do this should be dropped and userspace should handle mapping ACPI events to keycodes

• the first option is the one we favor if this is supported by upstream; and MatthewGarrett appears to be actively pursuing this upstream: http://mjg59.livejournal.com/99754.html and http://lwn.net/Articles/310170

Hal

• hal handles mapping of hardware-specific scancodes to generic evdev keycodes where necessary, by calling setkeycodes for keymaps generated using fdi files in hal-info.

• hal also handles enumeration of input devices for X
• it should not be in between the kernel evdev device and X.

X

• keycode events are read from the evdev devices, which use a flat namespace for keycodes
• these keycodes differ from the pre-evdev keycodes
• the keycodes are platform-agnostic and should not require any translation at a layer between the kernel and X

Other

• some events should be handled by hal and not read from X at all, if they should be available in contexts other than the current desktop session

Implementation

• hotkey-setup: should be obsolete
  • review all settings and confirm that they are present in hal-info, then drop from hotkey-setup
  • thinkpad-acpi module includes dmi: modaliases, so udev should handle this (confirmed with Keybuk), test that this can be removed from hotkey-setup
  • package should be removed from ubuntu-desktop when it's confirmed to not be needed
• acpi-support: try to clean up scripts as possible that are no longer necessary
  • acpi_fakekey should go away completely, after reviewing that it's handled elsewhere

  • acpi-support also includes handling of certain events that are not desktop-y and should not be moved to that layer; where do we move this? (ex: Thinkpad wireless key) pitti says: hal, DeviceKit add-on

Bugs of interest

• bug #51537 Wrong handling of volume buttons on IBM Thinkpad notebooks
• bug #198197 IBM Thinkpad (T23): no OSD indication for volume control display inhibit or thinklight - (original report for Hardy, but comments indicate still present in Intrepid)
• bug #198214 thinkpad sleep suspend fn buttons do not work without g-p-m
• bug #217504 acpi_fakekey stopped working for certain keycodes
• bug #267682 Hotkeys no longer working in Intrepid on Thinkpads
• bug #281284 No function keys for sleep and hibernation in Kubuntu on Thinkpad

• bug #294400 Intrepid: XF86AudioStop button incorrectly mapped as XF86AudioLowerVolume

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec