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: [RESEND] Running libcamera on KernelCI to detect regressions in the media subsystem
Date: Fri, 21 May 2021 10:47:18 -0300 [thread overview]
Message-ID: <CBIYXUHIO2UY.Z2ZEJCSV5RES@notapiano> (raw)
(Resending since the previous one didn't reach KernelCI, sorry for the noise)
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-21 13:47 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=CBIYXUHIO2UY.Z2ZEJCSV5RES@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