Re: [PATCH] media: uvcvideo: Add quirk to retry SET_INTERFACE for SVBONY SV105C
From: Константин Осташов
Date: Mon Oct 19 2026 - 08:01:49 EST
Hi Laurent, Hans,
On Mon, Oct 19, 2026 at 02:27:26PM +0300, Laurent Pinchart wrote:
> On Mon, Oct 19, 2026 at 01:21:49PM +0200, Hans de Goede wrote:
> > On 19-Oct-26 1:17 PM, Laurent Pinchart wrote:
> > > What does Windows do differently then ?
> >
> > I guess Windows always has a short-delay of at least one USB frame-time
> > between the VS_COMMIT and SET_INTERFACE. I think we should simply add
> > a flseep(1000) before the set_interface instead of adding a quirk for
> > this.
>
> The commit message says it doesn't help, but I can't tell if that can be
> trusted.
Fair point. I have measured both sides again.
Windows 11, AMD xHCI, camera on a root port, 120 stream starts with
ffmpeg/DirectShow (MJPEG 1920x1080, and YUYV 1920x1080 for 5 of them),
captured with USBPcap and an ETW trace of USBXHCI/UCX/USBHUB3:
- The requests are the same as on Linux: PROBE GET_CUR, SET_CUR,
GET_CUR, GET_MAX, GET_MIN, SET_CUR, GET_CUR, then a 26 byte COMMIT,
then SET_INTERFACE alt 6. There is nothing else in between.
- The SET_INTERFACE URB is submitted 22 us after the COMMIT completes.
The xHCI driver first runs a Configure Endpoint command (3 ms), then
queues the control transfer. That puts about 3 ms between the two
requests.
- The control transfer completes successfully after 263 ms, every time
(402 ms for YUYV 1920x1080). In a 100 start run, the ETW trace shows
exactly 10 control transfers on the camera's EP0 per start (8 for
probe/commit and 2 for SET_INTERFACE alt 6/alt 0). There was no
Reset Endpoint command, and every xHCI command completed with Success.
Windows does not see an error and does not retry. 0 failures out of
120.
Linux 6.18, Raspberry Pi 4 (VL805 xHCI, camera behind the VL805's
internal USB 2.0 hub). I added an fsleep() right before
usb_set_interface() in uvc_video_start_transfer() and checked the
resulting gap in usbmon. 20 starts per value, MJPEG 1920x1080, auto
exposure:
fsleep() COMMIT -> SET_INTERFACE (usbmon) first SET_INTERFACE -EPROTO
none 0.35 - 0.90 ms 1/20
1 ms 1.53 - 1.84 ms 2/20
5 ms 5.42 - 7.26 ms 6/20
20 ms 20.4 - 26.4 ms 3/20
100 ms 100.7 - 108.1 ms 5/20
300 ms 319.5 - 325.2 ms 1/20
So a delay does not help, even one longer than the time the device
takes to complete the request.
The timing differs between failure and success. A failing
SET_INTERFACE completes with -EPROTO about 1 ms after it is submitted.
A successful one, whether the first attempt or the retry, takes about
260 ms, the same as on Windows. My guess is that the device starts
reconfiguring right after the SETUP stage and sometimes fails to
answer the status stage for a few microframes before it starts
NAKing. The VL805 then reports a transaction error. I have no bus
analyzer to confirm this.
I also need to correct the commit message: the failure rate is not a
stable 80%. Today it was between 0% and 50% per series of 10 to 20
starts, with auto exposure failing more often than manual exposure.
The retry always succeeded on the first attempt.
With 0 out of 120 on Windows against roughly 15% per start on the Pi,
the difference is real. I can't tell yet whether it comes from the OS
or from the host controller. I haven't tested the camera with Linux
on a non-VL805 controller. I can do that before a v2 if it would help.
--
Regards,
Constantine