BlueZ

It seems that commercial stack manufactures like to spread FUD (Fear, uncertainty and doubt) about BlueZ and its qualification status. Trying to eliminate the open source competition by telling customers that BlueZ can’t be qualified is just plain bad business practice and these companies are lying to you.

The truth is that BlueZ has been qualified according to the Bluetooth PRD 2.0 (and later) and has been used successful in products. The most prominent example is the Nokia N810 Internet tablet. It is based on the Maemo platform which includes BlueZ as one of its core components. If you don’t believe me, check the official qualification record by yourself.

To help qualifying BlueZ based products we split the qualification into components for the host stack (GAP, L2CAP, RFCOMM and SDP) and profile stack. Companies like Nokia, ACCESS, TomTom and others have sponsored the qualification of BlueZ components that can be re-used by others.

Current known qualification records can be found at the BlueZ qualification page and it is expected that are more products out there are using BlueZ and have successfully passed the Bluetooth qualification.

If there exist any questions when it comes to BlueZ qualification, feel free to mail me. You find my email address in the source code.

This version switches to gtk-doc for API documentation instead of Doxygen. It allows an easier and a lot cleaner way for creating and publishing documentation.

libgdbus-0.2.tar.gz

The libgdbus is a helper library to make it easier for system daemons using GLib to integrate with D-Bus. It provides convenient functions for registering interfaces, signals and properties and handles all the introspection details. It also provides a simple API to listen NameOwnerChanged or any other signals without getting into D-Bus low-level details.

libgdbus-0.1.tar.gz

Unfortunately the 4.0 release was more like a brown paper bag release. It didn’t include the compat/sdp.h header file and thus building some of the legacy applications became impossible. To make it easier for the package maintainers to perform the transition from 3.x, here comes a new release that fixes it.

bluez-4.1.tar.gz

This release also includes two patches that should have been already included in the 3.x series, but for some reasons slipped through the net. They should improve the A2DP performance when using ALSA and allow PAN/BNEP to pass qualification testing.

For Bluetooth USB devices, the current driver is called hci_usb. However the new btusb driver is suppose to take over. This update now makes sure that all quirks are also present in this new driver.

patch-2.6.26-mh2.gz

The missing piece in the btusb driver is the full SCO support. Oliver Neukum is working on this and I hope we will see an update soon.

The Bluetooth 2.1 specification has been released over a year ago and so far no Bluetooth 2.1 device made it to market. However in the past months a couple of devices with Bluetooth 2.1 capable chips showed up. The only problem is that even with these chips built in, the host stacks on these devices are still only implementing the Bluetooth 2.0 specification. Examples of such devices are:

• Apple iPhone 3G
• Apple MacBook, MacBook Pro and MacBook Air
• Asus EeePC 901

So in theory all of these devices could support Simple Pairing and Extended Inquiry, but for some reason both companies decided to go the easy way. And I guess there are even more out there since I had a Symbian based Samsung phone in my hands with a Bluetooth 2.1 chips, but no 2.1 features enabled.

All big host stack vendors like Microsoft, Apple, Broadcom and Symbian are working on Simple Pairing support, but only BlueZ has put it out there for public consumption. Seems like everybody is waiting for the others to go first.

So I am most disappointed with Apple here since neither their iPhone 3G nor their new MacBooks make use of the possibilities that their hardware offers.

BD Address:  00:21:E9:xx:xx:xx
Device Name: Marcel’s iPhone 3G
LMP Version: 2.1 (0×4) LMP Subversion: 0x12e9
Manufacturer: Cambridge Silicon Radio (10)
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0×59 0×83

And it is not about which company provided the Bluetooth chip since Apple clearly buys chips from CSR and Broadcom. While on older MacBooks and other Apple machines clearly CSR dominated, they now also go with Broadcom like they have done for their keyboard and mouse products.

BD Address:  00:21:E9:xx:xx:xx
Device Name: Marcel’s MacBook Pro
LMP Version: 2.1 (0×4) LMP Subversion: 0×2187
Manufacturer: Broadcom Corporation (15)
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0×71 0×83

Both iPhones still have a CSR chip in it. The original comes with a 2.0 chip and the 3G version with the 2.1 version of it.

When the Bluetooth 1.2 specification was development, Apple was the first ones to add support for Adaptive Frequency Hopping (AFH) to their products and also provided firmware updates for the chips they used. I expected Apple to push forward with Simple Pairing support, but now I think it is unlikely to happen soon.

BD Address:  00:15:AF:xx:xx:xx
Device Name: Marcel’s EeePC 901
LMP Version: 2.1 (0×4) LMP Subversion: 0x420e
Manufacturer: Broadcom Corporation (15)
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0×79 0×83

The EeePC 901 comes with Windows XP per-installed at the moment. Installing Linux with a 2.6.27 kernel and BlueZ 4.0 on it would make it the first product with Simple Pairing and Extended Inquiry support. So happy hacking.

And finally here it is. The first release of the new BlueZ 4.x series.

bluez-4.0.tar.gz

As mentioned before, the source for bluez-libs and bluez-utils has been merged together. So it is now up the package maintainers to create proper libbluetooth packages from this. It is important that this has been done right in the beginning so it gets simpler for later releases. If questions or issues come up, feel free to discuss them with the upstream developers.

With this new major version a lot of things have been changed:

• The main daemon is now called bluetoothd (instead of hcid)
• The main configuration file is /etc/bluetooth/main.conf and follows INI-style syntax
• The GLib library (with GModule support) is no longer optional, because eglib support has been fully removed
• The old D-Bus API from 3.x series has been fully removed

This release will break compatiblity with bluez-gnome at the moment. Please keep this in mind when starting testing. It is almost the same situation when 3.0 got released. It is the price for creating a cleaner and simpler API. The bluez-gnome will be moved to the new API soon.

This will be the last release supporting the BlueZ 3.x series with the old D-Bus API. It contains some pending bug fixes and a translation update.

bluez-gnome-0.28.tar.gz

The current bluez-gnome CVS repository has been converted into GIT. The new location of the bluez-gnome.git repository is on kernel.org and marks the start of the development for BlueZ 4.x series API.