Bluetooth connectivity is a key feature in many embedded Linux systems. When it comes to implementing Bluetooth support, you can choose between using the open source BlueZ stack or a proprietary Bluetooth stack that can typically be purchased from the Bluetooth controller vendor. In many industries, the go-to approach is to use the proprietary solution, unlike the Open First approach taken for other connectivity protocols. However, BlueZ provides a notable advantage as an open source solution, benefiting from contributions across various communities and industries that actively use it.

When adopting BlueZ, it is crucial to understand how it differs from proprietary counterparts and manage expectations accordingly. While BlueZ offers significant advantages, there are also trade-offs to consider. In this post, we'll explore those differences and share insights based on a recent project where we transitioned a customer's system from a proprietary Bluetooth stack over to BlueZ.

What is BlueZ?

BlueZ is the official Linux Bluetooth protocol stack, integrated with the Linux kernel since 2001. BlueZ consists mainly of two parts: an in-kernel subsystem core containing device drivers with low level protocol implementations, and a userspace management daemon, bluetoothd, that exposes higher-level functionality via D-Bus APIs. In addition, the userspace part also includes CLI tools for configuration and monitoring, as well as a secondary daemon, obexd, which implements the Object Exchange protocol and Bluetooth profiles that are based on it, such as the Phone Book Access Profile (PBAP) and the Message Access Profile (MAP).

On top of those components, BlueZ allows for integration with audio daemons, for implementing audio-related profiles, as well as other custom software that may implement non-standard profiles. For implementing the audio profiles, namely the Advanced Audio Distribution Profile (A2DP), the Head-Set Profile (HSP), the Hands-Free Profile (HFP) as well as the new LE Audio profiles, we recommend using PipeWire, since it is the most feature-complete implementation and adheres to qualification standards. Recently, we also contributed a telephony API to it, allowing it to make phone calls as the “Hands Free” unit, when connected to a remote mobile phone "Audio Gateway.”

In a diagram, this is how the BlueZ architecture looks like (with PipeWire):

In-kernel vs Userspace

One distinction between BlueZ and proprietary Bluetooth stacks is that BlueZ has a core component implemented within the Linux kernel, whereas proprietary stacks typically operate entirely in userspace. The userspace approach is commonly achieved by communicating with the Bluetooth controller over a serial port, which is exposed as-is by the operating system. The "Host Controller Interface” (HCI) protocol and all protocol layers above are then implemented directly in a userspace daemon.

In contrast, BlueZ manages this controller serial interface inside the kernel and implements upper layer protocols, such as the "Logical Link Control and Adaptation Protocol" (L2CAP), the “Synchronous Connection-Oriented” (SCO) protocol and the "Isochronous channel" (ISO) protocol, directly in there. It then exposes standardized socket types to userspace — such as HCI, L2CAP, SCO and ISO using the “Bluetooth” address family (AF_BLUETOOTH) — similar to how traditional networking exposes IP/TCP/UDP sockets in the “internet" address family (AF_INET).

While the userspace approach offers flexibility, the in-kernel approach benefits from lower latency and tighter security controls. It is surely easier to port a userspace daemon to multiple operating systems or to distribute it in containers or even virtual machines, achieving some sort of abstraction and containment. However, this can be at the cost of efficiency, as the userspace process is bound to scheduler constraints and also security, as the userspace can more easily be tampered with.

Design implications

Regardless of any advantages, BlueZ's “distributed” design comes with certain implications that are important to understand. One implication is that the in-kernel part of BlueZ is maintained as part of the Linux kernel and therefore adheres to the rules of its development. On one hand, this means that it is actively cared for and patched in a timely manner for potential security issues, with Long Term Supported (LTS) releases also being available. On the other hand, it also means that changes to support recent additions in the Bluetooth specification or to fix qualification-related issues may not be readily available on LTS or other old kernels. This is of particular concern when working with embedded SoCs that come with their own vendor-patched version of the Linux kernel. It is often the case with such systems that many BlueZ fixes from more recent kernels have to be backported in order to comply with requirements.

Another implication is that it is difficult to guarantee that a particular version of the Bluetooth specification is supported. This is because there are many parts involved, each evolving differently: the hardware itself, the kernel subsystem and drivers, and the userspace components. In addition, some profiles, such as the audio ones, are implemented with external components, such as PipeWire. This fragmentation makes it hard to assert which Bluetooth specification versions are supported by the system. One has to collect all the pieces, glue them together, configure them for a particular use case and then go through the list of actual profiles and features that are implemented, matching them against the Bluetooth qualification requirements.

Hardware challenges

As with all hardware, Bluetooth controllers are no different in that they may require hardware-specific quirks, such as vendor-specific HCI commands, in order to operate certain features of the hardware or firmware. Unless the hardware vendor actively supports BlueZ for their customers, another distinction between the vendor's proprietary stack and BlueZ is that certain functionality may be unsupported, despite the community's best efforts to support most Bluetooth hardware. This was, for instance, the case with a recent customer, where we needed to patch BlueZ and PipeWire to send particular vendor-specific commands to tap into some niche functions of the firmware. This may be a hard challenge at times, but such is the case with all kinds of hardware, and thankfully the BlueZ community has done a stellar job maintaining a well compatible stack with hundreds of different controllers from various vendors.

On the flip side, having a stack that can operate different hardware without changes is important to avoid vendor lock-in. While proprietary stacks may provide easier access to the full functionality of a specific controller, they can pose challenges when upgrading hardware. Having, potentially, to change the software stack just to get access to a different Bluetooth adapter may be a show-stopper for upgrades, which can easily be prevented by using a vendor-neutral, open source software, such as BlueZ.

We can help!

If you are now left thinking whether choosing BlueZ is a good idea in the first place, let me assure you that it is. The benefits in terms of flexibility, community support, and long-term maintainability make it a worthwhile investment - and that applies to open source software in general, not just BlueZ. Our team has hands-on experience with this entire software stack and can assist in every step - from evaluating hardware compatibility and configuring BlueZ to implementing custom patches and ensuring compliance. If you are considering deploying BlueZ on your embedded Linux device, we'd be happy to help streamline the process and ensure it meets the qualification requirements as effortlessly as possible. Get in touch with us to learn more!