Em Wed, 3 Nov 2021 15:41:05 +0100 Hans Verkuil <hverkuil-cisco@xxxxxxxxx> escreveu: > On 03/11/2021 14:54, Mauro Carvalho Chehab wrote: > > Hi, > > > > From what I've seen so far, those are the main issues with regards to V4L2 API, > > in order to allow a generic V4L2 application to work with it. > > > > MMAP support > > ============ > > > > Despite having some MMAP code on it, the current implementation is broken. > > Fixing it is not trivial, as it would require fixing the HMM support on it, > > which does several tricks. > > > > The best would be to replace it by something simpler. If this is similar > > enough to IPU3, perhaps one idea would be to replace the HMM code on it by > > videodev2 + IPU3 HMM code. > > > > As this is not trivial, I'm postponing such task. If someone has enough > > time, it would be great to have this fixed. > > > > From my side, I opted to add support for USERPTR on camorama: > > > > https://github.com/alessio/camorama > > > > As this is something I wanted to do anyway, and it allowed me to cleanup > > several things in camorama's code. > > > > Support for USERPTR is not autodetected. So, this should be selected > > You can autodetect this: the capabilities field returned by VIDIOC_REQBUFS > or VIDIOC_CREATE_BUFS will indicate support for this. This works with any > vb2-based driver. > > Just thought I should mention this... Yeah, surely the app could try it, but: 1. As libv4l doesn't support USERPTR, such detection should happen early inside camorama code; 2. Atomisp does have support for MMAP, but it is broken. (this is the most relevant reason) Ok, we could change it to return -ENOIOCTLCMD for mmap, and add a basic logic at camorama that would try to call REQBUFS in order to verify if -ENOIOCTLCMD is returned. Perhaps one more item to our todo list, if nobody fixes MMAP before that. Regards, Mauro
