linux-kernel - Re: [PATCH resend v2] drm/fourcc: Add missing big-endian XRGB1555 and RGB565 formats

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 24 Nov 2022 07:51:48 +0100
From:   Gerd Hoffmann <kraxel@...hat.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Daniel Vetter <daniel@...ll.ch>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...il.com>,
        dri-devel@...ts.freedesktop.org, linux-fbdev@...r.kernel.org,
        linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH resend v2] drm/fourcc: Add missing big-endian XRGB1555
 and RGB565 formats

  Hi,

> > > +#ifdef __BIG_ENDIAN
> >
> > Why do we need the #ifdef here? Iirc some hw has big endian flags in the
> > scanout registers, so could supprt this unconditionally if there's no
> > #ifdef around the format defines. Some drivers might then also want a
> > DRM_FORMAT_FOO_BE define to simplify tables and stuff, but that's more a
> > bikeshed.
> 
>  "Limit this to big-endian platforms, as there is currently no need
>  to support these formats on little-endian platforms."
> 
> Will anyone make use of this? In theory, all of the 16-bpp formats
> can have a big-endian counterpart.

Highly unlikely.  Dealing with 16-bpp formats in non-native byte order
is a PITA because it isn't enough to simply adjust the masks and shifts
to pick the correct bits and be done with it.

The qemu stdvga happens to have a register to switch framebuffer
byteorder (so both x64 and ppc are happy), and the bochs drm driver
actually supports that no matter what the cpu byte order is, but it
supports only DRM_FORMAT_XRGB8888 + DRM_FORMAT_BGRX8888.

Supporting 16 bpp in the driver wouldn't be that much of a problem, but
processing the framebuffer on the host side when emulating a big endian
guest on a little endian host is painful.  I think I can't ask pixman to
do a conversation from DRM_FORMAT_RGB565 | DRM_FORMAT_BIG_ENDIAN to
DRM_FORMAT_XRGB8888 on a little endian machine.

take care,
  Gerd