We're hiring!
*

Testing cameras with lc-compliance on KernelCI

Nícolas F. R. A. Prado avatar

Nícolas F. R. A. Prado
June 15, 2021

Share this post:

Earlier this month, the very first KernelCI sprint or "hackfest" was held virtually, with more than a dozen engineers & developers from different communities in attendance. Initiated as a joint effort by the Google Chrome OS team and Collabora, the sprint's main objective was to extend KernelCI's coverage, including adding new tests such as the ability to detect regressions on the Linux kernel that can directly affect cameras.

With Linux powering so many things and in so many different settings, there's great interest in making sure that it runs well in as many of them. KernelCI fills this purpose with an ever-increasing amount of tests and environments. The media subsystem is of course no exception, and it's just been joined by a new test suite.

There are different ways to test software: unit testing, API conformance testing, functional testing, the list goes on. While Linux's media subsystem (responsible for camera handling amongst other things) already had v4l2-compliance (which tests if the V4L2 userspace API works correctly) running on KernelCI, there wasn't yet a complete system test to make sure that cameras continue working on real use cases.

Enter libcamera, a library that abstracts the hardware-specific Media Controller API usage away from applications. It is a real user of the V4L2 API, so running it as a test in KernelCI would help detect regressions that affect real camera usage.

libcamera also has its own testing tool: lc-compliance. This tool was just recently added, so there still aren't many tests, but it is already able to check that capturing images works on a few different platforms and with different image qualities.

During the KernelCI hackfest that took place at the beginning of June, I worked on adding lc-compliance as a new test. Since libcamera has its own set of dependencies, this involved first creating a new rootfs definition in KernelCI.

Only runtime dependencies are listed there (which is just libevent-dev for lc-compliance). The script pointed by script is the one that will collect the build-time dependencies and build libcamera and lc-compliance from source. It can be seen here.

In the rootfs yaml there's also an overlay field. That overlay contains a parser for lc-compliance's output. That is needed because of the way LAVA works. When a job is triggered by KernelCI, it is scheduled on a device in a LAVA lab. While the job is running, all output is archived by LAVA, and the result of each test case needs to be signalled to LAVA through calls like lava-test-case --result <result>. The parser script is the one responsible for translating the output of lc-compliance into those LAVA calls.

With those definitions done, KernelCI generated rootfs images based on them. Next, to get the test set up to run, these necessary definitions were added:

  • The image, which pointed to the ramdisk and rootfs generated by KernelCI.
  • The LAVA test template, which instructs how the test shall be conducted on the device, in my case it's just running the parser script. KernelCI will fill out the information here and send it to a LAVA lab.
  • The test, which points to both the image and the LAVA test template.

Finally, I added where the test should be run. At first, we'll be running it just on mt8173-elm-hana since it has an USB camera integrated, and there are a few spare on Collabora's LAVA lab, but soon we'll add the test to other devices with cameras as well. So I added my test to that device's list, and also to Collabora's lab list.

And that was everything. lc-compliance should now get run after kernel updates occur in the trees tracked by KernelCI. Here's an example of one of the runs.

Stay tuned in the coming days as we share more about our participation in the KernelCI hackfest and what was achieved. If you would like to learn more about KernelCI, or would like to get involved, visit kernelci.org.

Comments (0)


Add a Comment






Allowed tags: <b><i><br>Add a new comment:


Search the newsroom

Latest Blog Posts

Visual-inertial tracking for Monado

05/04/2022

Monado now has initial support for 6DoF ("inside-out") tracking for devices with cameras and an IMU! Three free and open source SLAM/VIO…

Spotlight on Meson's full-featured developer environment

30/03/2022

When developing an application or a library, it is very common to want to run it without installing it, or to install it into a custom prefix…

How to write a Vulkan driver in 2022

23/03/2022

An incredible amount has changed in Mesa and in the Vulkan ecosystems since we wrote the first Vulkan driver in Mesa for Intel hardware…

Improving the reliability of file system monitoring tools

14/03/2022

Every file system used in production has tools to try to recover from system crashes. To provide a better infrastructure for those tools,…

PipeWire: A year in review & a look ahead

08/03/2022

The PipeWire project made major strides over the past few years, bringing shiny new features, and paving the way for new possibilities in…

Landing a new syscall, part 1: What is futex?

08/02/2022

Over the past 18 months, we have been on a roller-coaster ride developing futex2, a new set of system calls. As part of this effort, the…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2022. All rights reserved. Privacy Notice. Sitemap.