Cannot use a USB camera

abis866i commented 6 years ago

Qubes OS version:

R4.0

Affected component(s):

USB Camera I am not able to use my usb camera (Logitech C270) Camera is the only usb device on a PCI card.

Steps to reproduce the behavior:

I attach the camera PCI to the "personal" VM using the Qubes Manager
Check if camera is available in Personal VM and it seems it is attached according to second line in result. user@personal:~$ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 046d:0825 Logitech, Inc. Webcam C270 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Use 'cheese' application to see if camera is working but i does not. user@personal:~$ cheese (cheese:2274): Gtk-WARNING : Theme parsing error: cheese.css:7:35: The style property GtkScrollbar:min-slider-length is deprecated and shouldn't be used anymore. It will be removed in a future version (cheese:2274): GStreamer-CRITICAL : gst_element_message_full_with_details: assertion 'GST_IS_ELEMENT (element)' failed Message: cheese-application.vala:211: Error during camera setup: No device found (cheese:2274): cheese-CRITICAL : cheese_camera_device_get_name: assertion 'CHEESE_IS_CAMERA_DEVICE (device)' failed (cheese:2274): GLib-CRITICAL : g_variant_new_string: assertion 'string != NULL' failed (cheese:2274): GLib-GIO-CRITICAL : g_settings_schema_key_type_check: assertion 'value != NULL' failed (cheese:2274): GLib-CRITICAL : g_variant_get_type_string: assertion 'value != NULL' failed (cheese:2274): GLib-GIO-CRITICAL : g_settings_set_value: key 'camera' in 'org.gnome.Cheese' expects type 's', but a GVariant of type '(null)' was given (cheese:2274): CRITICAL : cheese_preferences_dialog_setup_resolutions_for_device: assertion 'device != NULL' failed
Check again if camera is available in Personal VM and it seems it is not attached anymore. user@personal:~$ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Expected behavior:

I would like to use my camera with Wire, Google Hangouts and eventually Skype.

Actual behavior:

Wire says there is no camera installed.

General notes:

I have tried to find an answer to this online but, unfortunately, I could not. It is probably that I am doing something wrong but I do not know how to fix this.

Related issues:

NA

jpouellet commented 6 years ago

Might this be an issue with the client you are trying to use to interact with your camera? Have you tried passing the PCI device to a VM with the same template to confirm whether qubes-usb-proxy is in fact the issue?

I've used usb-passthrough for a webcam recently and it worked for me.

Closing and re-opening the device can sometimes leave it in an inconsistent state and unable to use, but I've never had trouble with the first consumer of a device on a given boot.

abis866i commented 6 years ago

Thank you for looking into this. Here is my setting: personal and untrusted VMs are using the Debian template while the rest are using the Fedora template. I have to admit that I do not have too much knowledge into the Linux area so, please guide me through the process. I have removed the PCI from the sys-net where it was attached before. In this case, I try to attach the PCI to the "work" VM which is Fedora, but I get an error. Please see below.

[user@dom0 ~]$ qvm-pci BACKEND:DEVID DESCRIPTION USED BY dom0:00_00.0 Host bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers
dom0:00_02.0 VGA compatible controller: Intel Corporation HD Graphics 530
dom0:00_08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model
dom0:00_14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller sys-net (no-strict-reset=True) dom0:00_14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal subsystem
dom0:00_15.0 Signal processing controller: Intel Corporation Sunrise Point-H Serial IO I2C Controller #0
dom0:00_15.1 Signal processing controller: Intel Corporation Sunrise Point-H Serial IO I2C Controller #1
dom0:00_16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #1
dom0:00_17.0 SATA controller: Intel Corporation Sunrise Point-H SATA controller [AHCI mode]
dom0:00_1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #1
dom0:00_1c.2 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #3
dom0:00_1c.5 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #6
dom0:00_1c.7 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #8
dom0:00_1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #9
dom0:00_1d.2 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #11
dom0:00_1d.3 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #12
dom0:00_1d.4 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #13
dom0:00_1e.0 Signal processing controller: Intel Corporation Sunrise Point-H Serial IO UART #0
dom0:00_1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller
dom0:00_1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC
dom0:00_1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio
dom0:00_1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus
dom0:02_00.0 USB controller: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller sys-net (no-strict-reset=True) dom0:03_00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller
dom0:04_00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter sys-net dom0:06_00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge
dom0:07_01.0 Multimedia audio controller: C-Media Electronics Inc CMI8738/CMI8768 PCI Audio
dom0:08_00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller sys-net dom0:09_00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961

