BlueZ

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.

It is now official that bluez-libs-3.36 and bluez-utils-3.36 were the last releases in the BlueZ 3.x series. Both repository are now in maintenance mode and only important security fixes will justify another release from the 3.x branch.

For the BlueZ 4.x series the repositories have been moved from SourceForge.net over to kernel.org and we are now using GIT for revision control. Also bluez-libs and bluez-utils have been merged back together into one common bluez.git repository.

The 4.x series brings two important changes. The first one is that the eglib support has been completely removed. This means that GLib now becomes a hard depedency. The second one is that we removed the old D-Bus and now fully concentrate on improving the new API and making the code simpler, cleaner and easy to read and understand.

We haven’t had time to move bluez-gnome over to the new D-Bus API. So if you wanna try bluez-4.x be warned that this will break.

The merge window for the Linux 2.6.27 kernel opened just after the official release of 2.6.26 and on the Bluetooth side we have a big update pending to be merged. Most changes are security enhancements and full support for Simple Pairing from the Bluetooth 2.1 specification.

After an absence of two kernel release, I started to produce my -mh kernel patches again. And since we are moving a lot of the infrastructure to kernel.org these patches have their new home their, too. So have fun with it.

patch-2.6.26-mh1.gz

During the BlueZ developer meeting in Helsinki a month ago we talked with Lennart Poettering about the native integration of A2DP and Headset support with PulseAudio. He requested some enhancements to our Bluetooth support in the Linux kernel for a better synchronization of the audio stream.

• Support for SO_TIMESTAMP and/or SIOCGSTAMP/SIOCGSTAMPNS
• Support for TIOCOUTQ and TIOCINQ ioctls
• Support for retrieving the remote clock value

The current GIT tree is based on the 2.6.26-rc8 kernel release and contains support for the first two items on his list.

Adding the possibility to retrieve the remote clock value has not been implemented yet. The technical part is not really complicated, but I am not sure on how to present this information to the user-space.

This patch set also contains an update to the Simple Pairing support and a fix for the driver model integration of the low-level connections.

The bluez-libs-3.33 and bluez-utils-3.33 release introduced the user-space support for Simple Pairing via the new D-Bus API. The missing piece to make this fully work where appropriate kernel patches. These are now available via a GIT tree.

This patch series is based on the 2.6.26-rc7 kernel release and also contains fixes for the HID disconnect detection and updates to the RFCOMM TTY handling.

It is important that these changes are intensively tested before we start submitting them for the 2.6.27 merge window. Everybody with Bluetooth 2.1 hardware, please start testing and give feedback via the BlueZ developer mailing list.

The 3.33 release was suppose to be the last one before hitting 4.0, but unfortunately it is not. We will have 3.34 and maybe 3.35 to stabilize the 3.x series before it can enter maintenance mode. This still means that 4.0 is only a glimpse away.

With 4.0 a lot of things will change. The first big one is that bluez-libs and bluez-utils will be merged back into one package called bluez like it was for the 1.x series. These two packages have been released in sync since the whole 3.x series and so it only makes sense to combine them. It is then up to the package maintainers to split the library part into a libbluetooth package and so on.

The old D-Bus API will be removed. We gonna have a whole new D-Bus API set that is smaller and more powerful. It is a big step and will improve the usage of Bluetooth for end user applications a lot. In the current 3.33 release, both APIs exists in parallel to give current developers an outlook what is coming. So start using the new API.

Our embedded GLib support will be removed. The 4.x series will have a hard dependency on the GLib base library. The reason for doing it is that mainting the embedded GLib part became to much of a burden and took a lot of resources.

All future development will be done in a GIT tree on kernel.org and the CVS repositories at SourceForget.net will be marked as read-only. We will keep them for reference and potential security updates for the 3.x series.

Stay tuned. More updates on this topic will follow…

The www.bluez.org webserver had a major harddrive crash and is now partially back online. It is expected that the missing content gets merged over the weekend.