Bug 508696

PA doesn't handle the buttons.

Also, I don't see why Play/Pause/... on a headset should be treated any differently than similar keypresses on an mm keyboard? While the machine is locked, it should be locked, and not accept input until unlocked.

Reassigning to bluez now, but I think there is no bug here.

OK with the package change, did not know it was handled by bluez, But I still think it is a bug or missing feature. I was at home, just trying to do something around (lets call it cleaning or cooking, anything), and left the laptop on the table, Why I should not be able to forward to another song just because the session is locked?

opps forgot to mention, you use a keyboard when you use your computer, so it is expected that the session is not locked, but that is not the case with the headphone. This is like saying that if I lock my bluetooth phone I should not be able to use the headset buttons. a headset is not a keyboard, It could be implemented like one like it is currently I think, but it is not a keyboard

It does not works either when a popupmenu is displayed, or some windows like the "Account Information" password change window (even if the window is not focused). I will try to track this in bluez later

It has nothing to do with bluez, and everything to do with X, and the way the keys work.

It's a dupe of the same thing being done on keyboards (because it currently doesn't matter if it's generated by a keyboard or a headset).

(In reply to comment #5)
> It has nothing to do with bluez, and everything to do with X, and the way the
> keys work.
> 
> It's a dupe of the same thing being done on keyboards (because it currently
> doesn't matter if it's generated by a keyboard or a headset).  

In my opinion it has to do with bluez, because it should not be sending key events with "send_key(int fd, uint16_t key, int pressed)", it is an easy way to reuse the current implementation for processing the multimedia keys on a keyboard, but it is forcing a headset to behave like a keyboard, something it is not

The question is, how can it interact with the desktop environment and tell the applications about the keys, without tying bluez to any desktop? sending DBus events and add listeners on (for example) GNOME to receive those events?

Another reason why it should signal DBus events: bluez sends standard keys codes from multimedia keyboards, but gnome-settings-daemon uses user mapped keys, so if a use change one of those mappings, the headset button for that action do not work anymore. I will play a little changing bluez to signal DBus events, and allow gnome-settings-daemon to listen to those events

There's no reasons why the key events coming from the headset should be treated any differently from the ones used by a keyboard. Adding a layer between bluetoothd and the desktop isn't the way to solve that.

(In reply to comment #8)
> There's no reasons why the key events coming from the headset should be treated
> any differently from the ones used by a keyboard.

And that is something I disagree, you have the idea the headset is a keyboard attached to the computer. I see it as a networked equipment sending commands, like lirc for attached IR controls.

What if the headset does not have any keys, and is voice activated or movement activated (like some Sony phones you can shake it to switch songs). In that case the abstraction of a keyboard is more clearly wrong

(In reply to comment #9)
> (In reply to comment #8)
> > There's no reasons why the key events coming from the headset should be treated
> > any differently from the ones used by a keyboard.
> 
> And that is something I disagree, you have the idea the headset is a keyboard
> attached to the computer. I see it as a networked equipment sending commands,
> like lirc for attached IR controls.

Except that more and more bits of LIRC are finding their way into the kernel, and use the input or hid layer, just like keyboards.

> What if the headset does not have any keys, and is voice activated

Then you'd probably need something at the BlueZ layer to handle that.

> or movement
> activated (like some Sony phones you can shake it to switch songs).

Most likely the headset/phone actually does the work, and just sends you a key event as well.

> In that
> case the abstraction of a keyboard is more clearly wrong  

You're missing the point. It doesn't have to be handled like a keyboard once it gets to the X applications. Once GTK+ gets XI2 support, we'll know which device the keypress comes from, and can adjust gnome-screensaver to pass those keypresses (to the root window, where gnome-settings-daemon gets them) to adjust the volume, or send "next" to the media players.

But reinventing another way to propagate the key press is wrong (there used to be, or still is HAL, LIRC, X, a ton of hardware specific daemons, etc.).

> You're missing the point. It doesn't have to be handled like a keyboard once it
> gets to the X applications. Once GTK+ gets XI2 support, we'll know which device
> the keypress comes from, and can adjust gnome-screensaver to pass those
> keypresses (to the root window, where gnome-settings-daemon gets them) to
> adjust the volume, or send "next" to the media players.

Learning about XInput 2 enhancements right now, looks good. But XI2 does not solve the problem that the desktop allow the user to redefine the keys, and bluez is sending standard keycodes because it is desktop agnostic, unless they key mapping logic is made device dependent

> 
> But reinventing another way to propagate the key press is wrong (there used to
> be, or still is HAL, LIRC, X, a ton of hardware specific daemons, etc.).

See:
https://bugzilla.gnome.org/show_bug.cgi?id=422390