Collabora is well-known for its strong relationship to upstream development, so it is an important part of this role make significant contributions to upstream projects.
Visit our jobs page or talk me to put you in contact with our Hiring Team!]]>
In the ARM multi_v7_defconfig we have the addition of support for Exynos Chromebooks, all options that had a tristate Kconfig option were added as module. After this change it was found that a few drivers weren’t working properly when built as module, so this was fixed. This work was done by Javier Martinez.
Javier also added multi EC support as newer Chromebooks have more than one Embedded Controller in the system.
Tomeu Vizoso added EMC (External Memory Controller) support to the Tegra124 platform.
On the DRM side initial support for Atomic Modesetting was added to Exynos devices by Gustavo Padovan. The Atomic Modesetting interface allows all screen updates such as changing modes, pageflip and set planes/cursors to happen in the same IOCTL. Thus everything can be updated atomically. More on that can be found at Daniel Vetter’s post at LWN.net. Another contribution, from Daniel Stone, to Atomic Modesetting was the addition of the CRTC state mode property, it is through this property that userspace configure a modeset that will be updated via an Atomic Modesetting ioctl.
Following is a list of all patches submitted by Collabora for this kernel release:
Daniel Stone (17):
Gustavo Padovan (17):
Javier Martinez Canillas (19):
Tomeu Vizoso (11):
Another important work that got merged was the HIDP session management rewrite by David Herrmann. The old code was suffering a lot with ref-counting issues and bad tracking of instantiated structs. This work improve this, and also adds better ref-counting handling in other parts of the stack (HCI and L2CAP).
Dean Jenkins did a similar work for the RFCOMM subsystem, so now is more reliable and track objects properly. Marcel Holtmann added a better handling for devices that need special vendor commands in their init procedure. Other than that we got a couple of device ID added, many bugfixes clean up and small improvements all over the stack.
We managed to rewrite a good part of the Bluetooth support in GNOME, most of this provided by the gnome-bluetooth component. During the port we also managed to do a major cleanup on it, mainly because the new BlueZ 5 API is a way more simple than the old one. The UI stayed basically the same, with some small improvements here and there, as an example, now the bluetooth-wizard only shows the valid Passkey/PIN options so the user don’t end with a pairing failure for choosing an invalid one.
The replacement of obex-data-server with Obexd in gnome-user-share was also in the roadmap, however due to the lack of some features in Obexd, mainly the ability to enable/disable the Server side of Object Push Profile(OPP) and File Transfer Profile(FTP). In GNOME a user can disable Bluetooth sharing or if a fast-switching happens the Servers needs to be stopped. The initial patches to support Obexd are working perfectly fine, but are still pending in the GNOME Bugzilla waiting for the missing features to land in the BlueZ repository, Once this happens the gnome-user-share patches should be reworked and then pushed upstream.
All the code already upstreamed will be part of the upcoming GNOME 3.10 release in a few months. While this does not happen you can go to git.gnome.org and fetch all the fresh new code, play with it, and give feedback back to us. :)
Despite the fact the port is complete, there is still room for a number of UX improvements in the Bluetooth bits of GNOME. Changes to the UX should happen in the near future, so stay tuned for more announcements, or join the loop to help this happen.
I would like to thank Bastien Nocera – gnome-bluetooth maintainer – for all his help during the development and the BlueZ developers for joining discussions on how to improve BlueZ APIs to cover the use cases the arose during the last two months.]]>
Other than that we only have fixes and clean ups from Andre Guedes, Andrei Emeltchenko, Gustavo Padovan, Rami Rosen and Szymon Janc.
One can always see all Bluetooth commits in the 3.9 with the following command line:
git shortlog –no-merges v3.8..v3.9-rc1 — net/bluetooth/ include/net/bluetooth/ drivers/bluetooth/
The 3.10 release is going to be a busy release for Bluetooth subsystem,so stay tuned!]]>
Another sensible change is related to the kernel requirements of BlueZ 5.0. BlueZ developers have recently added the Bluetooth Management (MGMT) Interface to the Linux Kernel, which significantly improves the Bluetooth experience on Linux. Among other things, you now get fine control of the HCI commands and events we send and receive to/from the Bluetooth device. In the past, this control was split between userspace and the kernel, creating synchronization problems. Now, it is handled solely by the MGMT interface in an internal queue inside the kernel. This change makes the bluetoothd daemon wake up a lot less often, saving more CPU and power for your system. A nice side-effect of those changes is that we could also get rid of blocking operations in the bluetoothd daemon when talking with Bluetooth devices.
As the MGMT interface is the only one to support the new Bluetooth Low Energy devices, BlueZ developers decided to drop support for the old interface once MGMT was completed. As a result, you need to be running Linux Kernel 3.4 or newer to use BlueZ 5.
While BlueZ developers felt the API change was necessary for this new BlueZ release, they understand that API breaks are painful for everyone. Therefore, in BlueZ 5 they introduced the notion of API versioning. For example, let’s say that today BlueZ supports “org.bluez.Device1” and “org.bluez.AgentManager1” interfaces, among others. The “1“ would refer to version 1 of the API. If for some reason we need to upgrade the Device API a new interface, “org.bluez.Device2”, could be created while still supporting the “org.bluez.Device1” interface. The two interfaces will therefore be supported simultaneously, giving you time to port your software to the new API instead of seeing things breaking overnight.
To help you with the migration to BlueZ 5, we released an extensive guide introducing the new APIs.
If you need help to bring your product to the future of Bluetooth on Linux, Collabora is available to assist you with your adoption of BlueZ 5. We can also help you on any commercial support, development or training around BlueZ, come talk to us.]]>
Another important set of patches is from Johan Hedberg to enable support for Low Energy single mode Bluetooth radios. Those are now well supported by the Linux Kernel.
A new printk modifier, %pMR, was introduced to help print Bluetooth devices addresses, which are stored in the little endian order. The modifier was actually introduced in 3.7, however we could only make the changes in the Bluetooth subsystem for 3.8. Then we were able to remove the old and racy batostr() function from the subsystem. This was work of Andrei Emeltchenko.
Also, the ongoing work of split the L2CAP code into the Core an Socket parts gained a few more improvements by Gustavo Padovan. More work is expected to come in the next releases.
The SCO socket interface gained support for the Defer Setup feature, which is already present in the L2CAP and RFCOMM sockets interface. Defer Setup allows the kernel to ask the userspace if it wants to accept an incoming connection or not. Sometimes we don’t even want connections to be established, so stopping them at the CONNECTING state is of great help.
Apart from that we added support for 5 new Bluetooth devices that do not report themselves correctly as Bluetooth devices or need some firmware to be loaded. And as usual we had a lot of small changes, comprehending fixes, clean ups and small improvements.]]>
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. :-)
I would like to take the opportunity to thank people at ProFUSION for the time I’ve working there. Those were good times.
And for the Collaborans: I hope we will rock a lot together. I’ll keep updating this blog with posts about my work at Collabora.
See you around. ;-)]]>
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.]]>