public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"David Airlie" <airlied@linux.ie>,
	"Michel Dänzer" <michel@daenzer.net>,
	"open list" <linux-kernel@vger.kernel.org>,
	dri-devel@lists.freedesktop.org,
	"Pekka Paalanen" <ppaalanen@gmail.com>,
	"Sean Paul" <seanpaul@chromium.org>,
	amd-gfx@lists.freedesktop.org,
	"Alex Deucher" <alexdeucher@gmail.com>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Ilia Mirkin" <imirkin@alum.mit.edu>
Subject: Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
Date: Fri, 21 Apr 2017 15:12:03 +0200	[thread overview]
Message-ID: <1492780323.25675.45.camel@redhat.com> (raw)
In-Reply-To: <f1b0ae60-b20e-ad52-7fbf-32f2c045f5fc@amd.com>

  Hi,

> > "native" to me feels more like "native to the GPU" since these things
> > really are tied to the GPU not the CPU. That's also why I went with the
> > explicit endianness originally so that the driver could properly declare
> > what the GPU supports.
> And to be honest I would really prefer to stick with that approach for 
> exactly that reason.
> 
> The proposed change would require that drivers have different code path 
> for different CPU byte order. Those code path tend to be not tested very 
> well and are additional complexity we probably don't want inside the driver.

We can add fixed-endian #defines without too much effort, at least for
the 8 bits per color formats.  In qemu we have the same problem, only
with pixman.  Those formats are native endian too, but often we have to
handle a fixed format, so we did this:

/*
 * pixman image formats are defined to be native endian,
 * that means host byte order on qemu.  So we go define
 * fixed formats here for cases where it is needed, like
 * feeding libjpeg / libpng and writing screenshots.
 */

#ifdef HOST_WORDS_BIGENDIAN
# define PIXMAN_BE_r8g8b8     PIXMAN_r8g8b8
# define PIXMAN_BE_x8r8g8b8   PIXMAN_x8r8g8b8
# define PIXMAN_BE_a8r8g8b8   PIXMAN_a8r8g8b8
# define PIXMAN_BE_b8g8r8x8   PIXMAN_b8g8r8x8
# define PIXMAN_BE_b8g8r8a8   PIXMAN_b8g8r8a8
# define PIXMAN_BE_r8g8b8x8   PIXMAN_r8g8b8x8
# define PIXMAN_BE_r8g8b8a8   PIXMAN_r8g8b8a8
# define PIXMAN_BE_x8b8g8r8   PIXMAN_x8b8g8r8
# define PIXMAN_BE_a8b8g8r8   PIXMAN_a8b8g8r8
# define PIXMAN_LE_x8r8g8b8   PIXMAN_b8g8r8x8
#else
# define PIXMAN_BE_r8g8b8     PIXMAN_b8g8r8
# define PIXMAN_BE_x8r8g8b8   PIXMAN_b8g8r8x8
# define PIXMAN_BE_a8r8g8b8   PIXMAN_b8g8r8a8
# define PIXMAN_BE_b8g8r8x8   PIXMAN_x8r8g8b8
# define PIXMAN_BE_b8g8r8a8   PIXMAN_a8r8g8b8
# define PIXMAN_BE_r8g8b8x8   PIXMAN_x8b8g8r8
# define PIXMAN_BE_r8g8b8a8   PIXMAN_a8b8g8r8
# define PIXMAN_BE_x8b8g8r8   PIXMAN_r8g8b8x8
# define PIXMAN_BE_a8b8g8r8   PIXMAN_r8g8b8a8
# define PIXMAN_LE_x8r8g8b8   PIXMAN_x8r8g8b8
#endif

> My personal opinion is that formats in drm_fourcc.h should be 
> independent of the CPU byte order and the function 
> drm_mode_legacy_fb_format() and drivers depending on that incorrect 
> assumption be fixed instead.

The problem is this isn't a kernel-internal thing any more.  With the
addition of the ADDFB2 ioctl the fourcc codes became part of the
kernel/userspace abi ...

cheers,
  Gerd

  reply	other threads:[~2017-04-21 13:12 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21  7:58 [PATCH] drm: fourcc byteorder: brings header file comments in line with reality Gerd Hoffmann
2017-04-21  8:06 ` Pekka Paalanen
2017-04-21  9:38   ` Gerd Hoffmann
2017-04-21  9:44     ` Ville Syrjälä
2017-04-21  9:25 ` Ville Syrjälä
2017-04-21  9:50   ` Gerd Hoffmann
2017-04-21 11:05     ` Ville Syrjälä
2017-04-21 11:08     ` Ville Syrjälä
2017-04-21 11:40       ` Pekka Paalanen
2017-04-21 11:49         ` Ville Syrjälä
2017-04-21 12:02           ` Christian König
2017-04-21 11:41       ` Gerd Hoffmann
2017-04-21 11:42       ` Christian König
2017-04-21 13:12         ` Gerd Hoffmann [this message]
2017-04-21 13:21           ` Christian König
2017-04-21 13:27             ` Christian König
2017-04-21 15:21               ` Harry Wentland
2017-04-21 16:14           ` Gerd Hoffmann
2017-04-22 10:05             ` Ville Syrjälä
2017-04-22 21:59               ` Gerd Hoffmann
2017-04-24  6:57               ` Michel Dänzer
2017-04-24 13:03                 ` Ville Syrjälä
2017-04-25  1:12                   ` Michel Dänzer
2017-04-25  3:08                     ` Michel Dänzer
2017-04-25 10:26                     ` Ville Syrjälä
2017-04-26  2:10                       ` Michel Dänzer
2017-05-11 21:23       ` Pavel Machek
2017-05-12  9:10         ` Ville Syrjälä
2017-04-21 14:49 ` Ilia Mirkin
2017-04-21 16:59   ` Ville Syrjälä
2017-04-22  5:07     ` Ilia Mirkin
2017-04-22  9:50       ` Ville Syrjälä
2017-04-22 13:40         ` Ilia Mirkin
2017-04-22 13:48           ` Ilia Mirkin
2017-04-22 19:24             ` Ilia Mirkin
2017-04-24  6:33               ` Michel Dänzer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1492780323.25675.45.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=airlied@linux.ie \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imirkin@alum.mit.edu \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michel@daenzer.net \
    --cc=ppaalanen@gmail.com \
    --cc=seanpaul@chromium.org \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox