[PATCH, RFC] Add support for keyboard hotkeys

[Danny Milosavljevic]

Hi,

Am Mittwoch, den 01.02.2006, 08:34 +0000 schrieb 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 

Something strange: What was the use of X having it's own keymap /
keyboard driver again ?

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

cheers,
  Danny