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 > > >
