[PATCH v4 5/5] drm/ofdrm: Support big-endian scanout buffers
Javier Martinez Canillas
javierm at redhat.com
Thu Oct 13 07:39:21 UTC 2022
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
More information about the dri-devel
mailing list