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:

Reading time:

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

MLfix to quickly fix datasets


Contrary to traditional software development, data is more important than code in machine learning. Building a high-performing model requires…

USB 3.0 preliminary support in U-boot for Radxa Rock-5B


A while back I presented USB 2.0 host support that was added to U-boot for the Radxa Rock-5B RK3588 Rockchip board. This time, USB 3.0 was…

Radxa Rock-5B PCIe and RTL8125B networking in U-boot


Work continues on the Radxa ROCK5B RK388, as PCIe and RTL8125B networking support in U-boot have now been added. Publishing code as Open…

Introducing Multiview for NVK


NVK, an open-source Vulkan driver for NVIDIA hardware that is part of Mesa, now supports the Vulkan extension VK_KHR_multiview.

Adding bootloader support for USB 2.0 Host for Radxa ROCK 5B RK3588


The beauty of Open Source is that we can reuse code written by many other people, keep their authorship, and credit them for their work,…

Meson & VSCode: Develop your project in a modern IDE


Want to develop your Meson project in a modern IDE? Make sure to install Meson VSCode extension which is now fully functional with the recent…

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-2023. All rights reserved. Privacy Notice. Sitemap.