Archive for the ‘News’ Category.

GSoC: Accepted Students Announced

Yesterday Google released the accepted students for this year’s Google Summer of Code and BlueZ will be participating with 4 students:

Project: Bluetooth Replayer
Student: Anton Weber
Mentor: Anderson Lizardo

Project: OBEX Filesystem In Userspace
Student: Michał Poczwardowski
Mentor: Vinicius Gomes

Project: Implement AVRCP 1.3 Controller Role
Student: Rafael Fonseca
Mentor: Luiz Augusto von Dentz

Project: Visualization of Bluetooth traffic
Student: Thiago da Silva Arruda
Mentor: Gustavo Padovan

It is now community bonding time, where students get know their mentors and the community. We wish a great summer to all students.  :-)

 

BlueZ on Google Summer of Code 2012

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.

We hope to have a great summer in this year’s Google Summer of Code.

Bluetooth Changes for Linux 3.1

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:

git shortlog -n v3.0..origin/master –no-merges  net/bluetooth/ include/net/bluetooth/ drivers/bluetooth/

GSoC: BlueZ projects sucessfullly finished

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:

Improve EDS backend of Phone Book Access Profile (PBAP)
Student: Bartosz Szatkowski
Mentor: Claudio Takahasi

Nintendo Wii Remote Device Driver
Student: David Herrmann
Mentor: Gustavo Padovan

Implementing the Basic Imaging Profile(BIP)
Student: Jakub Adamek
Mentor: Vinicius Gomes

Implement the Video Distribution Profile(VDP)
Student: Prasad Bhat
Mentor: Luiz Augusto von Dentz

That is it for this summer, I’m hoping to have another great summer on GSoC next year.

GSoC: Video Distribution Profile(VDP)

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:

  1. 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.
  2. 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.

By Prasad Bhat

GSoC: Basic Image Profile(BIP)

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.

By Jakub Adamek

GSoC: Nintendo Wii Remote Device Driver

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].

By David Herrmann

[1] http://github.com/dvdhrm/xwiimote_kernel
[2] http://github.com/dvdhrm/xwiimote

GSoC: EDS backend of Phonebook Access Profile(PBAP)

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.

By Bartosz Szatkowski