Message-ID: <87bl0amc6s.fsf@x1.stackframe.org>
Date:   Mon, 17 Jan 2022 19:47:39 +0100
From:   Sven Schnelle <svens@...ckframe.org>
To:     Thomas Zimmermann <tzimmermann@...e.de>
Cc:     Helge Deller <deller@....de>, linux-fbdev@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

Hi Thomas,

Thomas Zimmermann <tzimmermann@...e.de> 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@....de>
>
> 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@x1.stackframe.org/T/#m57cdea83608fc78bfc6c2e76eb037bf82017b302
[2] https://lore.kernel.org/all/87ee7qvcc7.fsf@x1.stackframe.org/T/#m46a52815036a958f6a11d2f3f62e1340a09bd981

Powered by blists - more mailing lists