After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 573759 - We need a simple way to activate bluetooth headsets/mice/keyboards
We need a simple way to activate bluetooth headsets/mice/keyboards
Status: RESOLVED FIXED
Product: gnome-bluetooth
Classification: Core
Component: applet
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-bluetooth-general-maint@gnome.bugs
gnome-bluetooth-general-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2009-03-02 14:39 UTC by Lennart Poettering
Modified: 2009-03-23 16:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
What it looks like in MacOS X (179.74 KB, image/png)
2009-03-03 22:46 UTC, Bastien Nocera
Details

Description Lennart Poettering 2009-03-02 14:39:01 UTC
Bluetooth Headsets need to be explicitly activated (i.e. connected to) in most cases before they can be used. On Macs this is implemented by a special menu in the top right corner that lists all known headsets and shows a checkmark next to them when they are activated. It would be good to have something similar, e.g. integrated into the bluetooth applet. Just list all devices that are found on the org.bluez D-Bus service and that implement the AudioSink or Headset interfaces. If one is selected then call the Connect() method on those interfaces.

Since connecting might take some time it would be nice to give some form of feedback while a connection is in progress. (i.e. similar to how the nm applet does it)

If a device implements both AudioSink *and* Headset just call one of the two Connect() methods. For PA it doesn't really matter which one you pick.

On login it might make sense to automatically try to connect to all known headsets. 

PA will automatically pick up all AudioSink/Headset devcies that are connected, so more logic that simply calling Connect() (as mentioned above) is not necessary.
Comment 1 Bastien Nocera 2009-03-03 22:46:11 UTC
Created attachment 129975 [details]
What it looks like in MacOS X

I can't see any ways to connect to the device in the menus, and the "Don't use Headset" menu item doesn't seem to do anything...
Comment 2 Bastien Nocera 2009-03-05 16:50:53 UTC
For the wizard, we'd need to connect when done, and that's done through create_callback() in the main (see the call to bluetooth_client_connect_input()).

The problem is, do we connect on "org.bluez.Headset", or "org.bluez.AudioSink", or on one first, then the other? What can we do for devices that support both?
Comment 3 Lennart Poettering 2009-03-07 15:24:41 UTC
Quoting from above:

> If a device implements both AudioSink *and* Headset just call one of the two
> Connect() methods. For PA it doesn't really matter which one you pick.


Comment 4 Lennart Poettering 2009-03-12 20:31:22 UTC
Ok, I just learned a few more things:

For each adapter only one A2DP and one HSP device may be connect simultaneously. i.e. exposing this menu is not just useful for activating/deactivating devices but also for simply selecting which one to use. i.e. when a new A2DP device is activated a preexisting connection to a different A2DP device needs to be explicitly disconnected (possibly before asking the user if he is ok with that...).

Then, in contrast to what I said earlier if a device has both AudioSink AND Headset you should connect BOTH. And the order matters: FIRST Headset.Connect(), SECOND AudioSink.Connect().
Comment 5 Lennart Poettering 2009-03-13 21:42:56 UTC
One more addition:

In addition to activating/deactivating audio devices like this this should also allow activating mice and keyboard in a very similar fashion. After our discussions here at the BlueZ meeting no other types of BT devices would need this however.
Comment 6 Bastien Nocera 2009-03-19 19:06:45 UTC
Won't quite have time to finish this, so:
TODO list:
1) Fix BluetoothClient not seeing services on newly created devices
2) Look at what the device supports before blindly connecting, and remove the separate connect functions
3) Fix wizard to connect _all_ devices (that way, computers with A2DP or keyboard capabilities will work as expected)
Comment 7 Bastien Nocera 2009-03-23 15:38:40 UTC
(In reply to comment #6)
> Won't quite have time to finish this, so:
> TODO list:
> 1) Fix BluetoothClient not seeing services on newly created devices

Fixed in:
http://svn.gnome.org/viewvc/gnome-bluetooth?view=revision&revision=527
Comment 8 Bastien Nocera 2009-03-23 16:16:25 UTC
(In reply to comment #6)
> 2) Look at what the device supports before blindly connecting, and remove the
> separate connect functions

http://svn.gnome.org/viewvc/gnome-bluetooth?view=revision&revision=528

> 3) Fix wizard to connect _all_ devices (that way, computers with A2DP or
> keyboard capabilities will work as expected)

http://svn.gnome.org/viewvc/gnome-bluetooth?view=revision&revision=529

Just need to make the applet itself connect now.
Comment 9 Bastien Nocera 2009-03-23 16:42:06 UTC
First pass all done:
http://svn.gnome.org/viewvc/gnome-bluetooth?view=revision&revision=531

I filed bug 576442 about a potential UI niggle, and bug 576443 about disconnecting other devices.