Bug 508696 - Bluetooth headset AVRCP commands do not work when the screen is locked
Bluetooth headset AVRCP commands do not work when the screen is locked
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: bluez (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-29 10:25 EDT by Robert Marcano
Modified: 2009-11-02 10:26 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-02 10:26:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 422390 None None None Never

  None (edit)
Description Robert Marcano 2009-06-29 10:25:03 EDT
Description of problem:
Any Bluetooth AVRCP profile command, like pause, next, previous is ignored when the GNOME session is locked

Steps to Reproduce:
1. Let pulseaudio use your Bluetooth headset
2. Play something on Rhythmbox and control the playback with the headset buttons
3. Lock your GNOME session
4. try again to control the media player
5. Unlock the session
6. test again the headset buttons
  
Actual results:
The buttons only works before the session is locked and after, not when the session is locked

Expected results:
The buttons should work when the session is locked too
Comment 1 Lennart Poettering 2009-06-29 14:34:37 EDT
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.
Comment 2 Robert Marcano 2009-06-29 15:16:06 EDT
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?
Comment 3 Robert Marcano 2009-06-29 15:20:47 EDT
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
Comment 4 Robert Marcano 2009-06-30 12:40:06 EDT
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
Comment 5 Bastien Nocera 2009-06-30 13:00:30 EDT
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).
Comment 6 Robert Marcano 2009-06-30 13:28:38 EDT
(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?
Comment 7 Robert Marcano 2009-06-30 14:32:01 EDT
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
Comment 8 Bastien Nocera 2009-06-30 18:55:02 EDT
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.
Comment 9 Robert Marcano 2009-06-30 19:32:04 EDT
(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
Comment 10 Bastien Nocera 2009-06-30 19:43:54 EDT
(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.).
Comment 11 Robert Marcano 2009-06-30 20:09:32 EDT
> 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.).
Comment 12 Bastien Nocera 2009-11-02 10:26:26 EST
See:
https://bugzilla.gnome.org/show_bug.cgi?id=422390

Note You need to log in before you can comment on or make changes to this bug.