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

Run your own CI pipeline with GStreamer's new monorepo

26/10/2021

Maintaining a non-trivial set of GStreamer patches can be tricky. Thanks to the recent move to a single, unified git repo, you can now easily…

Improving test coverage for cameras in KernelCI

08/10/2021

Earlier this year, I joined Collabora as an intern to work on improving testing in libcamera and automating it through KernelCI. Having…

A tale of two toolchains and glibc

30/09/2021

With the LLVM toolchain seeing increasing development and adoption alongside the older, more established GNU toolchain, projects needing…

An xrdesktop summer of code

10/09/2021

This summer, Christoph Haag and I had the pleasure of taking part in Google Summer of Code as mentors for xrdesktop, the Open Source project…

Adding VP9 and MPEG2 stateless support in v4l2codecs for GStreamer

23/06/2021

Earlier this year, from January to April 2021, I worked on adding support for stateless decoders for GStreamer as part of a multimedia internship…

Bag of Freebies for XR Hand Tracking: Machine Learning & OpenXR

17/06/2021

In our previous post, we presented a project backed by INVEST-AI which introduces a multi-stage neural network-based solution. Now let's…

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

Collabora Limited is registered in England and Wales. Company Registration number: 5513718. Registered office: The Platinum Building, St John's Innovation Park, Cambridge, CB4 0DS, United Kingdom. VAT number: 874 1630 19.