Hello, My Logitech HD Pro Webcam C920 does not work correctly on -CURRENT. # uname -a FreeBSD laptop.martymac.org 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r364057: Mon Aug 10 11:25:36 UTC 2020 root@laptop.martymac.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 Here are my kernel logs : Aug 25 18:52:22 laptop kernel: usb_alloc_device: Failure selecting configuration index 0:USB_ERR_TIMEOUT, port 2, addr 4 (ignored) Aug 25 18:52:22 laptop kernel: ugen1.4: <vendor 0x046d HD Pro Webcam C920> at usbus1 and usbconfig output : ugen1.1: <Intel EHCI root HUB> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen2.1: <Intel EHCI root HUB> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen2.2: <vendor 0x8087 product 0x0024> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.2: <vendor 0x8087 product 0x0024> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.3: <Chicony Electronics Co., Ltd. Integrated Camera> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA) ugen1.4: <vendor 0x046d HD Pro Webcam C920> at usbus1, cfg=255 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA) Dumping all configuration descriptors seems to timeout : # usbconfig -d ugen1.4 dump_all_desc ugen1.4: <vendor 0x046d HD Pro Webcam C920> at usbus1, cfg=255 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x00ef <Miscellaneous device> bDeviceSubClass = 0x0002 bDeviceProtocol = 0x0001 bMaxPacketSize0 = 0x0040 idVendor = 0x046d idProduct = 0x0892 bcdDevice = 0x0019 iManufacturer = 0x0000 <no string> iProduct = 0x0002 <HD Pro Webcam C920> iSerialNumber = 0x0001 <AF8FC4EF> bNumConfigurations = 0x0001 <waits a bit... and nothing more> Finally, webcamd-5.7.1.1_1 gives me the following : Aug 25 18:52:23 laptop webcamd[1422]: webcamd: Cannot find USB device Note that idProduct (0x0892) is different from usual HD Pro Webcam C920 (0x082d) as found on : https://wiki.freebsd.org/WebcamCompat maybe a new version of the product (I've just received it) ? Best regards, Ganael.
I think I read somewhere in the Linux code that this device is quirked! Try: usbconfig -d X.Y set_config 0 Then attach webcamd manually. X.Y are numbers after ugenX.Y Search the Linux kernel code for .idVendor and .idProduct values. --HPS
Hello Hans Petter, Thanks for your answer. You may be talking about the following, as seen in drivers/usb/core/quirks.c : /* Logitech HD Pro Webcams C920, C920-C, C922, C925e and C930e */ { USB_DEVICE(0x046d, 0x082d), .driver_info = USB_QUIRK_DELAY_INIT }, { USB_DEVICE(0x046d, 0x0841), .driver_info = USB_QUIRK_DELAY_INIT }, { USB_DEVICE(0x046d, 0x0843), .driver_info = USB_QUIRK_DELAY_INIT }, { USB_DEVICE(0x046d, 0x085b), .driver_info = USB_QUIRK_DELAY_INIT }, { USB_DEVICE(0x046d, 0x085c), .driver_info = USB_QUIRK_DELAY_INIT }, but I could not find any quirk for product 0x0892 (I know the webcam works on Ubuntu 20: I successfully tested it). Also, "usbconfig -d 1.3 set_config 0" does not seem to produce anything interesting (no new kernel message), and webcamd still fails to find USB device afterwards :/ Best regards, Ganael.
> You may be talking about the following, as seen in drivers/usb/core/quirks.c Yes. What does usbconfig report in the cfg= field after you executed set_config 0 ? --HPS
Created attachment 217550 [details] Kernel messages with hw.usb.debug set Just in case, here are my kernel logs when calling "usbconfig -d 1.3 set_config 0" with hw.usb.debug set.
> What does usbconfig report in the cfg= field after you executed set_config 0 ? Still 255 (cfg=255)
Could you get USBDUMP logs instead: usbdump -i usbusX -f Y -vvv -s 65536 --HPS
> Still 255 (cfg=255) It means the device did not accept the command. --HPS
Created attachment 217551 [details] usbdump logs while running "usbconfig set_config 0" Yes, here they are :)
From the log you attached I see there is a problem reading the configuration descriptor. Can you show the device descriptor using usbconfig ? --HPS
Created attachment 217552 [details] usbdump logs while running "usbconfig dump_all_desc" I can show the device descriptor (dump_device_desc works) but dump_all_desc seems to timeout and only shows device descriptor and no configuration descriptor.
Created attachment 217553 [details] usbdump logs while running "usbconfig dump_all_config_desc"
Can you try this patch: Index: sys/dev/usb/usb_request.c =================================================================== --- sys/dev/usb/usb_request.c (revision 364423) +++ sys/dev/usb/usb_request.c (working copy) @@ -1010,7 +1010,7 @@ USETW(req.wLength, min_len); err = usbd_do_request_flags(udev, mtx, &req, - desc, 0, NULL, 500 /* ms */); + desc, 0, NULL, 1000 /* ms */); if (err != 0 && err != USB_ERR_TIMEOUT && min_len != max_len) { @@ -1021,7 +1021,7 @@ USETW(req.wLength, max_len); err = usbd_do_request_flags(udev, mtx, &req, - desc, USB_SHORT_XFER_OK, NULL, 500 /* ms */); + desc, USB_SHORT_XFER_OK, NULL, 1000 /* ms */); if (err == 0) { /* verify length */ I think the problem is the device is responding a bit too slow! --HPS
Hello, Thanks for your patch! I'll try it and get back to you ASAP :)
Ping.
Hello, Sorry for the delay, it took more time than expected to rebuild the kernel on my laptop. Good catch! Now the webcam is properly initialized (and I can successfully dump all descriptors), I also get an uaudio0 device! Unfortunately webcamd still cannot find USB device. It probably needs a patch to attach to product ID 0x0892. I'll see if I can make the webcam recognized. Thanks!
Created attachment 217597 [details] usbconfig dump_all_desc output after patch
Created attachment 217599 [details] Patch attempt for webcamd No luck, I tried the simple patch attached, but it did not work. Am I missing something ?
Comment on attachment 217599 [details] Patch attempt for webcamd + .bInterfaceClass = USB_CLASS_VIDEO, + .bInterfaceSubClass = 1, + .bInterfaceProtocol = 0, Check that these values also match! --HPS
A commit references this bug: Author: hselasky Date: Fri Aug 28 19:21:11 UTC 2020 New revision: 364932 URL: https://svnweb.freebsd.org/changeset/base/364932 Log: Allow slow USB devices to be given more time to return their USB descriptors, like Logitech HD Pro Webcam C920. PR: 248926 MFC after: 1 week Sponsored by: Mellanox Technologies Changes: head/sys/dev/usb/usb_request.c
> Check that these values also match! They seem so. I have just found that vendor 0x046d / product 0x0892 should be handled by the gspca/vc032x driver, not uvc as I originally thought. The uvc driver only handles another kind of C920, with product ID 0x082d. So Logitech seems to sell two versions of the C920 and my webcam appears as Orbicam in the driver's code. Anyway, this is weird as gspca/vc032x is enabled and should detect the webcam... Best regards, Ganael.
Try to run usbdump -i usbusX -f Y while attaching webcamd, to see if there are any more USB errors. --HPS
OK, thanks for the hint. I'll try that ASAP. Best regards, Ganael.
Created attachment 217643 [details] usbcump logs while starting webcamd Hello, Find attached usbdump logs when running webcamd. It seems the last request has stalled ?
Created attachment 217748 [details] Working patch for webcamd Hello, Finally I got the webcam working with webcamd. It seems that the gspca/vc032x driver catches the webcamd before uvc and fails to handle the device properly. The attached patch disables detection of product ID 0x0892 within vc032x and adds appropriate product ID to uvc. With that patch, I am able to use the device with vlc. Best regards, Ganael.
This patch should go upstream Linux first: linux-media@vger.kernel.org --HPS
Hello, Thanks, but there is something I don't understand. My patch here forces uvc driver to handle the device, but that may not be the best fix (because I have to disable original orbicams support). On Linux (Debian 10), both drivers are loaded and my webcam works natively. I don't think that Debian has local patches to add support for product ID 0x0892 within uvc so, in some way, both drivers (gspca/vc032x and uvc) manage to handle the device. I don't know how they relate to each other, though. I am thinking to something as gspca/vc032x acting as a "frontend" driver and delegating USB video class management to the uvc driver afterwards. Is that possible ? Is there a possibility webcamd misses something in that area ? (also, as a side note, Logitech support has just confirmed that my device is not a fake)
It may be a race that UVC wins over the other driver, or they have some kind of priority. Can you check if both drivers are attached to the device in Linux? How many V4L devices are produced? --HPS
Hello, Reading kernel logs, we can see that gspca_vc032x tries to attach to the webcam but fails. Finally, uvcvideo handles the device : Sep 8 17:32:23 usbkey kernel: [ 36.871243] gspca_main: v2.14.0 registered Sep 8 17:32:23 usbkey kernel: [ 36.886648] gspca_main: vc032x-2.14.0 probing 046d:0892 Sep 8 17:32:23 usbkey kernel: [ 36.887121] gspca_vc032x: reg_r err -32 Sep 8 17:32:23 usbkey kernel: [ 36.898532] uvcvideo: Found UVC 1.00 device HD Pro Webcam C920 (046d:0892) Sep 8 17:32:23 usbkey kernel: [ 36.900605] uvcvideo 3-2:1.0: Entity type for entity Processing 3 was not initialized! Sep 8 17:32:23 usbkey kernel: [ 36.900608] uvcvideo 3-2:1.0: Entity type for entity Extension 6 was not initialized! Sep 8 17:32:23 usbkey kernel: [ 36.900609] uvcvideo 3-2:1.0: Entity type for entity Extension 8 was not initialized! Sep 8 17:32:23 usbkey kernel: [ 36.900611] uvcvideo 3-2:1.0: Entity type for entity Extension 9 was not initialized! Sep 8 17:32:23 usbkey kernel: [ 36.900612] uvcvideo 3-2:1.0: Entity type for entity Extension 10 was not initialized! Sep 8 17:32:23 usbkey kernel: [ 36.900613] uvcvideo 3-2:1.0: Entity type for entity Extension 11 was not initialized! Sep 8 17:32:23 usbkey kernel: [ 36.900614] uvcvideo 3-2:1.0: Entity type for entity Extension 13 was not initialized! Sep 8 17:32:23 usbkey kernel: [ 36.900616] uvcvideo 3-2:1.0: Entity type for entity Camera 1 was not initialized! Sep 8 17:32:23 usbkey kernel: [ 36.901788] uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b2eb) Sep 8 17:32:23 usbkey kernel: [ 36.913210] uvcvideo 1-1.6:1.0: Entity type for entity Extension 4 was not initialized! Sep 8 17:32:23 usbkey kernel: [ 36.913213] uvcvideo 1-1.6:1.0: Entity type for entity Extension 3 was not initialized! Sep 8 17:32:23 usbkey kernel: [ 36.913215] uvcvideo 1-1.6:1.0: Entity type for entity Processing 2 was not initialized! Sep 8 17:32:23 usbkey kernel: [ 36.913216] uvcvideo 1-1.6:1.0: Entity type for entity Camera 1 was not initialized! Sep 8 17:32:23 usbkey kernel: [ 36.913358] usbcore: registered new interface driver uvcvideo Afterwartds, I get the following : # lsmod | grep -e uvc -e vc032x gspca_vc032x 36864 0 gspca_main 28672 1 gspca_vc032x uvcvideo 118784 0 videobuf2_vmalloc 16384 2 gspca_main,uvcvideo videobuf2_v4l2 28672 2 gspca_main,uvcvideo videobuf2_common 53248 3 gspca_main,videobuf2_v4l2,uvcvideo videodev 212992 5 gspca_main,videobuf2_v4l2,uvcvideo,videobuf2_common,gspca_vc032x media 45056 2 videodev,uvcvideo usbcore 294912 11 gspca_main,xhci_hcd,ehci_pci,snd_usb_audio,snd_usbmidi_lib,usb_storage,uvcvideo,ehci_hcd,xhci_pci,uas,gspca_vc032x So gspca_vc032x does *not* use uvcvideo, they act as two separate drivers. I finally get 4 video devices : # ls -al /dev/video* crw-rw----+ 1 root 81, 0 Sep 8 17:05 /dev/video0 crw-rw----+ 1 root 81, 1 Sep 8 17:05 /dev/video1 crw-rw----+ 1 root 81, 2 Sep 8 17:06 /dev/video2 crw-rw----+ 1 root 81, 3 Sep 8 17:06 /dev/video3 The good one is /dev/video2 (usable in vlc), /dev/video0 is for my integrated webcam. I don't know for the others. # ls -l /sys/dev/char/81:*/device/driver lrwxrwxrwx 1 root 0 Sep 8 17:10 /sys/dev/char/81:0/device/driver -> ../../../../../../../bus/usb/drivers/uvcvideo lrwxrwxrwx 1 root 0 Sep 8 17:10 /sys/dev/char/81:1/device/driver -> ../../../../../../../bus/usb/drivers/uvcvideo lrwxrwxrwx 1 root 0 Sep 8 17:10 /sys/dev/char/81:2/device/driver -> ../../../../../../bus/usb/drivers/uvcvideo lrwxrwxrwx 1 root 0 Sep 8 17:10 /sys/dev/char/81:3/device/driver -> ../../../../../../bus/usb/drivers/uvcvideo We can see that all video* devices are handled through uvcvideo. That leads to two questions : - does Webcamd try other drivers if a previous one (with a matching vendorId:productId couple) fails to attach ? - how does uvcvideo attach to the device as I cannot find productId 0x0892 anywhere in its code ? For that second question, it seems that uvc_driver.c, function uvc_probe() is able to probe non-declared (generic) UVC devices, so we might be in a "fallback" case here. Remains the first question, then. A last precision: uvcvideo.ko comes from linux-image-4.19.0-10-amd64 (Debian 10) and I could not find local (Debian) patches to add productId 0x0892.
I see. Try this patch for webcamd: https://github.com/hselasky/webcamd/commit/9ddac5ff8ef5009bd6ad4e048a391268ceb1d186 --HPS
Yes! It works like a charm :) Thanks a lot HPS !
I think that PR can be close by now, thanks again :)
A commit references this bug: Author: hselasky Date: Mon Sep 21 18:27:44 UTC 2020 New revision: 365964 URL: https://svnweb.freebsd.org/changeset/base/365964 Log: MFC r364932: Allow slow USB devices to be given more time to return their USB descriptors, like Logitech HD Pro Webcam C920. PR: 248926 Sponsored by: Mellanox Technologies Changes: _U stable/12/ stable/12/sys/dev/usb/usb_request.c
A commit references this bug: Author: hselasky Date: Mon Sep 21 18:28:23 UTC 2020 New revision: 365965 URL: https://svnweb.freebsd.org/changeset/base/365965 Log: MFC r364932: Allow slow USB devices to be given more time to return their USB descriptors, like Logitech HD Pro Webcam C920. PR: 248926 Sponsored by: Mellanox Technologies Changes: _U stable/11/ stable/11/sys/dev/usb/usb_request.c
Hello Hans Petter, Any chance to get r364932 merged back to 12.2 branch ? Thanks in advance, Best regards, Ganael.
Try sending a message to re@ about that.
Hello, A quick followup: it's too late to get the patch merged to 12.2. It may be merged later as an errata notice. Stay tuned! Best regards, Ganael.
A commit references this bug: Author: martymac Date: Wed Oct 14 06:25:55 UTC 2020 New revision: 366693 URL: https://svnweb.freebsd.org/changeset/base/366693 Log: MFS r365964: Allow slow USB devices to be given more time to return their USB descriptors, like Logitech HD Pro Webcam C920. PR: 248926 Approved by: re (gjb), hselasky Changes: _U releng/12.2/ releng/12.2/sys/dev/usb/usb_request.c
As a third RC will finally be built, the patch has been merged and will be present in 12.2-RC3. Let's close that PR for real now :)
A commit references this bug: Author: hselasky Date: Wed Dec 2 11:29:10 UTC 2020 New revision: 556814 URL: https://svnweb.freebsd.org/changeset/ports/556814 Log: Update webcamd to 5.7.1.2 List of changes: - Try probing more drivers, when probe fails (PR 248926) - While at it, use GitHub to provide the required tarball archives PR: 248926 Submitted by: martymac@FreeBSD.org Approved by: pi (implicit) Changes: head/multimedia/webcamd/Makefile head/multimedia/webcamd/distinfo head/multimedia/webcamd/pkg-descr