[PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Gerd Hoffmann]

On Tue, Jan 18, 2022 at 09:20:43AM +0100, Helge Deller wrote:
> On 1/18/22 07:29, Gerd Hoffmann wrote:
> >> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is
> >> currently unaccelerated and bound to Truecolour modes only,
> >
> > Yes.  Adding support for formats beside argb8888 to the drm fbcon
> > emulation shouldn't be that much of a problem though.
> 
> Really? Assuming a graphic card which runs with only 256 colors framebuffer
> is easily supported by DRM, and you can use fbcon without using lots of memcpy()?

Driver: programming a fixed color cube palette, then use RGB332.

fbcon/fbdev emulation: RGB332 support must be added I think.  But both
argb888 and rgb565 are supported today, so it should not be hard to find
the places where you have to add some code to handle RGB332 too.

> > Acceleration is harder.  The scroll acceleration had issues nobody
> > addressed for years, and on modern hardware it is simply not used, which
> > is probably the reason nobody stepped up fixing things and it ended up
> > being dropped.
> 
> The DRM layer doesn't use scroll acceleration.
> More than 30 other existing fbdev drivers use it.

Yes.  The world shifted from 2d acceleration to 3d acceleration.  Modern
hardware simply has no classic blitter any more.  Which is a problem
when it comes to keeping scroll acceleration alive, it is already a very
niche use case and it will only become worse ...

> > Bringing it back is much more work than just reverting the commits removing it.
> 
> Reverting those commits have no effect on DRM's usage of fbcon.
> But reverting those commits bring back scroll acceleration for all others.
> I'm trying to find out which patches did apparently fixed such issues
> for the REDRAW case. If you have a pointer it would be helpful.

IIRC the code had a bunch of races and syzkaller flagged problems.
I didn't follow very closely though.

take care,
  Gerd