Ilia Mirkin wrote:
XRGB8888 means that the memory layout should match a 32-bit integer, stored as LE, with the low bits being B, next bits being G, etc. This translates to byte 0 = B, byte 1 = G, etc. If you're on a BE system, and you're handed a XRGB8888 buffer, it still expects that byte 0 = B, etc (except as I outlined, some drivers which are from before these formats were a thing, sort of do their own thing). Thankfully this is equivalent to BGRX8888 (big-endian packing), so you can just munge the format.
I understand! Thanks a lot for clarifying.
It makes much more sense to me that the format indeed describes what is in memory rather than how pixels look to software.
I'm not sure why you guys were talking about BE in the first place,
I was worried that the translation didn't consider endianess.
The translation in gud_xrgb8888_to_color definitely seems suspect.
So to me this means that the gud_pipe translations from XRGB8888 to the 1-bit formats *do* have to adjust for the reversed order on BE.
There's also a gud_is_big_endian, but I'm guessing this applies to the downstream device rather than the host system.
gud_is_big_endian() is a static bool wrapper around defined(__BIG_ENDIAN) so yes, it applies to the host.
With memory layout being constant I again think gud_xrgb8888_to_color() needs to take further steps to work correctly also on BE hosts. (Maybe that's le32_to_cpu(*pix32), maybe drm_fb_swab(), maybe something else?)
I didn't check if dev->mode_config.quirk_addfb_prefer_host_byte_order is set
I can't tell if that's helpful, probably Noralf can.
Thanks a lot
//Peter