Eject notification doesn't use new notification framework

Bug #333997 reported by Mario Limonciello on 2009-02-24
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-settings-daemon (Ubuntu)
Ubuntu Desktop Bugs
Ubuntu Desktop Bugs

Bug Description

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

Mario Limonciello (superm1) wrote :
Mark Shuttleworth (sabdfl) wrote :

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

Changed in gnome-settings-daemon:
status: New → Confirmed
Changed in gnome-settings-daemon:
assignee: nobody → desktop-bugs
importance: Undecided → High
milestone: none → ubuntu-9.04-beta
David Barth (dbarth) wrote :

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

Changed in notify-osd:
status: New → Invalid
Martin Pitt (pitti) wrote :

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

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.

David Barth wrote:
> case MUTE_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 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:

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!


David Barth (dbarth) on 2009-03-04
Changed in gnome-settings-daemon:
status: Confirmed → Fix Committed
Martin Pitt (pitti) wrote :

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

Martin Pitt (pitti) wrote :

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

Changed in gnome-settings-daemon:
status: Fix Committed → Fix Released
no longer affects: notify-osd
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments