Speaker
Description
Through the last years cameras' ISPs have evolved from something configurable to something programmable, just like the video cards.
Unfortunately, video4linux2 (v4l2) has not evolved in the same way. It still abstracts the cameras as a set of blocks that send video streams to others in well known formats that have controls (the media controller). This has these problems:
- v4l2 drivers builds abstractions that do not match the hardware, resulting in extremely large drivers (complex drivers)
- v4l2 drivers have fixed functionality. Vendors cannot have differentiating features on their camera stack. (lack of innovation)
- v4l2 subsystem obliges that all the access to the hardware is documented, which can lead to lawsuits if cores use patented algos unknowingly (legal uncertainty)
In comparison, Android has avoided v4l2 on their stack, instead they expect that vendors support a very abstracted userspace API, not imposing any limitation to vendors on how they access their hardware.
To solve this problem, Google has been working on KCAM, a new camera kernel infrastructure that lets you send command buffers directly to ISPs. It mimics very much DRM in that sense, most of the driver lives in userspace not in kernelspace. Memory operations are abstracted as well as unsafe commands.
The objective of the workshop is to discuss how Kcam fits on the camera and kernel ecosystem and the openness requirements.
| Code of Conduct | Yes |
|---|---|
| In-person or virtual presentation | In-person |
| GSoC, EVoC or Outreachy | No |
