On 1/17/22 16:03, Daniel Vetter wrote:

On Mon, Jan 17, 2022 at 3:48 PM Helge Deller [off-list ref] wrote:

quoted

On 1/17/22 15:10, Geert Uytterhoeven wrote:

quoted

Hi Thomas,

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

quoted

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.

quoted

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.

From this conversation it seems DRM completely lacks backwards compatibility,
including a missing 2D bitblt copy.
Isn't that all what's needed and then migrating existing drivers would
be easy ?

Not sure who you talked to, but we have drivers with fbdev bitblt
accel (well, in some cases had, because driver maintainers decided
it's just not worth it and ripped it out again or never merged it).
Also the other discussions about some low-bit formats is pretty much
just a question of extending a few enums and wiring through the fbdev
emulation layer.

No, you got me wrong.

I'm not talking about making other low-bit formats available to userspace.

I'm talking about running the framebuffer natively on a lower-bit format
and to speed up text emulation (fbcon) with help of on-chip 2D bitblt.
So, similiar as it was done in fbdev for non-DRM graphic cards before two
patches were applied and which disabled this speedup for *all* existing fbdev drivers:
b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next

Esp. the commit message of patch 39aead8373b3 completely
ignored the acceleration of the fbdev drivers.

Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
currently unaccelerated and bound to Truecolour modes only, which is probably
one of the main reasons why most fbdev drivers can't be ported to DRM...

Helge

So the things brought up in this thread thus far are
actually the fairly easy items, which should take at most a handful of
patches to rectify. There's much more nastier issues in fbdev, which
will take serious amounts of development time to fix.

Unfortunately in the past 5+ years absolutely no one stepped up with
actual patches, which is why fbdev was marked as orphaned in
MAINTAINERS.
-Daniel

quoted

Helge

quoted

quoted

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