From: Helge Deller <deller@gmx.de>
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>
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Date: Tue, 18 Jan 2022 11:44:25 +0100 [thread overview]
Message-ID: <c2526855-233e-c785-ddca-e89c79ca9676@gmx.de> (raw)
In-Reply-To: <ffef1042-e1af-d5b5-b140-ae24fcc1855b@gmx.de>
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
next prev parent reply other threads:[~2022-01-18 10:45 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-14 18:11 [PATCH] MAINTAINERS: Add Helge as fbdev maintainer Helge Deller
2022-01-14 18:31 ` Geert Uytterhoeven
2022-01-17 9:48 ` Daniel Vetter
2022-01-17 10:02 ` Daniel Vetter
2022-01-17 10:19 ` Javier Martinez Canillas
2022-01-17 10:49 ` Jani Nikula
2022-01-17 10:57 ` Helge Deller
2022-01-17 12:15 ` Helge Deller
2022-01-17 12:57 ` Gerd Hoffmann
2022-01-17 13:29 ` Geert Uytterhoeven
2022-01-17 13:51 ` Thomas Zimmermann
2022-01-17 14:10 ` Geert Uytterhoeven
2022-01-17 14:47 ` Helge Deller
2022-01-17 15:03 ` Daniel Vetter
2022-01-17 20:17 ` Helge Deller
2022-01-18 6:29 ` Gerd Hoffmann
2022-01-18 8:10 ` Geert Uytterhoeven
2022-01-18 11:44 ` Daniel Vetter
2022-01-18 14:23 ` Thomas Zimmermann
2022-01-18 14:39 ` Simon Ser
2022-01-20 12:50 ` Gerd Hoffmann
2022-01-21 8:55 ` Daniel Vetter
2022-01-24 18:38 ` Geert Uytterhoeven
2022-01-24 18:50 ` Daniel Vetter
2022-01-24 19:05 ` Thomas Zimmermann
2022-01-18 8:20 ` Helge Deller
2022-01-18 9:16 ` Gerd Hoffmann
2022-01-18 10:13 ` Helge Deller
2022-01-18 10:44 ` Helge Deller [this message]
2022-01-18 12:48 ` Gerd Hoffmann
2022-01-17 15:05 ` Thomas Zimmermann
2022-01-17 16:05 ` Helge Deller
2022-01-17 14:53 ` Thomas Zimmermann
2022-01-18 6:11 ` Gerd Hoffmann
2022-01-18 8:09 ` Helge Deller
2022-01-17 15:00 ` Daniel Vetter
2022-01-17 15:42 ` Helge Deller
2022-01-17 15:56 ` Daniel Vetter
2022-01-17 15:58 ` Thomas Zimmermann
2022-01-17 16:21 ` Helge Deller
2022-01-17 16:38 ` Daniel Vetter
2022-01-17 17:19 ` Helge Deller
2022-01-17 19:45 ` Helge Deller
2022-01-17 21:55 ` Ilia Mirkin
2022-01-18 11:14 ` Daniel Vetter
2022-01-18 14:14 ` Thomas Zimmermann
2022-01-17 21:40 ` Jani Nikula
2022-01-17 21:44 ` Helge Deller
2022-01-18 8:38 ` Jani Nikula
2022-01-18 8:41 ` Geert Uytterhoeven
2022-01-18 11:41 ` Daniel Vetter
2022-01-18 12:11 ` Simon Ser
2022-01-18 8:54 ` Helge Deller
2022-01-18 9:33 ` Javier Martinez Canillas
2022-01-18 9:45 ` Geert Uytterhoeven
2022-01-18 11:18 ` Daniel Vetter
2022-01-18 11:42 ` Helge Deller
2022-01-18 8:41 ` Helge Deller
2022-01-18 9:12 ` Helge Deller
2022-01-17 11:16 ` Thomas Zimmermann
2022-01-17 11:33 ` Helge Deller
2022-01-17 12:13 ` Thomas Zimmermann
2022-01-17 18:47 ` Sven Schnelle
2022-01-18 8:33 ` Pekka Paalanen
2022-01-18 9:53 ` Gerd Hoffmann
2022-01-18 11:22 ` Daniel Vetter
2022-01-18 12:07 ` Gerd Hoffmann
2022-01-19 8:39 ` Pekka Paalanen
2022-01-20 9:06 ` Geert Uytterhoeven
2022-01-20 11:32 ` Daniel Vetter
2022-01-20 12:13 ` Geert Uytterhoeven
2022-01-20 12:33 ` Daniel Vetter
2022-01-20 12:46 ` Geert Uytterhoeven
2022-01-24 18:50 ` Geert Uytterhoeven
2022-01-24 19:37 ` Daniel Vetter
2022-01-20 11:51 ` Gerd Hoffmann
2022-01-18 8:58 ` Michel Dänzer
2022-01-18 10:05 ` Sven Schnelle
2022-01-18 14:06 ` Thomas Zimmermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c2526855-233e-c785-ddca-e89c79ca9676@gmx.de \
--to=deller@gmx.de \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=geert@linux-m68k.org \
--cc=javierm@redhat.com \
--cc=kraxel@redhat.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=svens@stackframe.org \
--cc=torvalds@linux-foundation.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).