[PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Pekka Paalanen]

On Fri, 21 Apr 2017 09:58:24 +0200
Gerd Hoffmann <kraxel at redhat.com> wrote:

> While working on graphics support for virtual machines on ppc64 (which
> exists in both little and big endian variants) I've figured the comments
> for various drm fourcc formats in the header file don't match reality.
> 
> Comments says the RGB formats are little endian, but in practice they
> are native endian.  Look at the drm_mode_legacy_fb_format() helper.  It
> maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB8888, no matter
> whenever the machine is little endian or big endian.  The users of this
> function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
> is native endian, not little endian.  Most userspace also operates on
> native endian only.
> 
> So, go update the comments for all 16+24+32 bpp RGB formats.
> 
> Leaving the yuv formats as-is.  I have no idea if and how those are used
> on bigendian machines.
> 
> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter at intel.com>
> Cc: Pekka Paalanen <ppaalanen at gmail.com>
> Cc: Ilia Mirkin <imirkin at alum.mit.edu>
> Cc: Michel Dänzer <michel at daenzer.net>
> Cc: Alex Deucher <alexdeucher at gmail.com>
> Cc: amd-gfx at lists.freedesktop.org
> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
> ---
>  include/uapi/drm/drm_fourcc.h | 82 +++++++++++++++++++++----------------------
>  1 file changed, 41 insertions(+), 41 deletions(-)

Hi,

just an idea - since we are not sure how the remaining formats are being
used, should those be marked somehow uncertain whether they are little
or native endian?

Otherwise the documentation will guide people to believe those are
certain, which OTOH might not be bad, because then it will make them
certain over time. Unless we would prefer everything to be native
endian?

This might be a chance to choose the endianess (native vs. little) for
all formats. Should we take it? Prefer native?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170421/07f8d301/attachment.sig>