Menu
▾
▴
linux-uvc-devel — Linux UVC development
You can subscribe to this list here.
| 2006 |
Jan
(183) |
Feb
(152) |
Mar
(69) |
Apr
(65) |
May
(57) |
Jun
(38) |
Jul
(109) |
Aug
(77) |
Sep
(85) |
Oct
(72) |
Nov
(149) |
Dec
(68) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(183) |
Feb
(143) |
Mar
(84) |
Apr
(120) |
May
(109) |
Jun
(68) |
Jul
(88) |
Aug
(150) |
Sep
(124) |
Oct
(182) |
Nov
(131) |
Dec
(175) |
| 2008 |
Jan
(195) |
Feb
(260) |
Mar
(167) |
Apr
(150) |
May
(101) |
Jun
(129) |
Jul
(245) |
Aug
(64) |
Sep
(72) |
Oct
(75) |
Nov
(152) |
Dec
(135) |
| 2009 |
Jan
(72) |
Feb
(93) |
Mar
(107) |
Apr
(35) |
May
(59) |
Jun
(127) |
Jul
(91) |
Aug
(73) |
Sep
(79) |
Oct
(82) |
Nov
(84) |
Dec
(104) |
| 2010 |
Jan
(61) |
Feb
(44) |
Mar
(81) |
Apr
(74) |
May
(50) |
Jun
(58) |
Jul
(31) |
Aug
(66) |
Sep
(83) |
Oct
(68) |
Nov
(61) |
Dec
(23) |
| 2011 |
Jan
(88) |
Feb
(81) |
Mar
(101) |
Apr
(95) |
May
(21) |
Jun
(147) |
Jul
(56) |
Aug
(121) |
Sep
(66) |
Oct
(54) |
Nov
(119) |
Dec
(50) |
| 2012 |
Jan
(54) |
Feb
(67) |
Mar
(24) |
Apr
(72) |
May
(134) |
Jun
(64) |
Jul
(105) |
Aug
(50) |
Sep
(38) |
Oct
(38) |
Nov
(53) |
Dec
(43) |
| 2013 |
Jan
(69) |
Feb
(15) |
Mar
(25) |
Apr
(14) |
May
(10) |
Jun
(13) |
Jul
(31) |
Aug
(30) |
Sep
(44) |
Oct
(12) |
Nov
(29) |
Dec
(19) |
| 2014 |
Jan
(18) |
Feb
(42) |
Mar
(25) |
Apr
(11) |
May
(20) |
Jun
(15) |
Jul
(2) |
Aug
(3) |
Sep
(10) |
Oct
(22) |
Nov
(27) |
Dec
(18) |
| 2015 |
Jan
(19) |
Feb
(17) |
Mar
(12) |
Apr
(10) |
May
(12) |
Jun
(22) |
Jul
(7) |
Aug
(12) |
Sep
(2) |
Oct
(16) |
Nov
(3) |
Dec
(30) |
| 2016 |
Jan
(19) |
Feb
(10) |
Mar
(20) |
Apr
(2) |
May
(3) |
Jun
(3) |
Jul
(4) |
Aug
(5) |
Sep
(14) |
Oct
(1) |
Nov
(7) |
Dec
(19) |
| 2017 |
Jan
(4) |
Feb
(4) |
Mar
(5) |
Apr
(3) |
May
(1) |
Jun
(8) |
Jul
(4) |
Aug
(7) |
Sep
|
Oct
(4) |
Nov
(7) |
Dec
(2) |
| 2018 |
Jan
(11) |
Feb
(5) |
Mar
(4) |
Apr
(6) |
May
(6) |
Jun
(4) |
Jul
(6) |
Aug
(2) |
Sep
(3) |
Oct
(6) |
Nov
|
Dec
(2) |
| 2019 |
Jan
(2) |
Feb
(10) |
Mar
(6) |
Apr
|
May
(6) |
Jun
(6) |
Jul
(2) |
Aug
(4) |
Sep
(2) |
Oct
(11) |
Nov
(1) |
Dec
(1) |
| 2020 |
Jan
(4) |
Feb
(1) |
Mar
(5) |
Apr
(19) |
May
(18) |
Jun
(5) |
Jul
(13) |
Aug
(12) |
Sep
(7) |
Oct
(4) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(1) |
May
(3) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(12) |
Dec
(1) |
| 2022 |
Jan
(2) |
Feb
(2) |
Mar
(6) |
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Laurent P. <lau...@id...> - 2025-10-09 09:29:45
|
On Thu, Oct 09, 2025 at 12:22:57PM +0300, Angel4005 wrote: > Hello, > > Thank you very much for your quick and helpful responses! > > I confirm that the problem seems to be related to duplicate IDs in the > descriptor of my Grandstream GUV3100 device. > > Unfortunately, I was unable to test the proposed patch, as kernel > building is beyond my current capabilities. I am not experienced in > such matters and do not want to risk the stability of my system. > > The exact breaking point when the camera stopped working was found: > > * Last known WORKING kernel (GOOD): 6.12.50-1-lts > * First known NON-WORKING kernel (BAD): 6.12.51-1-lts > > I hope this information will help pinpoint the commit that caused the > regression. We know which commit caused the regrassion, but it's hard to fix the issue properly without being able to test on the device. That's why Ricardo asked if the camera can be easily bought from somewhere. > Thank you very much for your help, guidance, and understanding! > > чт, 9 жовт. 2025 р. о 09:55 Ricardo Ribalda <ri...@ch...> пише: > > > > Hi Angel > > > > Thank you very much for the detailed report. > > > > Your device has two entities with the same id: > > VideoControl Interface Descriptor: > > bLength 31 > > bDescriptorType 36 > > bDescriptorSubtype 6 (EXTENSION_UNIT) > > bUnitID 4 > > > > > > ideoControl Interface Descriptor: > > bLength 9 > > bDescriptorType 36 > > bDescriptorSubtype 3 (OUTPUT_TERMINAL) > > bTerminalID 4 > > wTerminalType 0x0101 USB Streaming > > bAssocTerminal 0 > > bSourceID 3 > > iTerminal 0 > > > > And that confuses the code. We have recently introduced a change that > > has probably triggered the regression > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/media/usb/uvc?id=0e2ee70291e64a30fe36960c85294726d34a103e > > > > Do you know the commercial name of the device and if it is available to buy? > > > > Could you try this patch and let me know if it fixes the issue? > > > > diff --git a/drivers/media/usb/uvc/uvc_driver.c > > b/drivers/media/usb/uvc/uvc_driver.c > > index fa61f1d0ea2c..81937501fb0c 100644 > > --- a/drivers/media/usb/uvc/uvc_driver.c > > +++ b/drivers/media/usb/uvc/uvc_driver.c > > @@ -167,11 +167,23 @@ static struct uvc_entity > > *uvc_entity_by_reference(struct uvc_device *dev, > > > > static struct uvc_streaming *uvc_stream_by_id(struct uvc_device *dev, int id) > > { > > - struct uvc_streaming *stream; > > + struct uvc_streaming *stream, *last_entry; > > + unsigned int count = 0; > > > > list_for_each_entry(stream, &dev->streams, list) { > > if (stream->header.bTerminalLink == id) > > return stream; > > + count += 1; > > + last_entry = stream; > > + } > > + > > + /* > > + * If the streaming entity has an invalid id, but it is the only > > + * one available, use it. > > + */ > > + if (count == 1 && id == UVC_INVALID_ENTITY_ID) { > > + dev_err(&dev->intf->dev, "Heuristics triggered\n"); > > + return last_entry; > > } > > > > return NULL; -- Regards, Laurent Pinchart |
|
From: Vince <ube...@ya...> - 2025-08-03 19:38:06
|
Hello. I'm trying to set up a handheld camera with a webcam mode but it fails to initialize. (https://www.amazon.com/THPACIP-Camcorder-Vlogging-Recorder-Batteries/dp/B0DTJSNW9B) I'm plugging it in with a USB C cable and selecting the webcam mode when prompted. I can also disconnect it and reconnect it with the cable and the same log entries occur. Please find attached the applicable dmesg.log and lsusb.log files. Thank you all for your help and your work on the uvcvideo driver. Vince~ |
|
From: Robert A. <rob...@gm...> - 2024-02-28 02:56:38
|
Hi Folks, I was wondering if anyone has gotten UVC working on the RB5? I'm
having trouble with the UDC probe and not sure if it's a problem with
kernel configuration, configFS script (haven't made into a service yet), or
some UDC problem.
I'm getting a ENODEV error 19 when I try to bind my UVC configuration to
the UDC according to dmesg, and stdin output says "Device or resource
busy". I put printk statements into driver/usb/udc/core.c's
usb_gadget_probe_driver() which is producing the error line:>>
mutex_lock(&udc_lock);
if (driver->udc_name) {
list_for_each_entry(udc, &udc_list, list) {
ret = strcmp(driver->udc_name, dev_name(&udc->dev));
printk("****DEBUG: Driver->udc_name: %s\n",
driver->udc_name);
printk("****DEBUG: udc->dev name: %s\n", &udc->dev);
if (!ret)
break;
}
if (ret)
ret = -ENODEV;
else if (udc->driver)
ret = -EBUSY;
else
goto found;
<<
...and while udc_name came up with the string a600000.usb, &udc->dev was an
empty string. So it seems like the device is not in the master UDC list?
I don't know why...maybe my ConfigFS script is wrong?
I've attached my kernel config, ConfigFS script, and dmesg output as a
single file. Would appreciate if someone could tell me if I'm looking in
the right direction or completely off.
Regards,
Robert
|
|
From: Mark L. <la...@Ha...> - 2023-02-28 04:16:21
|
I have a Sony SRG-120DU camera. When I connect via USB3, I get dmesg:
[ 1010.810058] usb 4-3: new SuperSpeed USB device number 6 using xhci_hcd
[ 1010.830763] usb 4-3: LPM exit latency is zeroed, disabling LPM.
[ 1010.831279] usb 4-3: New USB device found, idVendor=054c,
idProduct=0b7f, bcdDevice= 0.01
[ 1010.831288] usb 4-3: New USB device strings: Mfr=0, Product=2,
SerialNumber=0
[ 1010.831291] usb 4-3: Product: SRG-120DU Series
[ 1010.833700] usb 4-3: Found UVC 1.00 device SRG-120DU Series (054c:0b7f)
[ 1010.833713] usb 4-3: No streaming interface found for terminal 2.
[ 1010.833852] input: SRG-120DU Series: SRG-120DU Ser as
/devices/pci0000:00/0000:00:14.0/usb4/4-3/4-3:1.0/input/input44
and no /dev/video* device is created.
lsusb -v for 054c:0b7f produces:
Bus 004 Device 006: ID 054c:0b7f Sony Corp. SRG-120DU Series
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 9
idVendor 0x054c Sony Corp.
idProduct 0x0b7f
bcdDevice 0.01
iManufacturer 0
iProduct 2 SRG-120DU Series
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x00dd
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 144mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 2 SRG-120DU Series
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 2 SRG-120DU Series
VideoControl Interface Descriptor:
bLength 13
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 0x004e
dwClockFrequency 1.000000MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength 0
bControlSize 3
bmControls 0x00000000
VideoControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 4
iTerminal 0
VideoControl Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 3
bSourceID 1
wMaxMultiplier 0
bControlSize 2
bmControls 0x00000000
iProcessing 0
bmVideoStandards 0x1b
None
NTSC - 525/60
SECAM - 625/50
NTSC - 625/50
VideoControl Interface Descriptor:
bLength 27
bDescriptorType 36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {0fce0c35-5728-43e0-a5cb-fde8f16efb22}
bNumControl 3
bNrPins 1
baSourceID( 0) 3
bControlSize 2
bmControls( 0) 0x07
bmControls( 1) 0x00
iExtension 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
bMaxBurst 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
INTERFACE CLASS: 0e 24 01 01 4d 00 83 00 02 00 00 00 01 00
INTERFACE CLASS: 1b 24 04 01 01 59 55 59 32 00 00 10 00 80 00
00 aa 00 38 9b 71 10 01 00 00 00 00
INTERFACE CLASS: 1e 24 05 01 00 00 05 d0 02 00 00 f9 15 00 00
f9 15 00 20 1c 00 80 1a 06 00 01 80 1a 06 00
INTERFACE CLASS: 06 24 0d 01 01 04
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 0x0016
bNumDeviceCaps 2
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x00000006
BESL Link Power Management (LPM) Supported
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
wSpeedsSupported 0x000c
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 3
Lowest fully-functional device speed is SuperSpeed (5Gbps)
bU1DevExitLat 0 micro seconds
bU2DevExitLat 0 micro seconds
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Though discontinued some years ago, Sony advertised this camera as
supported by UVC, as "plug and play" without an additional driver. It
does produce a video signal on Windows via USB3, but fails on Linux. I
am running Linux Mint:
Linux Mint 20.3 Una
5.14.0-1057-oem #64-Ubuntu SMP Mon Jan 23 17:02:19 UTC 2023 x86_64
x86_64 x86_64 GNU/Linux
Thank you for your time,
Mark Lasersohn
|
|
From: Gregoire G. <gre...@ge...> - 2022-07-01 05:22:49
|
On 6/27/22 17:31, Gregoire Gentil wrote: > Hello, > > I have UVC gadget over configfs working well alone. I have also acm + > mtp working at the same time. But uvc doesn't work in a uvc + acm > configfs configuration (while acm works in that same configuration). > > uvc alone gives: > > [ 13.544000] dwc2 c0040000.dwc2otg: new device is high-speed > [ 13.624000] dwc2 c0040000.dwc2otg: new device is high-speed > [ 13.696000] dwc2 c0040000.dwc2otg: new address 53 > [ 13.720000] configfs-gadget gadget: high-speed config #1: c > [ 13.720000] configfs-gadget gadget: uvc_function_set_alt(0, 0) > [ 13.720000] configfs-gadget gadget: reset UVC Control > [ 13.720000] configfs-gadget gadget: uvc_function_set_alt(1, 0) > [ 13.720000] configfs-gadget gadget: uvc_function_set_alt(1, 0) > > > while uvc + acm gives: > [ 13.784000] dwc2 c0040000.dwc2otg: new device is high-speed > [ 13.864000] dwc2 c0040000.dwc2otg: new device is high-speed > [ 13.932000] dwc2 c0040000.dwc2otg: new address 55 > [ 13.956000] configfs-gadget gadget: high-speed config #1: c > [ 13.956000] configfs-gadget gadget: uvc_function_set_alt(2, 0) > [ 13.956000] configfs-gadget gadget: reset UVC Control > [ 13.956000] configfs-gadget gadget: uvc_function_set_alt(3, 0) > [ 13.956000] dwc2 c0040000.dwc2otg: dwc2_hsotg_ep_sethalt(ep > ffffffc01e1fe318 ep0, 1) > [ 13.956000] dwc2 c0040000.dwc2otg: dwc2_hsotg_ep_sethalt(ep > ffffffc01e1fe318 ep0, 1) > [ 13.956000] dwc2 c0040000.dwc2otg: dwc2_hsotg_ep_sethalt(ep > ffffffc01e1fe318 ep0, 1) > [ 13.956000] dwc2 c0040000.dwc2otg: dwc2_hsotg_ep_sethalt(ep > ffffffc01e1fe318 ep0, 1) > [ 13.956000] configfs-gadget gadget: uvc_function_set_alt(3, 0) > [ 13.960000] dwc2 c0040000.dwc2otg: dwc2_hsotg_ep_sethalt(ep > ffffffc01e1fe318 ep0, 1) > [ 13.960000] dwc2 c0040000.dwc2otg: dwc2_hsotg_ep_sethalt(ep > ffffffc01e1fe318 ep0, 1) > > > And the host PC kernel gives an error when info is retrieved from the > OTG device. > > Because of a lot other (much more complicated) constraints, I'm on an > old 4.4 kernel far away from the latest. > > Is this a known bug? Could it be a hardware limitation of my OTG which > has 1 control endpoint and 16 device mode endpoints? It seems that acm > is handled before uvc, would it make sense to patch to swap how those > two are handled initially? Where should I look into in my kernel to > figure out my issue? > > Any pointer or idea would be appreciated! Thanks, > > Grégoire Hello again, It turns out that VIDIOC_DQEVENT gives 0x0102 for ((struct uvc_event *)&v4l2_event.u.data)->req.wIndex instead of 0x0100 in an uvc standalone case. All the userspace code is then screwed from this change. Does anyone have any idea why DQEVENT gives a different wIndex value (+2) in case another gadget has been handled before uvc? Grégoire |
|
From: Gregoire G. <gre...@ge...> - 2022-06-28 01:25:56
|
Hello, I have UVC gadget over configfs working well alone. I have also acm + mtp working at the same time. But uvc doesn't work in a uvc + acm configfs configuration (while acm works in that same configuration). uvc alone gives: [ 13.544000] dwc2 c0040000.dwc2otg: new device is high-speed [ 13.624000] dwc2 c0040000.dwc2otg: new device is high-speed [ 13.696000] dwc2 c0040000.dwc2otg: new address 53 [ 13.720000] configfs-gadget gadget: high-speed config #1: c [ 13.720000] configfs-gadget gadget: uvc_function_set_alt(0, 0) [ 13.720000] configfs-gadget gadget: reset UVC Control [ 13.720000] configfs-gadget gadget: uvc_function_set_alt(1, 0) [ 13.720000] configfs-gadget gadget: uvc_function_set_alt(1, 0) while uvc + acm gives: [ 13.784000] dwc2 c0040000.dwc2otg: new device is high-speed [ 13.864000] dwc2 c0040000.dwc2otg: new device is high-speed [ 13.932000] dwc2 c0040000.dwc2otg: new address 55 [ 13.956000] configfs-gadget gadget: high-speed config #1: c [ 13.956000] configfs-gadget gadget: uvc_function_set_alt(2, 0) [ 13.956000] configfs-gadget gadget: reset UVC Control [ 13.956000] configfs-gadget gadget: uvc_function_set_alt(3, 0) [ 13.956000] dwc2 c0040000.dwc2otg: dwc2_hsotg_ep_sethalt(ep ffffffc01e1fe318 ep0, 1) [ 13.956000] dwc2 c0040000.dwc2otg: dwc2_hsotg_ep_sethalt(ep ffffffc01e1fe318 ep0, 1) [ 13.956000] dwc2 c0040000.dwc2otg: dwc2_hsotg_ep_sethalt(ep ffffffc01e1fe318 ep0, 1) [ 13.956000] dwc2 c0040000.dwc2otg: dwc2_hsotg_ep_sethalt(ep ffffffc01e1fe318 ep0, 1) [ 13.956000] configfs-gadget gadget: uvc_function_set_alt(3, 0) [ 13.960000] dwc2 c0040000.dwc2otg: dwc2_hsotg_ep_sethalt(ep ffffffc01e1fe318 ep0, 1) [ 13.960000] dwc2 c0040000.dwc2otg: dwc2_hsotg_ep_sethalt(ep ffffffc01e1fe318 ep0, 1) And the host PC kernel gives an error when info is retrieved from the OTG device. Because of a lot other (much more complicated) constraints, I'm on an old 4.4 kernel far away from the latest. Is this a known bug? Could it be a hardware limitation of my OTG which has 1 control endpoint and 16 device mode endpoints? It seems that acm is handled before uvc, would it make sense to patch to swap how those two are handled initially? Where should I look into in my kernel to figure out my issue? Any pointer or idea would be appreciated! Thanks, Grégoire |
|
From: Lotz, C. <Con...@ru...> - 2022-04-29 10:52:16
|
I've troubleshooting issues with AUKEY PC-LM1E webcams. They are not working stable under Ubuntu 18.04+.
It seems there are to hardware versions. The one with 0c45:636d is working, the reported one 1d6c:0103 is not working and i've not yet found the correct quirks or settings.
Tried with:
Options uvcvideo timeout=5000
Options uvcvideo quirks=0x80 || 0x100, 0x120
Options nodrop=1
And blacklisting snd_audio...
Main error is:
Apr 29 11:09:39 test123 kernel: [ 258.735933] OT 4 <- XU 3 <- PU 2 <- IT 1
Apr 29 11:09:39 test123 kernel: [ 258.735945] usb 1-3: Found a valid video chain (1 -> 4)
Apr 29 11:09:44 test123 kernel: [ 263.837560] uvcvideo 1-3:1.1: Failed to set UVC probe control : -110 (exp. 26).
Apr 29 11:09:49 test123 kernel: [ 268.957605] uvcvideo 1-3:1.1: Failed to query (129) UVC probe control : -110 (exp. 26).
Apr 29 11:09:49 test123 kernel: [ 268.957632] uvcvideo 1-3:1.1: Failed to initialize the device (-5).
Does anybody has an idea what I could try next, or what the issue could be?
Thanks so far,
Constantin
Syslog output:
Apr 29 11:09:38 test123 kernel: [ 258.581459] usb 1-3: new high-speed USB device number 7 using xhci_hcd
Apr 29 11:09:39 test123 kernel: [ 258.730844] usb 1-3: New USB device found, idVendor=1d6c, idProduct=0103, bcdDevice= 0.10
Apr 29 11:09:39 test123 kernel: [ 258.730856] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 29 11:09:39 test123 kernel: [ 258.730862] usb 1-3: Product: PC-LM1E
Apr 29 11:09:39 test123 kernel: [ 258.730865] usb 1-3: Manufacturer: PC-LM1E
Apr 29 11:09:39 test123 kernel: [ 258.730869] usb 1-3: SerialNumber: PC-LM1E
Apr 29 11:09:39 test123 kernel: [ 258.733739] usb 1-3: Probing generic UVC device 3
Apr 29 11:09:39 test123 kernel: [ 258.733913] usb 1-3: Found format MJPEG
Apr 29 11:09:39 test123 kernel: [ 258.733921] usb 1-3: - 1280x720 (30.0 fps)
Apr 29 11:09:39 test123 kernel: [ 258.733929] usb 1-3: - 640x480 (30.0 fps)
Apr 29 11:09:39 test123 kernel: [ 258.733938] usb 1-3: - 1920x1080 (30.0 fps)
Apr 29 11:09:39 test123 kernel: [ 258.733944] usb 1-3: - 1280x720 (30.0 fps)
Apr 29 11:09:39 test123 kernel: [ 258.733953] usb 1-3: Found format H.264
Apr 29 11:09:39 test123 kernel: [ 258.733958] usb 1-3: - 1280x720 (30.0 fps)
Apr 29 11:09:39 test123 kernel: [ 258.733963] usb 1-3: - 640x480 (30.0 fps)
Apr 29 11:09:39 test123 kernel: [ 258.733969] usb 1-3: - 1920x1080 (30.0 fps)
Apr 29 11:09:39 test123 kernel: [ 258.733977] usb 1-3: - 1280x720 (30.0 fps)
Apr 29 11:09:39 test123 kernel: [ 258.733984] usb 1-3: Found format YUV 4:2:2 (YUYV)
Apr 29 11:09:39 test123 kernel: [ 258.733991] usb 1-3: - 640x480 (30.0 fps)
Apr 29 11:09:39 test123 kernel: [ 258.733996] usb 1-3: - 1280x720 (30.0 fps)
Apr 29 11:09:39 test123 kernel: [ 258.734010] usb 1-3: Found a Status endpoint (addr 81)
Apr 29 11:09:39 test123 kernel: [ 258.734021] usb 1-3: Found UVC 1.00 device PC-LM1E (1d6c:0103)
Apr 29 11:09:39 test123 kernel: [ 258.734034] usb 1-3: Added control 00000000-0000-0000-0000-000000000001/2 to device 3 entity 1
Apr 29 11:09:39 test123 kernel: [ 258.734224] usb 1-3: Adding mapping 'Exposure, Auto' to control 00000000-0000-0000-0000-000000000001/2
Apr 29 11:09:39 test123 kernel: [ 258.734237] usb 1-3: Added control 00000000-0000-0000-0000-000000000001/3 to device 3 entity 1
Apr 29 11:09:39 test123 kernel: [ 258.734427] usb 1-3: Adding mapping 'Exposure, Auto Priority' to control 00000000-0000-0000-0000-000000000001/3
Apr 29 11:09:39 test123 kernel: [ 258.734438] usb 1-3: Added control 00000000-0000-0000-0000-000000000001/4 to device 3 entity 1
Apr 29 11:09:39 test123 kernel: [ 258.734578] usb 1-3: Adding mapping 'Exposure (Absolute)' to control 00000000-0000-0000-0000-000000000001/4
Apr 29 11:09:39 test123 kernel: [ 258.734586] usb 1-3: Added control 00000000-0000-0000-0000-000000000101/2 to device 3 entity 2
Apr 29 11:09:39 test123 kernel: [ 258.734723] usb 1-3: Adding mapping 'Brightness' to control 00000000-0000-0000-0000-000000000101/2
Apr 29 11:09:39 test123 kernel: [ 258.734728] usb 1-3: Added control 00000000-0000-0000-0000-000000000101/3 to device 3 entity 2
Apr 29 11:09:39 test123 kernel: [ 258.734912] usb 1-3: Adding mapping 'Contrast' to control 00000000-0000-0000-0000-000000000101/3
Apr 29 11:09:39 test123 kernel: [ 258.734923] usb 1-3: Added control 00000000-0000-0000-0000-000000000101/7 to device 3 entity 2
Apr 29 11:09:39 test123 kernel: [ 258.735116] usb 1-3: Adding mapping 'Saturation' to control 00000000-0000-0000-0000-000000000101/7
Apr 29 11:09:39 test123 kernel: [ 258.735127] usb 1-3: Added control 00000000-0000-0000-0000-000000000101/8 to device 3 entity 2
Apr 29 11:09:39 test123 kernel: [ 258.735316] usb 1-3: Adding mapping 'Sharpness' to control 00000000-0000-0000-0000-000000000101/8
Apr 29 11:09:39 test123 kernel: [ 258.735327] usb 1-3: Added control 00000000-0000-0000-0000-000000000101/10 to device 3 entity 2
Apr 29 11:09:39 test123 kernel: [ 258.735515] usb 1-3: Adding mapping 'White Balance Temperature' to control 00000000-0000-0000-0000-000000000101/10
Apr 29 11:09:39 test123 kernel: [ 258.735526] usb 1-3: Added control 00000000-0000-0000-0000-000000000101/4 to device 3 entity 2
Apr 29 11:09:39 test123 kernel: [ 258.735662] usb 1-3: Adding mapping 'Gain' to control 00000000-0000-0000-0000-000000000101/4
Apr 29 11:09:39 test123 kernel: [ 258.735669] usb 1-3: Added control 00000000-0000-0000-0000-000000000101/5 to device 3 entity 2
Apr 29 11:09:39 test123 kernel: [ 258.735786] usb 1-3: Adding mapping 'Power Line Frequency' to control 00000000-0000-0000-0000-000000000101/5
Apr 29 11:09:39 test123 kernel: [ 258.735791] usb 1-3: Added control 00000000-0000-0000-0000-000000000101/11 to device 3 entity 2
Apr 29 11:09:39 test123 kernel: [ 258.735923] usb 1-3: Adding mapping 'White Balance Temperature, Auto' to control 00000000-0000-0000-0000-000000000101/11
Apr 29 11:09:39 test123 kernel: [ 258.735930] usb 1-3: Scanning UVC chain:
Apr 29 11:09:39 test123 kernel: [ 258.735933] OT 4 <- XU 3 <- PU 2 <- IT 1
Apr 29 11:09:39 test123 kernel: [ 258.735945] usb 1-3: Found a valid video chain (1 -> 4)
Apr 29 11:09:44 test123 kernel: [ 263.837560] uvcvideo 1-3:1.1: Failed to set UVC probe control : -110 (exp. 26).
Apr 29 11:09:49 test123 kernel: [ 268.957605] uvcvideo 1-3:1.1: Failed to query (129) UVC probe control : -110 (exp. 26).
Apr 29 11:09:49 test123 kernel: [ 268.957632] uvcvideo 1-3:1.1: Failed to initialize the device (-5).
Apr 29 11:09:49 test123 mtp-probe: checking bus 1, device 7: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
Apr 29 11:09:49 test123 mtp-probe: bus: 1, device: 7 was not an MTP device
Apr 29 11:09:49 test123 mtp-probe: checking bus 1, device 7: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
Apr 29 11:09:49 test123 mtp-probe: bus: 1, device: 7 was not an MTP device
Apr 29 11:09:49 test123 cheese[2515]: Native Windows taller than 65535 pixels are not supported
Apr 29 11:09:49 test123 cheese[2515]: cheese-application.vala:222: Error during camera setup: No device found
Apr 29 11:09:49 test123 cheese[2515]: cheese_camera_device_get_name: assertion 'CHEESE_IS_CAMERA_DEVICE (device)' failed
Apr 29 11:09:49 test123 cheese[2515]: g_variant_new_string: assertion 'string != NULL' failed
Apr 29 11:09:49 test123 cheese[2515]: g_variant_ref_sink: assertion 'value != NULL' failed
Apr 29 11:09:49 test123 cheese[2515]: g_settings_schema_key_type_check: assertion 'value != NULL' failed
Apr 29 11:09:49 test123 cheese[2515]: g_variant_get_type_string: assertion 'value != NULL' failed
Apr 29 11:09:49 test123 cheese[2515]: g_settings_set_value: key 'camera' in 'org.gnome.Cheese' expects type 's', but a GVariant of type '(null)' was given
Apr 29 11:09:49 test123 cheese[2515]: g_variant_unref: assertion 'value != NULL' failed
Apr 29 11:09:49 test123 cheese[2515]: cheese_preferences_dialog_setup_resolutions_for_device: assertion 'device != NULL' failed
Apr 29 11:09:49 test123 gnome-shell[987]: Could not create transient scope for PID 0: GDBus.Error:org.freedesktop.systemd1.UnitExists: Unit app-gnome-org.gnome.Cheese-0.scope already exists.
Apr 29 11:09:55 test123 cheese[2515]: Unable to create dummy onscreen: No foreign surface, and wl_shell unsupported by the compositor
Lsusb:
Bus 001 Device 012: ID 1d6c:0103 PC-LM1E PC-LM1E
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x1d6c
idProduct 0x0103
bcdDevice 0.10
iManufacturer 1 PC-LM1E
iProduct 2 PC-LM1E
iSerial 3 PC-LM1E
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x02be
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 4 config
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 5 PC-LM1E
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 5 PC-LM1E
VideoControl Interface Descriptor:
bLength 13
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 0x004f
dwClockFrequency 48.000000MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength 0
bControlSize 3
bmControls 0x0000000e
Auto-Exposure Mode
Auto-Exposure Priority
Exposure Time (Absolute)
VideoControl Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 2
bSourceID 1
wMaxMultiplier 0
bControlSize 2
bmControls 0x0000165b
Brightness
Contrast
Saturation
Sharpness
White Balance Temperature
Gain
Power Line Frequency
White Balance Temperature, Auto
iProcessing 0
bmVideoStandards 0x1c
PAL - 625/50
SECAM - 625/50
NTSC - 625/50
VideoControl Interface Descriptor:
bLength 28
bDescriptorType 36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 3
guidExtensionCode {a29e7641-de04-47e3-8b2b-f4341aff8888}
bNumControls 19
bNrInPins 1
baSourceID( 0) 2
bControlSize 3
bmControls( 0) 0xff
bmControls( 1) 0xff
bmControls( 2) 0x07
iExtension 0
VideoControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 4
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 3
iTerminal 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 8
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
VideoStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (INPUT_HEADER)
bNumFormats 3
wTotalLength 0x01ac
bEndpointAddress 0x83 EP 3 IN
bmInfo 0
bTerminalLink 4
bStillCaptureMethod 0
bTriggerSupport 0
bTriggerUsage 0
bControlSize 1
bmaControls( 0) 0
bmaControls( 1) 0
bmaControls( 2) 0
VideoStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 6 (FORMAT_MJPEG)
bFormatIndex 1
bNumFrameDescriptors 4
bFlags 0
Fixed-size samples: No
bDefaultFrameIndex 1
bAspectRatioX 0
bAspectRatioY 0
bmInterlaceFlags 0x00
Interlaced stream or variable: No
Fields per frame: 1 fields
Field 1 first: No
Field pattern: Field 1 only
bCopyProtect 0
VideoStreaming Interface Descriptor:
bLength 34
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 1
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 18432000
dwMaxBitRate 55296000
dwMaxVideoFrameBufferSize 1843200
dwDefaultFrameInterval 333333
bFrameIntervalType 2
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
VideoStreaming Interface Descriptor:
bLength 34
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 2
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 480
dwMinBitRate 18432000
dwMaxBitRate 55296000
dwMaxVideoFrameBufferSize 614400
dwDefaultFrameInterval 333333
bFrameIntervalType 2
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
VideoStreaming Interface Descriptor:
bLength 34
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 3
bmCapabilities 0x00
Still image unsupported
wWidth 1920
wHeight 1080
dwMinBitRate 18432000
dwMaxBitRate 55296000
dwMaxVideoFrameBufferSize 4147200
dwDefaultFrameInterval 333333
bFrameIntervalType 2
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
VideoStreaming Interface Descriptor:
bLength 34
bDescriptorType 36
bDescriptorSubtype 7 (FRAME_MJPEG)
bFrameIndex 4
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 18432000
dwMaxBitRate 55296000
dwMaxVideoFrameBufferSize 1843200
dwDefaultFrameInterval 333333
bFrameIntervalType 2
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
VideoStreaming Interface Descriptor:
bLength 28
bDescriptorType 36
bDescriptorSubtype 16 (FORMAT_FRAME_BASED)
bFormatIndex 2
bNumFrameDescriptors 4
guidFormat {34363248-0000-0010-8000-00aa00389b71}
bBitsPerPixel 16
bDefaultFrameIndex 1
bAspectRatioX 0
bAspectRatioY 0
bmInterlaceFlags 0x00
Interlaced stream or variable: No
Fields per frame: 2 fields
Field 1 first: No
Field pattern: Field 1 only
bCopyProtect 0
bVariableSize 1
VideoStreaming Interface Descriptor:
bLength 34
bDescriptorType 36
bDescriptorSubtype 17 (FRAME_FRAME_BASED)
bFrameIndex 1
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 18432000
dwMaxBitRate 55296000
dwDefaultFrameInterval 333333
bFrameIntervalType 2
dwBytesPerLine 0
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
VideoStreaming Interface Descriptor:
bLength 34
bDescriptorType 36
bDescriptorSubtype 17 (FRAME_FRAME_BASED)
bFrameIndex 2
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 480
dwMinBitRate 18432000
dwMaxBitRate 55296000
dwDefaultFrameInterval 333333
bFrameIntervalType 2
dwBytesPerLine 0
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
VideoStreaming Interface Descriptor:
bLength 34
bDescriptorType 36
bDescriptorSubtype 17 (FRAME_FRAME_BASED)
bFrameIndex 3
bmCapabilities 0x00
Still image unsupported
wWidth 1920
wHeight 1080
dwMinBitRate 18432000
dwMaxBitRate 55296000
dwDefaultFrameInterval 333333
bFrameIntervalType 2
dwBytesPerLine 0
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
VideoStreaming Interface Descriptor:
bLength 34
bDescriptorType 36
bDescriptorSubtype 17 (FRAME_FRAME_BASED)
bFrameIndex 4
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 18432000
dwMaxBitRate 55296000
dwDefaultFrameInterval 333333
bFrameIntervalType 2
dwBytesPerLine 0
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
VideoStreaming Interface Descriptor:
bLength 27
bDescriptorType 36
bDescriptorSubtype 4 (FORMAT_UNCOMPRESSED)
bFormatIndex 3
bNumFrameDescriptors 2
guidFormat {32595559-0000-0010-8000-00aa00389b71}
bBitsPerPixel 16
bDefaultFrameIndex 1
bAspectRatioX 0
bAspectRatioY 0
bmInterlaceFlags 0x00
Interlaced stream or variable: No
Fields per frame: 2 fields
Field 1 first: No
Field pattern: Field 1 only
bCopyProtect 0
VideoStreaming Interface Descriptor:
bLength 34
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 1
bmCapabilities 0x00
Still image unsupported
wWidth 640
wHeight 480
dwMinBitRate 18432000
dwMaxBitRate 55296000
dwMaxVideoFrameBufferSize 614400
dwDefaultFrameInterval 333333
bFrameIntervalType 2
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
VideoStreaming Interface Descriptor:
bLength 34
bDescriptorType 36
bDescriptorSubtype 5 (FRAME_UNCOMPRESSED)
bFrameIndex 2
bmCapabilities 0x00
Still image unsupported
wWidth 1280
wHeight 720
dwMinBitRate 18432000
dwMaxBitRate 55296000
dwMaxVideoFrameBufferSize 1843200
dwDefaultFrameInterval 333333
bFrameIntervalType 2
dwFrameInterval( 0) 333333
dwFrameInterval( 1) 400000
VideoStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 13 (COLORFORMAT)
bColorPrimaries 1 (BT.709,sRGB)
bTransferCharacteristics 1 (BT.709)
bMatrixCoefficients 4 (SMPTE 170M (BT.601))
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x13fc 3x 1020 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 2
bInterfaceCount 2
bFunctionClass 1 Audio
bFunctionSubClass 2 Streaming
bFunctionProtocol 0
iFunction 6 PC-LM1E
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 0
iInterface 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 0x0026
bInCollection 1
baInterfaceNr(0) 3
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Microphone
bAssocTerminal 0
bNrChannels 1
wChannelConfig 0x0000
iChannelNames 0
iTerminal 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 3
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 5
iTerminal 0
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 5
bSourceID 1
bControlSize 1
bmaControls(0) 0x03
Mute Control
Volume Control
iFeature 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 3
bDelay 255 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 20
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 1
bSubframeSize 2
bBitResolution 16
bSamFreqType 4 Discrete
tSamFreq[ 0] 8000
tSamFreq[ 1] 16000
tSamFreq[ 2] 32000
tSamFreq[ 3] 48000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x89 EP 9 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0080 1x 128 bytes
bInterval 4
bRefresh 0
bSynchAddress 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 0 Undefined
wLockDelay 0x0000
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
bNumConfigurations 0
Device Status: 0x0000
(Bus Powered)
|
|
From: Laurent P. <lau...@id...> - 2022-03-13 14:26:13
|
On Sun, Mar 13, 2022 at 09:27:12AM +0000, Kieran Bingham wrote: > Quoting Jonathan Neuschäfer (2022-03-12 20:52:47) > > On Sat, Mar 12, 2022 at 10:43:22PM +0200, Laurent Pinchart wrote: > > > Hi Jonathan, > > > > > > Thank you for the patch. > > > > > > On Sat, Mar 12, 2022 at 09:33:22PM +0100, Jonathan Neuschäfer wrote: > > > > The mailing list address for UVC development has changed a while ago, > > > > but it was only updated in MAINTAINERS, not in the documentation. > > > > Update it there, too. > > > > > > Thanks for bringing this to my attention, I didn't know we were still > > > referencing that old list. > > > > > > How about moving to the lin...@vg... mailing list instead > > > ? I don't see many reasons to treat this driver with a special mailing > > > list anymore. > > > > Fine by me, but I'll wait for the opinion of others who more regularly > > contribute to the media subsystem. > > Being subscribed to the linux-uvc-devel list, and seeing that it's a > black hole where people post, and unfortunately get very little to no > response I certainly concur that it needs to be changed. > > I don't think we can guarantee a better response with linux-media, but > at least it's the right place, where the driver is actually maintained. > > So I also believe it should be moved to linux-media. Jonathan, would you send a v2 that references the lin...@vg... list ? -- Regards, Laurent Pinchart |
|
From: Kieran B. <kie...@id...> - 2022-03-13 09:27:31
|
Quoting Jonathan Neuschäfer (2022-03-12 20:52:47) > On Sat, Mar 12, 2022 at 10:43:22PM +0200, Laurent Pinchart wrote: > > Hi Jonathan, > > > > Thank you for the patch. > > > > On Sat, Mar 12, 2022 at 09:33:22PM +0100, Jonathan Neuschäfer wrote: > > > The mailing list address for UVC development has changed a while ago, > > > but it was only updated in MAINTAINERS, not in the documentation. > > > Update it there, too. > > > > Thanks for bringing this to my attention, I didn't know we were still > > referencing that old list. > > > > How about moving to the lin...@vg... mailing list instead > > ? I don't see many reasons to treat this driver with a special mailing > > list anymore. > > Fine by me, but I'll wait for the opinion of others who more regularly > contribute to the media subsystem. Being subscribed to the linux-uvc-devel list, and seeing that it's a black hole where people post, and unfortunately get very little to no response I certainly concur that it needs to be changed. I don't think we can guarantee a better response with linux-media, but at least it's the right place, where the driver is actually maintained. So I also believe it should be moved to linux-media. -- Kieran > > > Jonathan |
|
From: Laurent P. <lau...@id...> - 2022-03-12 20:43:55
|
Hi Jonathan,
Thank you for the patch.
On Sat, Mar 12, 2022 at 09:33:22PM +0100, Jonathan Neuschäfer wrote:
> The mailing list address for UVC development has changed a while ago,
> but it was only updated in MAINTAINERS, not in the documentation.
> Update it there, too.
Thanks for bringing this to my attention, I didn't know we were still
referencing that old list.
How about moving to the lin...@vg... mailing list instead
? I don't see many reasons to treat this driver with a special mailing
list anymore.
> Fixes: 616bd4e2573cb ("[media] MAINTAINERS: Update UVC driver's mailing list address")
> Signed-off-by: Jonathan Neuschäfer <j.n...@gm...>
> ---
>
> The ML is marked "subscribers-only" in MAINTAINERS. Perhaps it would
> be useful to bring that up in the docs too.
> ---
> Documentation/userspace-api/media/drivers/uvcvideo.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/userspace-api/media/drivers/uvcvideo.rst b/Documentation/userspace-api/media/drivers/uvcvideo.rst
> index e5fd8fad333c9..dcf992f85d471 100644
> --- a/Documentation/userspace-api/media/drivers/uvcvideo.rst
> +++ b/Documentation/userspace-api/media/drivers/uvcvideo.rst
> @@ -7,7 +7,7 @@ This file documents some driver-specific aspects of the UVC driver, such as
> driver-specific ioctls and implementation notes.
>
> Questions and remarks can be sent to the Linux UVC development mailing list at
> -lin...@li....
> +lin...@li....
>
>
> Extension Unit (XU) support
--
Regards,
Laurent Pinchart
|
|
From: Laurent P. <lau...@id...> - 2022-03-12 18:59:46
|
Hi Michael, On Fri, Mar 11, 2022 at 09:24:26PM +0100, Michael Grzeschik wrote: > Ping! > > This series seems to be hanging around. It would be nice to get these > patches upstream, as they help my uvc-gadget workflow. Without them it > is likely that in the development cases my gadget won't start and then > leave the whole xhci controller broken. > > @Laurent, what do you think? I think I've explained before how this should be fixed at the V4L2 level. The problem actually affects character devices globally, and Greg KH said he would have a go at fixing it there, but I don't think much happened. Starting with a V4L2-level fix is fine with me. There are a few patches in the series that are specific to uvcvideo, I'll have another look and merge those. > On Wed, Sep 16, 2020 at 07:25:42PM -0700, Guenter Roeck wrote: > > Something seems to have gone wrong with v3 of this patch series. > > I am sure I sent it out, but I don't find it anywhere. > > Resending. Sorry for any duplicates. > > > > The uvcvideo code has no lock protection against USB disconnects > > while video operations are ongoing. This has resulted in random > > error reports, typically pointing to a crash in usb_ifnum_to_if(), > > called from usb_hcd_alloc_bandwidth(). A typical traceback is as > > follows. > > > > usb 1-4: USB disconnect, device number 3 > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 > > PGD 0 P4D 0 > > Oops: 0000 [#1] PREEMPT SMP PTI > > CPU: 0 PID: 5633 Comm: V4L2CaptureThre Not tainted 4.19.113-08536-g5d29ca36db06 #1 > > Hardware name: GOOGLE Edgar, BIOS Google_Edgar.7287.167.156 03/25/2019 > > RIP: 0010:usb_ifnum_to_if+0x29/0x40 > > Code: <...> > > RSP: 0018:ffffa46f42a47a80 EFLAGS: 00010246 > > RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff904a396c9000 > > RDX: ffff904a39641320 RSI: 0000000000000001 RDI: 0000000000000000 > > RBP: ffffa46f42a47a80 R08: 0000000000000002 R09: 0000000000000000 > > R10: 0000000000009975 R11: 0000000000000009 R12: 0000000000000000 > > R13: ffff904a396b3800 R14: ffff904a39e88000 R15: 0000000000000000 > > FS: 00007f396448e700(0000) GS:ffff904a3ba00000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: 0000000000000000 CR3: 000000016cb46000 CR4: 00000000001006f0 > > Call Trace: > > usb_hcd_alloc_bandwidth+0x1ee/0x30f > > usb_set_interface+0x1a3/0x2b7 > > uvc_video_start_transfer+0x29b/0x4b8 [uvcvideo] > > uvc_video_start_streaming+0x91/0xdd [uvcvideo] > > uvc_start_streaming+0x28/0x5d [uvcvideo] > > vb2_start_streaming+0x61/0x143 [videobuf2_common] > > vb2_core_streamon+0xf7/0x10f [videobuf2_common] > > uvc_queue_streamon+0x2e/0x41 [uvcvideo] > > uvc_ioctl_streamon+0x42/0x5c [uvcvideo] > > __video_do_ioctl+0x33d/0x42a > > video_usercopy+0x34e/0x5ff > > ? video_ioctl2+0x16/0x16 > > v4l2_ioctl+0x46/0x53 > > do_vfs_ioctl+0x50a/0x76f > > ksys_ioctl+0x58/0x83 > > __x64_sys_ioctl+0x1a/0x1e > > do_syscall_64+0x54/0xde > > > > While there are not many references to this problem on mailing lists, it is > > reported on a regular basis on various Chromebooks (roughly 300 reports > > per month). The problem is relatively easy to reproduce by adding msleep() > > calls into the code. > > > > I tried to reproduce the problem with non-uvcvideo webcams, but was > > unsuccessful. I was unable to get Philips (pwc) webcams to work. gspca > > based webcams don't experience the problem, or at least I was unable to > > reproduce it (The gspa driver does not trigger sending USB messages in the > > open function, and otherwise uses the locking mechanism provided by the > > v4l2/vb2 core). > > > > I don't presume to claim that I found every issue, but this patch series > > should fix at least the major problems. > > > > The patch series was tested exensively on a Chromebook running chromeos-4.19 > > and on a Linux system running a v5.8.y based kernel. > > > > v3: > > - In patch 5/5, add missing calls to usb_autopm_put_interface() and kfree() > > to failure code path > > > > v2: > > - Added details about problem frequency and testing with non-uvc webcams > > to summary > > - In patch 4/5, return EPOLLERR instead of -ENODEV on poll errors > > - Fix description in patch 5/5 > > > > ---------------------------------------------------------------- > > Guenter Roeck (5): > > media: uvcvideo: Cancel async worker earlier > > media: uvcvideo: Lock video streams and queues while unregistering > > media: uvcvideo: Release stream queue when unregistering video device > > media: uvcvideo: Protect uvc queue file operations against disconnect > > media: uvcvideo: Abort uvc_v4l2_open if video device is unregistered > > > > drivers/media/usb/uvc/uvc_ctrl.c | 11 ++++++---- > > drivers/media/usb/uvc/uvc_driver.c | 12 ++++++++++ > > drivers/media/usb/uvc/uvc_queue.c | 32 +++++++++++++++++++++++++-- > > drivers/media/usb/uvc/uvc_v4l2.c | 45 ++++++++++++++++++++++++++++++++++++-- > > drivers/media/usb/uvc/uvcvideo.h | 1 + > > 5 files changed, 93 insertions(+), 8 deletions(-) -- Regards, Laurent Pinchart |
|
From: Michael G. <mg...@pe...> - 2022-03-11 20:42:12
|
Ping! This series seems to be hanging around. It would be nice to get these patches upstream, as they help my uvc-gadget workflow. Without them it is likely that in the development cases my gadget won't start and then leave the whole xhci controller broken. @Laurent, what do you think? Regards, Michael On Wed, Sep 16, 2020 at 07:25:42PM -0700, Guenter Roeck wrote: >Something seems to have gone wrong with v3 of this patch series. >I am sure I sent it out, but I don't find it anywhere. >Resending. Sorry for any duplicates. > >The uvcvideo code has no lock protection against USB disconnects >while video operations are ongoing. This has resulted in random >error reports, typically pointing to a crash in usb_ifnum_to_if(), >called from usb_hcd_alloc_bandwidth(). A typical traceback is as >follows. > >usb 1-4: USB disconnect, device number 3 >BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 >PGD 0 P4D 0 >Oops: 0000 [#1] PREEMPT SMP PTI >CPU: 0 PID: 5633 Comm: V4L2CaptureThre Not tainted 4.19.113-08536-g5d29ca36db06 #1 >Hardware name: GOOGLE Edgar, BIOS Google_Edgar.7287.167.156 03/25/2019 >RIP: 0010:usb_ifnum_to_if+0x29/0x40 >Code: <...> >RSP: 0018:ffffa46f42a47a80 EFLAGS: 00010246 >RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff904a396c9000 >RDX: ffff904a39641320 RSI: 0000000000000001 RDI: 0000000000000000 >RBP: ffffa46f42a47a80 R08: 0000000000000002 R09: 0000000000000000 >R10: 0000000000009975 R11: 0000000000000009 R12: 0000000000000000 >R13: ffff904a396b3800 R14: ffff904a39e88000 R15: 0000000000000000 >FS: 00007f396448e700(0000) GS:ffff904a3ba00000(0000) knlGS:0000000000000000 >CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >CR2: 0000000000000000 CR3: 000000016cb46000 CR4: 00000000001006f0 >Call Trace: > usb_hcd_alloc_bandwidth+0x1ee/0x30f > usb_set_interface+0x1a3/0x2b7 > uvc_video_start_transfer+0x29b/0x4b8 [uvcvideo] > uvc_video_start_streaming+0x91/0xdd [uvcvideo] > uvc_start_streaming+0x28/0x5d [uvcvideo] > vb2_start_streaming+0x61/0x143 [videobuf2_common] > vb2_core_streamon+0xf7/0x10f [videobuf2_common] > uvc_queue_streamon+0x2e/0x41 [uvcvideo] > uvc_ioctl_streamon+0x42/0x5c [uvcvideo] > __video_do_ioctl+0x33d/0x42a > video_usercopy+0x34e/0x5ff > ? video_ioctl2+0x16/0x16 > v4l2_ioctl+0x46/0x53 > do_vfs_ioctl+0x50a/0x76f > ksys_ioctl+0x58/0x83 > __x64_sys_ioctl+0x1a/0x1e > do_syscall_64+0x54/0xde > >While there are not many references to this problem on mailing lists, it is >reported on a regular basis on various Chromebooks (roughly 300 reports >per month). The problem is relatively easy to reproduce by adding msleep() >calls into the code. > >I tried to reproduce the problem with non-uvcvideo webcams, but was >unsuccessful. I was unable to get Philips (pwc) webcams to work. gspca >based webcams don't experience the problem, or at least I was unable to >reproduce it (The gspa driver does not trigger sending USB messages in the >open function, and otherwise uses the locking mechanism provided by the >v4l2/vb2 core). > >I don't presume to claim that I found every issue, but this patch series >should fix at least the major problems. > >The patch series was tested exensively on a Chromebook running chromeos-4.19 >and on a Linux system running a v5.8.y based kernel. > >v3: >- In patch 5/5, add missing calls to usb_autopm_put_interface() and kfree() > to failure code path > >v2: >- Added details about problem frequency and testing with non-uvc webcams > to summary >- In patch 4/5, return EPOLLERR instead of -ENODEV on poll errors >- Fix description in patch 5/5 > >---------------------------------------------------------------- >Guenter Roeck (5): > media: uvcvideo: Cancel async worker earlier > media: uvcvideo: Lock video streams and queues while unregistering > media: uvcvideo: Release stream queue when unregistering video device > media: uvcvideo: Protect uvc queue file operations against disconnect > media: uvcvideo: Abort uvc_v4l2_open if video device is unregistered > > drivers/media/usb/uvc/uvc_ctrl.c | 11 ++++++---- > drivers/media/usb/uvc/uvc_driver.c | 12 ++++++++++ > drivers/media/usb/uvc/uvc_queue.c | 32 +++++++++++++++++++++++++-- > drivers/media/usb/uvc/uvc_v4l2.c | 45 ++++++++++++++++++++++++++++++++++++-- > drivers/media/usb/uvc/uvcvideo.h | 1 + > 5 files changed, 93 insertions(+), 8 deletions(-) -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | |
|
From: Massimo B. <mas...@gm...> - 2022-03-08 11:06:06
|
Please update https://www.kernel.org/doc/html/v5.17-rc7/userspace-api/media/drivers/uvcvideo.html for the new mail-adress: lin...@li... -------- Forwarded Message -------- From: Massimo B. <mas...@gm...> To: lin...@li... Subject: Quanta Computer Inc. Astro HD Cam, not initializing Date: Tue, 08 Mar 2022 10:59:50 +0100 Hello, I have already sent this message to lin...@li... without being subcribed, got no notification if that was received and archive didn't receive it after several days. https://www.kernel.org/doc/html/v5.17-rc7/userspace-api/media/drivers/uvcvideo.html does not tell something about subcription is required or not. Anyway, trying again being subscribed now: I have a combined USB Camera with microphone. Some while ago I had the camera working, just needed to disable the microphone because if issues with pulseaudio. Now with 5.15.23-gentoo, nothing works anymore with that camera, no video and no audio input: https://forums.gentoo.org/viewtopic-p-8693533.html Is this the right place to discuss this hardware? I'm testing with guvcview, and it does not start anymore: Mar 02 10:41:49 [kernel] usb 3-12.2: USB disconnect, device number 12 Mar 02 10:41:57 [kernel] usb 3-12.2: new high-speed USB device number 14 using xhci_hcd Mar 02 10:41:57 [kernel] usb 3-12.2: New USB device found, idVendor=0408, idProduct=2090, bcdDevice=21.17 Mar 02 10:41:57 [kernel] usb 3-12.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Mar 02 10:41:57 [kernel] usb 3-12.2: Product: Astro HD Camera Mar 02 10:41:57 [kernel] usb 3-12.2: Manufacturer: QCM Mar 02 10:41:57 [kernel] usb 3-12.2: Found UVC 1.00 device Astro HD Camera (0408:2090) Mar 02 10:41:57 [kernel] usb 3-12.2: No streaming interface found for terminal 9. Mar 02 10:41:57 [kernel] input: Astro HD Camera: Astro HD Camer as /devices/pci0000:00/0000:00:14.0/usb3/3-12/3-12.2/3-12.2:1.0/input/input22 Mar 02 10:42:02 [kernel] usb 3-12.2: 4:1: cannot set freq 48000 to ep 0x84 Mar 02 10:42:08 [kernel] usb 3-12.2: 10:3: cannot get min/max values for control 2 (id 10) Mar 02 10:42:08 [mtp-probe] checking bus 3, device 14: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-12/3-12.2"_ Mar 02 10:42:08 [mtp-probe] bus: 3, device: 14 was not an MTP device_ Mar 02 10:42:08 [mtp-probe] checking bus 3, device 14: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-12/3-12.2"_ Mar 02 10:42:08 [mtp-probe] bus: 3, device: 14 was not an MTP device_ Mar 02 10:42:13 [kernel] usb 3-12.2: Failed to query (GET_DEF) UVC control 13 on unit 1: -110 (exp. 8). Mar 02 10:42:18 [kernel] usb 3-12.2: Failed to query (GET_DEF) UVC control 2 on unit 2: -110 (exp. 2). Mar 02 10:42:23 [kernel] usb 3-12.2: Failed to query (GET_DEF) UVC control 13 on unit 1: -110 (exp. 8). Mar 02 10:42:28 [kernel] usb 3-12.2: Failed to query (GET_DEF) UVC control 2 on unit 2: -110 (exp. 2). Mar 02 10:42:33 [kernel] usb 3-12.2: Failed to query (GET_DEF) UVC control 11 on unit 1: -110 (exp. 2). Mar 02 10:42:38 [kernel] usb 3-12.2: Failed to query (GET_DEF) UVC control 13 on unit 1: -110 (exp. 8). - Last output repeated twice - Mar 02 10:42:49 [kernel] usb 3-12.2: Failed to query (GET_DEF) UVC control 11 on unit 1: -110 (exp. 2). Mar 02 10:42:54 [kernel] usb 3-12.2: Failed to query (GET_DEF) UVC control 13 on unit 1: -110 (exp. 8). - Last output repeated twice - Mar 02 10:43:04 [kernel] usb 3-12.2: Failed to query (GET_DEF) UVC control 11 on unit 1: -110 (exp. 2). Booting the machine with the device connected I see many repeating lines like this in the log until unplugging the device: Mar 08 10:44:59 [kernel] usb 3-12.2: 4:1: usb_set_interface failed (-71) Mar 08 10:44:59 [kernel] usb 3-12.2: 4:0: usb_set_interface failed (-71) - Last output repeated twice - Mar 08 10:44:59 [kernel] usb 3-12.2: 4:1: usb_set_interface failed (-71) Mar 08 10:44:59 [kernel] usb 3-12.2: 4:0: usb_set_interface failed (-71) Best regards, Massimo |
|
From: Fabian S. <f.s...@ne...> - 2022-02-12 14:36:09
|
Hi Our Welch Allyn Digital Otoscope gets recognized by the uvc driver but playback on device /dev/video0 or /dev/video1 fails ffplay /dev/video0 ffplay version 4.2.4-1ubuntu0.1 Copyright (c) 2003-2020 the FFmpeg developers built with gcc 9 (Ubuntu 9.3.0-10ubuntu2) configuration: --prefix=/usr --extra-version=1ubuntu0.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-nvenc --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared libavutil 56. 31.100 / 56. 31.100 libavcodec 58. 54.100 / 58. 54.100 libavformat 58. 29.100 / 58. 29.100 libavdevice 58. 8.100 / 58. 8.100 libavfilter 7. 57.100 / 7. 57.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 5.100 / 5. 5.100 libswresample 3. 5.100 / 3. 5.100 libpostproc 55. 5.100 / 55. 5.100 [video4linux2,v4l2 @ 0x7f880c000bc0] ioctl(VIDIOC_STREAMON): Input/output error /dev/video0: Input/output error Do I need to configure any quirks to get it working ? Fabian |
|
From: Fabian S. <f.s...@ne...> - 2022-02-12 14:36:09
|
Hi Our Welch Allyn Digital Otoscope gets recognized by the uvc driver but playback on device /dev/video0 or /dev/video1 fails ffplay /dev/video0 ffplay version 4.2.4-1ubuntu0.1 Copyright (c) 2003-2020 the FFmpeg developers built with gcc 9 (Ubuntu 9.3.0-10ubuntu2) configuration: --prefix=/usr --extra-version=1ubuntu0.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-nvenc --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared libavutil 56. 31.100 / 56. 31.100 libavcodec 58. 54.100 / 58. 54.100 libavformat 58. 29.100 / 58. 29.100 libavdevice 58. 8.100 / 58. 8.100 libavfilter 7. 57.100 / 7. 57.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 5.100 / 5. 5.100 libswresample 3. 5.100 / 3. 5.100 libpostproc 55. 5.100 / 55. 5.100 [video4linux2,v4l2 @ 0x7f880c000bc0] ioctl(VIDIOC_STREAMON): Input/output error /dev/video0: Input/output error Do I need to configure any quirks to get it working ? Fabian |
|
From: Felix S. <fel...@os...> - 2022-01-19 10:19:34
|
In the mean time I noticed that "UVC" stands for "USB Video Class" so this driver does not have anything to do with audio. The right place is likely alsa and the kernel code in usb/sound which also contains a similar quirk for an earlier version of my webcam. Felix |
|
From: Felix S. <fel...@os...> - 2022-01-02 20:39:21
|
Hi, I have a Creative Live! Cam Chat HD VF0790 (USB id 041e:4097). This webcam used to work fine with Linux but for some weeks the microphone does not record the sound correctly (right now I'm using kernel 5.15.12). [1] As far as I know the uvc driver is handling this device in Linux. Is that correct? If not do you know which driver is the handling the device? One interesting thing is that Windows 10 has the exact same issue as Linux. For Windows the fix is to change the mic settings from 2 channel, 24 bit, 48000 Hz (Studio Quality) -> 2 channel, 16 bit, 48000 Hz (DVD Quality) I guess the problem is that the device advertises wrong capabilities so both Linux+Windows use the wrong bit rate. Based on other drivers I guess the best solution is to add some kind of quirk for this specific device so only 16 bit are advertised. I did not find the USB ID in the Linux source code so I guess the kernel is using a generic driver based on the USB profile but I noticed uvc_driver.c contains some quirks already. Thank you for reading until here: 1. Is this the right mailing list for my question? 2. Am I right that this device is handled by uvc? 3. Is there an easy way to restrict Linux to use only 16 bits? Felix [1] I'm not sure why it does not work anymore but it might be connected with my upgrade from F34 -> F35 (pulseaudio -> pipewire?). |
|
From: Damiano A. <dam...@gm...> - 2021-12-20 21:03:48
|
Hello,
I've been the owner of a Logitech C930e for many years now, and it does
work well on Linux in terms of "basic" webcam functionality.
But I've always found it a bit of a shame that I can't use the features I
originally bought it for: namely UVC 1.5 and H264. And not mentioning SVC
either...
To be honest, this particular model is a tricky one as far as I can see.
This is for example what *lsusb* reports out the box:
> Bus 002 Device 011: ID 046d:0843 Logitech, Inc. Webcam C930e
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 239 Miscellaneous Device
> bDeviceSubClass 2
> bDeviceProtocol 1 Interface Association
> bMaxPacketSize0 64
> idVendor 0x046d Logitech, Inc.
> idProduct 0x0843 Webcam C930e
> bcdDevice 0.13
> iManufacturer 0
> iProduct 2
> iSerial 1
> *bNumConfigurations 1*
> Configuration Descriptor:
> ...
Actually, that's not quite true: this webcam supports 2 configurations!
That's what I found when I sniffed USB traffic on a Windows 10 machine.
The first configuration mentions UVC 1.0 and uncompressed / MJPEG streams.
But the second configuration reveals the "treasure": UVC 1.5 and
uncompressed / MJPEG / H264 streams.
I couldn't find an official way to override bNumConfigurations in the Linux
USB stack, so I hacked the *usb_get_configuration()* function in
*drivers/usb/core/config.c* to falsely report 2 configurations. (Any other
suggestions on how to properly implement that?)
Quite ugly but it did the job: *lsusb* revealed the second descriptor.
For the technical details, see the difference between:
- Descriptor 0 on Linux
- https://gist.github.com/dalbani/7266379ed93b7b693bb8dd899d18e92b
- Descriptor 1 on Windows 10
- https://gist.github.com/dalbani/05432f7ce20b41f2c68ee07ff5f1c7ee
Now the question is: where to go from there?
The Linux UVC driver doesn't seem to pickup the second descriptor. Probably
because probing stops when the first UVC descriptor is found?
The logs mention that it is detected as a "UVC 1.00 device" in any case.
Let's say we could make the UVC driver use the second descriptor, what
functionalities would still be missing to be able to use H264/SVC streams?
Thanks for your help!
Regards,
--
Damiano Albani
|
|
From: Scott K L. <lo...@co...> - 2021-11-24 20:44:40
|
Thanks very much for taking a look, Laurent.
On Wed, 2021-11-24 at 08:30 +0200, Laurent Pinchart wrote:
> Hi Scott,
>
> Thank you for the patch.
>
> On Wed, Nov 24, 2021 at 12:59:05AM +0000, Scott K Logan wrote:
> > At least some of the Microsoft LifeCam series of webcams exhibit a
> > behavior which requires a 'quirk' to be handled properly. When
> > configuring the absolute exposure value of the image, there are only a
> > handful of values which will result in a consistent change to the image
> > exposure, while all other values appear to result in a maximum
> > exposure.
> > The valid values appear to follow an exponential pattern from the
> > maximum value (10000) down to the minimum, yielding less than 15
> > possible values depending on the device's reported minimum.
> >
> > Signed-off-by: Scott K Logan <lo...@co...>
> > ---
> > drivers/media/usb/uvc/uvc_ctrl.c | 41 ++++++++++++++++++++++++++++++
> > drivers/media/usb/uvc/uvc_driver.c | 27 ++++++++++++++++++++
> > drivers/media/usb/uvc/uvcvideo.h | 1 +
> > 3 files changed, 69 insertions(+)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
> > index 30bfe9069a1f..2dfc70597858 100644
> > --- a/drivers/media/usb/uvc/uvc_ctrl.c
> > +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> > @@ -2142,6 +2142,40 @@ int uvc_ctrl_restore_values(struct uvc_device *dev)
> > return 0;
> > }
> >
> > +/* --------------------------------------------------------------------------
> > + * Quirks
> > + */
> > +
> > +static s32 uvc_ctrl_get_abs_exposure_exponential(
> > + struct uvc_control_mapping *mapping, u8 query, const u8 *data)
> > +{
> > + s32 i;
> > + s32 value = uvc_get_le_value(mapping, query, data);
> > +
> > + switch (query) {
> > + case UVC_GET_CUR:
> > + case UVC_GET_MIN:
> > + case UVC_GET_MAX:
> > + case UVC_GET_DEF:
> > + for (i = 0; i < 14; ++i) {
> > + if (10000 >> i <= value)
> > + break;
> > + }
> > + return 14 - i;
> > + case UVC_GET_RES:
> > + return 1;
> > + default:
> > + return value;
> > + }
> > +}
> > +
> > +static void uvc_ctrl_set_abs_exposure_exponential(
> > + struct uvc_control_mapping *mapping, s32 value, u8 *data)
> > +{
> > + value = 10000 >> (14 - value);
>
> In addition to restricting the values to the ones correctly supported by
> the device, this maps a linear scale (1 to 10000) to an exponential
> scale (1 to 14). The V4L2 control V4L2_CID_EXPOSURE_ABSOLUTE is supposed
> to be linear, and documented as expressed in 100 µs units.
>
> Wouldn't it be better to keep the original scale (1 to 10000) and round
> the requested value to the closest supported value ?
This is a very valid point. I'm not in a position to measure the
exposure accurately, but this morning I took the time to plot the
average pixel intensity across a series of stills at varying exposure
settings. While the data didn't look quite as linear as my laptop's
built-in camera, it was substantially closer than the data without the
scaling. If the scale is supposed to be linear, this patch will
certainly make it more so.
As a gut check, I've been operating my LifeCam camera in meetings at
the manual exposure level of 156 out of 10000. The exponentially scaled
value would be 8, which is roughly half way through the advertised
scale (1-14).
> Additionally, do we have a guarantee that all the devices that need this
> quirk will have the same exposure range (1 to 10000), or could the
> maximum value be different ?
I actually didn't think about that. It appears to be the case for both
of the models I own as well as the one Yuriy has (by the way, thanks
for your reply!).
I could change the patch to query UVC_GET_MAX for each get/set
operation if you think that might be worth it. It would obviously be
better to stash the value for later use, but I'm not sure there's a
convenient spot.
> > + uvc_set_le_value(mapping, value, data);
> > +}
> > +
> > /* --------------------------------------------------------------------------
> > * Control and mapping handling
> > */
> > @@ -2210,6 +2244,13 @@ static int __uvc_ctrl_add_mapping(struct uvc_video_chain *chain,
> > }
> > }
> >
> > + if ((chain->dev->quirks & UVC_QUIRK_EXPONENTIAL_EXPOSURE) &&
> > + ctrl->info.selector == UVC_CT_EXPOSURE_TIME_ABSOLUTE_CONTROL) {
> > + uvc_dbg(chain->dev, CONTROL, "Applying exponential exposure quirk\n");
> > + map->get = uvc_ctrl_get_abs_exposure_exponential;
> > + map->set = uvc_ctrl_set_abs_exposure_exponential;
> > + }
> > +
> > list_add_tail(&map->list, &ctrl->info.mappings);
> > uvc_dbg(chain->dev, CONTROL, "Adding mapping '%s' to control %pUl/%u\n",
> > uvc_map_get_name(map), ctrl->info.entity,
> > diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
> > index 7c007426e082..9edf77ee30e6 100644
> > --- a/drivers/media/usb/uvc/uvc_driver.c
> > +++ b/drivers/media/usb/uvc/uvc_driver.c
> > @@ -2718,6 +2718,33 @@ static const struct usb_device_id uvc_ids[] = {
> > .bInterfaceSubClass = 1,
> > .bInterfaceProtocol = 0,
> > .driver_info = (kernel_ulong_t)&uvc_quirk_probe_minmax },
> > + /* Microsoft Lifecam HD-5000 */
> > + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> > + | USB_DEVICE_ID_MATCH_INT_INFO,
> > + .idVendor = 0x045e,
> > + .idProduct = 0x076d,
> > + .bInterfaceClass = USB_CLASS_VIDEO,
> > + .bInterfaceSubClass = 1,
> > + .bInterfaceProtocol = 0,
> > + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_EXPONENTIAL_EXPOSURE) },
> > + /* Microsoft Lifecam Studio */
> > + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> > + | USB_DEVICE_ID_MATCH_INT_INFO,
> > + .idVendor = 0x045e,
> > + .idProduct = 0x0772,
> > + .bInterfaceClass = USB_CLASS_VIDEO,
> > + .bInterfaceSubClass = 1,
> > + .bInterfaceProtocol = 0,
> > + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_EXPONENTIAL_EXPOSURE) },
> > + /* Microsoft Lifecam HD-3000 */
> > + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> > + | USB_DEVICE_ID_MATCH_INT_INFO,
> > + .idVendor = 0x045e,
> > + .idProduct = 0x0810,
> > + .bInterfaceClass = USB_CLASS_VIDEO,
> > + .bInterfaceSubClass = 1,
> > + .bInterfaceProtocol = 0,
> > + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_EXPONENTIAL_EXPOSURE) },
> > /* Logitech Quickcam Fusion */
> > { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> > | USB_DEVICE_ID_MATCH_INT_INFO,
> > diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
> > index 2e5366143b81..b6d5ae0b1c90 100644
> > --- a/drivers/media/usb/uvc/uvcvideo.h
> > +++ b/drivers/media/usb/uvc/uvcvideo.h
> > @@ -209,6 +209,7 @@
> > #define UVC_QUIRK_RESTORE_CTRLS_ON_INIT 0x00000400
> > #define UVC_QUIRK_FORCE_Y8 0x00000800
> > #define UVC_QUIRK_FORCE_BPP 0x00001000
> > +#define UVC_QUIRK_EXPONENTIAL_EXPOSURE 0x00002000
> >
> > /* Format flags */
> > #define UVC_FMT_FLAG_COMPRESSED 0x00000001
|
|
From: Laurent P. <lau...@id...> - 2021-11-24 06:46:24
|
Hi Scott,
Thank you for the patch.
On Wed, Nov 24, 2021 at 12:59:05AM +0000, Scott K Logan wrote:
> At least some of the Microsoft LifeCam series of webcams exhibit a
> behavior which requires a 'quirk' to be handled properly. When
> configuring the absolute exposure value of the image, there are only a
> handful of values which will result in a consistent change to the image
> exposure, while all other values appear to result in a maximum
> exposure.
> The valid values appear to follow an exponential pattern from the
> maximum value (10000) down to the minimum, yielding less than 15
> possible values depending on the device's reported minimum.
>
> Signed-off-by: Scott K Logan <lo...@co...>
> ---
> drivers/media/usb/uvc/uvc_ctrl.c | 41 ++++++++++++++++++++++++++++++
> drivers/media/usb/uvc/uvc_driver.c | 27 ++++++++++++++++++++
> drivers/media/usb/uvc/uvcvideo.h | 1 +
> 3 files changed, 69 insertions(+)
>
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
> index 30bfe9069a1f..2dfc70597858 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -2142,6 +2142,40 @@ int uvc_ctrl_restore_values(struct uvc_device *dev)
> return 0;
> }
>
> +/* --------------------------------------------------------------------------
> + * Quirks
> + */
> +
> +static s32 uvc_ctrl_get_abs_exposure_exponential(
> + struct uvc_control_mapping *mapping, u8 query, const u8 *data)
> +{
> + s32 i;
> + s32 value = uvc_get_le_value(mapping, query, data);
> +
> + switch (query) {
> + case UVC_GET_CUR:
> + case UVC_GET_MIN:
> + case UVC_GET_MAX:
> + case UVC_GET_DEF:
> + for (i = 0; i < 14; ++i) {
> + if (10000 >> i <= value)
> + break;
> + }
> + return 14 - i;
> + case UVC_GET_RES:
> + return 1;
> + default:
> + return value;
> + }
> +}
> +
> +static void uvc_ctrl_set_abs_exposure_exponential(
> + struct uvc_control_mapping *mapping, s32 value, u8 *data)
> +{
> + value = 10000 >> (14 - value);
In addition to restricting the values to the ones correctly supported by
the device, this maps a linear scale (1 to 10000) to an exponential
scale (1 to 14). The V4L2 control V4L2_CID_EXPOSURE_ABSOLUTE is supposed
to be linear, and documented as expressed in 100 µs units.
Wouldn't it be better to keep the original scale (1 to 10000) and round
the requested value to the closest supported value ?
Additionally, do we have a guarantee that all the devices that need this
quirk will have the same exposure range (1 to 10000), or could the
maximum value be different ?
> + uvc_set_le_value(mapping, value, data);
> +}
> +
> /* --------------------------------------------------------------------------
> * Control and mapping handling
> */
> @@ -2210,6 +2244,13 @@ static int __uvc_ctrl_add_mapping(struct uvc_video_chain *chain,
> }
> }
>
> + if ((chain->dev->quirks & UVC_QUIRK_EXPONENTIAL_EXPOSURE) &&
> + ctrl->info.selector == UVC_CT_EXPOSURE_TIME_ABSOLUTE_CONTROL) {
> + uvc_dbg(chain->dev, CONTROL, "Applying exponential exposure quirk\n");
> + map->get = uvc_ctrl_get_abs_exposure_exponential;
> + map->set = uvc_ctrl_set_abs_exposure_exponential;
> + }
> +
> list_add_tail(&map->list, &ctrl->info.mappings);
> uvc_dbg(chain->dev, CONTROL, "Adding mapping '%s' to control %pUl/%u\n",
> uvc_map_get_name(map), ctrl->info.entity,
> diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
> index 7c007426e082..9edf77ee30e6 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -2718,6 +2718,33 @@ static const struct usb_device_id uvc_ids[] = {
> .bInterfaceSubClass = 1,
> .bInterfaceProtocol = 0,
> .driver_info = (kernel_ulong_t)&uvc_quirk_probe_minmax },
> + /* Microsoft Lifecam HD-5000 */
> + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> + | USB_DEVICE_ID_MATCH_INT_INFO,
> + .idVendor = 0x045e,
> + .idProduct = 0x076d,
> + .bInterfaceClass = USB_CLASS_VIDEO,
> + .bInterfaceSubClass = 1,
> + .bInterfaceProtocol = 0,
> + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_EXPONENTIAL_EXPOSURE) },
> + /* Microsoft Lifecam Studio */
> + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> + | USB_DEVICE_ID_MATCH_INT_INFO,
> + .idVendor = 0x045e,
> + .idProduct = 0x0772,
> + .bInterfaceClass = USB_CLASS_VIDEO,
> + .bInterfaceSubClass = 1,
> + .bInterfaceProtocol = 0,
> + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_EXPONENTIAL_EXPOSURE) },
> + /* Microsoft Lifecam HD-3000 */
> + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> + | USB_DEVICE_ID_MATCH_INT_INFO,
> + .idVendor = 0x045e,
> + .idProduct = 0x0810,
> + .bInterfaceClass = USB_CLASS_VIDEO,
> + .bInterfaceSubClass = 1,
> + .bInterfaceProtocol = 0,
> + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_EXPONENTIAL_EXPOSURE) },
> /* Logitech Quickcam Fusion */
> { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
> | USB_DEVICE_ID_MATCH_INT_INFO,
> diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
> index 2e5366143b81..b6d5ae0b1c90 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -209,6 +209,7 @@
> #define UVC_QUIRK_RESTORE_CTRLS_ON_INIT 0x00000400
> #define UVC_QUIRK_FORCE_Y8 0x00000800
> #define UVC_QUIRK_FORCE_BPP 0x00001000
> +#define UVC_QUIRK_EXPONENTIAL_EXPOSURE 0x00002000
>
> /* Format flags */
> #define UVC_FMT_FLAG_COMPRESSED 0x00000001
--
Regards,
Laurent Pinchart
|
|
From: Scott K L. <lo...@co...> - 2021-11-24 01:17:47
|
At least some of the Microsoft LifeCam series of webcams exhibit a
behavior which requires a 'quirk' to be handled properly. When
configuring the absolute exposure value of the image, there are only a
handful of values which will result in a consistent change to the image
exposure, while all other values appear to result in a maximum
exposure.
The valid values appear to follow an exponential pattern from the
maximum value (10000) down to the minimum, yielding less than 15
possible values depending on the device's reported minimum.
Signed-off-by: Scott K Logan <lo...@co...>
---
drivers/media/usb/uvc/uvc_ctrl.c | 41 ++++++++++++++++++++++++++++++
drivers/media/usb/uvc/uvc_driver.c | 27 ++++++++++++++++++++
drivers/media/usb/uvc/uvcvideo.h | 1 +
3 files changed, 69 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index 30bfe9069a1f..2dfc70597858 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -2142,6 +2142,40 @@ int uvc_ctrl_restore_values(struct uvc_device *dev)
return 0;
}
+/* --------------------------------------------------------------------------
+ * Quirks
+ */
+
+static s32 uvc_ctrl_get_abs_exposure_exponential(
+ struct uvc_control_mapping *mapping, u8 query, const u8 *data)
+{
+ s32 i;
+ s32 value = uvc_get_le_value(mapping, query, data);
+
+ switch (query) {
+ case UVC_GET_CUR:
+ case UVC_GET_MIN:
+ case UVC_GET_MAX:
+ case UVC_GET_DEF:
+ for (i = 0; i < 14; ++i) {
+ if (10000 >> i <= value)
+ break;
+ }
+ return 14 - i;
+ case UVC_GET_RES:
+ return 1;
+ default:
+ return value;
+ }
+}
+
+static void uvc_ctrl_set_abs_exposure_exponential(
+ struct uvc_control_mapping *mapping, s32 value, u8 *data)
+{
+ value = 10000 >> (14 - value);
+ uvc_set_le_value(mapping, value, data);
+}
+
/* --------------------------------------------------------------------------
* Control and mapping handling
*/
@@ -2210,6 +2244,13 @@ static int __uvc_ctrl_add_mapping(struct uvc_video_chain *chain,
}
}
+ if ((chain->dev->quirks & UVC_QUIRK_EXPONENTIAL_EXPOSURE) &&
+ ctrl->info.selector == UVC_CT_EXPOSURE_TIME_ABSOLUTE_CONTROL) {
+ uvc_dbg(chain->dev, CONTROL, "Applying exponential exposure quirk\n");
+ map->get = uvc_ctrl_get_abs_exposure_exponential;
+ map->set = uvc_ctrl_set_abs_exposure_exponential;
+ }
+
list_add_tail(&map->list, &ctrl->info.mappings);
uvc_dbg(chain->dev, CONTROL, "Adding mapping '%s' to control %pUl/%u\n",
uvc_map_get_name(map), ctrl->info.entity,
diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c
index 7c007426e082..9edf77ee30e6 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2718,6 +2718,33 @@ static const struct usb_device_id uvc_ids[] = {
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0,
.driver_info = (kernel_ulong_t)&uvc_quirk_probe_minmax },
+ /* Microsoft Lifecam HD-5000 */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x045e,
+ .idProduct = 0x076d,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_EXPONENTIAL_EXPOSURE) },
+ /* Microsoft Lifecam Studio */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x045e,
+ .idProduct = 0x0772,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_EXPONENTIAL_EXPOSURE) },
+ /* Microsoft Lifecam HD-3000 */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x045e,
+ .idProduct = 0x0810,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_EXPONENTIAL_EXPOSURE) },
/* Logitech Quickcam Fusion */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 2e5366143b81..b6d5ae0b1c90 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -209,6 +209,7 @@
#define UVC_QUIRK_RESTORE_CTRLS_ON_INIT 0x00000400
#define UVC_QUIRK_FORCE_Y8 0x00000800
#define UVC_QUIRK_FORCE_BPP 0x00001000
+#define UVC_QUIRK_EXPONENTIAL_EXPOSURE 0x00002000
/* Format flags */
#define UVC_FMT_FLAG_COMPRESSED 0x00000001
--
2.33.1
|
|
From: Pavel K. <kys...@in...> - 2021-11-16 21:06:01
|
Hi! I use a Microsoft LifeCam Cinema camera connected to a Raspberry Pi 4B board to capture YUV frames, and wish to have PTS timestamps in my application, instead of system clock samples quantized at the URB boundary (~4 ms). Enabling the hwtimestamps parameter puts into service the sophisticated clock conversion code that resides in the uvc_video_clock_update function, but resulting timestamps look somewhat weird. To say the least, timestamps for successive frames are not monotonic. uname -a Linux raspberrypi 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 045e:075d Microsoft Corp. LifeCam Cinema Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub <Output of lsusb -d 045e:075d -v attached in lsusb.txt> modinfo uvcvideo version: 1.1.1 <full response attached in modinfo.txt> Here is a piece of uvcvideo trace for a few seconds session (full log attached in dmesg.txt) [ 1490.494279] uvcvideo: Frame complete (EOF found). [ 1490.494314] uvcvideo: frame 62 stats: 23/244/267 packets, 1/4/267 pts (early initial), 266/267 scr, last pts/stc/sof 4171438061/623018987/1826 [ 1490.494433] uvcvideo: uvc_v4l2_poll [ 1490.494538] uvcvideo: Microsoft® LifeCam Cinema(TM):: PTS 4171438061 y 302681263.118759 SOF 36015.118759 (x1 2893195733 x2 2894125607 y1 252116992 y2 254148608 SOF offset 0) [ 1490.494552] uvcvideo: Microsoft® LifeCam Cinema(TM):: SOF 33967.118759 y 31188972826 ts 1520632885720 buf ts 1490435939653 (x1 252313600/1802/1799 x2 254148608/1830/1830 y1 1000000000 y2 1028066803) [ 1490.496271] uvcvideo: uvc_v4l2_poll [ 1490.526238] uvcvideo: Frame complete (EOF found). [ 1490.526270] uvcvideo: frame 63 stats: 23/244/267 packets, 1/4/267 pts (early initial), 266/267 scr, last pts/stc/sof 4172438005/624020101/1860 [ 1490.526477] uvcvideo: uvc_v4l2_poll [ 1490.526536] uvcvideo: Microsoft® LifeCam Cinema(TM):: PTS 4172438005 y 302681296.454742 SOF 36048.454742 (x1 2893155659 x2 2894085533 y1 254214144 y2 256245760 SOF offset 0) [ 1490.526550] uvcvideo: Microsoft® LifeCam Cinema(TM):: SOF 34000.454742 y 31118682782 ts 1520594607878 buf ts 1490471949068 (x1 254410752/1834/1831 x2 256245760/1862/1862 y1 1000000000 y2 1028000212) Please note that the ts field of the last trace message for frame 63 holds 1520594607878, that is less than frame 62's ts=1520632885720. usbmon and uvcvideo traces show that the camera uses a 30 MHz clock for PTS/SCR samples, and I haven't noticed any anomalies in these fields of stream headers. In the log fragment above, the difference between PTS values equals 4172438005-4171438061=999944, that is 33.33 ms @30 MHz, matching the capturing rate of 30 FPS. Trace fields related to dev_sof also look reliable, unlike the reconstructed values of SOF and ts. Raspberry Pi 4B has both the USB 2 and 3 ports, the problem holds for both options (the log was recorded for the former). Could you please comment on this? Thank you so much for your great work! P.S. I'm sorry for my fault with cluttering the mailing list with HTML in the previous message. |
|
From: Pavel K. <kys...@in...> - 2021-11-16 21:04:55
|
Hi! I use a Microsoft LifeCam Cinema camera connected to a Raspberry Pi 4B board to capture YUV frames, and wish to have PTS timestamps in my application, instead of system clock samples quantized at the URB boundary (~4 ms). Enabling the hwtimestamps parameter puts into service the sophisticated clock conversion code that resides in the uvc_video_clock_update function, but resulting timestamps look somewhat wierd. To say the least, timestamps for successive frames are not monotonic. uname -a Linux raspberrypi 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 045e:075d Microsoft Corp. LifeCam Cinema Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub <Output of lsusb -d 045e:075d -v attached in lsusb.txt> modinfo uvcvideo version: 1.1.1 <full response attached in modinfo.txt> Here is a piece of uvcvideo trace for a few seconds session (full log attached in dmesg.txt) [ 1490.494279] uvcvideo: Frame complete (EOF found). [ 1490.494314] uvcvideo: frame 62 stats: 23/244/267 packets, 1/4/267 pts (early initial), 266/267 scr, last pts/stc/sof 4171438061/623018987/1826 [ 1490.494433] uvcvideo: uvc_v4l2_poll [ 1490.494538] uvcvideo: Microsoft® LifeCam Cinema(TM):: PTS 4171438061 y 302681263.118759 SOF 36015.118759 (x1 2893195733 x2 2894125607 y1 252116992 y2 254148608 SOF offset 0) [ 1490.494552] uvcvideo: Microsoft® LifeCam Cinema(TM):: SOF 33967.118759 y 31188972826 ts 1520632885720 buf ts 1490435939653 (x1 252313600/1802/1799 x2 254148608/1830/1830 y1 1000000000 y2 1028066803) [ 1490.496271] uvcvideo: uvc_v4l2_poll [ 1490.526238] uvcvideo: Frame complete (EOF found). [ 1490.526270] uvcvideo: frame 63 stats: 23/244/267 packets, 1/4/267 pts (early initial), 266/267 scr, last pts/stc/sof 4172438005/624020101/1860 [ 1490.526477] uvcvideo: uvc_v4l2_poll [ 1490.526536] uvcvideo: Microsoft® LifeCam Cinema(TM):: PTS 4172438005 y 302681296.454742 SOF 36048.454742 (x1 2893155659 x2 2894085533 y1 254214144 y2 256245760 SOF offset 0) [ 1490.526550] uvcvideo: Microsoft® LifeCam Cinema(TM):: SOF 34000.454742 y 31118682782 ts 1520594607878 buf ts 1490471949068 (x1 254410752/1834/1831 x2 256245760/1862/1862 y1 1000000000 y2 1028000212) Please note that the ts field of the last trace message for frame 63 holds 1520594607878, that is less than frame 62's ts=1520632885720. usbmon and uvcvideo traces show that the camera uses a 30 MHz clock for PTS/SCR samples, and I haven't noticed any anomalies in these fields of stream headers. In the log fragment above, the difference between PTS values equals 4172438005-4171438061=999944, that is 33.33 ms @30 MHz, matching the capturing rate of 30 FPS. Trace fields related to dev_sof also look reliable, unlike the reconstructed values of SOF and ts. Raspberry Pi 4B has both the USB 2 and 3 ports, the problem holds for both options (the log was recorded for the former). Could you please comment on this? Thank you so much for your great work! P.S. I'm sorry for my fault with cluttering the mailing list with HTML in the previous message. |
|
From: Кыштымов П. <kys...@ya...> - 2021-11-16 20:11:01
|
<div>Hi!</div><div> </div><div>I use a Microsoft LifeCam Cinema camera connected to a Raspberry Pi 4B board to capture YUV frames, and wish to have PTS timestamps in my application, instead of system clock samples quantized at the URB boundary (~4 ms). Enabling the hwtimestamps parameter puts into service the sophisticated clock conversion code that resides in the uvc_video_clock_update function, but resulting timestamps look somewhat wierd. To say the least, timestamps for successive frames are not monotonic.</div><div> </div><div><div>uname -a</div><div><div>Linux raspberrypi 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux</div><div> </div><div>lsusb</div><div><div>Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub</div><div>Bus 001 Device 003: ID 045e:075d Microsoft Corp. LifeCam Cinema</div><div>Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub</div><div>Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub</div><div><Output of lsusb -d 045e:075d -v attached in lsusb.txt></div><div> </div><div>modinfo uvcvideo</div><div><div>version: 1.1.1</div><div><full response attached in modinfo.txt></div></div></div><div> </div></div></div><div>Here is a piece of uvcvideo trace for a few seconds session (full log attached in dmesg.txt)</div><div> </div><div><div>[ 1490.494279] uvcvideo: Frame complete (EOF found).</div><div>[ 1490.494314] uvcvideo: frame 62 stats: 23/244/267 packets, 1/4/267 pts (early initial), 266/267 scr, last pts/stc/sof 4171438061/623018987/1826</div><div>[ 1490.494433] uvcvideo: uvc_v4l2_poll</div><div>[ 1490.494538] uvcvideo: Microsoft® LifeCam Cinema(TM):: PTS 4171438061 y 302681263.118759 SOF 36015.118759 (x1 2893195733 x2 2894125607 y1 252116992 y2 254148608 SOF offset 0)</div><div>[ 1490.494552] uvcvideo: Microsoft® LifeCam Cinema(TM):: SOF 33967.118759 y 31188972826 ts 1520632885720 buf ts 1490435939653 (x1 252313600/1802/1799 x2 254148608/1830/1830 y1 1000000000 y2 1028066803)</div><div>[ 1490.496271] uvcvideo: uvc_v4l2_poll</div><div>[ 1490.526238] uvcvideo: Frame complete (EOF found).</div><div>[ 1490.526270] uvcvideo: frame 63 stats: 23/244/267 packets, 1/4/267 pts (early initial), 266/267 scr, last pts/stc/sof 4172438005/624020101/1860</div><div>[ 1490.526477] uvcvideo: uvc_v4l2_poll</div><div>[ 1490.526536] uvcvideo: Microsoft® LifeCam Cinema(TM):: PTS 4172438005 y 302681296.454742 SOF 36048.454742 (x1 2893155659 x2 2894085533 y1 254214144 y2 256245760 SOF offset 0)</div><div>[ 1490.526550] uvcvideo: Microsoft® LifeCam Cinema(TM):: SOF 34000.454742 y 31118682782 ts 1520594607878 buf ts 1490471949068 (x1 254410752/1834/1831 x2 256245760/1862/1862 y1 1000000000 y2 1028000212)</div><div> </div></div><div>Please note that the ts field of the last trace message for frame 63 holds 1520594607878, that is less than frame 62's ts=1520632885720.</div><div>usbmon and uvcvideo traces show that the camera uses a 30 MHz clock for PTS/SCR samples, and I haven't noticed any anomalies in these fields of stream headers. In the log fragment above, the difference between PTS values equals 4172438005-4171438061=999944, that is 33.33 ms @30 MHz, matching the capturing rate of 30 FPS. Trace fields related to dev_sof also look reliable, unlike the reconstructed values of SOF and ts.</div><div> </div><div>Raspberry Pi 4B has both the USB 2 and 3 ports, the problem holds for both options (the log was recorded for the former).</div><div> </div><div>Could you please comment on this?</div><div> </div><div>Thank you so much for your great work!</div> |
|
From: Michał B. <mic...@gm...> - 2021-11-12 11:10:34
|
For me the guvcview output window shows nothing (essentially whatever was underneath it, the desktop or other window). Changing the option you mention doesn't do anything. Thanks. On Thu, Nov 11, 2021 at 11:24 PM Jack via Linux-uvc-devel <lin...@li...> wrote: > > On 2021.11.11 16:40, Michał Bojanowski wrote: > > Hi! > > > > I have a HP ProBook 6450b laptop running xubuntu 20.04.3 LTS and > > cannot > > get the built-in camera (0bda:5801) to work. When I run `cheese` or > > `guvcview` the LED over the screen lights-up but both programs show a > > blank screen. > > > > I have surfed the internet looking for solution and tried few things > > without success. > > > > I'm writing you to rule-out that the driver is the problem and perhaps > > also to get some help how to further debug this problem. Please see > > below for various diagnostic output. Any help will be greatly > > appreciated! Thank you in advance. > > In guvcview, on the "Video Controls" tab, have you tried all the > options for Camera Output? I haven't had a completely black output, > but I have found that setting can make a huge difference. > > > _______________________________________________ > Linux-uvc-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-uvc-devel |
78 messages has been excluded from this view by a project administrator.
