[PATCH, RFC] Add support for keyboard hotkeys

[Matthew Garrett]

On Tue, Jan 31, 2006 at 09:58:27PM -0500, David Zeuthen wrote:

>  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..

While that would be nice, there's no real way of doing this with PS/2 
keyboards - the kernel claims that they support every key. USB ones 
would be easy enough, I'm not sure what the ADB situation is.

>     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 :-)

So just export the buttons that we actually care about? Yeah, that would 
be easy enough.

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

We'd just export them all the time for PS/2.

>     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?)

USB should have standardised codes.

>  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?

It would be a possibility, yes (though the list might start getting 
large - as I said, for PS/2 machines we'd have to export it all the 
time)

>  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]

Sure, that seems reasonable.

>  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.

The biggest problem here is that in the PS/2 world, there's no standard 
for what scancodes these keys actually produce. The de-facto one is what 
Microsoft use, and even they've overloaded that between different 
keyboards (Office and media keyboards can use the same scancodes for 
different functions). That's much less of a problem with the power keys, 
which tend to be much more consistent.

This is easy enough to fix - the kernel allows new mappings to be 
loaded. However, that's orthogonal to X's keymap settings. Hal would end 
up using the kernel's keymap rather than X's, which may cause user 
confusion. For now, I'd be tempted to keep the PS/2 situation simple and 
look into a more Utopian keyboard setup solution in the long run (eg, 
allow unprivileged users to set the kernel keymap through Hal and then 
have Gnome or whatever use that when setting the X keymap. Slightly 
awkward, in that we'd need some way of letting the system know when 
users are being switched between)

-- 
Matthew Garrett | mjg59 at srcf.ucam.org