linux-kernel - Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Jan 2022 11:44:25 +0100
From:   Helge Deller <deller@....de>
To:     Gerd Hoffmann <kraxel@...hat.com>
Cc:     Daniel Vetter <daniel@...ll.ch>,
        Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
        Sven Schnelle <svens@...ckframe.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        Javier Martinez Canillas <javierm@...hat.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

On 1/18/22 11:13, Helge Deller wrote:
> 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 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.
>
> I'd expect that that framework is provided by DRM developers if there is the 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, 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 ...
>
> For me it's Ok that the DRM drivers don't use 2d acceleration (as it is today
> 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 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.
>
> 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.

I've just looked through all patches in drivers/video which were tagged
with syzbot or syzkaller back to year 2005. The vast majority fixed the
reported issues on a higher level, e.g. when screen is to be resized,
or when font size is to be changed. The few ones which touched driver
code fixed a real driver bug, e.g. by adding a check.

NONE of those patches touched either the SCROLL_MOVE or the SCROLL_REDRAW case.
That means, I see no reason why SCROLL_MOVE had to be ripped-out and just
SCROLL_REDRAW had to be used instead, other than simply "it's not being
used by DRM, so let's pull it out".
The patches which removed SCROLL_MOVE support simply ignored the fact
that SCROLL_MOVE is still heavily used by fbdev (non-DRM).

I don't see a reason why the two patches which removed SCROLL_MOVE
shouldn't be reverted. Or what am I missing?

Helge