Linux Media Controller development
 help / color / mirror / Atom feed
From: "Nícolas F. R. A. Prado" <nfraprado@collabora.com>
To: <libcamera-devel@lists.libcamera.org>,
	<linux-media@vger.kernel.org>, <kernelci@groups.io>
Cc: <kernel@collabora.com>
Subject: Running libcamera on KernelCI to detect regressions in the media subsystem
Date: Thu, 20 May 2021 18:14:59 -0300	[thread overview]
Message-ID: <CBIDU2MJZPVY.2J8BDPUFIKZIQ@notapiano> (raw)

Hello,

as part of an effort to detect regressions in the kernel's media subsystem that
affects real use cases, I want to present a proposal and ask for feedback and
ideas.

Why?
====

There's been increasing interest in catching regressions in the kernel early, to
minimize the impact on userspace, and the media subsystem is no different. The
main test tool there is v4l2-compliance [1], but its focus is to purely exercise
the uAPI. There's currently nothing in place to test real use cases.

What to do?
===========

libcamera [2] is a library that works on top of the Media Controller and V4L2
APIs and abstracts away the hardware-specific pipeline configuration from the
application. It is a real user of the v4l2 uAPI.

Just recently an initial implementation of a testing tool for libcamera, called
lc-compliance, was merged [3]. It currently has only a few tests, but they
already test the capture of images for different purposes (raw images,
high-quality video capturing, etc), which exercise different media topology
configurations and pixelformats.

Although from the point of view of libcamera lc-compliance is a compliance tool,
from v4l2's perspective it is a real use case test rather than a pure API
compliance test like v4l2-compliance.

I'm currently in the process of refactoring lc-compliance to have a better test
framework [4], and make it ready to be automatically run on a CI.

By having lc-compliance run on actual hardware at KernelCI, we can exercise real
use cases of cameras and catch any kernel regressions that impact them as soon
as they happen.

Feedback
========

So, how can we best ensure we catch real use case regressions on the media
subsystem using lc-compliance? What kind of information should be present on the
test results? Any other suggestions?

Thanks,
Nícolas


[1] https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-compliance
[2] https://libcamera.org
[3] https://git.linuxtv.org/libcamera.git/tree/src/lc-compliance
[4] https://lists.libcamera.org/pipermail/libcamera-devel/2021-May/020382.html

                 reply	other threads:[~2021-05-20 21:15 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CBIDU2MJZPVY.2J8BDPUFIKZIQ@notapiano \
    --to=nfraprado@collabora.com \
    --cc=kernel@collabora.com \
    --cc=kernelci@groups.io \
    --cc=libcamera-devel@lists.libcamera.org \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox