Eject notification doesn't use new notification framework

[Mario Limonciello]

Binary package hint: gnome-settings-daemon

The new notification elements work wonderfully, except it seems that eject doesn't take advantage of them. See attached screenshot.

gnome-settings-daemon 2.25.90-0ubuntu4

[Mark Shuttleworth (sabdfl)]

Eject, as well as the multimedia keys (play, pause, stop, next, previous) are supposed to work for 9.04, so targeting this to Jaunty.

[David Barth (dbarth)]

Not strictly a notify-osd bug, so invalidating here.

[Martin Pitt (pitti)]

Does notify-osd already provide an interface and the necessary graphics/icons etc. for this? In other words, what do we need to change in g-s-d?

[David Barth (dbarth)]

Re-scoped to:

       case MUTE_KEY:
       case VOLUME_DOWN_KEY:
       case VOLUME_UP_KEY:
       case EJECT_KEY:

while the expected behaviour for the multimedia keys is refined. Issue: should we display both a KEY notification & the track+cover-art notification that the multimedia application is expected to send in response to the trigger? or should we try to optimize that more?

Pitti: we do have icons for all of these. DX patch to follow.

[Mark Shuttleworth (sabdfl)]

David Barth wrote:
> case MUTE_KEY:
> case VOLUME_DOWN_KEY:
> case VOLUME_UP_KEY:
> case EJECT_KEY:
>
My laptop also has STOP, NEXT, PREVIOUS, PLAY/PAUSE for multimedia.

Then there are keys like LOCK, BATTERY, SLEEP, WIFI-OFF, LCD/EXTERNAL,
SUSPEND. Is there a rigorous list anywhere of everything anybody has
stuck on a keyboard, and the state of Linux support for them?

Mark

[Martin Pitt (pitti)]

Mark Shuttleworth [2009-02-27 9:02 -0000]:
> Is there a rigorous list anywhere of everything anybody has
> stuck on a keyboard, and the state of Linux support for them?

You can generate an exhaustive list of known keycodes with

  grep KEY_ /usr/include/linux/input.h

However, that only means that those key codes are defined, not that
each and every laptop model has completely working keys. The hal-info
package maps scancodes (which are highly vendor, and even model
specific) to their intended meaning (the key codes from above), and in
general coverage is pretty good (see also my efforts on the platform
sprint where I asked everyone with nonworking hotkeys to come to me to
get them fixed).

Another glitch is that X.org currently can only digest key codes below
256; i. e. KEY_MAIL, KEY_REWIND etc. all work, but KEY_FAVORITES
(0x16c), KEY_TV (0x179), etc. cannot be used with X.org programs
(that's an X11 protocol limitation, see LP #313514); they can be used
with LIRC, hal, and other programs, though.

More information:
https://wiki.ubuntu.com/Hotkeys/Architecture
https://wiki.ubuntu.com/Hotkeys/Troubleshooting

[Mark Shuttleworth (sabdfl)]

Martin Pitt wrote:
> You can generate an exhaustive list of known keycodes with
>
> grep KEY_ /usr/include/linux/input.h
>

Ah, wow, that's really useful, thanks Martin.

The HotKeys work looks fantastic!

Mark

[Martin Pitt (pitti)]

For the record, with yesterday's g-s-d, pressing the eject key uses notify-osd. So can we close this?

[Martin Pitt (pitti)]

Closing this; I don't see what's left for handling the eject key.