[Henrik Ingo <henrik.ingo@av...>]

On Wed, Apr 27, 2016 at 5:09 PM, Laurent Pinchart
<laurent.pinchart@...> wrote:
> Believe me or not, I'm really ashamed for not taking more time to respond to
> your e-mails. Please rest assure that your efforts are appreciated, and please
> feel free to ping me as firmly as needed.

Thanks :-) Actually, I wasn't held back by waiting for your reply,
this time it was myself who was slow to context switch back to work on
this patch. Finally I've been able to do it over this weekend. The
patch was sent to this mailing list a minute ago.

The new patch is 100% according to your suggestions, with one twist:
For iterating over the XUs and PUs, I used list_for_each_prev()
instead of list_for_each_entry(). The reason is that iterating
backwards happens to produce the "most correct" chain for the
particular Acer camera I have on my laptop (and that many other people
seem to own as well). By this I mean that the baSourceIDs that do
point to another valid unit, remain unchanged and we only patch the
invalid reference from pointing to 6 to pointing to 4.

This was perhaps vanity on my part, since in general we don't do any
effort to preserve baSourceIDs once we're in the fallback heuristic.
So strictly speaking the order of XU and PU units should be considered
random, which just "accidentally on purpose" happens to be the correct
order for this device. But I figured it wouldn't hurt to do it for the
one device we're actually working with here, since I could do it
easily, without harming generality of the patch. I hope you don't mind
the additional line of code, since I now had to call list_entry()
separately.

The dmesg output is attached. The "most correct" order of units we
ended up producing is: OT 3 <- XU 4 <- PU 2 <- IT 1

henrik
-- 
henrik.ingo@...
+358-40-5697354        skype: henrik.ingo            irc: hingo
 http://www.openlife.cc

My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7