Revival of the Linux Framebuffer & DirectFB

pungentweasel · 2022-12-12 17:24:35

I've lately become intrigued by the Linux Framebuffer as a graphics backend. There is a strong push to move away from the classic Linux framebuffer and towards more modern technologies, but there's at least one effort to preserve and advance the use of the LFB.

This is a super interesting project, worthy of some attention. I thought some of you might be interested. Here are a few links:

https://higfxback.github.io/
https://directfb2.github.io/ & https://github.com/directfb2/DirectFB2

He's given a couple talks at FOSDEM about his work:

FB: https://archive.fosdem.org/2020/schedule/event/fbdev/
DirectFB: https://archive.fosdem.org/2022/schedule/event/directfb/

Last edited by pungentweasel (2022-12-15 22:03:14)

Head_on_a_Stick · 2022-12-13 12:25:08

Wayland compositors access the graphics hardware directly using KMS. What advantage does DirectFB2 offer over that? Seems like an unnecessary added layer for the current Linux graphics stack. Apologies if I am misunderstanding the protocol, I'm not an expert.

Camtaf · 2022-12-13 15:02:52

I think frame buffers allow graphics in the (virtual) terminals, don't they(?).

Head_on_a_Stick · 2022-12-13 16:16:56

Well yes but Wayland offers similarly direct access to the video hardware via KVM.

Or to put in another way: why is running graphics from a console screen useful?

Camtaf · 2022-12-13 17:49:17

Yes, if I remember right, you could play video with the likes of mplayer, & maybe have graphics in a text type web browser in a command line installation - it's been a long time since, but I'm pretty sure I used to watch videos.

trinidad · 2022-12-13 18:58:36

Bohdi Linux with Moksha/Enlightenment could do it (video in the term) if I remember correctly.

TC

steve_v · 2022-12-14 04:17:01

Camtaf wrote:

Yes, if I remember right, you could play video with the likes of mplayer, & maybe have graphics in a text type web browser in a command line installation - it's been a long time since, but I'm pretty sure I used to watch videos.

I used to do this as well, and further back with svgalib... Both on hardware far too slow to play video from X, and with too little memory for a full DE.

With links and directfb, you can run a graphics capable web browser in a TTY as well... That means a browser capable of accessing the current-day internet for machines with <128MB RAM.
Now we just need, say, a i386 Debian/Devuan "revival" as well. Perfectly Good Pentium deprecation stupidity and all that.

Head_on_a_Stick wrote:

why is running graphics from a console screen useful?

Because you can, windows are bloat, and who needs a window manager anyway when you have 12 TTYs?
Or maybe, because needing to run a full-blown WM and compositor on something with no use for windowing or a GUI (e.g. a "digital picture frame" type device or monitor for a video stream) just to get basic framebuffer video output is patently silly?

Last edited by steve_v (2022-12-14 04:22:06)

aluma · 2022-12-14 10:11:26

If we divide computers into workstations and servers (including media servers), then everything will fall into place and the framebuffer will find its place, as I understand it.

And there have already been attempts, with the help of a stripped-down Linux, to make a netbook, limiting the size of the memory and the performance of the processor. Nothing good happened.

Head_on_a_Stick · 2022-12-14 11:50:48

steve_v wrote:

With links and directfb, you can run a graphics capable web browser in a TTY as well... That means a browser capable of accessing the current-day internet for machines with <128MB RAM.

lol

Or just install an operating system that isn't ridiculously bloated by default:

^ oh look, it's OpenBSD running X with Dillo and memory to spare in a VM assigned 128MiB. Nice.

steve_v wrote:

Or maybe, because needing to run a full-blown WM and compositor on something with no use for windowing or a GUI (e.g. a "digital picture frame" type device or monitor for a video stream) just to get basic framebuffer video output is patently silly?

So you haven't read the DirectFB specifications then?

directfb2.github.io wrote:

Components running on DirectFB graphics backend are based on libdirectfb.so library. Compositing windowing system is performed by the default libdirectfb.so window manager module with libdirectfbwm_default.so plugin.

