On Fri, Jul 26, 2024 at 05:22:17PM +0300, Laurent Pinchart wrote: > I believe the latter can't be solved technically. At the end of the day > it's a matter of trust, and the only option I can see is to build that > trust with the vendors, and to make it clear that breaches of trust will > have consequences. A vendor that deliberately lies would end up on my > personal backlist for as long as they don't implement structural > solutions to be a better player in the ecosystem. FWIW this is largely my thinking with fwctl as well. > As for the first issue, I think it's a difficult one as it is very > difficult to quantify the features covered by open implementations, as > well as their importance. You could have a 99% open command set where > the 1% would impact open implementations extremely negatively, the same > way you could have a 50% open command set where the other 50% isn't of > any use to anyone but the vendor (for instance used to debug the > firmware implementation). I think it is likely cameras, there are lots and lots of use cases and scenarios. If you focus on a specific use case you need everything for that case. Another view would be how many scenarios and users does the open stack cover. > I'm sorry that this discussion is turning into something very > camera-centric, but that's the relevant area I know best. I hope that > discussing problems related to device pass-through in different areas in > the open will help build a wider shared understanding of the problems, > and hopefully help designing solutions by better taking into account the > various aspects of the issues. To be clear I wouldn't imagine fwctl as relating much to cameras, maybe you'd use fwctl to get diagnostics out of the camera fw or something, but it shouldn't touch the image path topics here. Jason
