** 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.
+ [ Impact ]
- 2. Currently in v4l2loopback-dkms/questing version 0.15.0-2, the
- compatibility patch was not included (because it's directly imported
- from Debian).
+ * 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.
- 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.
+ * 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 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.
** 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 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.
** Changed in: v4l2loopback-dkms (Ubuntu Questing)
Status: New => In Progress
** Changed in: v4l2loopback-dkms (Ubuntu Resolute)
Status: New => In Progress
** Changed in: v4l2loopback-dkms (Ubuntu Questing)
Importance: Undecided => High
** Changed in: v4l2loopback-dkms (Ubuntu Resolute)
Importance: Undecided => High
** Tags added: jira-somerville-3749
--
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
