Highlevel roadmap for BlueZ

This page lists planed features, changes, etc to BlueZ in the future.

  1. Highlevel roadmap for BlueZ
  2. BlueZ 4.x
    1. Strict GLib dependency
    2. Use of proper "object path" parameter type in D-Bus messages for object …
    3. Make hcid act as a proxy for services
      1. Special cases
  3. HAL integration
    1. Status
  4. Service daemons
    1. Input service
    2. Audio service
    3. Transfer service
    4. Network service
    5. Serial service
  5. User session daemon

BlueZ 4.x

BlueZ version 4.0 is targeted to be released during the first half of 2008. Most likely the first version will go out in March. The following is a list of changes planed for 4.x, many of which will be backwards incompatible with 3.x (hence the version 4.x and not 3.x).

Strict GLib dependency

BlueZ currently has an "embedded" GLib implementation which can be used on platforms which do not have the "real" GLib. The drawback of this has been that every time there has been a need to use some GLib feature which is not in eglib someone has had to reimplement it in eglib. To make maintenance easier BlueZ 4.x will have a mandatory dependency on GLib.

Use of proper "object path" parameter type in D-Bus messages for object paths

Originally when the BlueZ D-Bus API was created, all message parameters representing object paths were defined as strings (simply because the developers were unaware that there was a specialized type meant specifically for object paths). This desicion has remained unchanged in the 3.x series to maintain backwards compatibility. However, since 4.x will bring along another set of incompatible changes, it has been decided that this parameter type "mistake" will be fixed to. BlueZ 4.x will therefore use the proper object path type for D-Bus message parameters that represent D-Bus object paths.

Make hcid act as a proxy for services

Currently each service maintains its own remote device object tree and a Manager D-Bus interface for them. This means that applications have to:

  • resolve the unique bus name for each service before using the service
  • perform add/remove device operations separately to each service when configuring remote devices

It also means that each service must:

  • Maintain their own remote device object tree
  • Implement their own Manager D-Bus interface

BlueZ 4.x will introduce a unified remote device object tree inside hcid. Each service will register themselves to hcid and tell hcid what profiles (UUID's) they support and what D-Bus interfaces they implement that can deal with these profiles. When a new device is configured through hcid, hcid will automatically add the necessary interfaces to the newly created object based on the profiles that were discovered (through SDP). When hcid receives method calls on these interfaces it will automatically forward them though a private D-Bus connection to the service that matches the interface.

Each remote device object will also be associated with only one local adapter. This should hopefully once and for all solve the issue of using multiple adapters with services. One consequence of this (in order to keep the implementation fairly simple and practical) is that a new instance of each service daemon will be executed for each local adapter that it is needed for.

The benefit of this design is that applications only need to deal with the org.bluez D-Bus service and the object hieararchy that it provides. The benefit for the services will be that they will no longer need to implement a Manager interface nor will they need to handle multiple local adapters (each service process will get exactly one local adapter assigned to it).

Special cases

Some services are not designed using the Manager/remote device structure. One such case is the serial service. The proposal to fit this into the new architecture is to allow services to register new D-Bus interfaces to local adapter objects (e.g. /org/bluez/hci0). For the serial service case this would mean that once the service is running you could e.g. direct a org.bluez.Serial.ConnectService?("11:22:33:44:55:66", "dun") method call to the /org/bluez/hci0 object and the method call would get appropriately forwarded to the serial service.

HAL integration

The idea is to provide all information about local and remote bluetooth devices that makes sense via HAL.

Status

  • The network service has basic HAL support which the latest Network Manager versions can use
  • The audio service has an upcoming patch to register HAL objects for each configured audio device.

Service daemons

Service daemons are processes which utilize the Service interface and implement one or more Bluetooth profiles.

Input service

Status: implemented

  • Human Interface Device (HID) Profile
  • "fake" HID devices (headset button presses, serial input devices)

Audio service

See HOWTO/AudioDevices and Audio

  • Headset Profile (HSP)
    • PCM routing setup works, HCI partially
  • Handsfree Profile (HFP)
    • Not yet implemented. API proposal available.
  • Advanced Audio Distribution Profile (A2DP)
    • Usable, but still needs polishing
  • Audio and Video Remote Control Profile (AVRCP)
    • Basic message parsin in place

Transfer service

Produced as part of the Google Summer of Code (SoC) programme.

  • Obex Object Push Profile (OPP)
  • Obex File Transfer Profile (FTP)

Network service

  • Personal Area Networking Profile (PAN)
    • Implemented
    • Integration with HAL and Network Manager
  • Dialup Networking Profile (DUN)
    • Not yet implemented

Serial service

  • RFCOMM
    • Implemented

User session daemon

Multiple Bluetooth Dongles support and scheduling

Status: just some rough ideas. No work started yet.