From: Gerd Hoffmann <kraxel@redhat.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
Daniel Vetter <daniel.vetter@intel.com>,
David Airlie <airlied@redhat.com>,
dri-devel@lists.freedesktop.org,
virtualization@lists.linux-foundation.org
Subject: Re: DRM_FORMAT_* byte order (was: Re: [PATCH] drm: virtio: fix virtio_gpu_cursor_formats)
Date: Fri, 07 Apr 2017 10:13:09 +0200 [thread overview]
Message-ID: <1491552789.26308.15.camel@redhat.com> (raw)
In-Reply-To: <20170406172747.GB30290@intel.com>
Hi,
> > So, bigendian guests assume that DRM_FORMAT_XRGB8888 is big endian not
> > little endian. And given that the fourcc codes are used in the
> > userspace/kernel API too (see DRM_IOCTL_MODE_ADDFB2) I think we can't
> > change that any more ...
>
> Sigh. That makes mixed endian systems pretty much hopeless :(
At least you can't use the DRM_FORMAT_* (alone) to specify the format.
Still manageable, we have to do that to handle ppc64 and ppc64le ;)
> It's also doubly disappointing because eg. the more standardized YUV
> formats are definitely little endian as far the official fourccs are
> concerned. So if we now make everything follow the host endianness
> these things become a huge mess for anyone wanting to do video
> playback etc.
That one is up for discussion. Guess I should brew a initial patch to
kickstart it. At least in bigendian virtual machines (bochs and virtio
drivers) the YUV formats are not supported at all. Dunno how things
look elsewhere.
> Oh well, at least I tried to make it sane from the start. I'll just
> go back to my blissful little endian world now.
ppc64le springing into live pretty much proves that little endian is
pretty close to reach world domination. So maybe all our endian
troubles will be solved that way some day.
cheers,
Gerd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-04-07 8:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-05 8:09 [PATCH] drm: virtio: fix virtio_gpu_cursor_formats Laurent Vivier
2017-04-05 17:11 ` Ville Syrjälä
2017-04-06 7:20 ` Laurent Vivier
2017-04-06 8:25 ` Daniel Vetter
2017-04-06 8:29 ` DRM_FORMAT_* byte order (was: Re: [PATCH] drm: virtio: fix virtio_gpu_cursor_formats) Gerd Hoffmann
2017-04-06 17:27 ` Ville Syrjälä
2017-04-06 17:35 ` Ville Syrjälä
2017-04-07 8:29 ` Gerd Hoffmann
2017-04-07 8:45 ` Ville Syrjälä
2017-04-07 10:06 ` Gerd Hoffmann
2017-04-07 12:49 ` Ville Syrjälä
2017-04-07 12:49 ` Ville Syrjälä
2017-04-07 10:06 ` Gerd Hoffmann
2017-04-07 8:29 ` Gerd Hoffmann
2017-04-06 17:35 ` Ville Syrjälä
2017-04-07 8:13 ` Gerd Hoffmann
2017-04-07 8:13 ` Gerd Hoffmann [this message]
2017-04-05 17:11 ` [PATCH] drm: virtio: fix virtio_gpu_cursor_formats Ville Syrjälä
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=1491552789.26308.15.camel@redhat.com \
--to=kraxel@redhat.com \
--cc=airlied@redhat.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=lvivier@redhat.com \
--cc=ville.syrjala@linux.intel.com \
--cc=virtualization@lists.linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.