Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <ffef1042-e1af-d5b5-b140-ae24fcc1855b@gmx.de>
Date:   Tue, 18 Jan 2022 11:13:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Content-Language: en-US
To:     Gerd Hoffmann <kraxel@redhat.com>
Cc:     Daniel Vetter <daniel@ffwll.ch>,
        Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
        Sven Schnelle <svens@stackframe.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        DRI Development <dri-devel@lists.freedesktop.org>,
        Javier Martinez Canillas <javierm@redhat.com>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Linus Torvalds <torvalds@linux-foundation.org>
References: <c80ed72c-2eb4-16dd-a7ad-57e9dde59ba1@gmx.de>
 <20220117125716.yjwxsze35j2ndn2i@sirius.home.kraxel.org>
 <CAMuHMdW=Zpp2mHbrBx7i0WN8PqY3XpK5qpyAyYxgf9n88edpug@mail.gmail.com>
 <70530b62-7b3f-db88-7f1a-f89b824e5825@suse.de>
 <CAMuHMdW5M=zEuGEnQQc3JytDhoxCKRiq0QFw+HOPp0YMORzidw@mail.gmail.com>
 <57d276d3-aa12-fa40-6f90-dc19ef393679@gmx.de>
 <CAKMK7uE7jnTtetB5ovGeyPxHq4ymhbWmQXWmSVw-V1vP3iNAKQ@mail.gmail.com>
 <b32ffceb-ea90-3d26-f20e-29ae21c68fcf@gmx.de>
 <20220118062947.6kfuam6ah63z5mmn@sirius.home.kraxel.org>
 <ebe9c076-e2a9-0cb7-eb6a-ae71c075975e@gmx.de>
 <20220118091615.3ih5n7vhd6tgmnku@sirius.home.kraxel.org>
From:   Helge Deller <deller@gmx.de>
In-Reply-To: <20220118091615.3ih5n7vhd6tgmnku@sirius.home.kraxel.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On 1/18/22 10:16, Gerd Hoffmann wrote:
> 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 framebu=
ffer
>> 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.

I'd expect that that framework is provided by DRM developers if there is t=
he wish
to get rid of old fbdev and transition existing drivers over to use DRM.

>>> Acceleration is harder.  The scroll acceleration had issues nobody
>>> addressed for years, and on modern hardware it is simply not used, whi=
ch
>>> 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 ...

For me it's Ok that the DRM drivers don't use 2d acceleration (as it is to=
day
with the arguments mentioned multiple times).
But the patches broke existing fbdev acceleration which is available by
the fbdev drivers. That's a big regression from point of fbdev.

>>> Bringing it back is much more work than just reverting the commits rem=
oving it.
>>
>> Reverting those commits have no effect on DRM's usage of fbcon.
>> But reverting those commits bring back scroll acceleration for all othe=
rs.
>> 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.

That's sad.
Nevertheless I wonder if the changes which were apparently done for
the SCROLL_REDRAW case (on the higher level?) didn't also fixed the issues
for SCROLL_MOVE.

Helge