From: Sven Schnelle <svens@stackframe.org>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Helge Deller <deller@gmx.de>,
linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Date: Mon, 17 Jan 2022 19:47:39 +0100 [thread overview]
Message-ID: <87bl0amc6s.fsf@x1.stackframe.org> (raw)
In-Reply-To: <c48ad8ae-aea5-43fa-882f-dccb90dde9a4@suse.de> (Thomas Zimmermann's message of "Mon, 17 Jan 2022 12:16:22 +0100")
Hi Thomas,
Thomas Zimmermann <tzimmermann@suse.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@gmx.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
next prev parent reply other threads:[~2022-01-17 19:33 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-14 18:11 [PATCH] MAINTAINERS: Add Helge as fbdev maintainer Helge Deller
2022-01-14 18:31 ` Geert Uytterhoeven
2022-01-17 9:48 ` Daniel Vetter
2022-01-17 10:02 ` Daniel Vetter
2022-01-17 10:19 ` Javier Martinez Canillas
2022-01-17 10:49 ` Jani Nikula
2022-01-17 10:57 ` Helge Deller
2022-01-17 12:15 ` Helge Deller
2022-01-17 12:57 ` Gerd Hoffmann
2022-01-17 13:29 ` Geert Uytterhoeven
2022-01-17 13:51 ` Thomas Zimmermann
2022-01-17 14:10 ` Geert Uytterhoeven
2022-01-17 14:47 ` Helge Deller
2022-01-17 15:03 ` Daniel Vetter
2022-01-17 20:17 ` Helge Deller
2022-01-18 6:29 ` Gerd Hoffmann
2022-01-18 8:10 ` Geert Uytterhoeven
2022-01-18 11:44 ` Daniel Vetter
2022-01-18 14:23 ` Thomas Zimmermann
2022-01-18 14:39 ` Simon Ser
2022-01-20 12:50 ` Gerd Hoffmann
2022-01-21 8:55 ` Daniel Vetter
2022-01-24 18:38 ` Geert Uytterhoeven
2022-01-24 18:50 ` Daniel Vetter
2022-01-24 19:05 ` Thomas Zimmermann
2022-01-18 8:20 ` Helge Deller
2022-01-18 9:16 ` Gerd Hoffmann
2022-01-18 10:13 ` Helge Deller
2022-01-18 10:44 ` Helge Deller
2022-01-18 12:48 ` Gerd Hoffmann
2022-01-17 15:05 ` Thomas Zimmermann
2022-01-17 16:05 ` Helge Deller
2022-01-17 14:53 ` Thomas Zimmermann
2022-01-18 6:11 ` Gerd Hoffmann
2022-01-18 8:09 ` Helge Deller
2022-01-17 15:00 ` Daniel Vetter
2022-01-17 15:42 ` Helge Deller
2022-01-17 15:56 ` Daniel Vetter
2022-01-17 15:58 ` Thomas Zimmermann
2022-01-17 16:21 ` Helge Deller
2022-01-17 16:38 ` Daniel Vetter
2022-01-17 17:19 ` Helge Deller
2022-01-17 19:45 ` Helge Deller
2022-01-17 21:55 ` Ilia Mirkin
2022-01-18 11:14 ` Daniel Vetter
2022-01-18 14:14 ` Thomas Zimmermann
2022-01-17 21:40 ` Jani Nikula
2022-01-17 21:44 ` Helge Deller
2022-01-18 8:38 ` Jani Nikula
2022-01-18 8:41 ` Geert Uytterhoeven
2022-01-18 11:41 ` Daniel Vetter
2022-01-18 12:11 ` Simon Ser
2022-01-18 8:54 ` Helge Deller
2022-01-18 9:33 ` Javier Martinez Canillas
2022-01-18 9:45 ` Geert Uytterhoeven
2022-01-18 11:18 ` Daniel Vetter
2022-01-18 11:42 ` Helge Deller
2022-01-18 8:41 ` Helge Deller
2022-01-18 9:12 ` Helge Deller
2022-01-17 11:16 ` Thomas Zimmermann
2022-01-17 11:33 ` Helge Deller
2022-01-17 12:13 ` Thomas Zimmermann
2022-01-17 18:47 ` Sven Schnelle [this message]
2022-01-18 8:33 ` Pekka Paalanen
2022-01-18 9:53 ` Gerd Hoffmann
2022-01-18 11:22 ` Daniel Vetter
2022-01-18 12:07 ` Gerd Hoffmann
2022-01-19 8:39 ` Pekka Paalanen
2022-01-20 9:06 ` Geert Uytterhoeven
2022-01-20 11:32 ` Daniel Vetter
2022-01-20 12:13 ` Geert Uytterhoeven
2022-01-20 12:33 ` Daniel Vetter
2022-01-20 12:46 ` Geert Uytterhoeven
2022-01-24 18:50 ` Geert Uytterhoeven
2022-01-24 19:37 ` Daniel Vetter
2022-01-20 11:51 ` Gerd Hoffmann
2022-01-18 8:58 ` Michel Dänzer
2022-01-18 10:05 ` Sven Schnelle
2022-01-18 14:06 ` Thomas Zimmermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bl0amc6s.fsf@x1.stackframe.org \
--to=svens@stackframe.org \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).