[HN Gopher] Hands-On Graphics Without X11
___________________________________________________________________
Hands-On Graphics Without X11
Author : ingve
Score : 157 points
Date : 2025-01-17 17:54 UTC (1 days ago)
(HTM) web link (blogsystem5.substack.com)
(TXT) w3m dump (blogsystem5.substack.com)
| pjmlp wrote:
| On a parallel note, this brought memories of SVGALib.
|
| https://en.m.wikipedia.org/wiki/SVGALib
| keyle wrote:
| Never heard of it before, interesting!
| pjmlp wrote:
| Yeah, it was a long time ago that it mattered, grey dog over
| here.
| lizknope wrote:
| I remember running "sdoom" instead of "xdoom" on Linux. It did
| seem faster on sdoom using SVGAlib.
| ykonstant wrote:
| Very nice, I am very interested in raw framebuffer graphics and
| applications.
| mysterydip wrote:
| 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.
| arghwhat wrote:
| 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.
| jmmv wrote:
| > 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.
| taeric wrote:
| 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.
| arghwhat wrote:
| > 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.
| panic wrote:
| BTW if you want to learn how to put stuff on the screen without
| any display server on modern Linux, the kmscube example project
| is a great starting point:
| https://gitlab.freedesktop.org/mesa/kmscube
| segasaturn wrote:
| 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.
| LtWorf wrote:
| Yeah, also mpv has a framebuffer driver. AFAIK Qt has one as
| well, so any Qt program could run without X/wayland.
| qalmakka wrote:
| > Qt
|
| That's EGLFS, it's used quite a bit in automotive AFAIK. It's
| slowly getting replaced by Wayland and Weston though.
| jcelerier wrote:
| Qt also has a directfb backend (among many others: https://
| github.com/qt/qtbase/tree/dev/src/plugins/platforms)
| prmoustache wrote:
| I think netsurf can still be compiled for fb.
| baq wrote:
| May I introduce you to https://www.brow.sh/
| seba_dos1 wrote:
| > 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).
| jmmv wrote:
| It's the same font data but not the same rendering code. The
| spacing between the characters is probably different.
| seba_dos1 wrote:
| 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...
| jmmv wrote:
| 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!
| makz wrote:
| Awesome! I was thinking about playing with this on some BSD like
| two months ago.
| synergy20 wrote:
| i think that's what sdl provides? except sdl can do more
| incanus77 wrote:
| No, SDL provides a window/context in the existing windowing
| layer.
| jpc0 wrote:
| SDL does not need a windowing layer... There might be better
| docs somewhere but this should act as enough proof for you
| without linking directly to the source code.
|
| https://wiki.libsdl.org/SDL2/SDL_HINT_KMSDRM_REQUIRE_DRM_MAS.
| ..
| bregma wrote:
| SDL can provide a context in the native windowing system, if
| you ask it to. Or not. You have to ask for it though, it's
| not the default.
| synergy20 wrote:
| I think sdl works directly with fb when using fb as a
| backend,no windows system is needed
| zfg wrote:
| Avalonia (https://avaloniaui.net/) supports the Direct Rendering
| Manager on Linux for graphics without X11 or Wayland:
|
| https://avaloniaui.net/blog/unleashing-net-on-embedded-linux
|
| https://docs.avaloniaui.net/docs/guides/platforms/rpi/runnin...
___________________________________________________________________
(page generated 2025-01-18 23:01 UTC)