It's using both a compositor and a window manager...

As I said, Wayland is simpler, more direct and more widely adopted with better support.

aluma · 2022-12-14 13:46:50

oh look, it's OpenBSD running X with Dillo and memory to spare in a VM assigned 128MiB. Nice.

Here are the requirements for Trinity - "Trinity desktop - 300MHz CPU / 256MB RAM / 3GB disk".
https://q4os.org/downloads1.html
Yes, it will work, but any program you download will be, figuratively speaking, in swap. Who today has the patience for such feats?

pungentweasel · 2022-12-14 15:23:22

Head_on_a_Stick wrote:

directfb2.github.io wrote:
Components running on DirectFB graphics backend are based on libdirectfb.so library. Compositing windowing system is performed by the default libdirectfb.so window manager module with libdirectfbwm_default.so plugin.
It's using both a compositor and a window manager...

To be clear, it's only a plugin. Wayland might be the "latest and greatest", but there's something fun about using older, much simpler tech that's built directly into the kernel and compatible on any and all hardware you throw at it

One practical example of the usefulness of the raw framebuffer: My laptop has AMD graphics.. and I can use the open source amdgpu driver. That's great... except, in order for the kernel to load amdgpu, it requires closed-source non-free firmware and there's no way to know what that code is doing. Not so great.

steve_v wrote:

Because you can, windows are bloat, and who needs a window manager anyway when you have 12 TTYs?
Or maybe, because needing to run a full-blown WM and compositor on something with no use for windowing or a GUI (e.g. a "digital picture frame" type device or monitor for a video stream) just to get basic framebuffer video output is patently silly?

Exactly 👍 Running a complete system directly from TTYs is a completely viable option, and probably by far the most resource-friendly option available. Check out the Awesome TUIs project

Camtaf wrote:

Yes, if I remember right, you could play video with the likes of mplayer, & maybe have graphics in a text type web browser in a command line installation - it's been a long time since, but I'm pretty sure I used to watch videos.

Yep.. you can give it a try now.. it works surprisingly well and runs very smooth. mplayer -vo fbdev2 file.mp4

If you compile sdl2 with fbdev support, and run mpv media player with --vo=sdl, you can use the invidtui software for a full-featured Youtube client in the console using Invidious instances, running entirely from the framebuffer. Without fbdev it will use kms/drm, which also works well, but requires the graphics driver which likely requires non-free firmware.

Last edited by pungentweasel (2022-12-14 16:25:25)

steve_v · 2022-12-15 04:06:22

Head_on_a_Stick wrote:

It's using both a compositor and a window manager...

Sure. Unless everything has changed since I last used it, there's no requirement to actually use those functions though.

Head_on_a_Stick wrote:

As I said, Wayland is simpler, more direct and more widely adopted with better support.

You can try and sell me on Wayland all you like, but until it does all the things X can do I really have very little use for it.

A simple framebuffer for the TTY? that I'll use, if infrequently. A rich networked display server for more complex GUI environments? cool.
Something in-between, whose primary targets appear to be "high refresh rate" (aka gaming woo) and better support for "devices"... Yeah, I don't really need that at all.

If Wayland was X+, I'd be keen. Right now it appears to be X- with a number of missing features, and were I to switch to it I'd end up running something in xwayland ~80% of the time anyway.
Why is replacing X with something that can't do all the things X can useful?

Head_on_a_Stick · 2022-12-15 10:44:38

aluma wrote:

Here are the requirements for Trinity - "Trinity desktop - 300MHz CPU / 256MB RAM / 3GB disk"

Dear me, what a bloat monster

pungentweasel wrote:

One practical example of the usefulness of the raw framebuffer: My laptop has AMD graphics.. and I can use the open source amdgpu driver. That's great... except, in order for the kernel to load amdgpu, it requires closed-source non-free firmware and there's no way to know what that code is doing. Not so great.

So block the amdgpu module and use VESA in X instead then.

pungentweasel wrote:

mplayer -vo fbdev2 file.mp4

