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
