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 _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