[user@dom0 ~]$ qvm-pci attach --persistent --option permissive=true --option no-strict-reset=true work dom0:03_00.0 Can't attach PCI device to VM in pvh mode

jpouellet commented 6 years ago

Right. PVH-mode VMs can't do PCI-passthrough.

You need to set it to hvm instead:

[user@dom0 ~]$ qvm-prefs some-vm virt_mode hvm

To set it back to default (pvh):

[user@dom0 ~]$ qvm-prefs -D some-vm virt_mode

I'd probably create a new VM for this testing purpose, but it's not strictly necessary.

abis866i commented 6 years ago

Yes, that worked. Here is what I did:

created new appvm based on fedora, called "temp"
changed the virtualization mode to hvm for "temp"
attached the whole PCI card to the "temp" appvm
ran "cheese" in "temp" and camera worked this time.

What do you advise I do, change the virtualization mode to my AppVMs to make it work? Thank you!

jpouellet commented 6 years ago

So far this only confirms the problem is with qubes' USB passthrough layer or dependencies / configuration in the templates you were using before, and rules out your camera app, USB controller itself, etc.

Now, what happens if you make another VM based on the same template as temp (qvm-clone temp temp-client should do fine) and try to use qvm-usb to pass it from temp to temp-client, and use the same "cheese" app in temp-client (which we just confirmed working in temp)?

Additionally, I believe it should be by default in fedora templates, but confirm you have qubes-usb-proxy available in temp (meaning, installed in its template). Something like:

[user@temp ~]$ sudo dnf list installed | grep qubes-usb-proxy
qubes-usb-proxy.noarch                     1.0.18-1.fc26                @qubes-vm-r4.0-current

abis866i commented 6 years ago

Yes, I was able to use the cheese with the "temp" AppVM if the virtualization was "hvm"
Here is my "qubes-usb-proxy". I have noticed that your output says "fc26" while mine is "fc25". Currently, I have Fedora 28 template installed.

[user@dom0 ~]$ sudo dnf list installed | grep qubes-usb-proxy qubes-usb-proxy-dom0.noarch 1.0.18-1.fc25 @qubes-dom0-cached

Cloning went OK. Virtualization method for "temp-client" is still "hvm" should I change it to "pvh"?

[user@dom0 ~]$ qvm-clone temp temp-client temp-client: Cloning private volume

Attach the camera from temp to temp-client:

[user@dom0 ~]$ qvm-usb BACKEND:DEVID DESCRIPTION USED BY temp:1-2 046d_0825_A83B6C60
[user@dom0 ~]$ qvm-usb attach temp-client temp:1-2

In temp-client run "cheese". It did not work, result is that I get a message "no device found". Output is similar to the one in 3. of my initial post.

abis866i commented 6 years ago

Just a note on the post above: I can use my camera with "cheese" in the "temp" appvm when I start the appvm. But, if I attach the camera to "temp-client", try to use it in the "temp-client" with "cheese" , and then detach it, I will not be able to use it in "temp" anymore.

jpouellet commented 6 years ago

virt_mode for the VM getting the USB device passed to it does not matter. The USB traffic comes in over qrexec and gets injected to USBIP - there is no PCI device involved. virt_mode=hvm is only required for the device which actually has the USB controller PCI device assigned to it.

From everything you describe, this indeed sounds like a bug in the USB passthrough code.

As a workaround, you can use "cheese" directly in the VM which has your USB device attached. So long as the camera is the only device on that USB bus, then the security benefit from further isolating cheese and providing only that USB device is unclear.

If you are care about security implications, then making your USB vm disposable and restarting your computer^[1] between uses of your USB device will eliminate persistence of attacks originating over video-conferencing software (or similar) unless they re-write firmware on your USB controller (unclear if it has any) or camera (probably has some, but would likely be equally attackable regardless of whether the USB device is passed individually or not). This is admittedly inconvenient, so evaluate for your own threat model.

[1]: restarting your whole computer (not just the VM to which the USB controller is assigned) is required to reset your USB controller unless your USB controller supports function-level-reset at the PCI level, which is rare from what I've seen

jpouellet commented 6 years ago

Hmm, Xeon processor? If this is a server or workstation or something, then simply buying another USB PCI card and using it exclusively for a (camera, vm) pair would be ideal from a security perspective. Additionally, if the card supports function-level-reset (I wish I knew which chipsets did...) then you wouldn't need no-strict-reset and could restarting just that USB vm would be meaningful.

abis866i commented 6 years ago

Not sure if I actually have have a security model in mind. But I am fascinated by the fact that I can take resources and temporarily assign them to different vms. For example, I use Google Hangouts only for work, so in that case I would assign the camera to the "work" vm for that. For conversations with family/friends, I use Wire, so I would attach it to the personal.

