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