Collabora contributions to Linux Kernel 4.5

Linux Kernel 4.5 was released earlier this week, and once again Collabora engineers played a role in its development. In addition to their current projects, seven Collabora engineers contributed a total of 33 patches to the new Kernel.

As part of its continued committment to further increase ts participation to the Linux Kernel, Collabora is looking to expand its team of core software engineers. If you’d like to learn more, follow this link.

Here are some highlights of Collabora’s participation in Kernel 4.5:

Daniel Stone improved i915 runtime WARN() messages and fixed an important issue in the component subsystem when component_add() fails. Danilo Cesar made the DRM Docbook ready for Markdown text.

Gustavo Padovan improved the pm_runtime management on the drm/exynos driver and started work on de-staging the Android Sync Framework. On Rockchip, Sjoerd Simons enabled IR receiver to RK3288 Radxa Rock 2 Square, added multi_v7_defconfig for Rockchip audio and enabled RK3288 SPDIF clocks to change their parent. On the net side, Sjoerd added a patch to turn carrier off on phy attach to avoid unknown states and another patch to add ethernet0 alias for the RK3288 to help u-boot find this device-node.

During his brief time with us at Collabora, Heiko Stübner added the dts file for the veyron-brain board, a shutdown callback to platform variant dwc2 devices for a special clock handling to avoid getting stuck on the reboot/poweroff process and multi_v7_defconfig support to Rockchip’s io-domain driver, crypto module and rk808 clkout module. He also enabled support for veyron minnie touchscreen, adjusted temperature limits on veyron-speedy and fixed the edp-24m clock to be associated to the internal 24MHz oscillator all the time.

Martyn Welch added a driver for the Zodiac Aerospace RAVE Watchdog Processor, while Tomeu Vizoso added a device_is_bound() helper function and setter for dev.pm_domain that comes with extra checkings. Tomeu also added a patch to allow USB devices to remain runtime-suspended when sleeping and another patch to optimize sleep by going direct_complete if driver has no prepare and PM callbacks. Lastly, Tomeu also fixed a freq issue on Tegra callback.

Following is a list of all patches submitted by Collabora for this kernel release:

Daniel Stone (3):

Danilo Cesar Lemes de Paula (1):

Gustavo Padovan (9):

Heiko Stübner (8):

Martyn Welch (2):

Sjoerd Simons (5):

Tomeu Vizoso (5):

Collabora contributions to Linux Kernel 4.4

Linux Kernel 4.4 was released this week and Collabora engineers helped in the development of the new kernel in a few different areas. A total of 38 patches from 8 Collabora engineers were added, making it the kernel release with the most Collabora developers ever! Only 7 of the 8 engineers are still part Collabora however, as unfortunately Javier left a few months ago, after completing his patches.

On that note, Collabora is hiring experienced kernel hackers to further increase our participation in the Linux Kernel. If you are interested, please drop a line!

In this release Daniel Stone fixed a potential circular deadlock when loading the i915 GuC firmware and incorrect pipe paramenter on drm_crtc_send_vblank_event() that was leading to WARN_ON. Danilo Cesar Lemes de Paula improved the kernel-doc script to fix an issue with struct drm_modeset_lock not showing at the final kernel Doc and fixes a fault in the highlight processing by using arrays instead of hashes.

Emilio López enabled EC verified boot context on Peach Boards and driver to read/write nvram’s verified boot context to/from userspace for Chromebook devices and Enric Balletbo i Serra added support for TI’s tps65217 charger driver while Gustavo Padovan added cursor support on exynos DRM driver. Javier did some improvements to the Chromebook EC driver.

Sjoerd Simons added rockchip support by default on ARM multi_v7_defconfig and a driver for the SPDIF audio transceiver on rockchip boards. Tomeu Vizoso removed the regulator_list as it was redundant because the regulators devices can be found through the regulator_class, fixed an clk reparenting issue on exynos5250 that was preventing the screen to work after the second suspend.

A full list of all commits is provided here:

Daniel Stone (2):

Danilo Cesar Lemes de Paula (3):

Emilio López (3):

Enric Balletbo i Serra (3):

Gustavo Padovan (3):

Javier Martinez Canillas (3):

Sjoerd Simons (17):

Tomeu Vizoso (4):

Se comunicando com segurança na Internet

O Bloqueio do WhatsApp é bom momento pra gente pensar em segurança da informação.

Se tem um coisa que eu ficaria muito feliz se todas a pessoas entendessem é que a *internet não é um lugar seguro*. Uma analogia que a ajuda a entender: se comunicar online é como morar num quarto que não tem porta, as pessoas podem ir lá e ver qualquer coisa que você está fazendo em privado.

