Hi Laurent On Wed, 7 Sept 2022 at 12:51, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > > 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 ? It is really a jungle. You get UIO-like, real UIO (less common), franken V4L2... > > - 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. And also not forget about Industry 3.0. There is a lot of diversity there. > > - 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. I came up with: Closed-loop IQ algorithms. But it is less catchy than Secret Sauce. > > - 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. Vivid uses 100... But I agree, it is not the number of ioctls that makes it complicated. > > - 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. I am only considering upstream drivers. There is not much to discuss for downstream or closed drivers :) > > - 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. > We get a bit of everything, not only v4l2. So this is why it is purple: blue + red ;) > - Do you have a real life example of the type of outcome described on > slide 19 (black box hardware) ? Yes, I am working with the vendor to know how much I can disclose about it. > > - 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 ? Let's discuss that on Monday, > > - 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). It is still under work. Hardware, specially for standard buses, should be resilient (not crash) to format mismatches. Otherwise a mal-functionling sensor or too much noise could crash the system (with or without kcam). Drivers developed together should know about the rest of the system, so that is not the issue here. For drivers developed by different vendors for a standard bus, on hardware that is not resilient (that was a mouthful), then we need to prepare a set of read-only standard registers. > > - Does the bike on slide 32 illustrate the difficult discussions we've > had in the past and how progress was hindered ? :-) This is how we do code review at Google when two developers do not want to work together. We take the bike to the rooftop and the two developers that disagree tries to push the other developer to the edge of the building. The first second, when you see your colleague falling you think that you have won.... then you realise that you are falling with them. (you asked for a metaphor :P ) > > > Looking forward to see all of you again on Monday :) > > -- > Regards, > > Laurent Pinchart -- Ricardo Ribalda
