Hi Daniel,
On Fri, Jan 21, 2022 at 9:55 AM Daniel Vetter <daniel@xxxxxxxx> wrote:
Just to clarify, since we had lots of smaller and bigger
misunderstandings in the thread thus far: DRM_FORMAT_RGB332 exists, so
drm support that already. The fbdev emulation doesn't yet, but all
that's needed for that is filling out the code to remap the drm
description to the fbdev format description for this case. Plus
testing it all works ofc with fbcon and whatelse. Note that RGB332 is
a bit more work than e.g. C4, since atm fbdev still uses only bpp to
identify formats, so would need to be switch over to drm_fourcc first
before adding anything which aliases with something existing (we have
C8 already wired up).
I doubt that RGB332 would be a bit more work than C4, as RGB332 is still
8 bpp, while C4 is less. To support C4, all DRM code that cannot
handle format->cpp[0] < 1 or drm_format_info_block_width() > 1 has to be
fixed first.
On the plus side, I finally got my proof-of-concept Atari DRM driver
working with fbcon on ARAnyM. Mapping /dev/fb0 from userspace doesn't
work (fbtest SEGVs while reading from the mapped frame buffer). I don't
know yet if this is a general issue without deferred I/O in v5.17-rc1,
or a bug in the m68k MM code...
So far it supports C8 only, but I hope to tackle C4 and monochrome soon.
Whether the end result will be usable on real hardware is still to be
seen, but at least I hope to get some DRM code written...
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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature