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. > > 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 ... > > 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. take care, Gerd
