February 17, 2021
Time continues to fly by and 2021 is finally here. A year that could be known as the year of Rust in Linux kernel! Ok, maybe we're ahead of ourselves here, but it's fun to think about that. In the meantime though, Linus has released v5.11, so let's look at what has been contributed by Collabora.
We are certainly living in very exciting times, working on a kernel that has never been more stable. Or at least, that's how one feels reading the recent discussions related to kernel version overflow.
For v5.11, Collabora's team has merged exceptional patches, which were made possible with the contributions of the awesome kernel community.
Among the highlights in this release we have: the new Syscall User Dispatch mechanism, and the destaging of the both the H.264 stateless decoding interface and the Rockchip ISP driver. Let's dive in.
Hardware-accelerated decoding with stateless IP blocks is available in quite a few SoCs (including platforms from NXP, Rockchip and Microchip) so the V4L2 stateless decoding support is an important area of work.
Continuing our work on CODECs, in this release the V4L2 community finally stabilized the H.264 decoding stateless API. This was a requirement for FFMPEG to support the V4L2 stateless hardware-accelerated backend, which is now in progress.
If you are curious about GStreamer's v4l2codec element, we've got you covered as well.
Why is stabilizing this H.264 API interface a big deal, given H.264 is nearly 20-years-old? Despite its age (note that many of us are about double or even triple this age and we are still very alive and kicking out patches), the H.264 codec continues to be relevant.
Of course, H.264 is only one piece in the grand scheme of CODECs. The next step is to complete the V4L2 stateless decoding support for HEVC, as well as VP8 and VP9.
The rkisp1 drives the camera capture functionality of Rockchip SoCs (RK3399, RK3288, RK3326, PX30), which is present in devices such as Acer Chromebook Tab 10, ROCK Pi 4 and Pinebook Pro laptops. Note the rkisp1 driver only supports RK3399 at the moment, however the media community is working on RK3288 and PX30/RK3326 support.
Merged in v5.6 under staging, Collabora has kept working on rkisp1 with cleanups, bug fixing and, most importantly, stabilizing the uAPI, so we could safely move the driver out of staging in v5.11.
And it finally happened in v5.11 In this version we stabilized the device tree definitions, added support for capturing simultaneous streams, and contributed to the definition of an uAPI that is compatible with other Rockchip SoCs variants the driver may support in the future.
We also contributed to libcamera.org and worked on Chrome OS integration to complete the full camera stack.
libcamera, an open source camera stack, works out-of-the-box for basic capturing use cases, but not yet with 3A Algorithms. Please get in touch if you are interested in an Open Source 3A implementation for Rockchip SoCs.
For more technical details on the driver, check rkisp1 documentation.
One of our areas of work involves improving the Linux Kernel support for Wine. In this release, our team solved an interesting problem related to intercepting, filtering and emulating system calls efficiently.
Mechanisms for intercepting system calls exist and are broadly used elsewhere, but none fit the performance requirement of modern DRM-enabled Windows applications running with multi-personalities - that is, an application that is part native (the wine part) and part foreign (the windows code).
Our solution, which we called Syscall User Dispatch, introduces a new interface that, once configured, is entirely controlled from user space. This completely eliminated costs usually associated with the filtering of system calls on the native part.
With the kernel side of this work completed in v5.11, the long-term result should be more and more modern Windows games being supported by Wine and other compatibility layers for Linux.
The input subsystem in the kernel is a rather old one, but that doesn't mean nothing happens there. Quite the contrary, the development is as active as elsewhere. In particular, at Collabora we worked on a new input inhibition feature.
At a basic level, inhibiting an input device simply means ignoring input events from it. When an input device driver is inhibited, events are not passed to input handlers and thus have no effect. This can in turn be exploited by drivers, for instance turning off the device and save power. The kernel exposes the feature to applications, through a sysfs "inhibited" device property.
This feature is very useful in devices such as convertible laptops. One way of using such a laptop is tablet mode, where the physical keyboard ends up just under the touchscreen. While holding your device in this mode, you can't avoid accidentally pressing the keyboard keys, but the system is there to save the day, temporarily inhibiting your keyboard.
The feature was originally introduced by the Chrome OS team a few years ago and we are more than happy to see it landing upstream in v5.11, with the help of the input community.
Now that the feature is in place, it opens new possibilities for future development. Not all input device drivers currently support inhibition, so adding it (where feasible) is an area where we might expect some activity.
Debos is used throughout Collabora to create various custom OS images from simple recipe files. An important example is Apertis where the nightly image build pipeline consists of over 50 Debos jobs, most of which could run in parallel. Debos uses the fakemachine library under-the-hood to create throw-away virtual machines to sandbox the build from the host.
Until recently, Debos was only able to use KVM to create these ephemeral virtual machines which meant that each job in our GitLab CI/CD Pipelines had to run on a machine which supported KVM. Since most of the low-end cloud machine types don't allow you to run nested virtualisation, custom machines had to be setup for these specific jobs which has ended up being a bottleneck since the machines only allowed a limited number of jobs to run in parallel.
Last year Collabora integrated User Mode Linux (UML) support into Debos and Fakemachine which allows a standard cloud machine to build OS images, albeit a little slower than those running in KVM.
As a result of this effort, a very interesting data-corruption bug was uncovered in the user-mode-linux storage driver. The issue appeared when the communication pipe to the emulated disk was overloaded, and a multiple segment I/O request was submitted by a user application. In this case, there was a possibility of an I/O request being only partially executed.
The solution landed as a lenghty patch, rewritting most of the submission/completion code to provide atomicity guarantees when executing a segmented I/O request.
Additional miscellaneous patches were merged, the first to port the guest's random-number generator driver to the more generic hwrng framework (as the original implementation blocked random number generation for around three minutes after boot) and a second patch to allow virtualised disks to have a label attached to them.
We will continue to work on User Mode Linux support for Debos so remember to subscribe to the blog!
Continuing our work on MediaTek SoCs, we've merged a new power domain driver in this release, which deprecates the old one. The new driver not only adds support for the MT8183 chip, but also paves the way for the upcoming Mediatek SoCs.
As Chromebook's popularity continues to rise, these new MediaTek devices are playing an important role in the premium Chromebook scene. We are very excited to be part of the effort: coming up next in our roadmap is mainlining display panel support for the Chromebook IdeaPad Duet!
Adrian Ratiu (1):
Andrzej Pietrasiewicz (3):
Boris Brezillon (5):
Christopher Obbard (2):
Dafna Hirschfeld (14):
Enric Balletbo i Serra (12):
Ezequiel Garcia (20):
Gabriel Krisman Bertazi (31):
Guillaume Tucker (2):
Helen Koike (9):
Boris Brezillon (6):
Enric Balletbo i Serra (8):
Sebastian Reichel (33):
Andrzej Pietrasiewicz (1):
Dafna Hirschfeld (4):
Enric Balletbo i Serra (13):
Ezequiel Garcia (1):
Helen Koike (3):
Dave Stevenson (1):
Eddie Cai (1):
Heiko Stuebner (3):
Jitao Shi (1):
Jonas Karlman (1):
Matthias Brugger (8):
Mauro Carvalho Chehab (1):
Michael Klein (1):
Patrik Fimml (1):
Sebastian Krzyszkowiak (5):
Shunqian Zheng (2):
Tom Rix (1):
Weiyi Lu (3):
Yongqiang Niu (1):
Alyssa Rosenzweig (1):
Boris Brezillon (3):
Dafna Hirschfeld (2):
Daniel Stone (2):
Ezequiel Garcia (4):
Gabriel Krisman Bertazi (2):
Pekka Paalanen (2):
Christopher Obbard (1):
Daniel Stone (1):
Emil Velikov (1):
Enric Balletbo i Serra (3):
Helen Koike (17):
Pekka Paalanen (3):
Tomeu Vizoso (19):
Christopher Obbard (1):
Enric Balletbo i Serra (1):
Guillaume Tucker (1):
Andrzej Pietrasiewicz (1):
Martyn Welch (1):
We first announced our work on the driver last December, and posted an update earlier this year. We are now happy to announce a second update…
Simplifying AGL's existing Wayland-based graphical stack and avoiding the use of modules that aren't maintained upstream has lead to the…
Thanks to a new, low overhead extension in Mesa, OpenGL and Vulkan applications can now talk to each other, bringing more flexibility to…