Hi, > > > +#ifdef __BIG_ENDIAN > > > > Why do we need the #ifdef here? Iirc some hw has big endian flags in the > > scanout registers, so could supprt this unconditionally if there's no > > #ifdef around the format defines. Some drivers might then also want a > > DRM_FORMAT_FOO_BE define to simplify tables and stuff, but that's more a > > bikeshed. > > "Limit this to big-endian platforms, as there is currently no need > to support these formats on little-endian platforms." > > Will anyone make use of this? In theory, all of the 16-bpp formats > can have a big-endian counterpart. Highly unlikely. Dealing with 16-bpp formats in non-native byte order is a PITA because it isn't enough to simply adjust the masks and shifts to pick the correct bits and be done with it. The qemu stdvga happens to have a register to switch framebuffer byteorder (so both x64 and ppc are happy), and the bochs drm driver actually supports that no matter what the cpu byte order is, but it supports only DRM_FORMAT_XRGB8888 + DRM_FORMAT_BGRX8888. Supporting 16 bpp in the driver wouldn't be that much of a problem, but processing the framebuffer on the host side when emulating a big endian guest on a little endian host is painful. I think I can't ask pixman to do a conversation from DRM_FORMAT_RGB565 | DRM_FORMAT_BIG_ENDIAN to DRM_FORMAT_XRGB8888 on a little endian machine. take care, Gerd
