LWN: Comments on "Resurrecting fbdev"

Resurrecting fbdev

HelloWorld — Fri, 28 Jan 2022 03:23:45 +0000

> If this is the case, there is nothing Deller can do to make it worse.

Of course there is. He can make people think that using fbdev is a reasonable idea because, after all, it is being maintained now! Or he can delay the removal of that code.

This whole situation is very unfortunate. Just let it die already.

Resurrecting fbdev

ballombe — Sun, 23 Jan 2022 20:39:45 +0000

Everyone knew it was a regression when it was done. shift-page up is a documented user interface. The IOCTL is documented. consolation already existed. It is never too late to do the right thing.

Resurrecting fbdev

zdzichu — Sat, 22 Jan 2022 16:55:03 +0000

It's been years, isn't that too long to claim regression?

Resurrecting fbdev

tdz — Sat, 22 Jan 2022 16:24:22 +0000

Thanks a lot.

Resurrecting fbdev

ballombe — Sat, 22 Jan 2022 09:25:44 +0000

Is it what you want ?
https://bugs.debian.org/988039

Resurrecting fbdev

tdz — Sat, 22 Jan 2022 08:28:58 +0000

Hi, could you please link a bug report for this problem?

Resurrecting fbdev

bnorris — Fri, 21 Jan 2022 18:29:49 +0000

You mean something like this?

https://www.kernel.org/doc/html/latest/admin-guide/ramoop...

That's been upstream for quite a while, and it works just fine. Chrome OS uses it heavily for field crash logging. Despite its naming, it can be configured to dump logs to RAM even on non-crashes.

Resurrecting fbdev

geert — Fri, 21 Jan 2022 12:11:26 +0000

I wasn't aware of that. So this should be reported as as userspace regression.

Resurrecting fbdev

ballombe — Fri, 21 Jan 2022 11:51:28 +0000

I hope it will be restored. This breaks consolation

Resurrecting fbdev

geert — Fri, 21 Jan 2022 08:49:55 +0000

> fbcon scrollback rarely works

Fbcon scrollback was removed in v5.9 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...).

Resurrecting fbdev

blackwood — Thu, 20 Jan 2022 23:09:49 +0000

It stalled for a few years, but a few folks from rh and suse have picked up the pieces again. We have simpledrm now merged, which means firmware fbdev drivers (efifb, vesafb, ...) aren't needed anymore, and you can have a pure kms world.

Next step is to get some kernel console on top of drm landed, for (emergency) logging. This should probably wait for the remaining console_lock rework so that we don't have to maintain our own kthread for offloading.

At that point all the pieces are in places for distros to ditch CONFIG_VT and fbcon and use kmscon for non-graphical shell logins on the local machine. Apparently logind/seatd already can do all the vt switching without CONFIG_VT (since that's needed for all the additional seats anyway), so that part is covered.

It might all actually happen this decade!

Resurrecting fbdev

MrWim — Thu, 20 Jan 2022 21:42:26 +0000

> work in the face of unknown kernel corruption.

I quite like the scheme described here: https://apenwarr.ca/log/20190216 . The kmsg buffer is at a fixed location in memory, so you can write there which should be reliable even in the face of significant kernel memory corruption. On the next boot the kernel checks if there are valid messages there and preserves them so you can see what went wrong. It's beautiful in its simplicity.

The patches were posted upstream, but it never went anywhere.

https://lore.kernel.org/lkml/1331617001-20906-1-git-send-...

Resurrecting fbdev

josh — Thu, 20 Jan 2022 20:57:15 +0000

I agree; putting the simplest possible thing in kernel space and all the complexity into userspace seems like the right answer here. Keep a terminal up-to-date, and render it to a framebuffer based on a frame rate (e.g. vsync).

Resurrecting fbdev

flussence — Thu, 20 Jan 2022 19:08:19 +0000

Right now we have neither:

When things are working normally, the console's only function is as blinkenlights so people know their boot hasn't frozen. It's also a significant bottleneck as shown (restoring hwaccel would only hide this symptom) and as an interactive terminal it's pretty bad too. There's no reason to have "every frame a painting" here.

When things aren't working, the console is useless because it scrolls far too fast for an operator at the terminal to read it all (restoring hwaccel would only make this worse), and fbcon scrollback rarely works at the best of times so any important output that scrolls offscreen is lost. There are already half a dozen ways to get organic-readable boot output, this part doesn't need further fixing.

It's basically the atime thing all over again.

Resurrecting fbdev

JoeBuck — Thu, 20 Jan 2022 18:32:49 +0000

Or on a panic, do a switch to dumb mode and print raw, but this needs to work in the face of unknown kernel corruption.

Resurrecting fbdev

gnoutchd — Thu, 20 Jan 2022 18:22:10 +0000

Whatever became of kmscon? Putting the "smart" console in userspace sounds like a solution, no? Should people be thinking about converting hw-accelerated fbdev drivers into kmscon backends, or somesuch?

Resurrecting fbdev

ibukanov — Thu, 20 Jan 2022 16:22:46 +0000

If one needs absolutely reliable way to print kernel errors, then just output it to a serial port or log it over network if the former is not available. The modern graphics hardware is way too complex to allow for the dumbest frame buffer to be reliable. Probability of if not hardware bugs but at least quirks is just too high.

Resurrecting fbdev

daenzer — Thu, 20 Jan 2022 15:05:01 +0000

"The DRM subsystem does not have support for 2D acceleration" is not correct. The linked article is specifically about a generic 2D acceleration UAPI, which fbdev doesn't have either (because it's basically impossible to define a sensible one).