jpouellet commented 6 years ago

Sure... but depending on your threat model, that can only go so far.

If you're worried about any of the video conferencing applications getting owned and the attacker persisting to webcam firmware, then you're probably still screwed.

See, e.g.:

There's a place for separate hardware too.

jpouellet commented 6 years ago

That's also an argument for some higher-level unidirectional-video-stream-only implementation within Qubes. Maybe one day...

abis866i commented 6 years ago

No server here, it is just a system I built myself from parts from MicroCenter. Here is what I have:

Intel Core i3-6100 SkyLake 3.7 GHz LGA 1151
MSI Z170A PC Mate LGA 1151 ATX Intel Motherboard
Crucial Ballistix Sport LT 64GB 4 x 16GB DDR4-2400 PC4-19200 CL16 Dual Channel

I built it in preparation for Qubes OS 4.0 as the laptop I have used with 3.2 did not pass the hardware requirements. Since camera never worked on this computer, I got a PCI card to be used only with hoping I can pass it easier. As I said, I have no specific security concerns, it is just a fascination with the model.

jpouellet commented 6 years ago

Interesting, you say it's a Core-i3 but the PCI devs show as Xeon-E3 ¯_(ツ)_/¯

Would you mind sharing output of:

lspci -vv -s 00:14.0
lspci -vv -s 02:00.0
lspci -vv -s 03:00.0

Specifically, I'm interested if the output contains FLReset for any of the devices.

abis866i commented 6 years ago

[user@dom0 ~]$ lspci -vv -s 00:14.0 00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31) (prog-if 30 [XHCI]) Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7971 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at df510000 (64-bit, non-prefetchable) [size=64K] Capabilities: Kernel driver in use: pciback Kernel modules: xhci_pci

[user@dom0 ~]$ lspci -vv -s 02:00.0 02:00.0 USB controller: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller (prog-if 30 [XHCI]) Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7971 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at df400000 (64-bit, non-prefetchable) [size=32K] Capabilities: Kernel driver in use: pciback Kernel modules: xhci_pci

[user@dom0 ~]$ lspci -vv -s 03:00.0 03:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02) (prog-if 30 [XHCI]) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 17 Region 0: Memory at df300000 (64-bit, non-prefetchable) [disabled] [size=8K] Capabilities: Kernel driver in use: pciback Kernel modules: xhci_pci

abis866i commented 6 years ago

The usb camera is attached to the 03:00.0 USB controller: Renesas Technology Corp card and it is the only USB device on the card.

jpouellet commented 6 years ago

