Andrzej Pietrasiewicz
June 04, 2020
Share this post:
Reading time:
While the previous kernel was released at a time when many countries had already been affected by the COVID-19 pandemic, most of the work was actually completed before the spread of the SARS-Cov-2 virus. Kernel 5.7 development, on the other hand, took place after the lockdown measures were introduced.
Despite these significant changes, the kernel community has remained strong, forging ahead thanks to remote working already being the de facto mode of collaboration. Of course, there are, and continue to be, many people in the kernel community directly affected by the pandemic, and by no means should we forget the hardships these last few months have brought.
So, first and foremost, stay safe, follow any and all government guidelines, and of course, use your common sense. And once that's done (aka "adjusting to the new new normal"), sit back, grab a coffee and catch up on everything kernel 5.7 brings, including the contributions by Collaborans, detailed below! As usual, make sure to head to LWN for a detailed summary of the 5.7 merge window (part 1 & part 2).
The Hantro JPEG driver is currently in staging and has suffered from heavy image distortion when encoding with the quality setting not set to 100%. For example, this is the famous "Deadline" sequence encoded with quality=91:
The reason for this was compound and in itself is an interesting case study, which will be published in a separate blog post. The changes made by Andrzej Pietrasiewicz ([1] [2] [3] [4]) helped a lot:
This work provided us with a lot of fun and a ton of satisfaction when we completed it. We love such challenges! Having JPEG working properly allows offloading of image compression from the CPU to a dedicated piece of hardware. Smartphones will usually compress images with JPEG anytime you take a picture, so offloading that process from the CPU lets it do other things while encoding is in progress.
In the previous kernel release, Boris Brezillon started adding support for bus format negotiation in DRM bridges. Let's recall: A display pipeline is a chain of components (crtc -> encoder -> [bridge x n ] -> connector -> display ) where each element must know the pixel stream format sent by the previous element in the chain. Until now, bridges were lacking support for bus format negotiation, which was acceptable, either because the bridge only accepts one format, or because the format hardcoded in the driver was the one used by everyone. With bridge drivers being re-used in various configurations, the "one setting fits all cases" approach no longer works.
In 5.7, the second part of this work has landed ([1] [2] [3] [4] [5] [6] [7] [8] [9] [10]). Thanks to that, the bus format selection is done at runtime by testing all possible combinations across the whole bridge chain until one is reported to work.
Who remembers the times when we had to manually take care of which kernel modules are loaded at startup or when a piece of hardware becomes available? We're so used to this happening automatically now, but nothing happens "just because" and needs to be handled somewhere. The respective framework is generic enough to handle all modules and includes module aliases and uevents. i3c, the emerging chip-to-chip bus standard is gaining module alias generation now thanks to work by Boris Brezillon, so from now on we can enjoy our i3c modules loading automatically.
We've known Device Tree for a long time now and its usefulness has been proven especially in embedded systems. The Device Tree syntax itself does not tell us anything about what kind of dts entries make sense or are needed in the context of each particular piece of hardware.
Providing that information is the purpose of well-written bindings documents, which traditionally had been a prose-like description. Well-structured and computer-readable documentation lends itself to automated checks and allows verification of the respective Device Tree entries. That is why there's an ongoing effort to rewrite Device Tree binding documentation in YAML, which is both human-readable and at the same time structured enough for easy processing. Dafna Hirshfeld submitted 4 patches ([1] [2] [3] [4]), bringing us closer to the ultimate goal of having all bindings in YAML ;) There's also another series from us which is not completely merged yet, but some dts changes are.
The vimc (Virtual Media Controller Driver) emulates complex video hardware using the V4L2 API and the Media API. It has a capture device and three subdevices: sensor, debayer and scaler. It is a vital component of the kernel when testing V4L2. Probably no software is bug-free, but instead of lamenting we'd better be fixing found bugs - and that's what Dafna Hirshfeld did with vimc for this release! There are several bugfixes from us this time, but the most important one is eliminating a use-after-free bug.
rkisp1 is another driver in staging and this release we worked on this one, too! The driver is for the Image Signal Processing (ISP) module present in RK3399 SoCs. This driver is a hot topic as it is proving a very useful example of how to handle cameras, other communities agree how important it is to have an open source ISP stack. Helen Koike and Dafna Hirshfeld contributed numerous small fixes to make Rockchip ISP V1 support even better, and actually removed several items from its TODO list, aiming at eventually moving it out from staging. This is definitely not the last time you are hearing from us regarding this work!
One might think that a single patch is never worth mentioning. Quite the contrary, a single patch can contain important changes and this is exactly the case with adding the getfb2 ioctl. Ioctls are one of the ways user space processes interact with the kernel, so any new additions are of interest to all developers. This one in particular is a must-read for all developers using DRM (Direct Rendering Manager).
Some display servers such as Xorg implement a smooth handoff between different user sessions, by capturing the existing user content into their own session and transitioning to the new content. The same method can be used by more advanced clients to implement effects like a crossfade between different session content. The existing 'getfb' was used to implement this, however as it did not support multiple buffer handles, it could not be used for some advanced formats enabled by buffer modifiers.
The getfb2 ioctl not only implements support for handoff of compressed buffers between sessions - meaning you do not have to choose between efficiency and features - but also involved a great deal of core cleanup work which landed in earlier kernel versions, simplifying DRM's framebuffer management, eliminating redundancy, and making it easier to work with the DRM framebuffer code.
One part of our opensource involvement with the Linux kernel is maintaining the parts related to Chrome platform (Chromebooks and Chromeboxes). On top of that Enric Balletbò i Serra has contributed fixes and improvements that were merged for 5.7. ([1] [2] [3] [4] [5] [6] [7] [8])
The iSCSI subsystem relies on a user space daemon to perform management tasks to configure the kernel owned iSCSI connection. There are occasions, nevertheless, where the daemon could lose track of the kernel state, for instance if the daemon is restarted when a path failed. In those cases the daemon doesn't have enough information to recover the connections and bad things can happen, like hanging connections, stalled IO, etc. Collabora has been working with Google to eliminate those scenarios, which resulted in several improvements in previous kernel releases.
In v5.7 we eliminated another one of the gaps of information that could cause desynchronization between the kernel and user space: if a path fails when the daemon is restarting, the uevent reporting the failure could be lost and there was no mechanism for user space to probe the connection state. To solve that, Gabriel Krisman Bertazi submitted a fix, to make the current connection state information readily available on sysfs. With that in place, a restarted daemon can detect connections that need to go through a recovery cycle.
BIO-based multipath was somewhat abandoned in favor of request-based multipath in the past, but it seems to be regaining traction due to applications in extremely fast devices like NVMe. During the past development cycle, we worked with Google to upstream a new path selector based on historical path service time for both BIO and request based multipath. This work is queued to land on Linux v5.8, however during the development of the feature we uncovered an uninitialized memory bug on path bringup during BIO-based multipath. A fix was submitted by Gabriel Krisman Bertazi and committed in v5.7-rc4.
User-Mode-Linux has several applications, from security sandboxing to speeding up kernel development. At Collabora, we've been using UML as a backend for the generation of system images using Debos. Whilst revisiting this code, we uncovered a few memory corruption bugs, that can actually cause data corruption on backend storage using the UBD driver. Patches to fix these issues ([1] [2] [3]) were submitted by Gabriel Krisman Bertazi and Sjoerd Simons.
Robert Beckett added a trace event for drm scheduler when a job is actually committed to HW. This allows tracing tools to show how much time is spent waiting to be run vs actually running on HW.
While working with several Open Source projects, very often our engineers stumble upon minor issues or things worthy of improvement such as documentation or cleanups. We try to contribute upstream on a continuous basis and for 5.7 such minor changes were made for areas including Panfrost, Hantro, Direct Rendering Manager, Device Mapper, Human Interface Devices, Device Tree and ASoC, on top of the improvements mentioned above.
We enjoy and take great pride in being an active part of the community, helping and improving the projects we use. This also includes providing help with reviewing and testing patches from other community members.
Andrzej Pietrasiewicz:
Boris Brezillon:
Dafna Hirschfeld:
Daniel Stone:
Enric Balletbo i Serra:
Ezequiel Garcia:
Gabriel Krisman Bertazi:
Helen Koike:
Ricardo Cañuelo:
Robert Beckett:
Sebastian Reichel:
Sjoerd Simons:
Alyssa Rosenzweig:
Boris Brezillon:
Emil Velikov:
Enric Balletbo i Serra:
Ezequiel Garcia:
Sebastian Reichel:
Alyssa Rosenzweig:
Boris Brezillon:
Helen Koike:
Andrzej Pietrasiewicz:
Boris Brezillon:
Enric Balletbo i Serra:
Gabriel Krisman Bertazi:
Sebastian Reichel:
Andrzej Pietrasiewicz:
Enric Balletbo i Serra:
Ezequiel Garcia:
Sebastian Reichel:
Emil Velikov:
20/12/2024
The Rockchip RK3588 upstream support has progressed a lot over the last few years. As 2024 comes to a close, it is a great time to have…
09/12/2024
Collabora will be at NeurIPs this week to dive into the latest academic findings in machine learning and research advancements that are…
05/12/2024
Now based on Debian Bookworm, Apertis is a collaborative OS platform that includes an operating system, but also tools and cloud services…
Whether writing a line of code or shaping a longer-term strategic software development plan, we'll help you navigate the ever-evolving world of Open Source.
한국어 버전의 Collabora.com 보기
Acesse Collabora.com em Português
Comments (0)
Add a Comment