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?