Messages in this thread | | | Date | Thu, 24 Nov 2022 09:46:48 +0100 | Subject | Re: [PATCH resend v2] drm/fourcc: Add missing big-endian XRGB1555 and RGB565 formats | From | Thomas Zimmermann <> |
| |
Hi
Am 23.11.22 um 17:43 schrieb Geert Uytterhoeven: > As of commit eae06120f1974e1a ("drm: refuse ADDFB2 ioctl for broken > bigendian drivers"), drivers must set the > quirk_addfb_prefer_host_byte_order quirk to make the drm_mode_addfb() > compat code work correctly on big-endian machines. > > While that works fine for big-endian XRGB8888 and ARGB8888, which are > mapped to the existing little-endian BGRX8888 and BGRA8888 formats, it > does not work for big-endian XRGB1555 and RGB565, as the latter are not > listed in the format database. > > Fix this by adding the missing formats. Limit this to big-endian > platforms, as there is currently no need to support these formats on > little-endian platforms. > > Fixes: 6960e6da9cec3f66 ("drm: fix drm_mode_addfb() on big endian machines.") > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> > --- > v2: > - Use "DRM_FORMAT_foo | DRM_FORMAT_BIG_ENDIAN" instead of > "DRM_FORMAT_HOST_foo", > - Turn into a lone patch, as all other patches from series > https://lore.kernel.org/r/cover.1657300532.git.geert@linux-m68k.org > were applied to drm-misc/for-linux-next. > --- > drivers/gpu/drm/drm_fourcc.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c > index e09331bb3bc73f21..265671a7f9134c1f 100644 > --- a/drivers/gpu/drm/drm_fourcc.c > +++ b/drivers/gpu/drm/drm_fourcc.c > @@ -190,6 +190,10 @@ const struct drm_format_info *__drm_format_info(u32 format) > { .format = DRM_FORMAT_BGRA5551, .depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true }, > { .format = DRM_FORMAT_RGB565, .depth = 16, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 }, > { .format = DRM_FORMAT_BGR565, .depth = 16, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 }, > +#ifdef __BIG_ENDIAN > + { .format = DRM_FORMAT_XRGB1555 | DRM_FORMAT_BIG_ENDIAN, .depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 }, > + { .format = DRM_FORMAT_RGB565 | DRM_FORMAT_BIG_ENDIAN, .depth = 16, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
Getting back to the discussion on endianess, I don't understand why the BIG_ENDIAN flag is set here. AFAIK these formats are always little endian. And the BE flag is set by drivers/userspace if a framebuffer has a BE ordering.
It would be better to filter the BE flag in __drm_format_info() before the function does the lookup.
Best regards Thomas
> +#endif > { .format = DRM_FORMAT_RGB888, .depth = 24, .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 }, > { .format = DRM_FORMAT_BGR888, .depth = 24, .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 }, > { .format = DRM_FORMAT_XRGB8888, .depth = 24, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev [unhandled content-type:application/pgp-signature] | |