Yup. Looks like all of them need no-strict-reset :(

The quest to find a recommendable USB controller continues...

e6lk7dqzm83p commented 6 years ago

Hi, I have had a similar issue. I can fairly easily attach my USB devices to my Debian AppVMs for scanning and video conferencing, but haven't had much luck connecting them to my Fedora AppVMs.

As an example, Simple-Scan and guvcview seem to be able to use my scanner/camera without issue in my Debian AppVM (note that the scanning is a bit temperamental).

abis866i commented 6 years ago

Just an update on this issue. I bought a very cheap DI ChatCam webcam, like $8 new, and I tried it as well. I still cannot get it to work but it seems that the error is different. When I run "cheese" the error is "There was an error playing video from the webcam".

[user@work ~]$ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 1e4e:0110 Cubeternet Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[user@work ~]$ cheese (cheese:12365): Gtk-WARNING : 10:40:36.146: Theme parsing error: cheese.css:7:35: The style property GtkScrollbar:min-slider-length is deprecated and shouldn't be used anymore. It will be removed in a future version (cheese:12365): cheese-WARNING : 10:40:37.284: Could not read from resource.: gstv4l2bufferpool.c(1032): gst_v4l2_buffer_pool_poll (): /GstCameraBin:camerabin/GstWrapperCameraBinSrc:camera_source/GstBin:bin35/GstV4l2Src:v4l2src1: poll error 1: Invalid argument (22)

[user@work ~]$ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

e6lk7dqzm83p commented 6 years ago

Hi,

Any luck figuring out this issue? It would great to have consistent USB behavior, is there anything I can do to help diagnose this?

Thank you!

abis866i commented 6 years ago

As a matter of fact, after e6lk7dqzm83p asked the question, I tried one more time. In between several updates happened in dom0 and guess what? It is working now. I guess the Qubes OS team did its magic. For me this is a closed issue.

andrewdavidwong commented 6 years ago

@e6lk7dqzm83p, is this now working for you, too?

e6lk7dqzm83p commented 6 years ago

@andrewdavidwong, I still have issues with my USB devices (cameras, microphones, etc) being detected in my Fedora based AppVM (even though they are connected via the HW manager). When the HW manager detects my Debian AppVM I can connect the devices without issue and use them in applications (e.g. Camera, App, Wire, simple-scan, etc).

e6lk7dqzm83p commented 6 years ago

@andrewdavidwong, disregard my previous post. The latest version in testing appears to have solved this.

Thanks!

andrewdavidwong commented 6 years ago

Closing this as "resolved." If you believe the issue is not yet resolved, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen this. Thank you.

olekli commented 6 years ago

I'm trying to use a C920 USB camera on a Thinkpad X1 Carbon 6gen, latest Qubes4. The VM is running debian-9, but i also tried fedora-26. I tried both connecting the camera directly to a USB port of the Thinkpad and via a powered USB hub.

I attach it to my VM:

user@browser $ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 012: ID 046d:082d Logitech, Inc. HD Pro Webcam C920 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

user@browser $ ll /dev/video0 crw-rw----+ 1 root video 81, 0 Oct 30 13:30 /dev/video0

user@browser $ cheese

(cheese:3812): Gtk-WARNING **: Theme parsing error: cheese.css:7:35: The style property GtkScrollbar:min-slider-length is deprecated and shouldn't be used anymore. It will be removed in a future version

(cheese:3812): GStreamer-CRITICAL : gst_element_message_full_with_details: assertion 'GST_IS_ELEMENT (element)' failed Message: cheese-application.vala:211: Error during camera setup: No device found

(cheese:3812): cheese-CRITICAL **: cheese_camera_device_get_name: assertion 'CHEESE_IS_CAMERA_DEVICE (device)' failed

(cheese:3812): GLib-CRITICAL **: g_variant_new_string: assertion 'string != NULL' failed

(cheese:3812): GLib-GIO-CRITICAL **: g_settings_schema_key_type_check: assertion 'value != NULL' failed

(cheese:3812): GLib-CRITICAL **: g_variant_get_type_string: assertion 'value != NULL' failed

(cheese:3812): GLib-GIO-CRITICAL **: g_settings_set_value: key 'camera' in 'org.gnome.Cheese' expects type 's', but a GVariant of type '(null)' was given

(cheese:3812): CRITICAL : cheese_preferences_dialog_setup_resolutions_for_device: assertion 'device != NULL' failed ^C

user@browser $ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

user@browser $ ll /dev/video0 ls: cannot access '/dev/video0': No such file or directory

user@browser $ sudo dmesg [...] [ 1067.111409] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? [ 1067.999310] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? [ 1068.887291] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? [ 1069.775325] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? [ 1069.776403] usb 1-1: USB disconnect, device number 12 [ 1070.671126] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? [ 1071.559252] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? [ 1071.559340] usb usb1-port1: attempt power cycle [ 1072.759348] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? [ 1073.647189] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? [ 1073.647296] usb usb1-port1: unable to enumerate USB device

Qubes shows the device as still being attached to the VM. I can detach and reattach without problems.

Forwarding the Thinkpad's internal camera works fine.

Should I open a separate ticket for this?

andrewdavidwong commented 5 years ago

Should I open a separate ticket for this?

Let's keep it on this (reopened) issue for now (unless or until it's determined to be a separate bug).

hpaolini commented 5 years ago

Any updates? I've been trying to attach the same camera, the problem I have is that I only have one USB controller on my box, and attaching it in HVM-mode will crash mouse and keyboard.

Osndok commented 4 years ago

I'm affected by this too (for both of my webcams), and wonder if it has anything to do with using a USB-2.0 webcam on a USB-3.0 bus. I might try and dig up a USB-2.0-only card to test this theory later.

Also, I think that an earlier comment kerned out some important dmesgs, in particular all the Not yet implemented messages:

