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.