Hi Thomas,

On 1/17/22 16:05, Thomas Zimmermann wrote:

Hi

Am 17.01.22 um 15:47 schrieb Helge Deller:

quoted

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

quoted

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 ?

What exactly do you mean by 'backwards compatibility'?

DRM to provide possibility to run (in at least a few) of the bitmap formats
mentioned above.

The driver API is different, of course.

Sure.
I would think of a defined set how to activate a special graphics output.
And a function to do on-screen 2D bitblt to move contents (for usage of
fbcon emulation).

My conversion helpers can provide a starting point to move fbdev code
into DRM drivers.

I need to look into this.

For fbdev 2d-bitblt ioctls,

I'm not talking about 2d bitblt "IOCTLS". I'm talking about fbcon utilizing
2D graphic card bitblt to move on-screen contents to speed up a text console.
E.g. text upwards scrolling.

you can add them to DRM drivers and set
up DRM's fbdev emulation accordingly. Some DRM drivers do/did this.

To my knowledge, so far there's not been a use case where that
provides a benefit over simple memcpy.

It's a huge difference on older machines with slower busses for example.
So, for text console emulation, moving windows ... it's important.

For fast 2d blitting from userspace, you should read Daniel's comment
at [1]. tl;dr: a generic solution is non-trivial.

Probably. I think fbdev doesn't provide that functionality either today
(at least I think so) - so that's probably not a focus (and not relevant
regading the "backwards compatibility" I mentioned).

Helge

Best regards
Thomas

[1] https://blog.ffwll.ch/2018/08/no-2d-in-drm.html

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