video driver contributed by Sony, already mimic v4l2 interface: https://github.com/apache/incubator-nuttx/blob/master/drivers/video/video.c We can enhance this driver by: 1.Split the upper/lower half interface 2.Add more ioctl
On Sat, Apr 3, 2021 at 6:00 AM Matias N. <mat...@imap.cc> wrote: > I looked around to get a sense of V4L complexity. This [1] (very old) > article here gives a good broad idea > and it wouldn't seem too difficult to have something like this in NuttX, > focusing on minimal initial support. > It could be an upper-half driver which expects the lower-half to provide > the callbacks mentioned in > this article while at the same time registering a character driver. > > On the other hand, looking at more up-to-date documentation [2] I see V4L > nowadays is huge and > full of features. Maybe we can start with [1] in mind. > > For the time being I will most likely start creating an ad-hoc driver for > this camera (directly registering the chardev) > which could then be evolved into a v4l-like lower-half implementation. > > Best, > Matias > > [1] http://lwn.net/Articles/203924/ > [2] http://www.linuxtv.org/downloads/video4linux/API/V4L2_API > > On Sat, Apr 3, 2021, at 09:45, Marco wrote: > > Am Sa., 3. Apr. 2021 um 13:40 Uhr schrieb Matias N. <mat...@imap.cc > <mailto:matias%40imap.cc>>: > > > > > Do you see a need for something more? Not sure what other aspects of > video > > > handling require a specific solution. > > > > When talking about cameras you also need to specify the camera output > > format. > > This is mostly a raw format YUV for mipi cameras, but can also be e.g. > > mjpeg or h264 when supported by the camera. > > A lot of cameras providing different output formats nowadays. > > > > According to your map idea. > > Your implementation (the driver) must ensure that data capturing is > locked > > during accessing the buffer by the user space task. > > I don't know how the driver must handle this in terms of communication > with > > the camera. > > When working with v4l2 you need at least 2 registered framebuffer for > that > > reason. > > One is locked for capturing and the other for processing by the > application. > > > > I think there are other things to consider, but that's what I have > > currently in my mind. > > > > > > > > > > > > Best, > > > Matias > > > > > >
