Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
From: Ilia Mirkin
Date: Mon Jan 17 2022 - 16:56:03 EST
On Mon, Jan 17, 2022 at 2:47 PM Helge Deller <deller@xxxxxx> wrote:
>
> On 1/17/22 17:21, Helge Deller wrote:
> > On 1/17/22 16:58, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 17.01.22 um 16:42 schrieb Helge Deller:
> >>> [...]
> >>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines,
> >>>>> either when run on native hardware or in an emulator.
> >>>>> d) not break DRM development
> >>>>>
> >>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to
> >>>>> understand where the actual problems were and what's necessary to fix them.
> >>>>>
> >>>>> Helge
> >>>>>
> >>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@xxxxxx
> >>
> >> Seems like few people read linux-fbdev these days.
> >> I suggest to partly revert the patch to the point were performance
> >> gets better again.
> > Yes, *please*!
> > That would solve my biggest concern.
> >
> > As far as I can see that's only 2 commits to be reverted:
> > b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"
> > 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next
> >
> > I think both were not related to any 0-day bug reports (but again, I might be wrong).
>
> I did some more checking...
>
> Both patches are not related to DRM, since no DRM driver sets the
> FBINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags.
These used to be set by, at least, nouveau (which is a drm driver).
And yeah, console responsiveness is _way_ worse without that. People
keep pushing the messaging that it's the same speed to do it as
memcpy, but that's just not the case in my experience, on a pretty
bog-standard x86 desktop. The support got dumped, and it felt pretty
clear from the messaging at the time, "too bad". Would love to see it
come back.
Cheers,
-ilia