Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

On 2022-01-17 19:47, Sven Schnelle wrote:

quoted

 * 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.

(Most DRM drivers never bothered because the HW is more complex than traditional 2D accelerators, and can't safely be used under all circumstances where fbdev acceleration hooks could get called from. That's not an issue for a traditional 2D accelerator driver though)


-- 
Earthling Michel Dänzer            |                  https://redhat.com
Libre software enthusiast          |         Mesa and Xwayland developer