Hi Thomas, Thomas Zimmermann <tzimmermann@xxxxxxx> writes: > Hi > > Am 14.01.22 um 19:11 schrieb Helge Deller: >> The fbdev layer is orphaned, but seems to need some care. >> So I'd like to step up as new maintainer. >> Signed-off-by: Helge Deller <deller@xxxxxx> > > First of all, thank you for stepping up to maintain the fbdev > codebase. It really needs someone actively looking after it. > > And now comes the BUT. > > I want to second everything said by Danial and Javier. In addition to > purely organizational topics (trees, PRs, etc), there are a number of > inherit problems with fbdev. > > * It's 90s technology. Neither does it fit today's userspace, not > hardware. If you have more than just the most trivial of graphical > output fbdev isn't for you. > > * There's no new development in fbdev and there are no new > drivers. Everyone works on DRM, which is better in most > regards. The consequence is that userspace is slowly loosing the > ability to use fbdev. That might be caused by the fact that no new drivers are accepted for fbdev. I wrote a driver for the HP Visualize FX5/10 cards end of last year which was rejected for inclusion into fbdev[1]. Based on your recommendation i re-wrote the whole thing in DRM. This works but has several drawbacks: - no modesetting. With fbdev, i can nicely switch resolutions with fbset. That doesn't work, and i've been told that this is not supported[2] - It is *much* slower than fbset with hardware blitting. I would have to dig out the numbers, but it's in the ratio of 1:15. The nice thing with fbdev blitting is that i get an array of pixels and the foreground/background colors all of these these pixels should have. With the help of the hardware blitting, i can write 32 pixels at once with every 32-bit transfer. With DRM, the closest i could find was DRM_FORMAT_C8, which means one byte per pixel. So i can put 4 pixels into one 32-bit transfer. fbdev also clears the lines with hardware blitting, which is much faster than clearing it with memcpy. Based on your recommendation i also verified that pci coalescing is enabled. These numbers are with DRM's unnatural scrolling behaviour - it seems to scroll several (text)lines at once if it takes to much time. I guess if DRM would scroll line by line it would be even slower. If DRM would add those things - hardware clearing of memory regions, hw blitting for text with a FG/BG color and modesetting i wouldn't care about fbdev at all. But right now, it's working way faster for me. I also tested the speed on my Thinkpad X1 with Intel graphics, and there a dmesg with 919 lines one the text console took about 2s to display. In x11, i measure 22ms. This might be unfair because encoding might be different, but i cannot confirm the 'memcpy' is faster than hardware blitting' point. I think if that would be the case, no-one would care about 2D acceleration. Don't get me wrong, i'm not saying there's no reason for DRM. I fully understand why it exists and think it's a good way to go. But for system where a (fast) local console is required without X11, fbdev might be the better choice at the moment. Regards Sven [1] https://lore.kernel.org/all/87ee7qvcc7.fsf@xxxxxxxxxxxxxxxxx/T/#m57cdea83608fc78bfc6c2e76eb037bf82017b302 [2] https://lore.kernel.org/all/87ee7qvcc7.fsf@xxxxxxxxxxxxxxxxx/T/#m46a52815036a958f6a11d2f3f62e1340a09bd981
