[lkml]   [2017]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Mon, 10 Apr 2017 16:17:27 +0200
Gerd Hoffmann <> wrote:

> Hi,
> > which software have you used as representative of "reality"?
> ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
> driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB8888 (one and
> only format supported by bochs-drm), and we have to interpret that in
> bigendian byte order on the host side to get a correct display.

I wonder if that is just an oversight from trying to match OpenGL
formats to DRM formats. It's full of gotcha's.

Did you try with GLAMOR? Do you see a difference with and without
GLAMOR? Hmm, but you have no GPU support, so GLAMOR would be through a
Mesa software renderer? I think I heard someone say something about
Mesa software on BE...

But even if this actually is a valid example of software we must keep
working as is, well, ouch. But if I cannot show that your fix breaks
anything, then I suppose you win. Your proposal would certainly solve
the dilemma we have with wl_shm formats in Wayland.

I also wonder if a real BE machine could have different results than
the virtual machine.


> Didn't try wayland. Can do, but will take a while. Don't have a
> wayland-capable guest install at hand, and installing one takes a while
> because I don't have a physical pseries and emulation is slooooww.
> > To solve that problem, we would like to know if anything existing would
> > break for each possible solution, but no developers using BE have really
> > turned up.
> That is part of the problem.
> And even ppc is moving to little endian these days ...
> cheers,
> Gerd

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2017-04-10 17:12    [W:0.128 / U:14.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site