4 ms·

Few people asked "why duplicate v4l2 functionality", but really libcamera serves a different purpose. V4l2 (and v4l) are frameworks that support connecting mult

Few people asked "why duplicate v4l2 functionality", but really libcamera serves a different purpose. V4l2 (and v4l) are frameworks that support connecting multiple types of devices. IMO the biggest advantage of libcamera is their goal to abstract various camera controls (ISP profiles and on-camera registers) that are painful to use with v4l2. It complements v4l2, not replaces it For example v4l2 has an ioctl to send raw read/write commands to a camera module. Having a datasheet one can then check which registers do what and one can set various features, but this requires using different registers and values for different camera modules. Then we have ISP controls that v4l2 doesn't touch at all and to let's say change color correction, or automatic gain or autofocus one has to use (usually proprietary) tools from the Soc manufacturer. Some of those tools are open source and very powerful (on rockchip for example), but still developing apps one has to use a completely different method to adjust a rockchip's ISP vs let's say raspberry pi's. So libcamera is a great idea to abstract all those hardware interfaces. Last time I checked they supported raspberry pi, and had a very minimal rockchip support. Imagine there is a time when libcamera supports all kinds of Soc ISPs (rockchip, broadcom, allwinner, hisilicon and many others). Traditionally getting a directly connected camera to work (under mainline Linux) has been quite difficult on various embedded devices. Then getting hardware encoding to work is the second hurdle. Most often manufacturers distribute sdk's with their proprietary binary blobs built against ancient Linux kernels and one has to live with it if one wants to reuse various cheap Ip camera boards.

HankB99 4y ago
> For example v4l2 has an ioctl to send raw read/write commands to a camera module. Having a datasheet one can then check which registers do what and one can set various features, but this requires using different registers and values for different camera modules. That touches a nerve. I worked on an embedded system which used one of these camera modules and the datasheet was probably accurate at some point in time during the development of the module, but clearly as the module was developed the data sheet did not keep up. Eventually it was necessary to employ a bus sniffer to capture all traffic between a demonstration kit and module and reproduce the streams byte for byte to get the camera to do what was needed. It was clear from the streams that the demonstration code was using device registers not described in the data sheet. I suppose that a big customer for the module (such as a cell phone manufacturer) would get access to an engineer who could provide the necessary information, but that was not us. > ... has been quite difficult on various embedded devices. Agreed.
dcz_self 4y ago
A blog post about my work on libcamera I do for the Purism Librem 5 phone touches on this topic: https://puri.sm/posts/cameras-its-complicated/ https://puri.sm/posts/cameras-its-complicated/

HankB99 4y ago

> For example v4l2 has an ioctl to send raw read/write commands to a camera module. Having a datasheet one can then check which registers do what and one can set various features, but this requires using different registers and values for different camera modules. That touches a nerve. I worked on an embedded system which used one of these camera modules and the datasheet was probably accurate at some point in time during the development of the module, but clearly as the module was developed the data sheet did not keep up. Eventually it was necessary to employ a bus sniffer to capture all traffic between a demonstration kit and module and reproduce the streams byte for byte to get the camera to do what was needed. It was clear from the streams that the demonstration code was using device registers not described in the data sheet. I suppose that a big customer for the module (such as a cell phone manufacturer) would get access to an engineer who could provide the necessary information, but that was not us. > ... has been quite difficult on various embedded devices. Agreed.

dcz_self 4y ago

A blog post about my work on libcamera I do for the Purism Librem 5 phone touches on this topic: https://puri.sm/posts/cameras-its-complicated/ https://puri.sm/posts/cameras-its-complicated/