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

Adding VP9 and MPEG2 stateless support in v4l2codecs for GStreamer


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


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

Testing cameras with lc-compliance on KernelCI


Initiated as a joint effort by the Google Chrome OS team and Collabora, the recent KernelCI hackfest brought the addition of new tests including…

Zink: Summer 2021 update


There's a lot that has happened in the world of Zink since my last update, so let's see if I can bring you up to date on the most important…

Open Source OpenGL ES 3.1 on Mali GPUs with Panfrost


Panfrost, the open source driver for Arm Mali, now supports OpenGL ES 3.1 on both Midgard (Mali T760 and newer) and Bifrost (Mali G31, G52,…

Optimizing 3D performance with virglrenderer


Collabora has been investing into Perfetto to enable driver authors & users to get deep insights into driver internals and GPU performance.…

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.