I tried this with https://upload.wikimedia.org/wikipedia/commons/b/b4/Tearing-test.webm and the tearing in the console is absolutely atrocious, completely unbearable. Under Wayland (sway) that same video running in the same player is perfectly smooth with no tearing (or lag) whatsoever. This is with amdgpu and an AMD Cezanne iGPU. And the non-free firmware :-)

EDIT: and I couldn't get the console output to work without adding my user to the video group, which is completely unacceptable.

steve_v wrote:

there's no requirement to actually use those functions though

Just as under the Wayland protocol then.

steve_v wrote:

whose primary targets appear to be "high refresh rate" (aka gaming woo)

As a gamer I can happily confirm this. Linux is now a better platform for gaming than Windows, which pleases me much more than these shiny new toys irritate you.

Last edited by Head_on_a_Stick (2022-12-15 11:04:11)

aluma · 2022-12-15 12:51:38

Dear me, what a bloat monster tongue

It was a wonderful attempt to create a truly complete windowing environment.
A single graphic library, a complete set of GUIs for system maintenance.
Even today, this works, although, unfortunately, Konqueror can only be called a web browser.
And by downloading a full-fledged, the same Firefox, you can forget about the minimum memory for DE.

pungentweasel · 2022-12-15 21:52:50

Head_on_a_Stick wrote:

Dear me, what a bloat monster tongue
...
As a gamer I can happily confirm this. Linux is now a better platform for gaming than Windows, which pleases me much more than these shiny new toys irritate you.

Very childish. If you don't care about the linux framebuffer, then I'm not sure why you're even involving yourself in a conversation about it.

Nobody is suggesting that old framebuffer tech is in any way better than modern graphics backends... nor is anyone expecting a flawless experience, much less trying to "game" on the framebuffer. It's old tech and it's fun to mess around with, and it's good to see that someone is doing the work to resuscitate and improve it. To some of us, this is what makes linux fun to use and tinker with. If that's not you, then that's fine.

Last edited by pungentweasel (2022-12-15 22:13:11)

Head_on_a_Stick · 2022-12-15 22:48:42

pungentweasel wrote:

Very childish. If you don't care about the linux framebuffer, then I'm not sure why you're even involving yourself in a conversation about it.

Just trollin d00d.

pungentweasel wrote:

It's old tech and it's fun to mess around with, and it's good to see that someone is doing the work to resuscitate and improve it

+1. Nice toy. Thanks for sharing.

The officially official Devuan Forum!

#1 2022-12-12 17:24:35

Revival of the Linux Framebuffer & DirectFB

#2 2022-12-13 12:25:08

Re: Revival of the Linux Framebuffer & DirectFB

#3 2022-12-13 15:02:52

Re: Revival of the Linux Framebuffer & DirectFB

#4 2022-12-13 16:16:56

Re: Revival of the Linux Framebuffer & DirectFB

#5 2022-12-13 17:49:17

Re: Revival of the Linux Framebuffer & DirectFB

#6 2022-12-13 18:58:36

Re: Revival of the Linux Framebuffer & DirectFB

#7 2022-12-14 04:17:01

Re: Revival of the Linux Framebuffer & DirectFB

#8 2022-12-14 10:11:26

Re: Revival of the Linux Framebuffer & DirectFB

#9 2022-12-14 11:50:48

Re: Revival of the Linux Framebuffer & DirectFB

#10 2022-12-14 13:46:50

Re: Revival of the Linux Framebuffer & DirectFB

#11 2022-12-14 15:23:22

Re: Revival of the Linux Framebuffer & DirectFB

#12 2022-12-15 04:06:22

Re: Revival of the Linux Framebuffer & DirectFB

#13 2022-12-15 10:44:38

Re: Revival of the Linux Framebuffer & DirectFB

#14 2022-12-15 12:51:38

Re: Revival of the Linux Framebuffer & DirectFB

#15 2022-12-15 21:52:50

Re: Revival of the Linux Framebuffer & DirectFB

#16 2022-12-15 22:48:42

Re: Revival of the Linux Framebuffer & DirectFB

Board footer