BlueZ was accepted to take part in GSoC 2012, if you don’t know what GSoC is, please go to its page and learn about.

We have already published our list of ideas, so if you are a student take a look there and check what might interest you. Then you can talk to one of our mentors to learn more about and work on a GSoC proposal. You can get more information about BlueZ on GsoChere. Our contact info is on the same page.

The 3.1 release is coming and it’s time to see what have changed in the Bluetooth subsystem. The biggest part of the changes are related to Bluetooth Low Energy, Andre Guedes worked in adding LE Adversiment cache support, all the remote devices found are cached in a list and after a defined timeout this list is flushed. Vinicius Gomes and Anderson Briglia added a initial implementation of the LE Security Manager Protocol. At the moment only JustWorks pairing is implemented.

Gustavo Padovan worked in another L2CAP refactoring patchset towards a clear separation between l2cap_core.c and l2cap_sock.c. Peter Hurley fixed a lot of potential deadlock over all the Bluetooth subsystem. Mat Martineau reworked the local busy handling inside the L2CAP Enhanced Retransmission Mode.

There is also many minor changes, fixes and clean ups, like HCI auth path fixes by Waldemar Rymarkiewicz, remote device blacklisting in the MGMT interface among many others.

A full changelog can be viewed issuing the following command against linus’ tree:

During this summer four students took part in Google Summer of Code with BlueZ. All four have passed the final term and produced a lot of code. Each of them the wrote a report about their projects. The reports were posted in bluez.org. Here follows the links:

This summer Prasad Bhat worked in the support for the Video Distribution Profile(VDP) as his Google Summer of Code project. Check his report below.

The Video Distribution Profile provides a way for device share a streaming video from one device to the other. This project involves implementing VideoSource and VideoSink roles for the devices. And developing GStreamer elements for the VideoSource and VideoSink. There are mainly two parts in the project:

Video Streaming Set Up When a device wishes to start streaming of video the device firstly needs to set up a streaming connection. During such set-up procedure, the devices select the most suitable video streaming parameters.

Video Streaming Once streaming connection is established both source and sink are in the STREAMING state, in which the source is ready to send video stream and sink is ready to receive the video stream.

The source will encode the data into selected format and the stream data is sent out on the transport channel using the selected transport services defined in AVDTP.
The AVDTP entity of the sink receives the stream data from the transport channel using the selected transport services and passes it to the application layer. The frame of video will be decoded according to the selected coding format.

What we have done so far:

Me and my mentor Luiz Augusto von Dentz have completed the signaling procedure which works similar to signaling of A2DP.
We have developed the GStreamer elements for the VDP gstvdpsink and gstvdpsrc.
For now we have added support for H263 baseline and MPEG-4 visual simple profile encoding in gstvdpsink. Similarly H263 baseline and MPEG-4 visual simple profile decoding in gstvdpsrc. The source and sink support H263 baseline level 10, level20 and level30. The MPEG-4 visual simple profile supports level0, level1 and level2.

Status of the project:

Since the VDP and A2DP both use the AVDTP, we are attempting refactoring the code. I will get everything upstreamed within two weeks. We are testing the gstreamer elements gstvdpsink and gstvdpsrc.Since both VDP and A2DP use AVDTP.

This summer Jakub Adamek worked in the support for the Basic Image Profile(BIP) as his Google Summer of Code project. Check his report below.

My Google Summer Of Code project was to implement the Basic Imaging Profile in obexd, and with Vinicius Costa Gomes as my mentor and the help of the Bluez community.

BIP is an OBEX based profile. Its specification can be found here. It was created primarily to give devices a way to negotiate encoding and image size before exchanging image data. Given the multitude of image formats in use, having such a mechanism is necessary to make sure a transferred image can be used by the receiving device. BIP also ensures some interoperability by defining an image format that can be understood by all implementations (called an imaging thumbnail in the spec).

The code of my implementation can be found here. The main reason that it is not in the Obexd tree is that the profile requires support for User-Defined Headers. Obexd is currently in transition, with OpenOBEX being phased out in favor of gobex, which
supports User-Defined Headers cleanly. After that transition is complete shifting the BIP code will be possible.

The profile is divided into 6 features. I’ll try to outline for you what these features are for, to what extent they are implemented and
why.

Image Push and Image Pull provide functions used to exchange image data. Between them, their functions allow a client to list images on the server, find out their properties (such as encodings and pixel sizes they are available in); upload and download images, attachments and thumbnails. We decided on using a command line configurable BIP root folder (like the FTP root folder) to store uploaded and downloadable images. The server accepts all possible image formats and by using the MagickWand library converts the images stored to whatever format the client desires. All functions these features support are mapped out to DBus methods provided by the Obexd client.

