| 2021-03-26 08:18:38 |
You-Sheng Yang |
bug |
|
|
added bug |
| 2021-03-26 08:18:59 |
You-Sheng Yang |
nominated for series |
|
Ubuntu Hirsute |
|
| 2021-03-26 08:18:59 |
You-Sheng Yang |
bug task added |
|
v4l2loopback (Ubuntu Hirsute) |
|
| 2021-03-26 08:18:59 |
You-Sheng Yang |
nominated for series |
|
Ubuntu Focal |
|
| 2021-03-26 08:18:59 |
You-Sheng Yang |
bug task added |
|
v4l2loopback (Ubuntu Focal) |
|
| 2021-03-26 08:19:55 |
You-Sheng Yang |
bug |
|
|
added subscriber Canonical Hardware Enablement |
| 2021-03-26 08:20:00 |
You-Sheng Yang |
tags |
fossa-mewtwo ihv-intel |
fossa-mewtwo ihv-intel oem-priority originate-from-1917691 somerville |
|
| 2021-03-29 10:45:57 |
You-Sheng Yang |
v4l2loopback (Ubuntu Focal): status |
New |
In Progress |
|
| 2021-03-29 10:45:59 |
You-Sheng Yang |
v4l2loopback (Ubuntu Hirsute): status |
New |
In Progress |
|
| 2021-03-29 10:46:10 |
You-Sheng Yang |
v4l2loopback (Ubuntu Focal): importance |
Undecided |
Critical |
|
| 2021-03-29 10:46:14 |
You-Sheng Yang |
v4l2loopback (Ubuntu Hirsute): importance |
Undecided |
High |
|
| 2021-03-29 10:46:17 |
You-Sheng Yang |
v4l2loopback (Ubuntu Focal): importance |
Critical |
High |
|
| 2021-03-29 10:46:21 |
You-Sheng Yang |
v4l2loopback (Ubuntu Focal): assignee |
|
You-Sheng Yang (vicamo) |
|
| 2021-03-29 10:48:53 |
You-Sheng Yang |
attachment added |
|
hirsute.0.12.5-1ubuntu1.debdiff https://bugs.launchpad.net/ubuntu/+source/v4l2loopback/+bug/1921474/+attachment/5481898/+files/hirsute.0.12.5-1ubuntu1.debdiff |
|
| 2021-03-29 10:49:38 |
You-Sheng Yang |
attachment added |
|
focal.0.12.5-1ubuntu1.20.04.1.debdiff https://bugs.launchpad.net/ubuntu/+source/v4l2loopback/+bug/1921474/+attachment/5481899/+files/focal.0.12.5-1ubuntu1.20.04.1.debdiff |
|
| 2021-03-29 11:26:28 |
You-Sheng Yang |
description |
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 |
[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.
========= 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 |
|
| 2021-03-29 11:27:03 |
You-Sheng Yang |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2021-03-29 11:31:58 |
You-Sheng Yang |
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.
========= 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 |
[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.
========= 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 |
|
| 2021-04-01 01:22:49 |
Rex Tsai |
bug |
|
|
added subscriber Intel Team |
| 2021-04-01 01:23:09 |
Rex Tsai |
bug |
|
|
added subscriber Rex Tsai |
| 2021-04-15 21:38:26 |
Launchpad Janitor |
v4l2loopback (Ubuntu Hirsute): status |
In Progress |
Fix Released |
|
| 2021-05-05 08:44:42 |
Anthony Wong |
hwe-next: status |
New |
Fix Released |
|
| 2021-05-05 08:44:48 |
Anthony Wong |
hwe-next: status |
Fix Released |
In Progress |
|
| 2021-11-19 16:35:44 |
Brian Murray |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2022-01-04 10:36:06 |
You-Sheng Yang |
attachment added |
|
v4l2loopback_0.12.3-1ubuntu0.4_0.12.3-1ubuntu0.5.debdiff https://bugs.launchpad.net/ubuntu/+source/v4l2loopback/+bug/1921474/+attachment/5551074/+files/v4l2loopback_0.12.3-1ubuntu0.4_0.12.3-1ubuntu0.5.debdiff |
|
| 2022-01-04 10:42:46 |
You-Sheng Yang |
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.
========= 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 |
[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 |
|
| 2022-01-04 10:43:20 |
You-Sheng Yang |
attachment removed |
focal.0.12.5-1ubuntu1.20.04.1.debdiff https://bugs.launchpad.net/ubuntu/+source/v4l2loopback/+bug/1921474/+attachment/5481899/+files/focal.0.12.5-1ubuntu1.20.04.1.debdiff |
|
|
| 2022-01-04 10:47:21 |
You-Sheng Yang |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2022-01-07 08:52:05 |
Shih-Yuan Lee |
bug |
|
|
added subscriber OEM Solutions Group: Engineers |
| 2022-01-07 08:52:11 |
Shih-Yuan Lee |
tags |
fossa-mewtwo ihv-intel oem-priority originate-from-1917691 somerville |
fossa-mewtwo ihv-intel oem-priority originate-from-1917691 originate-from-1949435 somerville |
|
| 2022-01-07 08:52:34 |
Shih-Yuan Lee |
oem-priority: status |
New |
In Progress |
|
| 2022-01-07 08:52:37 |
Shih-Yuan Lee |
oem-priority: importance |
Undecided |
High |
|
| 2022-01-07 08:52:39 |
Shih-Yuan Lee |
oem-priority: assignee |
|
Shih-Yuan Lee (fourdollars) |
|
| 2022-01-10 14:16:34 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2022-02-22 09:29:11 |
Bin Li |
tags |
fossa-mewtwo ihv-intel oem-priority originate-from-1917691 originate-from-1949435 somerville |
fossa-mewtwo ihv-intel oem-priority originate-from-1917691 originate-from-1949435 originate-from-1961382 somerville sutton |
|
| 2022-09-02 14:36:45 |
Timo Aaltonen |
oem-priority: status |
In Progress |
Fix Released |
|
| 2022-09-02 14:36:50 |
Timo Aaltonen |
hwe-next: status |
In Progress |
Fix Released |
|
| 2022-09-02 14:36:53 |
Timo Aaltonen |
v4l2loopback (Ubuntu Focal): status |
In Progress |
Won't Fix |
|
