** Description changed:
1. We will have linux-oem-6.17/noble soon, which is based on
linux/questing, and therefore it's going to be built along with
v4l2loopback-dkms/questing.
2. Currently in v4l2loopback-dkms/questing version 0.15.0-2, the
compatibility patch was not included (because it's directly imported
from Debian).
With 1. and 2., it follows the v4l2loopback module in linux-
modules-6.17.0-xxxx-oem will not be compatible with v4l2-relayd/noble.
In order not to break the last oem kernel in Noble, that compatibility
patch is still necessary until 26.04.
---
[ Impact ]
* v4l2loopback 0.15.0 violates the V4L2 specification by pre-populating
the output buffer queue in prepare_buffer_queue(), causing VIDIOC_DQBUF
to return buffers that were never queued via VIDIOC_QBUF.
* This causes GStreamer v4l2sink to fail with errors: "buffer X was not
queued, this indicates a driver bug"
* Users cannot use GStreamer pipelines with v4l2sink to feed v4l2loopback
virtual cameras, breaking workflows like:
- Camera applications using icamerasrc → v4l2loopback → browser
- Video streaming applications
- Virtual camera setups for video conferencing
* The fix modifies two functions in v4l2loopback.c:
1. prepare_buffer_queue(): Clear outbufs_list instead of pre-populating it
2. vidioc_dqbuf(): Use list_del_init() instead of list_move_tail() to
remove buffers from the queue
* This ensures buffers only enter the output queue when explicitly
queued via VIDIOC_QBUF, complying with V4L2 specification.
[ Test Plan ]
* Install v4l2loopback-dkms package with the fix
* Load the v4l2loopback module:
sudo modprobe v4l2loopback exclusive_caps=0 card_label="Virtual Camera"
* Test GStreamer pipeline with v4l2sink:
gst-launch-1.0 videotestsrc ! videoconvert ! v4l2sink device=/dev/video0
* Expected result: Pipeline runs without errors, no "buffer was not
queued" warnings
* Test with actual camera source (if available):
gst-launch-1.0 icamerasrc ! videoconvert ! v4l2sink device=/dev/video0
* Verify browser can access the virtual camera:
- Open Firefox/Chrome
- Navigate to: https://mozilla.github.io/webrtc-landing/gum_test.html
- Select the virtual camera device
- Expected result: Video stream displays correctly
* Regression testing:
- Verify v4l2loopback still works with applications that read from the
device (e.g., ffmpeg, vlc)
- Test multiple buffer queue/dequeue cycles
- Verify with different video formats (NV12, YUYV, etc.)
[ Where problems could occur ]
* The change modifies the buffer queue management logic in
v4l2loopback's core functionality.
* Potential issues:
- Applications that incorrectly relied on the old pre-populated buffer
behavior might fail if they don't properly queue buffers via VIDIOC_QBUF
- Race conditions in buffer allocation/deallocation if the list management
has edge cases not covered by the fix
- Performance regression if clearing and re-populating buffers on each
prepare_buffer_queue() call impacts throughput
* However, the old behavior was objectively wrong according to V4L2
spec, so any application relying on it was already broken with properly-
implemented V4L2 drivers.
* The fix has been tested with:
- GStreamer v4l2sink (strict V4L2 compliance checking)
- Web browsers (Firefox, Chrome)
- Various video formats and resolutions
* Most likely failure mode would be buffer starvation if applications
don't queue buffers, but this is correct behavior per V4L2 spec.
[ Other Info ]
* Upstream PR (under review):
https://github.com/v4l2loopback/v4l2loopback/pull/656
* Upstream Issue: https://github.com/v4l2loopback/v4l2loopback/issues/383
* V4L2 Specification:
https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/vidioc-qbuf.html
* This affects:
- - Ubuntu Questing: v4l2loopback 0.15.0-0ubuntu2 → 0.15.0-0ubuntu3
+ - Ubuntu Questing: v4l2loopback 0.15.0-0ubuntu2 → 0.15.0-0ubuntu2.1
- Ubuntu Resolute: v4l2loopback 0.15.3-1ubuntu1 → 0.15.3-1ubuntu2
* Debdiffs attached for both releases
* The issue was discovered during MIPI camera integration testing where
v4l2-relayd uses v4l2sink to feed v4l2loopback, and the strict V4L2
compliance checking in GStreamer caught the specification violation.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2114127
Title:
Missing compatibility to old client usage event id in Questing
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/v4l2loopback-dkms/+bug/2114127/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs