https://bugzilla.kernel.org/show_bug.cgi?id=207045 Bug ID: 207045 Summary: uvcvideo: Realtek USB Camera (0bda:579f) reports wrong dwMaxVideoFrameSize Product: Drivers Version: 2.5 Kernel Version: v5.5 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: USB Assignee: drivers_usb@xxxxxxxxxxxxxxxxxxxxxx Reporter: jucmeyer@xxxxxxxx Regression: No The integrated webcam on the Razer Blade (2017) does not work. I found this thread from 2014 having issues with the same webcam, but it's unresolved: https://www.spinics.net/lists/linux-media/msg73476.html At first, I turned on the trace parameter for the uvcvideo module and found the following logs as mentioned in the above thread first: [ 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). After more investigation, I found this line at the end of uvc_video_decode_bulk that was causing the problem: if (buf->bytesused == stream->queue.buf_used || stream->bulk.payload_size == stream->bulk.max_payload_size) { // assume end of frame } I also ran a USBMon on the webcam and decoded it using the python script in the thread linked above. This yielded the following setup URB: bmHint 0x01 bFormatIndex 1 bFrameIndex 1 dwFrameInterval 333333 wKeyFrameRate 0 wPFrameRate 0 wCompQuality 0 wCompWindowSize 0 wDelay 32 dwMaxVideoFrameSize 614400 dwMaxPayloadTransferSize 119296 I also calculated the size of a video frame by adding up the lengths of each URB sent. So, after this, it sends the UVC header, which looks correct: 0c8d6018 3bbcfa9b .`.;¼ú› 3cbc3304 727a7082 <¼3.rzp‚ 717c717d 6f7e7089 q|q}o~p‰ 6e816f89 6e826e88 no‰n‚nˆ In total sends 37 16384 byte URBs and one 8264 byte URB or 614472 bytes total (greater than the 614400 specified in the URB by 72 bytes). I tried removing the second condition from the if statement above and making it consider the end of frame based on finding a URB with size less than dwMaxVideoFrameSize and that seemed to change the problem at least. Now, it was overflowing the V4L plane size which was set to 614400. It seems this is specified somewhere in uvc_queue_setup: struct uvc_video_queue *queue = vb2_get_drv_priv(vq); struct uvc_streaming *stream; unsigned int size; switch (vq->type) { case V4L2_BUF_TYPE_META_CAPTURE: size = UVC_METADATA_BUF_SIZE; break; default: stream = uvc_queue_to_stream(queue); size = stream->ctrl.dwMaxVideoFrameSize; // + 72 break; } I'm not really sure where to go from here. It's not always 72 bytes over either. I've found that if I switch the resolution/format, it can be a different number. -- You are receiving this mail because: You are watching the assignee of the bug.
