Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

Hi Thomas,

On Mon, Jan 17, 2022 at 2:51 PM Thomas Zimmermann [off-list ref] wrote:

Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven:

quoted

On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann [off-list ref] wrote:

quoted

quoted

b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be).
    I know of at least one driver which won't be able to support DRM....

Hmm?  I seriously doubt that.  There is always the option to use a
shadow framebuffer, then convert from standard drm formats to whatever
esoteric pixel format your hardware expects.

Been there, done that.  Have a look at the cirrus driver.  The physical
hardware was designed in the early 90-ies, almost 30 years ago.  These
days it exists in virtual form only (qemu emulates it).  Thanks to the
drm driver it runs wayland just fine even though it has a bunch of
constrains dictated by the hardware design.

The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888)
modes only.  The Cirrus fbdev driver also supports mochrome and 256
color modes.

There exist some DRM drivers that do support DRM_FORMAT_C8, but none of
the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}.  Using a shadow
frame buffer to convert from truecolor to 256 colors would be doable,
but would give bad results. And what about less colors?
Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as
the DRM core assumes in many places that a pixel is at least 1 byte,
and would crash otherwise (yes I tried).  Other modes needed are
DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome).

We export XRGB32 from each driver, because userspace expects it. But
that is not a hard requirement. Userspace can use any format. It's just
that no one seems to have any use cases so far, so no work has been
done. Think of XRGB32 as a fallback.

Using an XRGB32 intermediate would kill the user experience on old
machines, due to both increased memory usage and copy overhead.

Personally, I'd much appreciate if userspace would support more of the
native formats and not rely on XRGB32.

Supporting monochrome, 16 colors, and 256 colors would be nice.

quoted

This not only to support "old" hardware, but also modern small OLED
and e-ink displays.

There's a DRM driver for Repaper e-Ink displays. So it seems doable at
least.

Which uses an DRM_FORMAT_XRGB8888 intermediate, and
drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed()
to convert from truecolor to monochrome.  I guess that would work,
as this is a slow e-ink display.  Have fun as a text console ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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