On Fri, Apr 07, 2017 at 10:29:00AM +0200, Gerd Hoffmann wrote: > Hi, > > > Hmm. Maybe it's still possible to salvage something by redefining the > > BIG_ENDIAN format bit to mean the "the other endianness". Ugly but it > > might still result in something usable. > > Also at least for the virtual machine use case this doesn't buy us much. > The drm drivers (at least the ones used on both big and little endian > guests) support only 32 bpp + depth 24 formats. And for these we don't > need a "other endian" flag because we have fourcc codes for all sorts of > byte orders (i.e. DRM_FORMAT_XRGB8888 little endian == > DRM_FORMAT_BGRX8888 big endian). Yeah, those could be handled without the flag. But when mixed with any other format the code would look a bit weird IMO. So my idea with the flag was that if you display is big endian you always have the flag, and then you don't have to think so much which way the bytes go for each format. Less special casing is good IMO. > > The DRM_FORMAT_BIG_ENDIAN flags also seems not be used anywhere in the > code base (except in some format printing debug code ...). That's because either no one has big endian display hardware or they do but just didn't read the docs and cargo culted the format handling from some driver for little endian display. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
