Re: Dell XPS 12 USB camera bulk mode issues
Hi Mark,
On Friday 28 February 2014 10:34:24 Mark Ryan wrote:
On 02/26/2014 04:40 PM, Laurent Pinchart wrote:
[ ... ]
With the information I've given you, could you try to log more information
in the driver to try and find what goes wrong ? You could for instance
log the content of each header at the beginning of the
uvc_video_decode_start() function.
So maybe I have something here. I ran guvcview and set the format to
MJPEG running at a high resolution. I'm using the kernel 3.11.0-17 that
comes with Ubuntu 13.10. In the usbmon logs I see the following.
[...]
SETUP Host-to-device Class request to Interface
bRequest: SET CUR (01)
wValue: 0200
wIndex: INTF 1 ENTITY 0 (0001)
wLength: 001a
26 data bytes
bmHint 0x01
bFormatIndex 2
bFrameIndex 10
dwFrameInterval 33
wKeyFrameRate 0
wPFrameRate 0
wCompQuality 0
wCompWindowSize 0
wDelay 32
dwMaxVideoFrameSize 1843200
dwMaxPayloadTransferSize 34816
Note the dwMaxPayloadTransferSize of 34816
[...]
Now I have my first payload
16384 data bytes
0c8d863e 8c007d67.†Œ.}g
8e00b304 ffd8ffdbŽ.³.ÿØÿÛ
00430003 02020202.C..
02030202 02030303
16384 data bytes
fbf5aeff 00c25e12ûõ®ÿ.Â^.
5d1244d5 353b2437].DÕ5;$7
f92d06e6 24c28475ù-.æ$„u
c740c6b3 8bbb29adÇ@Ƴ‹»)
16384 data bytes
f1a3cc60 b8200c52ñ£Ì`¸ .R
0108eac3 1cd4610e..êÃ.Ôa.
ece45032 40c477a8ìäP2@Äw¨
e4f35b81 d05001fcäó[ÐP.ü
16384 data bytes
fb3528d1 bc4fcc56û5(ѼOÌV
fe2d9522 1d04b1e7þ-•..±ç
3fa1a9e5 2b9867f6?¡©å+˜gö
778e2dd0 7d9b57b5wŽ-Ð}›Wµ
16384 data bytes
c016baf6 99732c9aÀ.ºö™s,š
9db39b7b e6b995a4³›{湕¤
65751f78 649eb5edeu.xdžµí
9e2dfdb1 355fd9faž-ý±5_Ùú
16384 data bytes
a73d4053 8fad795c§=@Sy\
c9088170 ec1c1e54É.pì..T
9ce6a59a d89f5742œæ¥šØŸWB
82cf3297 26d95b18‚Ï2—Ù[.
16384 data bytes
b4d3b21b d4a53595´Ó².Ô¥5•
99cac904 2e1bb346™ÊÉ...³F
09fe555e 4d2b4b95.þU^M+K•
be6b488a 0e91b0ca¾kHŠ.‘°Ê
16384 data bytes
3adb9dbc 6323ad21:Û¼c#!
8aa85b9d b934d31eŠ¨[¹4Ó.
465885f6 a00ad25cFX…ö .Ò\
04fdd44b be43d08a.ýÔK¾CЊ
16384 data bytes
14f1cf4c 0ae43589.ñÏL.ä5‰
0acdbd0b c8afedc2.ͽ.ȯíÂ
f15d4339 8bfb5b2bñ]C9‹û[+
df39e42d 14ecb849ß9ä-.ì¸I
10466 data bytes
7fffd1fc af99e466ÿÑü¯™äf
c39cd475 cab500a2ÃœÔuʵ.¢
ad8ae147 d295ec0cŠáGÒ•ì.
bd639196 3cfa0ad5½c‘–ú.Õ
14 data bytes
0c8f863e 8c000fd7.†Œ..×
9300cb04 ffd9“.Ë.ÿÙ
The problem seems to be that the payload sent by the camera is much larger
than dwMaxPayloadTransferSize. For this reason the driver assumes that it
has found the end of the frame after processing the third URB. This test is
performed at the bottom of uvc_video_decode_bulk. It then expects URB 4 to
be the start of a new frame, which it isn't, and so it gets out of sync. If
I understand correctly, dwMaxPayloadTransferSize is set by the camera, so
perhaps the camera is at fault here.
Yes, I believe the camera violates the spec.
Interestingly, I checked some wireshark logs I took while using the camera
with the Dell XPS12 booted into Windows and I see the exact same thing. The
dwMaxPayloadTransferSize is set to 34816, but the payloads were much larger,
around 140kb.
What bulk URB size did Windows use ?
As the camera works fine on Windows, I'm guessing Windows is not relying on
the dwMaxPayloadTransferSize to detect the end of a payload. Perhaps it just
uses the FID. Does this sound plausible? If so, I might see if I can
replicate this behaviour locally, to see if it solves the issue.
I don't think it uses the FID, as that requires the presence of a header,
which is only present at the beginning of payloads, and thus require the
driver to be able to detect the payload in the first place.
With the three USB traces I've received so far for your camera it seems that
we could detect the end of a payload by a short URBs. Maybe that's what
Windows does. This would however probably break if the MJPEG data size +
header size happens to be a multiple of 16kB.
Have you looked at the YUYV capture traces ? What's the data pattern there ? I
would expect the last 14 bytes transfer not to be present for YUYV. Does the
camera use a single payload in that case as well ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dell XPS 12 USB camera bulk mode issues
Hi Laurent,
Thanks again for your reply.
On 03/04/2014 12:11 PM, Laurent Pinchart wrote:
Hi Mark,
On Friday 28 February 2014 10:34:24 Mark Ryan wrote:
On 02/26/2014 04:40 PM, Laurent Pinchart wrote:
[ ... ]
With the information I've given you, could you try to log more information
in the driver to try and find what goes wrong ? You could for instance
log the content of each header at the beginning of the
uvc_video_decode_start() function.
So maybe I have something here. I ran guvcview and set the format to
MJPEG running at a high resolution. I'm using the kernel 3.11.0-17 that
comes with Ubuntu 13.10. In the usbmon logs I see the following.
[...]
SETUP Host-to-device Class request to Interface
bRequest: SET CUR (01)
wValue: 0200
wIndex: INTF 1 ENTITY 0 (0001)
wLength: 001a
26 data bytes
bmHint 0x01
bFormatIndex 2
bFrameIndex 10
dwFrameInterval 33
wKeyFrameRate 0
wPFrameRate 0
wCompQuality 0
wCompWindowSize 0
wDelay 32
dwMaxVideoFrameSize 1843200
dwMaxPayloadTransferSize 34816
Note the dwMaxPayloadTransferSize of 34816
[...]
Now I have my first payload
16384 data bytes
0c8d863e 8c007d67.†Œ.}g
8e00b304 ffd8ffdbŽ.³.ÿØÿÛ
00430003 02020202.C..
02030202 02030303
16384 data bytes
fbf5aeff 00c25e12ûõ®ÿ.Â^.
5d1244d5 353b2437].DÕ5;$7
f92d06e6 24c28475ù-.æ$„u
c740c6b3 8bbb29adÇ@Ƴ‹»)
16384 data bytes
f1a3cc60 b8200c52ñ£Ì`¸ .R
0108eac3 1cd4610e..êÃ.Ôa.
ece45032 40c477a8ìäP2@Äw¨
e4f35b81 d05001fcäó[ÐP.ü
16384 data bytes
fb3528d1 bc4fcc56û5(ѼOÌV
fe2d9522 1d04b1e7þ-•..±ç
3fa1a9e5 2b9867f6?¡©å+˜gö
778e2dd0 7d9b57b5wŽ-Ð}›Wµ
16384 data bytes
c016baf6 99732c9aÀ.ºö™s,š
9db39b7b e6b995a4³›{湕¤
65751f78 649eb5edeu.xdžµí
9e2dfdb1 355fd9faž-ý±5_Ùú
16384 data bytes
a73d4053 8fad795c§=@Sy\
c9088170 ec1c1e54É.pì..T
9ce6a59a d89f5742œæ¥šØŸWB
82cf3297 26d95b18‚Ï2—Ù[.
16384 data bytes
b4d3b21b d4a53595´Ó².Ô¥5•
99cac904 2e1bb346™ÊÉ...³F
09fe555e 4d2b4b95.þU^M+K•
be6b488a 0e91b0ca¾kHŠ.‘°Ê
16384 data bytes
3adb9dbc 6323ad21:Û¼c#!
8aa85b9d b934d31eŠ¨[¹4Ó.
465885f6 a00ad25cFX…ö .Ò\
04fdd44b be43d08a.ýÔK¾CЊ
16384 data bytes
14f1cf4c 0ae43589.ñÏL.ä5‰
0acdbd0b c8afedc2.ͽ.ȯíÂ
f15d4339 8bfb5b2bñ]C9‹û[+
df39e42d 14ecb849ß9ä-.ì¸I
10466 data bytes
7fffd1fc af99e466ÿÑü¯™äf
c39cd475 cab500a2ÃœÔuʵ.¢
ad8ae147 d295ec0cŠáGÒ•ì.
bd639196 3cfa0ad5½c‘–ú.Õ
14 data bytes
0c8f863e 8c000fd7.†Œ..×
9300cb04 ffd9“.Ë.ÿÙ
The problem seems to be that the payload sent by the camera is much larger
than dwMaxPayloadTransferSize. For this reason the driver assumes that it
has found the end of the frame after processing the third URB. This test is
performed at the bottom of uvc_video_decode_bulk. It then expects URB 4 to
be the start of a new frame, which it isn't, and so it gets out of sync. If
I understand correctly, dwMaxPayloadTransferSize is set by the camera, so
perhaps the camera is at fault here.
Yes, I believe the camera violates the spec.
Interestingly, I checked some wireshark logs I took while using the camera
with the Dell XPS12 booted into Windows and I see the exact same thing. The
dwMaxPayloadTransferSize is set to 34816, but the payloads were much larger,
around 140kb.
What bulk URB size did Windows use ?
As the camera works fine on Windows, I'm guessing Windows is not relying on
the dwMaxPayloadTransferSize to detect the end of a payload. Perhaps it just
uses the FID. Does this sound plausible? If so, I might see if I can
replicate this behaviour locally, to see if it solves the issue.
I don't think it uses the FID, as that requires the presence of a header,
which is only present at the beginning of payloads, and thus require the
driver to be able to detect the payload in the first place.
With the three USB traces I've received so far for your camera it seems that
we could detect the end of a payload by a short URBs. Maybe that's what
Windows does. This would however probably break if the MJPEG data size +
header size happens to be a multiple of 16kB.
Have you looked at the YUYV capture traces ? What's the data pattern there ? I
would expect the last 14 bytes transfer not to be present for YUYV. Does the
camera use a single payload in that case as well ?
I have, and the behaviour seems to differ depending on the frameIndex.
I haven't tested all of the resolutions yet, but here are the two main
patterns I see for YVUV.
- For some resolutions, each frame is split up into multiple payloads,
each of which are equal in size to the dwMaxPayloadTransferSize, apart
perhaps from the last. Each payload consists of a single URB ( I hope
this is the correct terminology ) and has a header. The total
Re: Dell XPS 12 USB camera bulk mode issues
Hi Laurent,
On 02/26/2014 04:40 PM, Laurent Pinchart wrote:
Hi Mark,
[ ... ]
With the information I've given you, could you try to log more information in
the driver to try and find what goes wrong ? You could for instance log the
content of each header at the beginning of the uvc_video_decode_start()
function.
So maybe I have something here. I ran guvcview and set the format to
MJPEG running at a high resolution. I'm using the kernel 3.11.0-17 that
comes with Ubuntu 13.10. In the usbmon logs I see the following.
[...]
SETUP Host-to-device Class request to Interface
bRequest: SET CUR (01)
wValue: 0200
wIndex: INTF 1 ENTITY 0 (0001)
wLength: 001a
26 data bytes
bmHint 0x01
bFormatIndex 2
bFrameIndex 10
dwFrameInterval 33
wKeyFrameRate 0
wPFrameRate 0
wCompQuality 0
wCompWindowSize 0
wDelay 32
dwMaxVideoFrameSize 1843200
dwMaxPayloadTransferSize 34816
Note the dwMaxPayloadTransferSize of 34816
[...]
Now I have my first payload
16384 data bytes
0c8d863e 8c007d67.†Œ.}g
8e00b304 ffd8ffdbŽ.³.ÿØÿÛ
00430003 02020202.C..
02030202 02030303
16384 data bytes
fbf5aeff 00c25e12ûõ®ÿ.Â^.
5d1244d5 353b2437].DÕ5;$7
f92d06e6 24c28475ù-.æ$„u
c740c6b3 8bbb29adÇ@Ƴ‹»)
16384 data bytes
f1a3cc60 b8200c52ñ£Ì`¸ .R
0108eac3 1cd4610e..êÃ.Ôa.
ece45032 40c477a8ìäP2@Äw¨
e4f35b81 d05001fcäó[ÐP.ü
16384 data bytes
fb3528d1 bc4fcc56û5(ѼOÌV
fe2d9522 1d04b1e7þ-•..±ç
3fa1a9e5 2b9867f6?¡©å+˜gö
778e2dd0 7d9b57b5wŽ-Ð}›Wµ
16384 data bytes
c016baf6 99732c9aÀ.ºö™s,š
9db39b7b e6b995a4³›{湕¤
65751f78 649eb5edeu.xdžµí
9e2dfdb1 355fd9faž-ý±5_Ùú
16384 data bytes
a73d4053 8fad795c§=@Sy\
c9088170 ec1c1e54É.pì..T
9ce6a59a d89f5742œæ¥šØŸWB
82cf3297 26d95b18‚Ï2—Ù[.
16384 data bytes
b4d3b21b d4a53595´Ó².Ô¥5•
99cac904 2e1bb346™ÊÉ...³F
09fe555e 4d2b4b95.þU^M+K•
be6b488a 0e91b0ca¾kHŠ.‘°Ê
16384 data bytes
3adb9dbc 6323ad21:Û¼c#!
8aa85b9d b934d31eŠ¨[¹4Ó.
465885f6 a00ad25cFX…ö .Ò\
04fdd44b be43d08a.ýÔK¾CЊ
16384 data bytes
14f1cf4c 0ae43589.ñÏL.ä5‰
0acdbd0b c8afedc2.ͽ.ȯíÂ
f15d4339 8bfb5b2bñ]C9‹û[+
df39e42d 14ecb849ß9ä-.ì¸I
10466 data bytes
7fffd1fc af99e466ÿÑü¯™äf
c39cd475 cab500a2ÃœÔuʵ.¢
ad8ae147 d295ec0cŠáGÒ•ì.
bd639196 3cfa0ad5½c‘–ú.Õ
14 data bytes
0c8f863e 8c000fd7.†Œ..×
9300cb04 ffd9“.Ë.ÿÙ
The problem seems to be that the payload sent by the camera is much
larger than dwMaxPayloadTransferSize. For this reason the driver
assumes that it has found the end of the frame after processing the
third URB. This test is performed at the bottom of
uvc_video_decode_bulk. It then expects URB 4 to be the start of a new
frame, which it isn't, and so it gets out of sync. If I understand
correctly, dwMaxPayloadTransferSize is set by the camera, so perhaps the
camera is at fault here.
Interestingly, I checked some wireshark logs I took while using the
camera with the Dell XPS12 booted into Windows and I see the exact same
thing. The dwMaxPayloadTransferSize is set to 34816, but the payloads
were much larger, around 140kb. As the camera works fine on Windows,
I'm guessing Windows is not relying on the dwMaxPayloadTransferSize to
detect the end of a payload. Perhaps it just uses the FID. Does this
sound plausible? If so, I might see if I can replicate this behaviour
locally, to see if it solves the issue.
[ 80.490256] uvcvideo: Frame complete (FID bit toggled).
[ 80.490262] uvcvideo: frame 2080 stats: 0/0/1 packets, 0/0/0 pts (!early
!initial), 0/1 scr, last pts/stc/sof 0/2069725020/32605 [ 80.490264]
uvcvideo: Marking buffer as bad (error bit set).
[ 80.490606] uvcvideo: Frame complete (EOF found).
[ 80.490942] uvcvideo: Marking buffer as bad (error bit set).
[ 80.490947] uvcvideo: Dropping payload (out of sync).
[ 80.492920] uvcvideo: Marking buffer as bad (error bit set).
[ 80.492927] uvcvideo: Dropping payload (out of sync).
[ 80.495352] uvcvideo: frame 2081 stats: 0/0/3 packets, 0/0/1 pts (!early
!initial), 2/3 scr, last pts/stc/sof 2103017049/2069659484/32604 [
80.495360] uvcvideo: Marking buffer as bad (error bit set).
[ 80.496066] uvcvideo: Marking buffer as bad (error bit set).
[ 80.498021] uvcvideo: frame 2082 stats: 0/0/2 packets, 1/1/2 pts (!early
initial), 1/2 scr, last pts/stc/sof 2103148379/2103148379/32601 [
80.498030] uvcvideo: Marking buffer as bad (error bit set).
[ 80.498033] uvcvideo: Frame complete (FID bit toggled).
[ 80.498039] uvcvideo: frame 2083 stats: 0/0/1 packets, 0/0/1 pts (!early
initial), 0/1 scr, last pts/stc/sof 2103213661/2103213661/32349 [
80.498042] uvcvideo: Marking buffer as bad (error bit set).
[ 80.500420] uvcvideo: Marking buffer
Re: Dell XPS 12 USB camera bulk mode issues
Hi Sarah, On Tuesday 25 February 2014 13:49:56 Sarah Sharp wrote: Hi Laurent and Mauro, Mark has running into issues with the Realtek integrated webcam on a Dell XPS 12 system that uses bulk endpoints. The webcam shows visible glitches with certain resolutions (stripes of frame missing, distorted images, purple and green colors, blank image, or missing the bottom half of the image). How frequent are those issues, do they occur every frame (or nearly every frame), or are they transient ? The webcam works fine in Windows. The webcam works fine in Linux if we upgrade the firmware to make the camera use isochronous endpoints rather than bulk endpoints. This makes us suspect an issue with bulk mode. How is the Linux support for bulk mode cameras? If it's supposed to work, could we be dealing with a camera that doesn't conform to the bulk mode USB video class spec? It's supposed to work, I'm running a test with a bulk device right now using the latest linuxtv/master branch (or, to be accurate, the V4L subsystem from that branch compiled for a 3.10 kernel). We might be dealing with a device that doesn't conform to the spec, with a bug in the uvcvideo driver that happened to remain unnoticed until now, or just with a gray area in the spec that has been understood differently by the device manufacturer, Microsoft and me. Details: I tested using Ubuntu with a 3.14-rc4 kernel with guvcview. Resolutions that work: YUYV, resolutions: 640x480 160x120 352x288 848x480 960x540 MJPG, resolutions: 160x120 320x240 352x288 Resolutions that fail: YUYV, resolutions: 320x180 320x240 424x240 640x360 MJPG, resolutions: 640x480 320x180 424x240 640x360 848x480 960x540 RGB3, any resolution. (In fact, this seems to hang guvcview with messages like VIDIOC_DQBUF - Unable to dequeue buffer) Didn't thoroughly test BGR3, YU12, YV12. Those capture modes also sometimes hang guvcview. Attached is the lsusb output for the device, along with two usbmon captures. One shows the device working as MJPG at a 320x240 resolution, and the other shows the device failing as MJPG at a 320x180 resolution. I'm looking at that, I'll reply to Mark's e-mail. Please let me know if anything jumps out at you. For further debugging, please work with Mark. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dell XPS 12 USB camera bulk mode issues
Hi Mark, On Wednesday 26 February 2014 10:20:06 Ryan, Mark D wrote: On Tuesday, February 25, 2014 10:50 PM Sarah Sharp wrote: Hi Laurent and Mauro, Mark has running into issues with the Realtek integrated webcam on a Dell XPS 12 system that uses bulk endpoints. The webcam shows visible glitches with certain resolutions (stripes of frame missing, distorted images, purple and green colors, blank image, or missing the bottom half of the image). [Ryan, Mark D] Sarah, thanks for the introduction. I can provide a little bit more information. 1. I've tried all the UVC driver quirks but none of these seem to help. That was a good idea, but there's no quirk for this kind of issue I'm afraid. 2. I've also run some tests with the UVC traces enabled. There are quite a lot of errors. I include a portion of the logs below. They were generated on Ubuntu 13.10 (linux 3.11.0-12) running guvcview recording YVUV 1280x720 at 10fps. You can set the trace parameter to 0x7bf in future tests to remove messages regarding the V4L2 API calls and timestamp statistics, it will make the log slightly more readable. Sarah has sent me two usbmon traces, one in a working case and the other in a non-working case. They unfortunately look both correct to me, so I'll likely need your help to debug this. Let's start with a bit of background information. I'll skip the UVC control protocol as that's not relevant to this discussion, except to mention that UVC uses control messages to negotiate the video format with the device, and receives the maximum payload transfer size (more about this below) from the device. Here's URB 61 in the non-working trace that commits the streaming parameters to the device (the maximum payload transfer size has been retrieved from the device previously and is committed without being modified by the driver). URB TimestampEvent Address Type Direction Endpoint 612558.416852 Submission 4 Control OUT0 SETUP Host-to-device Class request to Interface bRequest: SET CUR (01) wValue: 0200 wIndex: INTF 1 ENTITY 0 (0001) wLength: 001a 26 data bytes bmHint 0x01 bFormatIndex 2 bFrameIndex 3 dwFrameInterval 33 wKeyFrameRate 0 wPFrameRate 0 wCompQuality 0 wCompWindowSize 0 wDelay 32 dwMaxVideoFrameSize 115200 dwMaxPayloadTransferSize 43008 You can find the script I use to decode the usbmon trace at http://www.ideasonboard.org/uvc/usbmon.py. Run it with the -C uvc option to decode the UVC protocol. You can also use the -a option to filter the URBs based on the device address. The equivalent URB in the working case is URB 101, and contains the following payload. SETUP Host-to-device Class request to Interface bRequest: SET CUR (01) wValue: 0200 wIndex: INTF 1 ENTITY 0 (0001) wLength: 001a 26 data bytes bmHint 0x01 bFormatIndex 2 bFrameIndex 4 dwFrameInterval 33 wKeyFrameRate 0 wPFrameRate 0 wCompQuality 0 wCompWindowSize 0 wDelay 32 dwMaxVideoFrameSize 153600 dwMaxPayloadTransferSize 43008 The only differences are the bFrameIndex (used to select the resolution) and the dwMaxVideoFrameSize (the maximum size of the compressed frame, computed by the device as a worst case estimate using the size of the frame after decompression) values. The maximum payload transfer size is identical in the two cases. Nothing unexpected so far. After those URBs the uvcvideo driver starts submitting bulk URBs and get frame data back from the device. The device returns the following data in the first URB for the non-working and working cases respectively. 16262 data bytes 58595a63 64656667XYZcdefg 68696a73 74757677hijstuvw 78797a82 83848586xyz‚ƒ„…† 8788898a 92939495‡ˆ‰Š’“”• 16262 data bytes 58595a63 64656667XYZcdefg 68696a73 74757677hijstuvw 78797a82 83848586xyz‚ƒ„…† 8788898a 92939495‡ˆ‰Š’“”• The first few data bytes stored in the usbmon capture look like MJPEG Huffman table data. This is a violation of the UVC specification, the camera is supposed to start sending frames immediately. Furthermore, every payload must start with a UVC header, which is clearly not the case here. We're getting to the concept of payloads. UVC cuts frames in payloads that are then transmitted over isochronous or bulk endpoints. Payloads have a variable size with a fixed maximum size, and each payload starts with a UVC payload header. When using isochronous transfers each isochronous URB contains a single payload. When using bulk transfers payloads can be split across multiple bulk URBs. Each isochronous URB thus
Re: Dell XPS 12 USB camera bulk mode issues
Hi Laurent, Thank you so much for your detailed response. On 02/26/2014 04:40 PM, Laurent Pinchart wrote: Hi Mark, On Wednesday 26 February 2014 10:20:06 Ryan, Mark D wrote: On Tuesday, February 25, 2014 10:50 PM Sarah Sharp wrote: Hi Laurent and Mauro, Mark has running into issues with the Realtek integrated webcam on a Dell XPS 12 system that uses bulk endpoints. The webcam shows visible glitches with certain resolutions (stripes of frame missing, distorted images, purple and green colors, blank image, or missing the bottom half of the image). [Ryan, Mark D] Sarah, thanks for the introduction. I can provide a little bit more information. 1. I've tried all the UVC driver quirks but none of these seem to help. That was a good idea, but there's no quirk for this kind of issue I'm afraid. 2. I've also run some tests with the UVC traces enabled. There are quite a lot of errors. I include a portion of the logs below. They were generated on Ubuntu 13.10 (linux 3.11.0-12) running guvcview recording YVUV 1280x720 at 10fps. You can set the trace parameter to 0x7bf in future tests to remove messages regarding the V4L2 API calls and timestamp statistics, it will make the log slightly more readable. Sarah has sent me two usbmon traces, one in a working case and the other in a non-working case. They unfortunately look both correct to me, so I'll likely need your help to debug this. Let's start with a bit of background information. I'll skip the UVC control protocol as that's not relevant to this discussion, except to mention that UVC uses control messages to negotiate the video format with the device, and receives the maximum payload transfer size (more about this below) from the device. Here's URB 61 in the non-working trace that commits the streaming parameters to the device (the maximum payload transfer size has been retrieved from the device previously and is committed without being modified by the driver). URB TimestampEvent Address Type Direction Endpoint 612558.416852 Submission 4 Control OUT0 SETUP Host-to-device Class request to Interface bRequest: SET CUR (01) wValue: 0200 wIndex: INTF 1 ENTITY 0 (0001) wLength: 001a 26 data bytes bmHint 0x01 bFormatIndex 2 bFrameIndex 3 dwFrameInterval 33 wKeyFrameRate 0 wPFrameRate 0 wCompQuality 0 wCompWindowSize 0 wDelay 32 dwMaxVideoFrameSize 115200 dwMaxPayloadTransferSize 43008 You can find the script I use to decode the usbmon trace at http://www.ideasonboard.org/uvc/usbmon.py. Run it with the -C uvc option to decode the UVC protocol. You can also use the -a option to filter the URBs based on the device address. The equivalent URB in the working case is URB 101, and contains the following payload. SETUP Host-to-device Class request to Interface bRequest: SET CUR (01) wValue: 0200 wIndex: INTF 1 ENTITY 0 (0001) wLength: 001a 26 data bytes bmHint 0x01 bFormatIndex 2 bFrameIndex 4 dwFrameInterval 33 wKeyFrameRate 0 wPFrameRate 0 wCompQuality 0 wCompWindowSize 0 wDelay 32 dwMaxVideoFrameSize 153600 dwMaxPayloadTransferSize 43008 The only differences are the bFrameIndex (used to select the resolution) and the dwMaxVideoFrameSize (the maximum size of the compressed frame, computed by the device as a worst case estimate using the size of the frame after decompression) values. The maximum payload transfer size is identical in the two cases. Nothing unexpected so far. After those URBs the uvcvideo driver starts submitting bulk URBs and get frame data back from the device. The device returns the following data in the first URB for the non-working and working cases respectively. 16262 data bytes 58595a63 64656667XYZcdefg 68696a73 74757677hijstuvw 78797a82 83848586xyz‚ƒ„…† 8788898a 92939495‡ˆ‰Š’“”• 16262 data bytes 58595a63 64656667XYZcdefg 68696a73 74757677hijstuvw 78797a82 83848586xyz‚ƒ„…† 8788898a 92939495‡ˆ‰Š’“”• The first few data bytes stored in the usbmon capture look like MJPEG Huffman table data. This is a violation of the UVC specification, the camera is supposed to start sending frames immediately. Furthermore, every payload must start with a UVC header, which is clearly not the case here. We're getting to the concept of payloads. UVC cuts frames in payloads that are then transmitted over isochronous or bulk endpoints. Payloads have a variable size with a fixed maximum size, and each payload starts with a UVC payload header. When using isochronous transfers each isochronous URB contains a single payload. When using bulk transfers payloads can be
