You Got A Question? Ask    GNOME Community!

gtk-theme2
 12349   |  Oct 25
gtk_logo2
 9593   |  Mar 17
arch
 8159   |  Mar 28
 6662   |  Jun 17

GNOME 3.10 port to BlueZ 5

This post was made with an older stylesheet

Shell has been ported to use the latest bluetooth protocol stack BlueZ 5 which released last December with numerous new features, API simplifications and other improvements. With this release BlueZ only supports the new Bluetooth Management kernel interface that was introduced in Linux 3.4, so essentially this is the minimum kernel requirement for BlueZ 5. For Low Energy support at least kernel version 3.5 is needed.

The energy profiles of BlueZ 5

  • Cycling Speed
  • Scan Parameters
  • Alert
  • Heartrate
  • HID over GATT (HoG)

Other changes

  • Move to standard D-Bus ObjectManager & Properties interface
  • Remove Manager interface as the same functionality comes through ObjectManager
  • Remove support for audio UNIX socket interface (the Media D-Bus interface replaces it)
  • SBC library moved into its own project
  • GStreamer elements removed after submitting them to the upstream GStreamer project
  • Removal of the Service interface and introduction of a new (libbluetooth independent) Profile interface
  • New bluetoothctl command line too for interacting with BlueZ
  • New btmon monitoring tool
  • Remove internal support for telephony (HFP and HSP) profiles. They should be implemented using the new Profile interface preferably by the telephony subsystem of choice (e.g. oFonowhich already supports this)
  • General connection establishment procedure and vastly simplified D-Bus API for it
  • The adapter power state is not stored persistently and remembered over bluetoothd restarts. An external entity (like ConnMan) is expected to handle this.
  • libbluetooth not installed by default as it’s not really useful or recommended anymore. The new Profile interface further decreases its usefulness.
  • INI-style format for all storage file. Old files from BlueZ 4 are auto-converted.
  • Merge obex-client into the main obexd daemon
  • D-Bus interface versions with the intent to always keep support at least for the two latest versions.

For full changelogs and migration guide from version 4 to 5:


Emilio Pozuelo Monfort software engineer at Collabora pushed the changes in Shell today

In BlueZ 4, Authorize() was used to authorize both service and JustWorks authorization requests. In BlueZ 5 these two have been split into AuthorizeService() for services and RequestAuthorization for JustWorks devices. Adapt the Bluetooth code accordingly.

Emilio and Gustavo Padovan have done this work for Intel. You can read the “The big changes of BlueZ 5″ post of Gustavo at his blog:


More migrations for BlueZ 5:

Gnome-Bluetooth[1] and Gnome-Shell[2] have been ported to use BlueZ 5, the new major version of the Bluetooth handling daemon and utilities[3], and will available in GNOME 3.10.

Gnome-User-Share is still being worked on [4] as it requires some obexd/bluetoothd changes. NetworkManager port is also in progress. PulseAudio already supports both BlueZ 4 and Bluez 5.

Nocera via GNOME ML


Bluetooth in System Status

Bluetooth indicator (and all the rest!) will also receive a major change in GNOME 3.10 or in GNOME after 3.10 — ;)

The system status icons will become much more dynamic –so, for example – if you turn on airplane mode, broadband, bluetooth and mobile broadband are replaced by an airplane mode icon or, if you are using a wired connection, the wifi icon is hidden.

combined-system-status-menu-v3-overview

This is work in progress

For more info on these you can check on System Status page @ GNOME Live!


 
  We can't watch comments unless G+ provides an API or if you send a notification, e.g +World Of Gnome
     Sometimes is better to place your questions on GNOME Community
  • Bastien

    Emilio and Gustavo have done that work for Intel (as the copyright headers show), not for Canonical.

    • alex285

      Thank you, I updated it!

      • Bastien

        It still looks like Emilio did that work for Canonical. That’s not the case…

        • alex285

          Well, I removed completely the Canonical part, which was just the job description of Emilio from Linkedin. It was an unnecessary detail anyway.

          Personally I didn’t understand how this sentence was looking like the way you meant it. Sorry anyway!

    • Craig

      Yeah, that looked strange for a second. I though to myself, “WTH, Canonical are actually contributing upstream!?”.