[PATCH, RFC] Add support for keyboard hotkeys

[David Zeuthen]

Hi,

Sorry for the late reply..

On Tue, 2006-01-31 at 01:52 +0000, Matthew Garrett wrote:
> I've attached two patches. The first adds some code to the acpi addon to
> place the type of the button pressed in the details field of the
> generated event. This isn't strictly necessary for acpi (since the
> button type can be worked out afterwards), but makes sense in the
> context of the second patch.
> 
> This adds an addon for keyboard devices. It simply attaches to the
> keyboard's event device (these allow multiple readers) and monitors
> keypresses. When an "interesting" key (currently defined as one which
> would correspond to power management events) is pressed, it generates a
> ButtonPressed condition and puts the appropriate type in the details
> field.
> 
> KEY_SLEEP corresponds to the sleep key that appears on Microsoft (and
> some laptop) keyboards. KEY_SUSPEND doesn't actually appear to exist on
> any PS/2 keyboards (judging by atkbd.c), so it's a handy thing to hijack
> for hibernation. KEY_POWER is fairly self-explanatory.
> 
> Any comments on this approach? Right now it doesn't provide any
> information about these capabilities, on the assumption that all
> keyboards may potentially have these keys (we certainly can't tell for
> PS/2, I'm not sure about USB)

I think this makes a lot of sense. A few comments

 1. In addition to putting the key-type in the detail of the
    ButtonPressed condition should we change the property
    button.type to be a strlist so applications know a'priori
    what buttons it can expect? It's breaking ABI but all our
    button handling is rather recent so I'm not uncomfortable
    doing this since we're pre 1.0... Obviously if button.has_state
    is TRUE it'll only make sense to have a single element.. no
    big deal I think..

 2. Actually I got a USB keyboard at work, it exposes two interfaces

      USB device
       - USB HID interface (all normal keypresses go here)
       - USB HID interface (keypresses for power/sleep/resume IIRC)

    We can actually match the 2nd HID interface by using fdi-files,
    how about merging e.g. a strlist property with 

      button_listener_keycodes = {"sleep", "0x42",
                                  "power", "0x43", ... }

    and invoke your add-on that will read these codes? Suggestions
    for a better name than button_listener_keycodes welcome :-)

    Also, can we do this for PS/2 keyboards where we can't match
    e.g. USB vendor ID / product ID. 

    Is it even reliable to do so for USB keyboards (e.g. consider a
    multimedia keyboard with a Danish, English and Russian layout..
    vid/pid may be similar but are the keycodes for "sleep" similar? 
    I think they are.. I even think the USB HID protocol might tell you
    the layout.. should we merge what layout it is?)

 3. Should we restrict the merged keys in 2. to "power mgmt" related
    stuff.. E.g. should we merge "web browser -> 0x44", "volume up
    -> 0x45" and so on?

 4. If we do merge e.g. "web browser", "volume up" should we emit
    ButtonPressed events? I probably think so.. these are hot-keys,
    sorta, at least that's what we're trying to abstract... [1]

 5. We could let e.g. gnome-settings-daemon use the bits discussed
    in 3. and 4. to automatically configure key shortcuts, e.g.
    personally I'm pretty annoyed that I have to go to the "Keyboard
    Shortcuts" preferences applet in GNOME to configure "play", "pause",
    "volume up" etc. etc.

Lots of questions :-)

    David

[1] : At some point we ought to rename HAL to e.g. PlatformKit or
something else :-)