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

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

[Fuzzey, Martin]

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

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

[Fabio Estevam]

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