Wrong BMP colours on i.MX after updating 2018.11 => 2020.10

Hi all,
After updating from u-boot 2018.11 to 2020.10 on an i.MX6 based board I notice the colours when displaying bitmaps are wrong. The reason is that, in both cases the framebuffer format (not necessarily the physical output format) is hardcoded as RGB565 in the IPU driver but the bmp command is now assuming RGB55
This is because, in 2018.10 (before DM_VIDEO support for the i.MX display was available) video_display_bitmap() in drivers/video/cfb_console.c was being used which supports both RGB565 and RGB555 depending on the "gdfIndex" in a global graphics device structure.
Now with DM_VIDEO video_bmp_display() in drivers/video/video_bmp.c is used instead and that always assumes RGB555 when displaying a 24 bit BMP on a 16 bit framebuffer.
Of course this is easy to hack around but what is the correct solution?
Maybe we should add a format field to struct video_priv that could be initialised by the driver like xsize, ysize and bpix already are?
Regards,
Martin

Hi Martin,
Thanks for the report. Adding Anatolij.
On Tue, Jan 12, 2021 at 1:11 PM Fuzzey, Martin martin.fuzzey@flowbird.group wrote:
Hi all,
After updating from u-boot 2018.11 to 2020.10 on an i.MX6 based board I notice the colours when displaying bitmaps are wrong. The reason is that, in both cases the framebuffer format (not necessarily the physical output format) is hardcoded as RGB565 in the IPU driver but the bmp command is now assuming RGB55
This is because, in 2018.10 (before DM_VIDEO support for the i.MX display was available) video_display_bitmap() in drivers/video/cfb_console.c was being used which supports both RGB565 and RGB555 depending on the "gdfIndex" in a global graphics device structure.
Now with DM_VIDEO video_bmp_display() in drivers/video/video_bmp.c is used instead and that always assumes RGB555 when displaying a 24 bit BMP on a 16 bit framebuffer.
Of course this is easy to hack around but what is the correct solution?
Maybe we should add a format field to struct video_priv that could be initialised by the driver like xsize, ysize and bpix already are?
Regards,
Martin
participants (2)
-
Fabio Estevam
-
Fuzzey, Martin