Hi Michel, Michel Dänzer <michel.daenzer@xxxxxxxxxxx> writes: > On 2022-01-17 19:47, Sven Schnelle wrote: >> >>> * 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. > > A DRM driver can implement the same fbdev acceleration hooks as an fbdev driver. But i guess i can still only use the DRM_FORMAT_* encodings with that? What i need is a pixel bitmap with separate FG/BG colors. Is that possible? /Sven