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
