[libcamera-devel] use of v4l2-compat.so

[Nicolas Dufresne]

(Adding George and Raghavendra in CC)

Le vendredi 19 juin 2020 à 18:44 +0300, Laurent Pinchart a écrit :
> Hi Nicolas,
> 
> On Fri, Jun 19, 2020 at 11:31:43AM -0400, Nicolas Dufresne wrote:
> > Le mardi 16 juin 2020 à 23:38 +0530, naidu nama a écrit :
> > > Hi team,
> > > By default gstreamer is not using v4l2-compat.so.So,then what is the
> > > use of v4l2 folder in libcamera.The goal is to by-pass the v4l2linux
> > > API and use the libcamera API.So,what is the use of this v4l2 folder.
> > 
> > It is what is is, a work in progress LD_PRELOAD wrapper for "legacy"
> > applications. Such a wrap would be achieve in a lauch script (or XDG desktop
> > file). We suspect some app will take a long time to migrate, and would like
> > to
> > we able to use cameras on the IPU3 laptops and ARM devices before they are
> > ported.
> > 
> > As for browser and sandboxed apps, it's all clear. In the flatpak community,
> > they really want to stop giving /dev access to apps unless strictly needed,
> > specially for V4L2 as it's then impossible to reclaim the access. But there
> > is a
> > WIP libcamera backend in pipewire already, so that is one way, but it does
> > not
> > really offer the features of libcamera. That all needs to be designed, I do
> > expect mixed support in the upcoming future (some browser may us libcamera,
> > some
> > will do pipewire, as they will have to decide between sandboxing and
> > features).
> 
> For pipewire-based stacks, we will need a camera backend for pipewire,
> as well as a frontend API for applications. Provided we use libcamera as
> a backend, do you think it would make sense to offer the same API for
> the frontend ? It would require a libcamera API implementation on top of
> pipewire, and would allow applications to use the same API, regardless
> of whether pipewire is part of the camera stack or not.

I believe so. For PulseAudio and JackD, there is session manages that implement
the API level, then they share some nodes. That difference seems that the nodes
would be implement with libcamera underneath. It's just a bit annoying to keep
in sync, so I'll let George explain what is possible to avoid duplication (e.g.
making a in-libcamera layer instead of a full copy of the API).

> 
> > > On Tue, Jun 16, 2020 at 12:40 AM Nicolas Dufresne wrote:
> > > > Le lundi 15 juin 2020 à 23:38 +0530, naidu nama a écrit :
> > > > > Hi,
> > > > > What does this wrapper library mean?
> > > > > where can i find this API??
> > > > 
> > > > The API is V4L2 API, this library will catch calls to
> > > > open/close/ioctl/poll and when they match a V4L2 use cases, they will
> > > > be emulated on top of libcamera.
> > > > 
> > > > > On Mon, Jun 15, 2020 at 9:32 PM Nicolas Dufresne <nicolas at ndufresne.ca
> > > > > >
> > > > > wrote:
> > > > > > Le lundi 15 juin 2020 à 11:52 -0400, Nicolas Dufresne a écrit :
> > > > > > > Le lundi 15 juin 2020 à 18:11 +0300, Laurent Pinchart a écrit :
> > > > > > > > On Mon, Jun 15, 2020 at 11:06:45AM -0400, Nicolas Dufresne
> > > > > > > > wrote:
> > > > > > > > > Le lundi 15 juin 2020 à 18:52 +0530, naidu nama a écrit :
> > > > > > > > > > Hi,
> > > > > > > > > > I am able to build the v4l2 directory.I am getting a shared
> > > > > > > > > > libary
> > > > > > > > > > v4l2-compat.so.How can i use this in my libcamera or how can
> > > > > > > > > > i test
> > > > > > > > > > that v4l2-compat.so
> > > > > > > > > 
> > > > > > > > > One way is to make sure it's in your library path, and
> > > > > > > > > use LD_PRELOAD=v4l2-compat.so .  Last time I tried it was
> > > > > > > > > missing
> > > > > > > > > poll() emulation.
> > > > > > > > 
> > > > > > > > poll() support has been merged, along with several bug fixes.
> > > > > > > > Paul is
> > > > > > > > working on additional fixes, they should hopefully land this
> > > > > > > > week.
> > > > > > > 
> > > > > > > Great ! I confirm it works under GStreamer now:
> > > > > > > 
> > > > > > > LD_LIBRARY_PATH=$(pwd)/build/src/v4l2 LD_PRELOAD=v4l2-compat.so
> > > > > > > gst-
> > > > > > > launch-1.0 v4l2src ! glimagesink
> > > > > > 
> > > > > > Well, it *minimally* works. It seems that it's impossible to pick
> > > > > > resolution different from 160x120, or select JPEG. As for other app,
> > > > > > libv4l2 wrapper don't seem handled, in firefox it does not get used
> > > > > > and
> > > > > > it causes chrome to hang at start.