Resurrecting fbdev
Resurrecting fbdev
Posted Jan 20, 2022 9:12 UTC (Thu) by blackwood (guest, #44174)In reply to: Resurrecting fbdev by flussence
Parent article: Resurrecting fbdev
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.
Posted Jan 20, 2022 11:29 UTC (Thu)
by Karellen (subscriber, #67644)
[Link] (3 responses)
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".
Posted Jan 20, 2022 18:32 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (2 responses)
Posted Jan 20, 2022 21:42 UTC (Thu)
by MrWim (subscriber, #47432)
[Link] (1 responses)
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-...
Posted Jan 21, 2022 18:29 UTC (Fri)
by bnorris (subscriber, #92090)
[Link]
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.
Posted Jan 20, 2022 16:22 UTC (Thu)
by ibukanov (subscriber, #3942)
[Link]
Posted Jan 20, 2022 18:22 UTC (Thu)
by gnoutchd (guest, #121472)
[Link] (2 responses)
Posted Jan 20, 2022 20:57 UTC (Thu)
by josh (subscriber, #17465)
[Link] (1 responses)
Posted Jan 20, 2022 23:09 UTC (Thu)
by blackwood (guest, #44174)
[Link]
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!
Posted Jan 20, 2022 19:08 UTC (Thu)
by flussence (guest, #85566)
[Link] (8 responses)
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.
Posted Jan 21, 2022 8:49 UTC (Fri)
by geert (subscriber, #98403)
[Link] (7 responses)
Fbcon scrollback was removed in v5.9 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...).
Posted Jan 21, 2022 11:51 UTC (Fri)
by ballombe (subscriber, #9523)
[Link] (6 responses)
Posted Jan 21, 2022 12:11 UTC (Fri)
by geert (subscriber, #98403)
[Link] (2 responses)
Posted Jan 22, 2022 16:55 UTC (Sat)
by zdzichu (guest, #17118)
[Link] (1 responses)
Posted Jan 23, 2022 20:39 UTC (Sun)
by ballombe (subscriber, #9523)
[Link]
Posted Jan 22, 2022 8:28 UTC (Sat)
by tdz (subscriber, #58733)
[Link] (2 responses)
Resurrecting fbdev
You can't really have it both ways, at least not without some solid effort by a pile of people.
Resurrecting fbdev
Resurrecting fbdev
Resurrecting fbdev
Resurrecting fbdev
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
Resurrecting fbdev
Resurrecting fbdev
Resurrecting fbdev
Resurrecting fbdev
I hope it will be restored. This breaks consolation
Resurrecting fbdev
Resurrecting fbdev
Resurrecting fbdev
Resurrecting fbdev
Resurrecting fbdev