News for hackers. Stuff that matters.
Re:Cameras and Open Source Smartphones: It’s Complicated by leni536 on Wednesday May 11, 2022 @04:11PM (#31345126)
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).

Re:Cameras and Open Source Smartphones: It’s Complicated by megous on Wednesday May 11, 2022 @04:50PM (#31345591)
These 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.

Re:Cameras and Open Source Smartphones: It’s Complicated by leni536 on Friday May 13, 2022 @03:21PM (#31371571)
Sure, 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.
Re:Cameras and Open Source Smartphones: It’s Complicated by megous on Friday May 13, 2022 @05:13PM (#31372589)
How? Dynamic linker hacks don't count.
Re:Cameras and Open Source Smartphones: It’s Complicated by leni536 on Friday May 20, 2022 @05:01PM (#31452456)
The same way OBS can expose a virtual camera? I believe it's the v4l2-loopback driver, but I'm not sure.
Re:Cameras and Open Source Smartphones: It’s Complicated by dcz_self on Wednesday May 11, 2022 @04:17PM (#31345183)
libcamera already has that functionality via LD_PRELOAD