Package: v4l2loopback-dkms
Version: 0.12.7-2
Severity: important
Tags: patch

With the Droidcam client (application to use mobile phone cameras with
the computer) the loopback device can be used only once. Then it is
neither an output nor a capture device, without being able to set format
and send data any more until the module is reloaded.
Without parameter "exclusive_caps=1" the issue doesn't appear, but I
need it for my scenario.

Output of command "v4l2-ctl -d /dev/video0 --all" before use:
Driver Info:
        Driver name      : v4l2 loopback
        Card type        : Loopback Cam
        Bus info         : platform:v4l2loopback-000
        Driver version   : 6.1.37
        Capabilities     : 0x85200002
                Video Output
                Read/Write
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps      : 0x05200002
                Video Output
                Read/Write
                Streaming
                Extended Pix Format

Output of command "v4l2-ctl -d /dev/video0 --all" after use:
Driver Info:
        Driver name      : v4l2 loopback
        Card type        : Loopback Cam
        Bus info         : platform:v4l2loopback-000
        Driver version   : 6.1.37
        Capabilities     : 0x85200000
                Read/Write
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps      : 0x05200000
                Read/Write
                Streaming
                Extended Pix Format

On analysis of the application no bug could be found there, but for
v4l2loopback module at the point of failure apparently
vidioc_try_fmt_cap() is called instead of vidioc_try_fmt_out(), which
must be caused by dev->ready_for_output == 0 but should be reset to 1
latest when all file handles are close.

As a VIDIOC_STREAMON ioctl is never happening here (no such call in
Droidcam), state of ready_for_output probably is changing in
v4l2_loopback_write() but without to set opener-type as WRITER at the
same time. Do I read it correctly that opener->type is unique for a
single file handle - what if the same file handle is used for both
writing and reading?

This patch fixes the issue for me:

--- v4l2loopback.c.orig 2022-08-05 00:30:07.000000000 +0200
+++ v4l2loopback.c      2023-07-10 00:25:06.480011644 +0200
@@ -2000,7 +2000,7 @@ static int v4l2_loopback_close(struct fi
        v4l2_fh_exit(&opener->fh);
 
        kfree(opener);
-       if (iswriter) {
+       if (iswriter || dev->open_count.counter == 0) {
                dev->ready_for_output = 1;
        }
        MARK();

Link to the original bug report for the Droidcam application
   https://github.com/dev47apps/droidcam/issues/242
Link to similar bug report for Pyvirtualcam
   https://github.com/letmaik/pyvirtualcam/issues/61


Kind regards,
   Gero


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages v4l2loopback-dkms depends on:
ii  dkms  3.0.10-8

v4l2loopback-dkms recommends no packages.

Versions of packages v4l2loopback-dkms suggests:
ii  v4l2loopback-utils  0.12.7-2

-- no debconf information

Reply via email to