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

[Helge Deller <deller@gmx.de>]

Hi Thomas,

On 1/17/22 16:05, Thomas Zimmermann wrote:
> Hi
>
> Am 17.01.22 um 15:47 schrieb Helge Deller:
>> On 1/17/22 15:10, Geert Uytterhoeven wrote:
>> [...]
>>> 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.
>>
>>  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
>
>>
>> Helge
>>
>>
>>>>> 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
>>>
>>
>