[   25.256452] vhci_hcd vhci_hcd.0: USB/IP Virtual Host Controller
[   25.256502] vhci_hcd vhci_hcd.0: new USB bus registered, assigned bus number 1
[   25.256523] vhci_hcd: created sysfs vhci_hcd.0
[   25.256558] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
[   25.256574] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   25.256590] usb usb1: Product: USB/IP Virtual Host Controller
[   25.256603] usb usb1: Manufacturer: Linux 4.19.81-1.pvops.qubes.x86_64 vhci_hcd
[   25.256618] usb usb1: SerialNumber: vhci_hcd.0
[   25.256684] hub 1-0:1.0: USB hub found
[   25.256697] hub 1-0:1.0: 8 ports detected
[   25.256836] vhci_hcd vhci_hcd.0: USB/IP Virtual Host Controller
[   25.256868] vhci_hcd vhci_hcd.0: new USB bus registered, assigned bus number 2
[   25.256892] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[   25.256921] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 4.19
[   25.256937] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   25.256952] usb usb2: Product: USB/IP Virtual Host Controller
[   25.256965] usb usb2: Manufacturer: Linux 4.19.81-1.pvops.qubes.x86_64 vhci_hcd
[   25.256980] usb usb2: SerialNumber: vhci_hcd.0
[   25.257036] hub 2-0:1.0: USB hub found
[   25.257049] hub 2-0:1.0: 8 ports detected
[   26.167104] vhci_hcd vhci_hcd.0: pdev(0) rhport(0) sockfd(0)
[   26.167123] vhci_hcd vhci_hcd.0: devid(131094) speed(3) speed_str(high-speed)
[   26.385790] usb 1-1: new high-speed USB device number 2 using vhci_hcd
[   26.503840] usb 1-1: SetAddress Request (2) to port 0
[   28.741723] usb 1-1: New USB device found, idVendor=046d, idProduct=082d, bcdDevice= 0.11
[   28.741807] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=1
[   28.741937] usb 1-1: Product: HD Pro Webcam C920
[   28.742019] usb 1-1: SerialNumber: 83CD87DF
[   28.785829] media: Linux media interface: v0.10
[   28.789937] videodev: Linux video capture interface: v2.00
[   28.796312] uvcvideo: Found UVC 1.00 device HD Pro Webcam C920 (046d:082d)
[   28.801421] uvcvideo 1-1:1.0: Entity type for entity Processing 3 was not initialized!
[   28.801443] uvcvideo 1-1:1.0: Entity type for entity Extension 6 was not initialized!
[   28.801459] uvcvideo 1-1:1.0: Entity type for entity Extension 12 was not initialized!
[   28.801474] uvcvideo 1-1:1.0: Entity type for entity Camera 1 was not initialized!
[   28.801499] uvcvideo 1-1:1.0: Entity type for entity Extension 8 was not initialized!
[   28.801528] uvcvideo 1-1:1.0: Entity type for entity Extension 9 was not initialized!
[   28.801550] uvcvideo 1-1:1.0: Entity type for entity Extension 10 was not initialized!
[   28.801573] uvcvideo 1-1:1.0: Entity type for entity Extension 11 was not initialized!
[   28.801642] input: HD Pro Webcam C920 as /devices/platform/vhci_hcd.0/usb1/1-1/1-1:1.0/input/input1
[   28.801703] usbcore: registered new interface driver uvcvideo
[   28.801717] USB Video Class driver (1.1.1)
[   29.176572] usbcore: registered new interface driver snd-usb-audio
[   29.191016] audit: type=1130 audit(1574513530.709:71): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=alsa-state comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   29.202093] vhci_hcd: unlink->seqnum 59
[   29.202106] vhci_hcd: urb->status -104
[   29.232011] audit: type=1106 audit(1574513530.749:72): pid=1078 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask,pam_lastlog acct="root" exe="/usr/lib/qubes/qrexec-agent" hostname=? addr=? terminal=? res=success'
[   29.608276] usb usb1: Not yet implemented
[   29.609356] usb usb1: Not yet implemented
[   29.610350] usb usb1: Not yet implemented
[   29.611277] usb usb1: Not yet implemented
[   29.612255] usb usb1: Not yet implemented
[   29.613255] usb usb1: Not yet implemented
[   29.614249] usb usb1: Not yet implemented
[   29.615269] usb usb1: Not yet implemented
[   29.616263] usb usb1: Not yet implemented
[   29.617277] usb usb1: Not yet implemented
[   34.609891] vhci_get_frame_number: 4992 callbacks suppressed
[   34.609898] usb usb1: Not yet implemented
[   34.611116] usb usb1: Not yet implemented
[   34.612113] usb usb1: Not yet implemented
[   34.612918] usb usb1: Not yet implemented
[   34.614174] usb usb1: Not yet implemented
[   34.615009] usb usb1: Not yet implemented
[   34.618497] vhci_hcd: unlink->seqnum 5092
[   34.618543] vhci_hcd: unlink->seqnum 5093
[   34.618578] vhci_hcd: unlink->seqnum 5094
[   34.618613] vhci_hcd: unlink->seqnum 5095
[   34.618648] vhci_hcd: unlink->seqnum 5096
[   34.618719] vhci_hcd: the urb (seqnum 5096) was already given back
[   34.618886] vhci_hcd: unlink->seqnum 5092
[   34.618922] vhci_hcd: unlink->seqnum 5093
[   34.618957] vhci_hcd: unlink->seqnum 5094
[   34.618992] vhci_hcd: unlink->seqnum 5095
[   34.619028] vhci_hcd: unlink->seqnum 5097
[   34.619064] vhci_hcd: the urb (seqnum 5097) was already given back
[   34.619122] vhci_hcd: unlink->seqnum 5092
[   34.619159] vhci_hcd: urb->status -104
[   34.619197] vhci_hcd: unlink->seqnum 5093
[   34.619233] vhci_hcd: urb->status -104
[   34.619271] vhci_hcd: unlink->seqnum 5094
[   34.619307] vhci_hcd: urb->status -104
[   34.619344] vhci_hcd: unlink->seqnum 5095
[   34.619379] vhci_hcd: urb->status -104
[   34.619416] vhci_hcd: unlink->seqnum 5098
[   34.619483] vhci_hcd: urb->status -104
[   34.619521] vhci_hcd: unlink->seqnum 5099
[   34.619556] vhci_hcd: urb->status -104
[   34.619593] vhci_hcd: unlink->seqnum 5100
[   34.619630] vhci_hcd: urb->status -104
[   34.619667] vhci_hcd: unlink->seqnum 5101
[   34.619703] vhci_hcd: urb->status -104
[   34.619799] vhci_hcd: unlink->seqnum 5102
[   34.619836] vhci_hcd: urb->status -104
[   34.619876] vhci_hcd: unlink->seqnum 5103
[   34.619923] vhci_hcd: urb->status -104
[   38.472013] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[   39.359966] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[   40.247998] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[   41.136080] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[   41.136243] usb 1-1: USB disconnect, device number 2
[   42.039816] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[   42.928001] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[   42.928094] usb usb1-port1: attempt power cycle
[   44.127965] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[   45.016620] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[   45.016719] usb usb1-port1: unable to enumerate USB device
[   57.041109] kauditd_printk_skb: 1 callbacks suppressed

