Em Sun, 20 Nov 2022 23:17:56 +0100 Hans de Goede <hdegoede@xxxxxxxxxx> escreveu: > Hi, > > On 11/14/22 21:38, Mauro Carvalho Chehab wrote: > > Em Thu, 20 Oct 2022 21:55:28 +0200 > > Hans de Goede <hdegoede@xxxxxxxxxx> escreveu: > > > >> camorama calls VIDIOC_REQBUFS(V4L2_MEMORY_MMAP) to test if MMAP support > >> works (this was added specifically because of the previously broken > >> MMAP support in atomisp). > >> > >> Currently this fails because atomisp_get_css_frame_info() fails in this > >> case. Although it is weird to call VIDIOC_REQBUFS before VIDIOC_S_FMT, > >> it is allowed to do this. > >> > >> Fix this not working by doing a S_FMT to V4L2_PIX_FMT_YUV420 + the highest > >> supported resolution. > >> > >> Note this will cause camorama to use mmap mode, which means it will also > >> use libv4l2 to do format conversion. libv4l2 will pick V4L2_PIX_FMT_RGB565 > >> as input format and this will lead to a garbled video display. This is > >> a libv4lconvert bug, the RGB565 -> RGB24 path in libv4lconvert assumes > >> that stride == width which is not true on the atomisp. > > > > Hmm... should we add a patch on Camorama for it to not use libv4l2 if > > format == V4L2_PIX_FMT_RGB565? > > This is not controlled by Camorama but by libv4lconvert, AFAICT there are > no atomisp2 native formats which are supported in Camorama without libv4l ? Actually, I added support on Camorama to decode it, plus other formats. It currently supports: V4L2_PIX_FMT_ABGR32 V4L2_PIX_FMT_ARGB32 V4L2_PIX_FMT_BGR24 V4L2_PIX_FMT_BGR32 V4L2_PIX_FMT_NV12 V4L2_PIX_FMT_NV21 V4L2_PIX_FMT_RGB24 V4L2_PIX_FMT_RGB32 V4L2_PIX_FMT_RGB565 V4L2_PIX_FMT_RGB565X V4L2_PIX_FMT_UYVY V4L2_PIX_FMT_VYUY V4L2_PIX_FMT_YUYV V4L2_PIX_FMT_YVYU V4L2_PIX_FMT_XBGR32 V4L2_PIX_FMT_XRGB32 V4L2_PIX_FMT_YUV420 V4L2_PIX_FMT_YVU420 It is just that it defaults to request RGB24 when not in userptr mode or when --dont-use-libv4l2 is not used. I guess it makes sense to make it smarter by using a native format, using its internal logic if the format is directly supported on it. It would also make sense to add Bayer and MPEG formats to it as well. > >> I've already send out a libv4lconvert fix for this. Also this can be worked > >> around by passing --dont-use-libv4l2 as argument to camorama. > > > > Was the patch already applied? The better would be to apply it at > > libv4l2 upstream, as a fix, porting it to old versions, and mentioning > > on what versions this got fixed on this changeset. > > I see that you have already found the patches. I will add a comment > to the commit msg pointing to the now applied patch. Ok. Regards, Mauro