search for: drm_format_big_endian

...g. 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...

...g. 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...

...ly byte-swap. In contrast handling 16bpp formats (5:6:5 or 5:5:5) with the non-native byte order is a PITA. The other reason of course is that this is the default format these days. So, do any "other formats" exist where the byteswapped variant is used in practice? Or can we just drop DRM_FORMAT_BIG_ENDIAN? > 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. Having two valid fourcc (DRM_FORMAT_XRGB8888 + (DRM_FORMAT_BGRX8888 |...

On Thu, Apr 06, 2017 at 08:27:47PM +0300, Ville Syrj?l? wrote: > On Thu, Apr 06, 2017 at 10:29:43AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > > static const uint32_t virtio_gpu_cursor_formats[] = { > > > > +#ifdef __BIG_ENDIAN > > > > + DRM_FORMAT_BGRA8888, > > > > +#else > > > > DRM_FORMAT_ARGB8888, > >

On Thu, Apr 06, 2017 at 08:27:47PM +0300, Ville Syrj?l? wrote: > On Thu, Apr 06, 2017 at 10:29:43AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > > static const uint32_t virtio_gpu_cursor_formats[] = { > > > > +#ifdef __BIG_ENDIAN > > > > + DRM_FORMAT_BGRA8888, > > > > +#else > > > > DRM_FORMAT_ARGB8888, > >

...ast 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). The DRM_FORMAT_BIG_ENDIAN flags also seems not be used anywhere in the code base (except in some format printing debug code ...). cheers, Gerd