xaki23 commented 4 years ago

this looks like another case of https://github.com/QubesOS/qubes-issues/issues/3778

the combination of "unlinking urbs" (which is a sign of the usb device being reset) followed by the "cable is bad" (indicating it never came back from that reset).

abeluck commented 4 years ago

I am also facing this issue.

I found a strange phenomenon however:

Attach usb webcam to computer (on a usb3 port)
via sys-usb attach the webcam device to a debian 10 vm
Run guvcview immediately after the device is passed-through

And it works! I've let it run several hours and it works fine.

However as soon as I exit/restart guvcview, it errors with "no video device found" and dmesg is back to:

[  983.828969] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[  984.717012] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[  985.605069] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[  986.493024] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[  986.497395] usb 1-1: USB disconnect, device number 12
[  987.404873] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[  988.293040] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[  988.293121] usb usb1-port1: attempt power cycle
[  989.493080] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[  990.380956] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[  990.381036] usb usb1-port1: unable to enumerate USB device

e6lk7dqzm83p commented 4 years ago

I had this issue reappear a few weeks ago (after an update, from what I can determine), but it appears to have been fixed with the latest update (interesting an issue I noticed reconnecting a printer from one AppVM to another that was only solved by power cycling the printer).

Hopefully this update solved you issue as well? Prior to the first update I did not have any issue connecting my camera.

andrewdavidwong commented 4 years ago

@abeluck, @Osndok, @hpaolini @olekli: Did the latest update also fix this for you?

e6lk7dqzm83p commented 4 years ago

Hi,

I'm sorry, but I'm afraid I have to report this is still an open issue for me. I am able to semi-reliably access my camera via guvcview, however it doesn't seem any other application (I've tried using a browser chat system and MS Teams) can (I should note MS Teams does detect the camera, but transmits no video).

It does seem that the USB camera only temporarily is detected...it's better (in that I can get the camera to sometimes work in guvcview), but still not fully functional.

jevank commented 4 years ago

