Hello, On 10/12/22 16:27, Michal Suchánek wrote: [...] >> >> If you are using the framebuffer code from vga.c, I would guess that >> that you can run a big-endian kernel with qemu-system-ppc64, >> or a little-endian kernel with qemu-system-ppc64le and get the >> correct colors, while running a little-endian kernel with >> qemu-system-ppc64 and vga.c, or using a different framebuffer >> emulation on a big-endian kernel would give you the wrong colors. > > Thanks for digging this up. > > That makes one thing clear: qemu does not emulate this framebuffer > property correctly, and cannot be relied on for verification. > > If you can provide test results from real hardware that show the current > logic as flawed it should be changed. > > In absence of such test results I think the most reasonable thing is to > keep the logic that nobody complained about for 10+ years. > I agree with Michal and Thomas on this. I don't see a strong reason to not use the same heuristic that the offb fbdev driver has been doing for this. Otherwise if this turns out to be needed, it will cause a regression for a user that switches to this driver instead. Specially since both fbdev and DRM drivers match against the same "display" OF compatible string. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
