On Fri, Nov 12, 2021 at 5:11 PM Ricardo Ribalda <ribalda@xxxxxxxxxxxx> wrote: > > HI > > On Sat, 13 Nov 2021 at 01:07, James Hilliard <james.hilliard1@xxxxxxxxx> wrote: > > > > On Fri, Nov 12, 2021 at 5:02 PM Ricardo Ribalda <ribalda@xxxxxxxxxxxx> wrote: > > > > > > Hi > > > > > > On Sat, 13 Nov 2021 at 00:59, James Hilliard <james.hilliard1@xxxxxxxxx> wrote: > > > > > > > > On Fri, Nov 12, 2021 at 4:50 PM Ricardo Ribalda <ribalda@xxxxxxxxxxxx> wrote: > > > > > > > > > > HI James > > > > > > > > > > You are getting -EPROTO while trying to get the current value of a > > > > > control. I believe this is a hardware/firmware error. > > > > > > > > Hmm, any idea why v4l2-compliance passes some of the time but not > > > > always? > > > > > > Race condition in the firmware? > > > Not enough current to complete a request and end up in some kind of brown-out? > > > > Hmm, think that might be the way the camera might be indicating commands > > are being sent too fast? Maybe a retry on the first -EPROTO seen would be > > enough to fix it? > > > > I do not think that it is part of the uvc standard :). The vendors seem to think the windows uvc driver is the standard I think. :) > > What is the model/vendor of the camera? No idea, something someone found in china from a random vendor. > > You might have to implement a quirk for it. Hmm, looking at a pcap the windows uvc driver looks like it might be sending a bunch of GET_CUR multiple times for the same request, maybe it makes sense to try and emulate the behavior there. > > > > > > > It is difficult to know without access to the hardware :) > > > > > > Maybe you can replicate what causes the error with just v4l-ctl calls > > > and then ping the manufacturer with a simple repro. > > > > > > > > > > > > > > > > > > > > > > Best regards! > > > > > > > > > > > > -- > > > Ricardo Ribalda > > > > -- > Ricardo Ribalda
