All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-usb@vger.kernel.org
Subject: [Bug 207045] uvcvideo: Realtek USB Camera (0bda:579f) sends UVC payloads in middle of URB
Date: Wed, 01 Apr 2020 22:34:57 +0000	[thread overview]
Message-ID: <bug-207045-208809-vR6RyG3h1v@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-207045-208809@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=207045

--- Comment #2 from Julian Meyer (jucmeyer@ucsc.edu) ---
I did more research and I found that the problem is that the camera is sending
the next UVC payload immediately after finishing the previous one instead of
waiting for the next URB.

I ran my camera at 640x480@30fps and found the following information:

First, the camera reports the max payload size and max frame size as follows:

Max Payload Size: 119296
Max Frame Size: 614400

Actual Received Payload Size (sum of all payloads): 614472

This number makes sense because it includes (frame size/payload size =) 6
payload headers of 12 bytes each, so 614472 bytes total.

The last URB is truncated because it fits in 37 full 16K URBs + one 8264 byte
URB.

uvc_video_decode_bulk calls the following functions:
1. uvc_video_decode_start - find header length and decode it
2. uvc_video_decode_meta - decode the rest of the header metadata
3. uvc_video_decode_data - decodes data up to the max payload size and if it
overflows, assume the frame is ended
4. uvc_video_decode_end - if this payload was end-of-frame, start the next
frame

uvc_video_decode_bulk is called from uvc_video_complete which is the completion
handler for each URB. This makes it so that each URB must contain one or less
payloads because we only process at most one payload per call to the completion
handler.

In the case of my camera, the driver hits the max payload size and assumes it's
finished (the next payload is in the next URB). Then, it tries to parse the
header for the next URB assuming it's a new payload even though it's actually
in the middle of a payload.

This causes FID mismatches and all sorts of other issues.

Proposed Fix: When we see a URB that's larger than the maximum payload size,
assume it's another payload and start processing the new payload.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

  parent reply	other threads:[~2020-04-01 22:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-31 22:11 [Bug 207045] New: uvcvideo: Realtek USB Camera (0bda:579f) reports wrong dwMaxVideoFrameSize bugzilla-daemon
2020-04-01 15:31 ` [Bug 207045] " bugzilla-daemon
2020-04-01 22:34 ` bugzilla-daemon [this message]
2020-04-02  2:09 ` [Bug 207045] uvcvideo: properly handle UVC payloads that occur in the middle of bulk URBs bugzilla-daemon
2020-10-27 14:49 ` bugzilla-daemon
2020-11-20 14:50 ` bugzilla-daemon
2020-11-20 16:45 ` bugzilla-daemon
2020-11-25 23:00 ` bugzilla-daemon
2021-01-24 22:30 ` bugzilla-daemon
2021-03-02 14:58 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-207045-208809-vR6RyG3h1v@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.