| Message ID | 20221016175729.187258-1-hdegoede@redhat.com |
|---|---|
| Headers | show |
| Series | Fix various v4lconvert functions assuming stride == width | expand |
Em Sun, 16 Oct 2022 19:57:25 +0200 Hans de Goede <hdegoede@redhat.com> escreveu: > Hi All, > > I (finally) have my videobuf2 conversion of the atomisp2 driver working > (I'll post the kernel patches real soon now). This means working MMAP mode, > which means I can use e.g. camorama with libv4l2 to do the conversion. > > By hacking libv4lconvert to prefer certain formats I have been able to test > yuv420, yuyv, rgb565, nv12 and nv16 support in the atomisp2 code. Which has > resulted in me finding a bunch of issues inside v4lconvert because > the atomisp2 driver generally creates frames where stride != width. > > This patch series fixes this. All patches have been tested on actual > hw, at least all the input -> rgb24 paths. > > Regards, > > Hans > > > Hans de Goede (4): > libv4lconvert: Fix v4lconvert_yuv420_to_rgb/bgr24() not taking stride > into account > libv4lconvert: Fix v4lconvert_rgb565_to_rgb/bgr24() not taking stride > into account > libv4lconvert: Fix v4lconvert_nv12_*() not taking stride into account > libv4lconvert: Fix v4lconvert_nv16_to_yuyv() not taking stride into > account Merged those on master: 0c96e7ca0266 (HEAD -> master, origin/master, origin/HEAD) libv4lconvert: Fix v4lconvert_nv16_to_yuyv() not taking stride into account e8b224d4be7e libv4lconvert: Fix v4lconvert_nv12_*() not taking stride into account aecfcfccfc2f libv4lconvert: Fix v4lconvert_rgb565_to_rgb/bgr24() not taking stride into account 6269f88db0d3 libv4lconvert: Fix v4lconvert_yuv420_to_rgb/bgr24() not taking stride into account I also merged them on 1.18, 1.20 and 1.22, as they're bug fixes and affects a real hardware. I was able to test only on 1.22 and master, as older versions don't build on Fedora 36. Regards, Mauro
Hi All, I (finally) have my videobuf2 conversion of the atomisp2 driver working (I'll post the kernel patches real soon now). This means working MMAP mode, which means I can use e.g. camorama with libv4l2 to do the conversion. By hacking libv4lconvert to prefer certain formats I have been able to test yuv420, yuyv, rgb565, nv12 and nv16 support in the atomisp2 code. Which has resulted in me finding a bunch of issues inside v4lconvert because the atomisp2 driver generally creates frames where stride != width. This patch series fixes this. All patches have been tested on actual hw, at least all the input -> rgb24 paths. Regards, Hans Hans de Goede (4): libv4lconvert: Fix v4lconvert_yuv420_to_rgb/bgr24() not taking stride into account libv4lconvert: Fix v4lconvert_rgb565_to_rgb/bgr24() not taking stride into account libv4lconvert: Fix v4lconvert_nv12_*() not taking stride into account libv4lconvert: Fix v4lconvert_nv16_to_yuyv() not taking stride into account lib/libv4lconvert/libv4lconvert-priv.h | 14 +++--- lib/libv4lconvert/libv4lconvert.c | 32 ++++++------ lib/libv4lconvert/rgbyuv.c | 70 +++++++++++++++++--------- 3 files changed, 69 insertions(+), 47 deletions(-)