[Bug 1921474] Re: Support client usage notification via V4l2 Event API
Robie Basak
1921474 at bugs.launchpad.net
Mon Jan 10 13:18:40 UTC 2022
Thank you for the detailed explanation!
> All the components can be found in
https://launchpad.net/~oem-solutions-group/+archive/ubuntu/intel-ipu6,
and are being proposed for inclusion to Ubuntu archive at. the same
time
What's the status of the inclusion of the entire stack in Jammy? I don't
see ipu6-camera-hal or ipu6-camera-bins packages in Ubuntu at all, for
example.
Right now, it seems to me that you're essentially asking for new
features in v4l2loopback in Focal because they are required to make this
new out-of-archive proprietary stack work. I assume that you're seeking
to justify this SRU on the basis of our hardware enablement policy, as
you've not stated any other justification in your SRU supplied
information. But I'm not sure how this fits in with Ubuntu's existing
hardware enablement policy, unless every required component for the
entire enablement is also being added to Focal. Otherwise, if out-of-
archive software will still be required to make the hardware enablement
work, then why do the required feature additions to v4l2loopback need to
go into the archive rather than the out-of-archive place?
Ubuntu SRU policy requires that changes being made are "fixed" in the
development release first. In this case I think the entire solution
needs to be demonstrated working in Jammy without the need for an out-
of-archive source - not just the v4l2loopback component. Otherwise, I
don't think it makes sense to justify the feature addition to
v4l2loopback on the basis of hardware enablement (as I assume you're
seeking to do) as there wouldn't be a hardware enablement in Ubuntu
itself actually happening.
Please complete the entire hardware enablement in Jammy first -
presumably using the restricted archive component as necessary - before
proceeding with the hardware enablement in the Ubuntu archive in Focal.
In the meantime, if users need to install out-of-archive (eg. PPA)
software to get the stack working anyway, then it shouldn't be onerous
for them to also bump v4l2loopback with the feature required.
The reason I'm pushing on this is that I think there's quite a bit of
risk in how the rest of the enablement will happen in Focal, which might
lead to development iteration for users in a stable release which really
should be avoided. We mitigate this by requiring fixes to be
demonstrated to be fully functional and tested in the development
release first, and I think that it's particularly important to ensure
that is done here because this is a particularly complex case. I would
also prefer to see the entire enablement in Focal being performed at
once (after Jammy is complete) so that it can be tested and verified as
a whole, rather than a component at a time. Otherwise we'll end up
testing something different from the actual goal for users when doing
v4l2loopback first, which risks those further iterations in a stable
release. With just the v4l2loopback feature being added here, it becomes
impossible for me to add "Check that a user can actually use the
hardware being enabled as expected" to the test plan for SRU
verification.
--
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1921474
Title:
Support client usage notification via V4l2 Event API
Status in HWE Next:
In Progress
Status in OEM Priority Project:
In Progress
Status in v4l2loopback package in Ubuntu:
Fix Released
Status in v4l2loopback source package in Focal:
In Progress
Status in v4l2loopback source package in Hirsute:
Fix Released
Bug description:
[SRU Justification]
[Impact]
On a MIPI camera through Intel IPU6 platform that its raw V4L2
loopback interface is preserved for Intel Camera HAL libraries, a
relay daemon + v4l2loopback is used to allow the usage of legacy V4L2
based apps.
By design, the relayd will open v4l2sink to v4l2loopback OUTPUT
deivce, and it will only open libcamhal based GStreamer source
element, and therefore underlying camera hardware, until received new
client notifications via V4L2 Event API that is introduced in this
SRU.
Besides, frame sizes/intervals enumeration is also fixed to meet
better compliance with user apps.
[Test Plan]
v4l2loopback doesn't support V4L2 Event API until recently, so
requests for the usage will always fail:
struct v4l2_event_subscription sub;
int fd;
memset (&sub, 0, sizeof (sub));
sub.type = ...;
if (ioctl (fd, VIDIOC_SUBSCRIBE_EVENT, &sub) == 0) // fail
With this fix, it shall support Event API operations, e.g.
VIDIOC_SUBSCRIBE_EVENT, VIDIOC_UNSUBSCRIBE_EVENT, VIDIOC_DQEVENT.
[Where problems could occur]
While a custom type of V4L2 event is now registered for OEM projects,
software expected same ID (numerically equivalent to
V4L2_EVENT_PRIVATE_START) may get confused. While this falls in the
private usage section, it's not supposed to be used in general, and
when it does, it should be under some presumptions, e.g. selected
hardware, so it's unlikely to happen on OEM projects.
For generic Ubuntu, programs may begin to take advantage of this new
capability to update its UI, or to take other actions after receiving
desired events. There might be behavior changes, but should be under
the original design if was done carefully.
[Other Info]
For Focal backports, 0.12.5-1 is equivalent to 0.12.3-1ubuntu0.3 plus
micro version updates, so there should be little risk backport a new
release, and we can drop additional patches carried. This implies bug
1905613.
This focal backport includes changes for bug 1921474, bug 1930208, and
bug 1936250, so it will then become synced with Impish and newer
again. The 0007-compliance-stop-
declaring-V4L2_CAP_VIDEO_M2M-capabil.patch carried in bug 1930208 is
deliberately skipped to avoid bug 1946660.
========= original bug report ==========
In addition to kernel/firmware proposed in bug 1921345, several user
space daemons/libraries, as well as fixes/features in v4l2loopback-
dkms, are also required to have seamless support for legacy/existing
Linux kernel V4L2 API based applications to adopt libcamera or Intel
libcamhal provided camera interfaces.
The idea is to add a v4l2 streaming relay daemon (currently developed
in [1] and packaged in [2]) that helps redirecting V4L2 buffer streams
into v4l2loopback output device, and then legacy apps open
v4l2loopback capture device in the ordinary way.
hw -> libcamera/libcamhal -> v4l2-relayd -> v4l2loopback ->
v4l2-based apps
To achieve this, we'd like v4l2-relayd to only open GStreamer
icamerasrc pipeline (provided by [3],[4]) when there is actual usage
request from v4l2-based apps for privacy and power consumption's
concerns. However, current (0.12.5 and therefore Ubuntu/Debian
0.12.5-1) doesn't have any available mechanism for this, therefore a
V4L2 Event API based proposal has been sent and accepted by
upstream[5][6].
This is needed for Ubuntu OEM projects with MIPI cameras through Intel
IPU6 (Imaging Processing Unit version 6).
[1]: https://gitlab.com/vicamo/v4l2-relayd
[2]: https://code.launchpad.net/~oem-solutions-engineers/v4l2-relayd/+git/packaging
[3]: https://github.com/intel/ipu6-camera-hal
[4]: https://github.com/intel/icamerasrc
[5]: https://github.com/umlaeute/v4l2loopback/pull/345
[6]: https://github.com/umlaeute/v4l2loopback/pull/352
To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1921474/+subscriptions
More information about the Ubuntu-sponsors
mailing list