Hi Ricardo, On Wed, Sep 07, 2022 at 09:55:12AM +0200, Ricardo Ribalda wrote: > Hi > > On ChromeOS we have opted to have a camera stack based on the upstream kernel. > > The camera ecosystem has become extremely heterogeneous thanks to the > proliferation of complex cameras. Meaning that, if ChromeOS wants to > keep with our upstream commitments, we have to look into how to get > more involvement from vendors and standardise our stack. > > Kcam is an initiative to support complex cameras in a way that can be > scalable, is acceptable by the vendors and respect the users rights. > > Slides at: https://drive.google.com/file/d/1Tew21xeKmFlQ7dQxMcIYqybVuQL7La1a/view Thank you. A few questions and comments for clarification: - Slide 4 mentions proprietary drivers and UIO drivers. Do you mean UIO as in the upstream UIO API, or as in UIO-like drivers with a vendor API ? - Slide 5 mentions "Code developed exclusively by vendor" for Android. There's the CameraX initiative (and possibly other I'm not aware of) that mixes the high-level HAL implementation from Google with low-level vendor code, to simplify (in theory at least) the life of vendors. Generally speaking you're right though, the vendor is in charge of providing the HAL, regardless of how it's structured internally. - Slide 8 is focussed on notebooks (Chrome OS, but I suppose also regular Linux machines) vs. Android when it comes to leveraging the camera stack, but let's not forget there are also other markets (IoT in particular) that may be structured differently. Not all vendors of SoCs that integrate ISPs consider Android as their main target, and they may ignore the notebook and mobile markets completely. - Slide 11 (and previous slides too) mention "Secret Sauce". I really dislike that term, as it's very vague. I would like discussions to clearly define the scope of that closed-source component, and we should come up with a more descriptive name that reflects that well-defined scope. - Slide 16 mentions 122 ioctls to emphasize that V4L2 is a complicated API. Most of those are not relevant to cameras. It is thus a bit misleading technically, but it can be still perceived as complicated by vendors for that reason. - Still on slide 16, V4L2 as an API is usable without disclosing vendor IP. What is not possible is upstreaming a driver. I don't see this as significantly different between V4L2 and the new API proposal. I expect this to be discussed on Monday. - On slide 17 the color scheme seems to imply that the daemon is open-source, while it's in most cases (maybe in all of them) closed. - Do you have a real life example of the type of outcome described on slide 19 (black box hardware) ? - Slide 24 mentions parameter buffers, it would be useful to describe what those typically contain, and who consumes them once they're provided by userspace to the driver. - Slide 27 mentions that upstreaming a driver will require a camera stack with the same open source requirements as V4L2. Doesn't that contradict slide 16 that mentions that V4L2 cannot product vendor IP, or at least infer that the new API wouldn't protect the vendor IP more than V4L2 does ? - Slide 31 mentions that entities can send operations internally and listen to each other events. I'd like to better understand how that will work without any abstraction in the API (as that is one of the main design decision behind this new API) when those entities are from different vendors, and handled by different drivers that are developed independently (for instance, the camera sensor and the CSI-2 receiver, or even the CSI-2 receiver and the ISP). - Does the bike on slide 32 illustrate the difficult discussions we've had in the past and how progress was hindered ? :-) > Looking forward to see all of you again on Monday :) -- Regards, Laurent Pinchart
