multimedia keys (and other keys) bof

[Dan Winship <danw novell com>]

(aka "Unfuck my Keyboard", starring Bastien Nocera)

The high-level summary: currently information about
multimedia/power/etc keys is handled in two places: HAL (which emits
events, which go to gnome-power-manager, etc), and the normal key
handling paths (which go to gnome-settings-daemon and some other
places). It would be good to have only one path, and have it be the
right path, and have it work with all keyboards without requiring user
configuration, even when the keyboard returns the wrong codes (which
will require having a database of broken keyboards at some level).

We also talked about global keybindings in general, and how best to
allow applications to register them in some way so that you can see
all global keybindings listed in one place.

--

The detailed minutes:

105 keys on the keyboard basically work
the other keys:
  - keys that go through input layer normally
     - eg, volume change keys on a USB multimedia keyboard
     - gnome-settings-daemon handles these
     - sonypi driver translates weird sony keycodes to standard ones.
       it doesn't do this perfectly, but David says that's a sonypi
       bug.
  - keys that go through ACPI
     - eg, volume and other special feature keys on laptops
  - completely hardware-based ones where the button causes the
    action to happen regardless of what software wants
     - eg, thinkpad brightness and volume buttons
     - sometimes you can get an event when they're pressed
     - userland still wants to see these, so it can draw the
       volume-changed overlay window, etc
  - some keyboards with volume knobs emit keypresses, but some treat
    it differently; we aren't trying to solve this bit right now...

HAL tries to emit volume/brightness/power-managerment, etc signals on
the message bus regardless of how the keyboard generates the event.
gnome-power-manager listens to these.

Sometimes HAL and X both emit events for a key. This can cause
problems, eg if two pieces of software both try to put the computer to
sleep on the same keypress.

Some (apparently many) brands of keyboards emit the wrong keycodes for
the multimedia keys. This is why we let the user remap the
multimedia/power/etc keys in gnome-keyboard-properties (NOT because we
want to let you bind "q" to "volume up")

Bastien thinks HAL should not emit events; it should just translate
the fake keypress notifications (ACPI, BIOS, etc) into the
corresponding ordinary keypresses, and then gnome-settings-daemon will
always handle everything.

Another possibility would be to have HAL know about broken keyboards
and translate their broken keycodes into the correct events and have
apps listen only to the HAL events, not the keypresses. Bill Haneman
likes this because key grabs are evil for a11y (they cause a focus out
and back in when the key is pressed).

We have to deal with the case where the user has a "broken" laptop
keyboard and a correct USB keyboard, or vice versa. This would be
easier if everyone didn't multiplex keyboard input in X, but everyone
does. OTOH, we could take advantage of multiplexing by having HAL create
the illusion of an additional keyboard, and emit keypresses on that
imaginary keyboard for X to process.

(Brief interlude about whether HAL should treat a CD drive's eject
button the same way as a keyboard "Eject" key. And what does the
keyboard Eject key mean if there are two CD drives?)

How do you generate a power/volume/etc key from an onscreen keyboard?
If no keycode has the right keysym, you'd have to bind an unused key
yourself.

Maybe instead of having the user pick keys to grab and assign
power/volume/etc events to, they should be picking keycodes to bind
the corresponding keysyms too, and always have the events tied to the
"right" keysyms. Basically a keyboard editor for the Keyboard capplet
rather than having this be part of the Keyboard Bindings capplet. No,
no, not a keymap editor. Internally, it's a keymap editor, but having
the existing keybinding editor actually change the keymap. But how do
we present this to the user? It can't be quite the same as the way the
keybindings capplet works now.

Consensus seemed to be that this is what we wanted, except that then
later on we remembered that this doesn't deal with the
broken-laptop-keyboard-and-working-USB-keyboard or
working-laptop-keyboard-and-broken-USB-keyboard cases. Someone
suggested we should push all of the broken-keyboard-key-remapping down
into the kernel.


Global keybindings:
  - 3 kinds of actions that could be taken on keypress:
    - app grabs the key itself and does something
    - launch an app
    - activate dbus method
      - does this make the first two redundant?
      - alternately, just emit a dbus signal, not to any particular
        destination.
  - who grabs the key?
    - currently metacity and g-s-d both handle some global
      keybindings.
    - the a11y framework has its own version that also uses XEvIE to
      be more a11y friendly (not causing FocusOut/FocusIn, etc). But
      it seems that no distros enable XEvIE by default. Many don't
      even ship it. Why? (The answer seems to be "because no one was
      using it"; there are no technical problems with it or anything.)
  - conflict resolution? Done in keybindings capplet. but what
    constitutes a conflict? Maybe just let multiple apps register for
    the same binding, and if the user doesn't like what happens, he
    can deal with it in the keybindings applet
  - We want a cross-desktop spec. (Does this make g-s-d the right
    place or the wrong place to implement it?)
  - "plugin" (probably just xml): Label for keybinding, default key,
    action eg: "Search", XK_F12, org.gnome.Beagle.search
  - but also want some keybindings to only happen when app is active
    (eg, Banshee or Totem grabbing "Pause" key)