These interfaces can be cute to play with, but there's a reason that fbdev is deprecated on Linux - it's not a good interface outside toy examples. wscons may be more powerful, but I don't think it can be used to fully enable modern accelerated display devices, although do correct me if I'm wrong.
Despite some confusion in terminology, modern interfaces also operate on frame buffers, but with an API for switching them out atomically. Likewise, your display server (at least modern ones) just take your client window as a completed frame buffer, and mainly serve to let multiple applications all show their frame buffers without having to worry about what other applications are doing. Frame buffers all the way down, just with support for DMA, atomicity, fancy formats and color spaces, etc.
You can use the appropriate modern APIs to make a single, exclusive graphical application with all the benefits of modern display hardware easily enough. That is, after all, what your display server is. You just don't gain much - just a little bit of saved sideband IPC.
X11 makes it seem like a display server is a complicated thing that has to support drawing and what not, but with alternatives like Wayland, a full screen client buffer is handed off zero-copy from the client application tot he hardware without being looked at.
> wscons may be more powerful, but I don't think it can be used to fully enable modern accelerated display devices, although do correct me if I'm wrong.
As I mentioned in the text, I think that's the difference between WSDISPLAYIO_MODE_MAPPED and WSDISPLAYIO_MODE_DUMBFB. The former allows access to the hardware registers whereas the latter does not. Obviously, if you choose to use the former, then you are tied to a specific graphics driver. (But I'm not sure of this.)
And yes, agree, what I described is not great for performant results, but there is a lot you gain from the simplicity of this approach if all you want is toy around. I feel we lost a lot of this simplicity over the years, but it's "still there" if you don't care about optimal performance.
> I feel we lost a lot of this simplicity over the years, but it's "still there" if you don't care about optimal performance.
You lost some simplicity in going "straight to the metal", but at the same time it never really went straight to the metal because things have not actually worked that way for ages, nor do anyone really want to deal with exclusive access.
On the other hand, you can make a window with a shm buffer on your display server, giving you the same drawing simplicity of the old interfaces but without having to deal with fbdev, evdev, exclusive access, etc. - with that in mind, I do not think anything educational was lost.
Completely agreed on the feeling that we lost a lot by moving away from some of the simpler interface options. Particularly for introductory and play purposes. Specifically, even.
> Same font, same colors, same… everything? Other than for the actual text they display, they look identical, don’t they?
Funny to see that written under two screenshots with clearly different fonts, and even different colors (though not so clearly; but still different enough to make me check).
It's not. Just look at it please! Glyphs are completely different. One font is serif, one is sans-serif. It's the most obvious when you look at p, y, r, a, s...
I remember Links, the text-based browser that runs in your terminal, had a framebuffer mode that you could use to get rudimentary graphical web browsing on a system with no X11 installed.
These interfaces can be cute to play with, but there's a reason that fbdev is deprecated on Linux - it's not a good interface outside toy examples. wscons may be more powerful, but I don't think it can be used to fully enable modern accelerated display devices, although do correct me if I'm wrong.
Despite some confusion in terminology, modern interfaces also operate on frame buffers, but with an API for switching them out atomically. Likewise, your display server (at least modern ones) just take your client window as a completed frame buffer, and mainly serve to let multiple applications all show their frame buffers without having to worry about what other applications are doing. Frame buffers all the way down, just with support for DMA, atomicity, fancy formats and color spaces, etc.
You can use the appropriate modern APIs to make a single, exclusive graphical application with all the benefits of modern display hardware easily enough. That is, after all, what your display server is. You just don't gain much - just a little bit of saved sideband IPC.
X11 makes it seem like a display server is a complicated thing that has to support drawing and what not, but with alternatives like Wayland, a full screen client buffer is handed off zero-copy from the client application tot he hardware without being looked at.
> wscons may be more powerful, but I don't think it can be used to fully enable modern accelerated display devices, although do correct me if I'm wrong.
As I mentioned in the text, I think that's the difference between WSDISPLAYIO_MODE_MAPPED and WSDISPLAYIO_MODE_DUMBFB. The former allows access to the hardware registers whereas the latter does not. Obviously, if you choose to use the former, then you are tied to a specific graphics driver. (But I'm not sure of this.)
And yes, agree, what I described is not great for performant results, but there is a lot you gain from the simplicity of this approach if all you want is toy around. I feel we lost a lot of this simplicity over the years, but it's "still there" if you don't care about optimal performance.
> I feel we lost a lot of this simplicity over the years, but it's "still there" if you don't care about optimal performance.
You lost some simplicity in going "straight to the metal", but at the same time it never really went straight to the metal because things have not actually worked that way for ages, nor do anyone really want to deal with exclusive access.
On the other hand, you can make a window with a shm buffer on your display server, giving you the same drawing simplicity of the old interfaces but without having to deal with fbdev, evdev, exclusive access, etc. - with that in mind, I do not think anything educational was lost.
No harm in playing around though.
Completely agreed on the feeling that we lost a lot by moving away from some of the simpler interface options. Particularly for introductory and play purposes. Specifically, even.
On a parallel note, this brought memories of SVGALib.
https://en.m.wikipedia.org/wiki/SVGALib
Never heard of it before, interesting!
> Same font, same colors, same… everything? Other than for the actual text they display, they look identical, don’t they?
Funny to see that written under two screenshots with clearly different fonts, and even different colors (though not so clearly; but still different enough to make me check).
It’s the same font data but not the same rendering code. The spacing between the characters is probably different.
It's not. Just look at it please! Glyphs are completely different. One font is serif, one is sans-serif. It's the most obvious when you look at p, y, r, a, s...
Hah, I was convinced I picked the same font file from NetBSD... and didn't really notice the difference on the small screen I'm running this on!
I remember Links, the text-based browser that runs in your terminal, had a framebuffer mode that you could use to get rudimentary graphical web browsing on a system with no X11 installed.
I think netsurf can still be compiled for fb.
Yeah, also mpv has a framebuffer driver. AFAIK Qt has one as well, so any Qt program could run without X/wayland.
Very nice, I am very interested in raw framebuffer graphics and applications.
Check this out: https://github.com/vvaltchev/tfblib
It worked well for a hobby project. I had issues on certain specific displays I think due to the color depth requirement.