A alternativa ao WhatApp segura é o Signal. Feito por uma galera de fato compremetida com comunição segura. Tem app pra Android e iPhone. (IMPORTANTE: O telegram não é seguro, existem algumas preocupações sobre vulnerabilidades no protocolo de criptografia)

Pra navegar na internet a opção é o Mozilla Firefox, um navegador que não deixa nada a desejar em relação ao Chrome por exemplo.

Porém algumas extensões são necessárias pra de fato navegar com segurança. A Electronic Frontier Foundation (EFF) disponibiliza o HTTPS Everywhere ( e o Privacy Badger( Juntos, eles garantem que sua comunicação com sites que você usa normalmente é segura e livre de espionagem seja de corporações, governos ou criminosos.

Além disso o AdBlockPlus( é um adicional muito bom, bloqueando propagandas e trackers indesejados.

Todas essas ferramentas são software livre, isso significa que o código fonte desses software está disponível para consulta e contribuições de terceiros.

Do mesmo jeito que pensamos em segurança no dia-a-dia devemos pensar nela na internet. Você não deixa seu portão ou carro aberto pra que quiser entrar. Você não troca segredos com seu namorado(a) na frente de outras pressoas. Na internet é mesma coisa.

Quem quiser saber mais, ou trocar idéia disso, mande um alô.

Collabora contributions to Linux Kernel 4.3

Collabora developers contributed 48 patches to kernel 4.3 as part of our current projects.

Danilo worked on the kernel doc scripts to add  cross-reference links to html documentation and arguments documentation in struct body. While Sjoerd Simons fixed a clock definition in rockchip and a incorrect udelay usage for the stmmac phy reset delay.

Tomeu fixed gpiolib to defer probe if the pin controller isn’t available, added another fix to chipidea USB to defer probe of usbmisc hasn’t been probed yet. On Tegra Tomeu worked to support to gpio-ranges property. Still on Tegra cpuidle_state.enter_freeze() was added.

Gustavo Padovan did a lot of exynos DRM work, with the most important changes being improvements to atomic modesetting, including the asynchronous atomic commit in exynos, in async mode we just schedule the atomic update and return right away to the userspace, in a similar way that PageFlips works in the old API. In this release the exynos atomic modesetting interface was enabled for userspace usage. Another important set of patches was the removal of structs exynos_drm_display and exynos_drm_encoder layers which greatly improved the code making it cleaner and easier to use. Apart from that there is also a few cleanup and fixes.

Danilo Cesar Lemes de Paula (2):

Gustavo Padovan (36):

Javier Martinez Canillas (1):

Sjoerd Simons (2):

Tomeu Vizoso (7):

Linux Kernel Engineer opportunity at Collabora!

Collabora is a software consultancy specialising in bringing companies and the open source software community together and it is currently looking for a Core Software Engineer, that works in the Linux kernel and/or all the plumbing around the kernel. In this role the engineer will be part of worldwide team who works with our clients to solve their Linux kernel and low level stack technical problems.

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!

Collabora contributions to Linux Kernel 4.2

A total of 63 patches were contributed upsteam by Collabora engineers as part of our current projects.

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 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):

Bluetooth Changes for Linux 3.10

The 3.10 development cycle was kind busy, we managed to add more than 110 patches in mainline. Almost half of this work comes from Johan Hedberg and it includes the addition of the HCI request framework, an infrastructure to handle HCI commands asynchronously, it is especially useful for situations where the HCI Core needs to send a number of commands at once. A optional callback will return when all commands are completed. We were able to fix many issues with the request framework. Fixes were also provided by Andre Guedes.

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.


GNOME 3 gets to know BlueZ 5!

I n the past two months I’ve been busy porting GNOME 3 to use the new BlueZ major version, BlueZ 5. I did this work along with Emilio Pozuelo Monfort – a colleague of me at Collabora.

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

Bluetooth Changes for Linux 3.9

The 3.9 cycle in the Bluetooth subsystem was a way more calm than the previous ones. 49 non-merge patches were pushed upstream through bluetooth-next this time. The bulk of changes for this release comes from Johan Hedberg. Along with many fixes to the HCI Management code he also added support for 32 and 128 its UUID in the EIR data.

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!

The big changes of BlueZ 5

The BlueZ project recently made a new major release, BlueZ version 5. This release brings tons of new features and improvements, however it is also accompanied by a significant  API change that makes it non-backwards compatible. BlueZ has changed to use the standard D-Bus Properties and Object Manager infrastructure, simplifying the handling of D-Bus interfaces and notifications. In addition to matching to D-Bus standards, the API of some of our interfaces also had to change, either to support new features and use cases or to optimize the API usage.

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.