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

[Michel Dänzer]

On 24/04/17 04:36 PM, Gerd Hoffmann wrote:
> 
>>>   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).

Ville is adamant that they represent the GPU view. This needs to be
resolved one way or the other.


> 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.

Not sure this can be hidden in the OpenGL driver. How would e.g. a
Wayland compositor or the Xorg modesetting driver know which OpenGL
format corresponds to a given DRM_FORMAT?


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer