Re: [linux-uvc-devel] Acer Usb Camera 5986:055a recognized but no /dev/video0 entry

[Laurent P. <lau...@id...>]

Hi Henrik and Samir,

Replying once to both of you, as my two replies would have contained roughly 
the same information.

On Saturday 19 December 2015 23:52:56 Henrik Ingo wrote:
> Hi Laurent
> 
> Thanks for coming back to this. I'm responding to this more general
> discussion, but acknowledge that I also read your response to my patch
> (which obviously is in line with your thoughts here).
> 
> On Wed, Dec 16, 2015 at 10:31 AM, Laurent Pinchart wrote:
> > The issue seems to be that the device USB descriptors are broken. One of
> > the entities claims to be connected to entity number 6, and there's no
> > entity number 6 defined in the descriptors.
> 
> Regarding the reference to this old discussion:
> https://www.mail-archive.com/lin...@vg.../msg87108.html
> 
> I didn't know this issue has surfaced before. Good to know. I assume
> RTL57A7 is also unfixed as we speak then?

That's correct.

> > I can think of two ways to work around this (there could be more though).
> > 
> > The first solution would be to add a way for the uvcvideo driver to
> > override the USB descriptors of known to be faulty devices. The drawback
> > of this method is that it would likely not scale if the number of faulty
> > devices with different USB VID/PID grows.
> 
> Based on my experience creating the patch I just posted, I don't think
> this would be a problem. I think there could be a single quirk, and
> then separately a mapping of idVendor+idProduct to a hard coded chain
> that works for each product. If the quirk is set, a single function
> would lookup the hard coded chain and just apply it.
> 
> The downside of this is that the driver would have to specifically add
> support for each new broken camera, but other than that (ie lines of
> code, architecture) I don't see an issue with scalability.

That was my point. We could certainly look up the patched descriptors based on 
the device VID+PID. As you correctly mention we would then have to update the 
driver for each new broken device. As I expect the descriptors breakage to 
usually be linked to the chipset and not the device, that would not only mean 
adding lots of VID+PID to the driver, but also requiring users to notice the 
issue and report it before we can fix it. A heuristic-based approach would 
(hopefully, if the heuristic is correct) allow supporting future broken 
devices out of the box.

> I could post a new patch using this logic, that would support both my
> Acer camera and the RTL57A7 from the April patch.
> 
> > A second solution would be to add a heuristic to try and create a valid
> > chain from invalid descriptors. For devices that are just mode of a
> > camera input terminal, a processing unit and a USB output terminal, that
> > shouldn't be too difficult.
> 
> As suggested also by Samir, I also think this is a valid approach. It
> would have the benefit that it may also work automatically for future
> products without having to list their idVendor+idProduct anywhere. In
> fact, this kind of fallback could probably happen automatically,
> without using a quirk.

You're reading my mind :-)

> The basic approach of this kind of fallback heuristic should be:
> 
> 1. Whatever units are discovered, we know that they should appear in
> the order: input -> processing -> extension -> output

Devices can be more complex than that, but I believe it's a safe assumption 
for now, at least for the known broken devices.

> 2. In the devices known to be problematic so far, there is a limited
> number of units anyway, and in fact there is only one chain, with only
> one input and output.
> 3. So we can easily just link the known units so they conform to the
> order from #1
> 4. If that isn't sufficient, for example if there are >1 extension
> units, try to use baSourceID to determine their internal order.
> 5. If that fails, just put them in order of entity id and hope for the best.

That looks good to me. We could make it a bit more clever by taking into 
account the links correctly specified in the descriptors, but that's not even 
needed right now, it could be a future enhancement if we find broken devices 
that wouldn't be supported correctly by the above heuristic. 

> Quite obviously, for devices where this heuristic still wouldn't work,
> there remains the option of implementing a device specific quirk as
> described above.

Hopefully that won't be needed :-)

> I can also work on this kind of patch over the Christmas weeks. In
> fact, as it may be more future-proof for future devices, it clearly
> makes sense to attempt this second, more generic heuristic, first.

That would be great.

-- 
Regards,

Laurent Pinchart