Reggression caused by "drm/fb-helper: Don't use the preferred depth for the BPP default"

[Thomas Zimmermann]

Hi,

thanks for the bug report.

Am 16.04.25 um 04:23 schrieb Fabio Estevam:
> Hi,
>
> I have a custom board populated with a cfaf240320x panel connected via
> SPI and driven by the drivers/gpu/drm/tiny/panel-mipi-dbi.c driver.
>
> It works well on kernel 6.1.
>
> After upgrading the kernel to 6.12 (also tested Linux-next), the panel
> no longer works correctly: the colors are wrong, and the image appears
> twice, one in each half of the screen.
>
> Running git bisect pointed to the following bad commit:
>
> 559358282e5b43b1b01e7f6afac6e0beb33cb4a2 is the first bad commit
> commit 559358282e5b43b1b01e7f6afac6e0beb33cb4a2
> Author: Thomas Zimmermann <tzimmermann at suse.de>
> Date:   Wed Nov 23 12:53:48 2022 +0100
>
>      drm/fb-helper: Don't use the preferred depth for the BPP default
>
>      If no preferred value for bits-per-pixel has been given, fall back
>      to 32. Never use the preferred depth. The color depth is the number
>      of color/alpha bits per pixel, while bpp is the overall number of
>      bits in most cases.
>
>      Most noteworthy, XRGB8888 has a depth of 24 and a bpp value of 32.
>      Using depth for bpp would make the value 24 as well and format
>      selection in fbdev helpers fails. Unfortunately XRGB8888 is the most
>      common format and the old heuristic therefore fails for most of
>      the drivers (unless they implement the 24-bit RGB888 format).
>
>      Picking a bpp of 32 will later on result in a default depth of 24
>      and the format XRGB8888. As XRGB8888 is the default format for most
>      of the current and legacy graphics stack, all drivers must support
>      it. So it is the safe choice.
>
>      v2:
>              * fix commit-message typo (Javier)
>
>      Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
>      Reviewed-by: Javier Martinez Canillas <javierm at redhat.com>
>      Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>      Link: https://patchwork.freedesktop.org/patch/msgid/20221123115348.2521-8-tzimmermann@suse.de
>
> Then I did a quick hack like this:
>
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -425,7 +425,7 @@ void drm_fb_helper_prepare(struct drm_device *dev,
> struct drm_fb_helper *helper,
>           *       format.
>           */
>          if (!preferred_bpp)
> -               preferred_bpp = 32;
> +               preferred_bpp = 16;
>
>          INIT_LIST_HEAD(&helper->kernel_fb_list);
>          spin_lock_init(&helper->damage_lock);
>
> and the display correctly again.
>
> What is the proper fix for this issue?

The proper fix would patch the driver to support 32-bit correctly. It 
looks like the panel only supports 16 bpp and 24 bpp, so format 
conversion would be required.

For an easier fix, you can replace drm_client_setup() at [1] with 
drm_client_setup_with_fourcc() and pass DRM_FORMAT_RGB565 as the second 
argument.

Best regards
Thomas

[1] 
https://elixir.bootlin.com/linux/v6.13.7/source/drivers/gpu/drm/tiny/panel-mipi-dbi.c#L393

>
> Thanks,
>
> Fabio Estevam

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)