Automatic Archive allows a device (e.g. a camera) to request its recently captured images to be downloaded by another device. This feature requires the establishment of a second connection used for actual data transfer, in which the former server becomes the client and vice versa. We decided on a solution where the obexd server uses the obexd client via dbus to establish this connection – thus using this feature without the client is impossible. Images pulled are stored in the BIP root folder. The client implementation lacks one optional function because it is difficult to implement under OpenOBEX but should be simple with gobex. The client uses the obexd server for handling the secondary connection, and the source of the images to be archived is the BIP root folder.

Advanced Image Printing gives the possibility to control a printing device using the Digital Print Order Format. Obtaining the
specification for DPOF however requires a licensing agreement (see http://panasonic.jp/dc/dpof_110/white_e.htm), and thus I resigned from implementing this feature.

Remote Camera and Remote Display can cause specific actions in devices, and so their implementation in the server allows registering agents to handle such actions. Remote Camera can be used to request a digital still camera to capture an image, while Remote Display gives the possibility to upload images to a displaying device (e.g. a projector) and control which of them are shown. The agent APIs are currently simple and could use refinement. For Remote Camera unfortunately no truly useful agent implementation exists as of this moment, though writing one using e.g. libgphoto2 as a back-end is possible. A primitive proof of concept agent implementation exists for Remote Display that uses Okular to display the received images on screen. Both features have client implementations that map out all functions to dbus methods on the obexd client.

That’s the status as far as functionality goes. The code could use some polishing and there are some things that can definitely be done better. At least after reading this you should be well informed. Even if time constraints may cause progress to be slow, it is underway, so please stay tuned.

This summer David Herrmann worked in the support for the Nitendo Wii Remote Device Driver as his Google Summer of Code project. Check his report below.

During this summer’s GSoC I’ve been working on getting Wiimote support into mainline bluez. The wiimote has a proprietary HID interface and several projects existed that allowed limited use of wiimotes under linux. With bluez-4.96 and linux-3.1 release I am proud to announce, that mainline linux now supports full wiimote access. Bluez was extended to
support binary PINs and the wiimote-pairing process so connecting wiimotes should be as easy as connecting any other bluetooth device.
With linux-3.1 release, the first basic wiimote HID device driver is introduced into the kernel. It handles wiimote I/O and provides an
input device to userspace to report button events. It also allows userspace to access the LEDs of the wiimote via led_classdev API
(sysfs via /sys/class/leds/).

Linux-3.2 will add support for additional wiimote peripherals, including the accelerometer, the IR cam, force-feedback rumble motor
and the wiimote extensions Nunchuck and Classic Controller. Current development focuses on userspace libraries and on X11 XInput2 drivers so using wiimotes will be as easy as any other input device. So stay tuned for further improvements and feel free to test development versions of the kernel device driver [1] and the userspace tools [2].

This summer Bartosz Szatkowski worked in the EDS backend of Phonebook Access Profile(PBAP) as his Google Summer of Code project. Check his report below.

Through last two months I’ve been working on Phonebook Access Profile (PBAP) in obexd, that uses Evolution Data Server (EDS) as data backend. PBAP let you use your PC, smartphone, tablet, etc. together with your Bluetooth device (like carkit or headset) for wireless addressbook access. For example you may use your car dashboard to pick a contact, from your phone adressbook, to call or your headset may tell you who is calling to you right into your ear — without ever touching the phone. EDS is main contact store on MeeGo (but you may use it on any other Linux distribution) so there is wide range (and it’s growing!) of devices you me use.

After three months of work, there is fully functional PBAP implementation for evolution data server, that let you use all yours
address books (even online services like google contacts — as far as it is supported by EDS). There are two things left to be done:
upstreaming support for vCards 2.1 into EDS (patch is waiting for review), second one is to do more testing and live usage to ensure
stability and catch as many interoperability problems as we can.

Yet another busy release. More than a hundred of commits for the Bluetooth subsystem will be in the upcoming kernel 3.0 release.

Those patches has the last bits for the Management Interface, By Johan Hedberg. There should be things to fix and minor features to implement, especially about Bluetooth Low Energy, but the hard work is done.

Another big set of changes is in the L2CAP layer, where Gustavo Padovan is rewritten some parts of it to remove the socket dependence from the L2CAP core. This will help fix many issues in the RFCOMM layer and will help the AMP Manager implementation.

Szymon Janc worked in add Out Of Band Pairing Support to the Management Interface and to replace the kernel_thread() usage with the kthread API among other fixes.

There is also support for 16 digit PIN code in the Legacy Pairing, and lot of bug fixing and clean ups.