Hi Gerd,
On Tue, Jul 12, 2022 at 9:47 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote:
On Mon, Jul 11, 2022 at 05:30:30PM +0200, Geert Uytterhoeven wrote:
Cirrus is the only driver setting quirk_addfb_prefer_host_byte_order
and supporting RGB565 or XRGB1555, but no one tried that on big-endian?
Cirrus does not support DRM_FORMAT_RGB565 | DRM_FORMAT_BIG_ENDIAN
in cirrus_fb_create, so you cannot get a graphical text console.
Do we need these definitions on little-endian platforms, too?
Would it be better to use "DRM_FORMAT_{XRGB1555,RGB565} |
DRM_FORMAT_BIG_ENDIAN" instead of "DRM_FORMAT_HOST_{XRGB1555,RGB565}" in
formats[]?
The intention of DRM_FORMAT_HOST_* is that they are macros in
include/drm/drm_fourcc.h which just map to little endian formats
defined in drivers/gpu/drm/drm_fourcc.c. Since this is not possible
for big endian hosts for XRGB1555 or RGB565 (or any other format
with non-8-bit components), this isn't applicable here.
It IMHO is not applicable to any physical hardware. It's used by
virtio-gpu where the supported format depends on the byte order
(it is argb8888 in native byte order). Only virtual hardware can
have that kind of behavior.
And we can probably drop the DRM_FORMAT_HOST_* variants for 1555 and
565, they are not used anywhere.
Atari DRM supports (big-endian) RGB565, so it uses
DRM_FORMAT_HOST_RGB565.
The alternative is to drop the quirk_addfb_prefer_host_byte_order
requirement on big-endian, and always use a little-endian RGB565
shadow frame buffer, at the expense of never being able to get rid
of the copying and byteswapping.
[Cirrus discussion removed]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
