Meetings in Montpellier

Attendees

  • Marcel Holtmann (BlueZ)
  • Johan Hedberg (Nokia)
  • Fabien Chevalier (Silicom)
  • Luiz von Dentz (INdT)
  • Claudio Takahasi (INdT)
  • Ville Tervo (Nokia)
  • Dave Woodhouse (RedHat)
  • Stefan Seyfried (Novell)
  • Steve Ross (Qualcomm)
  • Marc-Andre Lureau (Nokia)
  • Frederic Dalleau (Access)
  • Frederic Danis (Access)
  • Brad Midgley (BlueZ)
  • Chris Rivera (Novell)
  • Denis Kenzior (TrollTech)

Low-power modes

Every vendor's Bluetooth chip, using a UART interface, takes a different approach to implementing a chip low-power mode. There is no Bluetooth SIG standard and no prospect for one. However TI has made public their heretofore proprietary approach and Marcel has implemented support for that approach in BlueZ. In addition, he's implemented support for the low-power approach that CSR uses in their BCSP protocol.

Kernel driver changes

Marcel is reorganizing the hci opcode handling to make it simpler. He is also working on an sdio interface layer.

hci_usb is being replaced with btusb. This means the sco flowcontrol and the dynamic alternate setting will need to be implemented there.

Audio service current/future

Beginning

  • Need to get HSP support into N800
  • Integrate with the service framework
  • Only worry about PCM routing case (experimental HCI routing with alsa plugin)
  • Simple splitup into org.bluez.audio.Manager and org.bluez.audio.Headset D-Bus interfaces

Next steps

  • A2DP Headsets
  • Add org.bluez.audio.Sink D-Bus interface
  • Basic design decision:
    • service takes care of signaling (HSP RFCOMM/AVDTP signalling channel)
    • alsa plugin (or something similar) takes care of transport (SCO/AVDTP media transport)
    • service passes stream fd (SCO socket/AVDTP transport L2CAP socket) to alsa plugin
  • Make use of lessons learned from btsco, plugz projects

Challenges

  • Some headsets don't do proper flow control (particularly broadcom based ones)
  • Create separate worker thread in ALSA plugin which takes care of incrementing the HW pointer at the correct pace
  • Turns out this also helps with SCO so kernel patch is no-longer needed in the short term (however it will improve audio quality when available)

Future

  • ALSA plugin rework
    • Split stream setup into two parts
      • Get a SEP with a list of capabilities (and set the ALSA HW params accordingly)
      • Request a specific set of settings for the SEP
    • Receive commands from service (e.g. Suspend)
    • Send stream pause/start requests to service
  • AVRCP
    • Add org.bluez.audio.Control interface
    • Receive commands from headset and convert to D-Bus signals
    • Receive D-Bus method calls and send commands to headset (e.g. volume up/down)
  • Support for remote sources (org.bluez.audio.Source interface)
  • Support for remote HSP AG
  • Support for HFP
    • Issue with HFP is that there is a need for close integration with phone application, and PIM
    • Frederic & Frederic proposal was to somewhat extend the HSP API, and add the notion of Client agent, somewhat similar to the passkey agent or authorization agent
    • Marcel's proposal is to go with a set of plugins inside the audio service, that would connect to whatever underlying GSM system (OpenMoko's gsmd, Telepathy, voip software)
  • HAL integration
  • Handling video too (and renaming "audio" to "multimedia")
  • Moving AVDTP to the kernel space

Serial Service

  • security
  • how address dynamic channels?

Network

  • how address security? PANU, GN and NAP servers share the same security option, it is not possible enable/disable for one server only.
  • Zeroconf support? (maybe it is useful for embedded systems)

BlueZ and v2.1/3.0

New device API ideas

  • define SAP API + requirements
  • define print server API + requirements.

BlueZ 4.0

  • some d-bus methods should have been made to use object id instead of string--breaks api, but fix it
  • /etc/bluetooth/hcid.conf will go away (will use eg /etc/defaults/bluetooth and put params on daemon command line)
  • /etc/bluetooth/rfcomm.conf will go away (rfcomm service will manage bindings)
  • "timestamp" on releases (Johan's suggestion)
  • drop compat paths
  • drop eglib, introduce glib requirement
  • hcid changed to bluetoothd?
  • will require new kernel (ie, anyone interested will have to backported v4 if they use older kernels)
  • maybe use gbus? (but not libdbus-glib)

BlueZ 5.0

  • tight HAL integration

"Policy" callback

E.g. for checking of doing mode changes is allowed.

Decision: Needs more thinking. A more general purpose policy framework (non-bluez specific) might be better to have.

Return to previous mode

If an application wants to turn BT on and also restore the same mode (discoverable/connectable) that was used before switching it off

Decision: add SetMode("enable") or Enable()