Re: Problematic Alt Setting for ALi Corp. Newmine Camera. (plaintext)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Karel,

On Thu, Oct 19, 2023 at 11:15:40AM +0200, Karel Janda wrote:
> Hi,
> 
> in my class I use ten C-TECH CAM-07HD cameras, detected as
>     ID 0402:8841 ALi Corp. Newmine Camera.
> The camera works OK with resolutions <= 320x240@60fps.
> Bigger MJPEG resolutions were laggy, with lots of errors in kern.log:
>     usb 1-2: USB isochronous frame lost (-75)
>     xhci_hcd 0000:15:00.0: WARN: buffer overrun event for slot 9 ep 4 on endpoint
> Bigger YUY2 resolutions did not get any data. Quirks doesn't help.
> Behavior is the same on (Ubuntu) kernels 6.5.0, 6.2.0, 5.4.0,
> both on 2.0 and 3.0 USB ports.
> 
>   So I start USB scanning and finally find the reason:
> - camera sends four isochronous interface descriptors for wMaxPacketSize 1024 bytes
>    and linux uvcvideo module always chooses bAlternateSetting 4.
> - Windows 10 always chooses bAlternateSetting 1 for the camera
>     and bigger resolutions are working OK there.
> 
> (I attached listing from lspci -v -d 0402:8841 )

Thank you for the report and the detailed analysis, that's great work !

> This original line of code from drivers/media/usb/uvc/uvc_video.c 
>   if (psize >= bandwidth && psize <= best_psize) {
> 
> chooses last alt setting in case the same wMaxPacketSize values.
> 
> If I force using settings 1, 2 or 3 instead in uvc_video.c,
> my REALLY BAD camera starts working OK like a charm, without log errors.

Ouch. A buggy firmware then. That's very common, unfortunately :-(

> So I offer you to change the line above in some future uvc_video.c to:
>     if (psize >= bandwidth && psize < best_psize) { //first preferency
> 
> which I probe completely solved this problem 
> and as Windows does the same will not harm other types of cameras.

Normally I would be fairly worried about making such a change. As I
mentioned, lots of devices are buggy, and picking the first best
alternate setting instead of the last one may well fix the problem for
your device, but break other devices.

In this specific case, however, I have good hopes it would be safe, as
we would implement the same behaviour as Windows 10, and most devices
are tested with Windows (and Windows only, otherwise they would have
caught the firmware bug).

I will submit a patch shortly and CC you.

-- 
Regards,

Laurent Pinchart



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux