3 ms·
Would it make sense to optionally also have a service that exposes these cameras through v4l2, so legacy applications can still make use of them, without patchi
by leni536 4y ago
Would it make sense to optionally also have a service that exposes these cameras through v4l2, so legacy applications can still make use of them, without patching them to make use of libcamera?
edit:
This would also resolve the dilemma of having complex camera drivers either in kernel or in a library. It could be in userspace while the kernel provides a small kernel module to make it work (like v4l2-loopback, or not unlike FUSE for filesystems).
- dcz_self 4y agolibcamera already has that functionality via LD_PRELOAD
- megous 4y agoThese cameras are already exposed via v4l2 they are just exposed by many v4l2 subdevices (for a separate parts of the HW camera and image processing pipeline) and not just as a single video device having all the necessary highlevel controls. So the interface is the same, it's just split over many device and platform specific subdevices, which normal apps can't really be expected to understand.
- leni536 4y agoSure, but then a libcamera based service could expose a single virtualized v4l2 device with all the necessary high level controls, and normal legacy apps could use that.