| Message ID | CAOMZO5Dw9O_8E72ZsQhm7j+PX9XQfj9_w-WrkzaxczyyCGndVA@mail.gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Reggression caused by "drm/fb-helper: Don't use the preferred depth for the BPP default" | expand |
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@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@suse.de> > Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> > Acked-by: Daniel Vetter <daniel.vetter@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
Hi Thomas, On Wed, Apr 16, 2025 at 3:41 AM Thomas Zimmermann <tzimmermann@suse.de> wrote: > 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. Your suggestion works, and I have just sent a patch. Thanks a lot for your help!
--- 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);
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@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@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221123115348.2521-8-tzimmermann@suse.de Then I did a quick hack like this: spin_lock_init(&helper->damage_lock); and the display correctly again. What is the proper fix for this issue? Thanks, Fabio Estevam