Proximity (Link Loss) and Find Me

by: INdT/OpenBossa BlueZ team

Proximity (PXP) and Find Me (FMP) profiles are publicly available since second half of June. BlueZ does not officially support LE GATT profiles yet. There are pending kernel patches related to interleaved BR/LE discovery, security manager and passive scanning that require more feedback from the community and review. This process takes time, in the meanwhile we would like to share the status and reference to the source code.

First of all, it needs to be clear that Proximity and Find Me are distinct profiles located under the same proximity/ sub-directory, only because they share a common GATT service: Immediate Alert Service.

Proximity’s Link Loss is functional, Path Loss requires tuning and real hardware to test against it, and thus is disabled by default in the configuration file (proximity.conf). After creating a device D-Bus object which supports Link Loss (i.e. a LE device on the Proximity Reporter role), the “high” alert level is automatically written on the remote device, meaning that UI is not necessary to enable alert level (unless you want change it to “mild” or “none”). The “test-proximity” script (under the test/ sub-directory) can be used to change alert levels and also test Find Me (which basically consists of writing some alert level to a characteristic of the Immediate Alert Service).

For LE profiles, the new Bluetooth Management kernel interface (mgmt) is required, mainly due to Security Manager requirements. Even though device discovery works on both interfaces (HCI and Management), only mgmt can be used for current LE GATT profiles, because they require at least security mode 1 level 2.

For re-connections, it is planned to trigger automatic connections based on user (or platform specific) events. For instance, automatic connections would be enabled during a configurable time when the user unlocks the screen (Desktop, phone, tablet, …). The idea is to control connections based on profile requirements and user input. Power saving mode (when scanning) is not being addressed since automatic connection has a small active period.

Much of the code is still under development. While it is not upstream, it can be found in the repositories below.

userspace: git://git.infradead.org/users/cktakahasi/bluez.git proximity-devel
kernel: git://github.com/aguedes/linux-2.6.git proximity-devel

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

Release of bluez-4.96

This release fixes a few minor issues and adds support for auto-pairing of Nintendo Wii Remote devices.

bluez-4.96.tar.gz

Release of obexd-0.42

This release fixes a few minor bugs in the phonebook handling and adds support for the OBEX Action command.

obexd-0.42.tar.gz