Den 12.03.2021 05.32, skrev Peter Stuge: > 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. > I skimmed a discussion a while back around BE and all it's problems through the whole graphics stack and my take away was that I needed a BE machine so I could test the whole stack to make sure it works. Judging from what Ilia says I've been wrong in my assumptions so the driver is probably broken on BE (along with my SPI display drivers). I'm not going to try and fix this now, I need someone with a BE machine that can test the whole stack and make sure it actually works. Me doing more guesswork is not going to work out well I think :) I'll add a FIXME in gud_pipe.c that BE is probably broken and link to this discussion. It seems Gerd did some work to fix BE in the kernel: drm: byteorder fixes https://patchwork.freedesktop.org/series/49073/ But that seems to deal with the format value itself and not the buffer contents. Noralf.
