[PATCH 0/6] drm: tackle byteorder issues, take two

[Gerd Hoffmann]

  Hi,

> > Gerd Hoffmann (6):
> >   drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN
> 
> I don't see how it can be dropped. It's only optional for formats where
> all components have 8 bits.

Well, we can, because it is simply not used anywhere ...

We indeed can't specify RGB565 or XRGB2101010 in bigendian byte order
without this.  Apparently nobody needed that so far.  Should the need to
support this arise I'd rather define new fourcc codes, because I think
we should have exactly one fourcc per format.

With the bigendian flag all 8bit component formats have two:  XRGB8888
in bigendian can be "XRGB8888 | BIGENDIAN" and "BGRX8888".

> >   drm: fourcc byteorder: add DRM_FORMAT_CPU_*
> >   drm: fourcc byteorder: add bigendian support to
> >     drm_mode_legacy_fb_format
> 
> As I explained in my last followup in the "[PATCH] drm: fourcc
> byteorder: brings header file comments in line with reality." thread,
> the mapping between GPU and CPU formats has to be provided by the
> driver, it cannot be done statically.

Well, the drm fourcc codes represent the cpu view (i.e. what userspace
will fill the ADDFB2-created framebuffers with).  The gpu view can
certainly differ from that.  Implementing this is up to the driver IMO.

When running on dumb framebuffers userspace doesn't need to know what
the gpu view is.

When running in opengl mode there will be a hardware-specific mesa
driver in userspace, which will either know what the gpu view is (for
example because there is only one way to implement this in hardware) or
it can use hardware-specific ioctls to ask the kernel driver what the
gpu view is.

So, I can't see the problem you are seeing here.  Did I miss something?

cheers,
  Gerd