Re: [Media Summit] ChromeOS Kernel CAM

Laurent Pinchart
2022-09-07T10:51:33Z

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