A DRM driver can however implement the same fbdev acceleration hooks as a native fbdev driver can, and some DRM drivers actually did. Many DRM drivers haven't done this because the HW is more complex than a traditional 2D accelerator and cannot safely be used under all circumstances where fbdev acceleration hooks can get called.

Resurrecting fbdev

Karellen — Thu, 20 Jan 2022 11:29:10 +0000

You can't really have it both ways, at least not without some solid effort by a pile of people.

I guess the answer would be two separate modules, fbcon_basic and fbcon_fast, and you pick which one you want at either kernel build time, or build both and pick at initrd creation time?

But I suppose that falls under "some solid effort by a pile of people".

Resurrecting fbdev

error27 — Thu, 20 Jan 2022 10:56:05 +0000

Huh... I know that patching fbdev is a waste of time, but sometimes code annoys me so much that I just fix it anyway. I just looked at my outbox and I discovered that *none* of my fbdev patches from 2021 were applied.

I sent four patches to fbdev in 2021. In one case, the original author fixed his bug before me so that's fine. In another case, my patch was Acked but not applied. And for the remaining two patches I was just ignored. There is no other subsystem right now that's as bad as that.

It's such a discouraging thing because newbies are like:

Step 1: Find an easy bug
Step 2: Fbdev hasn't applied bugfixes for years so it has the most obvious bugs
Step 3: Send a patch
Step 4: Wait for feedback before going further
Step 5: Die of old age

Resurrecting fbdev

ballombe — Thu, 20 Jan 2022 10:56:01 +0000

> The thing _is_ a root exploit pretty much end-to-end :-/

If this is the case, there is nothing Deller can do to make it worse.
Since KMS made all but impossible to use the VGA console, all systems are running fbdev now.
I for one, am happy there is a new maintainer that see fbdev as something else as a liability.

Resurrecting fbdev

shiftee — Thu, 20 Jan 2022 09:37:06 +0000

Easier to ask for forgiveness than permission

Resurrecting fbdev

blackwood — Thu, 20 Jan 2022 09:12:29 +0000

The problem with fbcon is that people want two things from it, which aren't very compatible:

Either a fast console because they don't want to run bloated X or something like that, or because boot times or whatever. Those people want the shadow buffered fbcon and redraw limiting. Because all the people capable of writing high performance graphics are busy hacking on wayland (not even X anymore), there's just not many folks who care enough to push the kernel console forward.

The others want the dumbest possible console which can be slow, but should try the hardest to get an oops to the screen when the kernel is on fire. In that case you do not want shadow buffering, and the dumber and more immediate the code is, the better. This also means the least amount of hw touching, so definitely no acceleration or anything.

You can't really have it both ways, at least not without some solid effort by a pile of people.

Resurrecting fbdev

blackwood — Thu, 20 Jan 2022 09:05:49 +0000

From drm side we do care a bit about fbdev, but it's extremely limited to just the core code, fbcon, and the handful of firmware drivers that run before drm drivers take over.

So yeah any driver patches for something like cirrusfb tend to get ingored. Run the drm/cirrus driver instead, if that blows up there will be people who take a look.

The thing _is_ a root exploit pretty much end-to-end :-/

Resurrecting fbdev

error27 — Thu, 20 Jan 2022 06:17:55 +0000

The fbdev subsystem has needed a maintainer for a years. It's a super frustrating subsystem because when you report bugs the attitude is "Yeah. Fbdev is a known root exploit so who cares if it crashes a bit?"

For example, here are some bugs I reported back in 2014.
https://marc.info/?l=kernel-janitors&m=13906030980688...

Here is the fix for that from last December but it still has not been applied. I asked George Kennedy to wait for a bit and resend it through Andrew Morton.
https://lkml.org/lkml/2021/12/7/1040

On the other hand, I really don't want the accelerated scrolling patch to be revived. The main problem with fbdev is all the crashing and the memory corruption bugs. Memory corruption bugs confuse syzbot so instead of showing up as one bug, it shows up as dozens of crazy bugs in random parts of the kernel. It's horrible and we spent a long time fixing it. Let's not go backwards.

Resurrecting fbdev

flussence — Thu, 20 Jan 2022 03:49:35 +0000

Making fbcon render asynchronously from a shadow buffer should be the top priority here. To demonstrate a point:

~ $ time find /usr/share
[~140k lines snipped]
# on a vt, backed by radeondrmfb and a very fast CPU
real 1m4.837s	user 0m0.128s	sys 0m31.975s

# xfce4-terminal, which according to actual science is one of the slowest X11 terms:
# https://lwn.net/Articles/751763/
real 0m0.873s	user 0m0.192s	sys 0m0.199s

A bare-bones fbcon is almost 75x slower than a (imho) somewhat bloated terminal emulator that happens to have a simple redraw-throttling optimisation - that's the kind of thing that leads to cargo-cult boot optimisation guides telling people to disable all kernel and init output to shave off a few centiseconds.