[PATCH 0/6] drm: tackle byteorder issues, take two
michel at daenzer.net
Mon Apr 24 07:54:25 UTC 2017
On 24/04/17 04:36 PM, Gerd Hoffmann wrote:
>>> drm: fourcc byteorder: add DRM_FORMAT_CPU_*
>>> drm: fourcc byteorder: add bigendian support to
>> 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
More information about the dri-devel