FYI, in most trouble cases with webcam we`ve seen it needs more ram at sys-usb. At least 400mb looks ok.

e6lk7dqzm83p commented 4 years ago

@jevank I have 1024MB of RAM for sys-usb, should I increase that?

fepitre commented 4 years ago

@e6lk7dqzm83p: I would say yes. In my case for a HD webcam without setting 4GB of memory it makes crashing the webcam when attaching it to other VM (I've also several devices attached to sys-usb) while using it.

e6lk7dqzm83p commented 4 years ago

@fepitre, I'll try that. I should point out that this had previously worked with my current setup and it was only recently that this became an issue.

jevank commented 4 years ago

@jevank I have 1024MB of RAM for sys-usb, should I increase that?

I have not come across such options, but give it a try. If camera works fine in sys-usb (simple check with cheese app), kernel versions in sys-usb and appvm are the same (at least appvm not newer) everything usually works in my cases.

e6lk7dqzm83p commented 4 years ago

So, I've increased my ram to 4096GB and it has had no impact. I can still get a camera feed in guvcview, but I can't get any other apps (i.e. actual video conferencing apps) to work. This has previously been working and I suspect one of the recent Qubes updates broke this.

e6lk7dqzm83p commented 4 years ago

Ok, some more information. I swapped out my old webcam (a Logitech Orbit, which output 720p video) and tried a camera through a video capture card (which is 1080p). I can get video working in the guvcview and the Zoom app, but video through a website is weird; the video is slow and choppy generally (that's probably more of a systems resource thing). I can't get the video feed working at all in MS Teams (which I think had worked with the orbit previously) with either setup.

I also have found the capture card to be continuously detected by the AppVM (i.e. it shows up when I run lsusb); this doesn't happen with the Logitech Orbit.

e6lk7dqzm83p commented 4 years ago

More information: -The old Logitech Orbit does work on a Windows machine; for some reason it cannot be consistently detected in Qubes (it appears and then disappears in lsusb); given I can't replicate this with any other camera I'm guessing this is an issue with the old Logitech Orbit

-Everything works fine with my built in, extremely low quality, laptop camera (which runs over USB), including MS Teams.

-The camera capture card is consistently detected, but it appears that only some local apps (e.g., guvcview, Zoom) have no issues, others (e.g., MS Teams) cannot. The issue I had with a browser seems to be a formatting issues (it appears the browser is reading the video feed as YU12 or YV12 which I haven't figured out how to fix).

All of this is to say that it appears I can only reproduce this USB connection issue with an old webcam and it appears everything otherwise seems to be working. Given the age of the problematic camera I think we can discount this issue and considered it closed (at least from my end).

Sorry for all the posts....

andrewdavidwong commented 4 years ago

Thanks for the update, @e6lk7dqzm83p. Before closing this issue, I'd like to hear back from the other users who reported it above to see whether it has been resolved for them too.

khisanth6 commented 4 years ago

Hi I am still struggling to use my Logitech C270 in Qubes. It runs only in guvcview under debian. It doesn't work in fedora or zoom. Interesting observation might be that if I attach camera, run guvcview, exit guvcview and run it again. It works only for the first time. Second time it will show no cameras attached. It might suggest that it is not a problem with forwarding the video stream but in device closure. Anyway for me the issue is still open.

SvenSemmler commented 4 years ago

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

On 7/30/20 4:31 PM, khisanth6 wrote:

I am still struggling to use my Logitech C270 in Qubes

I am using the same camera also with a Debian qube. Since installing cheese in the qube's template it works substantially better for me.

/Sven

public key: https://www.svensemmler.org/0x8F541FB6.asc fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6 -----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAl8jeY4ACgkQ2m4We49U H7bIDhAAxMqYfeVtcm/zzfIor0v5BoGVpa5AzVkC7e4olMfkl+i5id7aQ9pZIzx+ 3zyXB185W3WIBYmctBbM5W3afOjXdaTohT4VejWuZcpvH07VlaMB6PgWIzDGfQae k3uTtY2uwKnCl1kiyqTgKnLuGCvfS4zvpq4KJ3bTmM2Ehcr9OHCyTWZabfnxZjw0 4gJZ5jzUXB4AWAQu6QXhoL3mOCz80KeNIJvtANgvsxwNM+tdqNvmTOMEnyZifJMv 0boPMn/85Ebqczw05DrvVYjNlhsjTyg2VIgNaYtS5BDlUhPPad0UoJ4hnq2Qc3/y SPuVLAilm+J/zmOp5VGJc+9tLtUjmb0i+isAO84WKukq5IOxwSeqJqSgyPskZPKv PFyts/GjqP4rGJEwic0Wo86fAJQDah+JyaAhjsODnF2elyyeCfMo+BL37DM4FSxA BWCqxVqhtqyBzLD7SqDlI4+UoDcflfJsNen7QFeZC402zxYrieq9RMvjYJqCM3DI AoicMjTgVF5G/O45XpqcnFcjnJLxtsSedn8K1chTeAKHdvNRWHCmC87F3Xe/OxkE t5J0VLDB4Vpcb2rQH8xCSd5/BLo/wPBPeT/xVVwx1CpRkgv5R7YDq7kh1vrpeHOh deXJIojV6UiJ8byFUoWg5VaqRJ1M7WngxUeru5rCGmqXKgmUxh8= =LWlC -----END PGP SIGNATURE-----

Osndok commented 4 years ago

It's still a pretty hard fail over here. Just updated everything & rebooted (to make sure the updates took). My convenient test vectors find that *native" fedora-31 works with my two connected webcams. Likewise, both work well enough in sys-usb (maybe some 2d image copy lag), but when forwarded to another qube it falls flat on its face.

Version numbers (in case it helps): 4.19.128-1.pvops.qubes.x86_64 - dom0 - fedora-25 5.6.16-1.qubes.x86_64 - sys-usb - fedora-32 5.6.16-1.qubes.x86_64 - disposable vm - fedora-32

Somewhere between "fails miserably" & "fails spectacularly", as it seems that everything is left in an inconsistent state: the webcam(s), the source vm (sys-usb), the target vm... maybe even the usb hub?!? From this state trying to connect or disconnect other usb devices may experience minutes worth of latency before qubes picks them up (if ever), sometimes the webcams don't work quite right afterwards (hard/unplug reset), reboot computer, etc. I'm not sure, but it might have even permanently upset the white-balance on one of them (not sure which tool to use to reset it to defaults).

I even tried the "four gigs of memory" thing, but that didn't seem to help at all.

brendanhoar commented 4 years ago

usb-ip, used in qubes for usb forwarding, continues to be an unreliable mess. If possible on your hardware, consider attaching the pci device that is the usb Controller directly to the VM that needs the camera (Iljust be sure your keyboard, etc. doesn’t go through that controller).

khisanth6 commented 4 years ago

Thanks for all the suggestions but ...

Cheese behaves the same way as guvcview and installing it do not change anything in general.
I wish I could connect my usb hub with camera directly to AppVM but unfortunately all of my devices are connected to one usb hub.

SvenSemmler commented 4 years ago

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

Well "cheese" made it better, not reliable. I just have to detach/attach 2-3 times instead of fiddling for minutes.

Another observation is that my build-in Webcam (almost) always works. The reason I have the Logitech C270 is that I needed one to go on-top of the external monitor and in the middle of the pandemic this was the only one available at a local Walmart.

It would be useful to have some kind of poll / survey of other Qubes users using external webcams. Which ones work perfectly? Please reply.

/Sven

public key: https://www.svensemmler.org/0x8F541FB6.asc fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6 -----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAl8kSyQACgkQ2m4We49U H7ZSiBAAzyjOkAYVQJBwQL+7D1ao8RuHknvrEFxPK6eQuWCbicoAeIfxhf45lpb9 4PspDe7hKixThSY33URiiub8HSwCOAaAo+mGzq0vIofoZwVVr0b+fEQ19D+zLHVT LoNbyq8/WvDK7VgCZa3Omd+vmg294qf75xNtZEr9wY9KzsOLWvx9FoSWzsCaOzYB F1a+q9VZo5wqL77hjdamGPHqAGkr8Jkooux85FDhRZYtPCyCYk1S6+NNIP7Qneg+ GBcHYVETMT4E49NZZYXrfb6CzMwE7zXg41mWn2KjnpeRpvaPImCK6HAppBGLl3ig RMcFHtCrv1yqs6wSFqGsqFFaQw21mJS+GmXVTdvykv9BzcN91J5NPl3ixAOc2nuX +7CrglNONCF6xX6E6hMrr3+yohVQE8fi/e/7NEUWNC0WEa2FpDUSrXaX/fLmM89L 3lipvpIz9VQyjFiJ5Q1Zg8/BUu2CSuet02hOCDZg3+55ydgUZM/xReVgIzuR1+Wd XfOC28jVrnayxMbG0NW01oHuPCcz6r9zHiwNBmpu2zQA+bSH/CmX3G4yqrWWw7e/ Mfb1s2BnAWkMHdqGQAOGx/xgkSIFAiZSjgnqpv0JbpEJDAho/JduzHWaSdMpMMUQ NTc4tdjmwwgq/7++I1XBwgJ3ECApLaFcaHIhZJ4LiWGjzQmvC2g= =N+eL -----END PGP SIGNATURE-----

thoughtless commented 4 years ago

It would be useful to have some kind of poll / survey of other Qubes users using external webcams. Which ones work perfectly? Please reply.

I have a Logitech C210 and it does not work. cheese and https://meet.jit.si are unreliable and Slack doesn't work at all. The webcam disappears, and I get similar errors to those noted above (Cannot enable. Maybe the USB cable is bad?)

I have a built-in webcam and it works very reliably for everything. It is a Acer, Inc BisonCam, NB Pro.

QubesOS / qubes-issues