On Sat, 2006-01-07 at 17:24 +0000, Matthew Garrett wrote: > Currently, there are three ways that a sleep hotkey may generate an > event: > > 1) Exposed in DSDT as an ACPI object, generates an ACPI notification > event (the "normal" way) > > 2) Uses hardware-specific ACPI driver, generates an ACPI notification > event. Not exposed in the DSDT in any standard way (ibm-acpi, > toshiba-acpi, panasonic-acpi) > > 3) Generates a scancode, which is picked up by the kernel and turned > into a keycode (HP laptops work like this) > > This is all quite horribly confusing, and makes life miserable for > userspace.
Wholeheartedly agree. > I would like to suggest the following standardisation: > > a) Hal should assume that all hardware has a sleep key, since there's no > way to actually tell. > > b) Events generated in cases (1) and (2) should, for now, be caught by > acpid (or something similar) and then fed back into the input layer via > uinput. This should be scancode 142, which will end up as X keycode 223. Yes, I proposed something similar here [http://www.nabble.com/ACPI-to-uinput-bridge-t409384.html] -- using HAL and uinput to send the keys to user-programs. > c) Most keyboards in case (3) will already send scancode 142. For > laptops, those that shouldn't should be remapped at boot time by > checking the system DMI information and consulting a lookup table. Yes, perhaps using the existing HAL infrastructure with FDI lookup tables? We already have a HAL addon for watching ACPI events, and doing things like refreshing the battery values, and emitting conditions for the common buttons (lid, sleep, power) -- we could just extend this code in the HAL addon. The HAL addon is well tested, and plays nice with acpid if required. > Rationale: > > Having one type of event rather than three makes it easier for userspace > coders. Choosing to do it through the input layer lets people take > advantage of pre-existing code for binding userspace events to keyboard > events, and is significantly easier to do than getting keyboard events > back to the ACPI layer. Keycode 142 is chosen because it's what > Microsoft uses, and so most manufacturers who have taken this approach > have copied them. Can we not go further and define Dock/UnDock, BrightnessUp/BrightnessDown, Hibernate, etc? Richard. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
