31 ms·
Intro to Low-Level Graphics on Linux
- jdironman 9y agoQuiet a bit off topic, but this website is a joy to browse just for it's simplicity, high visibility, and speed. Just good ole basic HTML & PHP pages without a ton of overhead.
- BoorishBears 9y ago> high visibility The moment it loaded my eyes felt out of focus and everything had a certain fuzziness to it. The color combinations don't seem to agree with font smoothing, at least not on OS X w/ Safari on a 3440x1440 monitor
- notamy 9y ago> high visibility Really? I found it quite difficult to read due to the text color being too close to the background color.
- khedoros1 9y agoIt's similar to my preferred terminal settings. Dark background, light grey text, some brighter colors to highlight important things.
- _ph_ 9y agoFor me, light fonts on dark backgrounds are very difficult to read, I quickly get a lot of after images making reading the text very difficult. I was always fine with green and amber monochrome screens back then - perhaps my eyes just were much younger. I have not been able to find out what changed that for me, unfortunately.
- fenwick67 9y agoA monitor with deep blacks seems to show this well, but with high gamma or bright blacks it looks bad. I have two monitors and it looks way better on one than the other.
- ausjke 9y agogreat write-up, fbdev is straightforward but the kernel is phasing it out in favor of DRM, I hope DRM will maintain a fbdev emulation at least. it's sad SDL2 did not have fddev support either as most people are fond of doing opengl/2d/3d-accleration these days.
- digikata 9y agoThat takes me back, fbdev was pretty useful for embedded linux configured with no X, dedicated Qt apps... or even just for putting up the all important custom boot splash screen.
- jdmoreira 9y agoAnyone remember SVAlib? I wish it was still around. Maybe it should be ported on top of OpenGL and made cross platform. Would love to have something similar on macOS.
- pjmlp 9y agoYes, having to make applications setuid. I used it for a while, if I remember correctly I even wrote a pixmap loader. Why not just use SDL, or would you like to port old games? Nowadays on macOS I would just use SpriteKit.
- digi_owl 9y agoTo me Wayland is basically that for the GL generation...
- jasonkostempski 9y agoDoes "DRM" here mean something other than the "DRM" most of us are used to?
- thehardsphere 9y agoDirect Rendering Manager: https://en.m.wikipedia.org/wiki/Direct_Rendering_Manager https://en.m.wikipedia.org/wiki/Direct_Rendering_Manager Very different from Digital Rights Management.
- shmerl 9y agoInteresting write up, but it would be useful to explain how major graphics APIs fit into this (i.e. Vulkan / OpenGL) and how it all glues together (GPU drivers with KMS/DRM and higher level APIs). Also note, that Mir is now basically gone, Canonical decided now to stop that rift and stick to Wayland.
- simplicio 9y agoIs there a decent write-up of how the graphics stack goes, from userland to the monitor? I have a really hazy picture of how framebuffers, drivers, compositors, GPUs, display servers etc. all fit together. I've read good tutorials about the various pieces, but don't really grok how they inter-relate.
- shmerl 9y agoI saw one brief overview here: http://blog.mecheye.net/2012/06/the-linux-graphics-stack/ http://blog.mecheye.net/2012/06/the-linux-graphics-stack/
- thehardsphere 9y agoThat is a particularly superb overview. Thank you for sharing it.
- Jasper_ 9y ago(Author of that article here) It's a bit outdated and honestly needs replacing at this point. Xplain[0] replaces parts of it, and some of my newer blog posts[1][2] replace other parts. I can also answer any questions people have about the stack. [0] http://magcius.github.io/xplain/article/ http://magcius.github.io/xplain/article/ [1] http://blog.mecheye.net/2014/06/xdg-shell/ http://blog.mecheye.net/2014/06/xdg-shell/ [2] http://blog.mecheye.net/2016/01/dri/ http://blog.mecheye.net/2016/01/dri/
- shmerl 9y ago
- tombert 9y agoThese articles always make me appreciate the work that must go into something like SDL or OpenGL and the like. It's easy to take these things for granted, but if this is the stuff that they have to make everything work, then I have to give some props and respect to the authors.
- pjmlp 9y agoA nice way to give value to it, and at the same time a learning exercise, is to try do implement software rendering like we were doing in the MS-DOS days. For something more modern, grabbing an ESP32 coupled with a LCD screen, for example.
- outworlder 9y agoI made my first serious attempt almost as soon as I joined my university, CompSci. First attempt took a long time, as I did not really know how matrices applied to computer graphics, so I did all operations again and again, when they were required. My first rotating cube "exploded" due to numerical errors, as I was modifying the geometry instead of using matrix projections. That made me appreciate the linear algebra classes much more.
- AceJohnny2 9y agoTangential question from an embedded-but-not-Linux developer: The structs use the types like __u32 or __u16. I know the kernel defines its own types for internal usage[1], but why redefine types exposed to user-space? Why not use C99 <stdint.h> types? Is it only historical? And why are they double-underscore? [1] because... reasons? I never really understood why
- valarauca1 9y agoGenerally speaking when you interface with a c library you should use the same types it uses. So while you can like get by with `stdint.h`'s `uint64_t` on _most_ platforms you hurt portability. Example: This is because `stdint.h` isn't 100% compatible with _every_ platform Linux supports. This gets in hair brained definitions of pointers lengths on some obscure platforms. For example SPARC64's `long`, `long long`, `void\`, and `uint64_t` aren't all the same size (`long long` is `uint64_t`, while void\ and `long` are `uint32_t`, but in kernel land `void\*` is `uint64_t`). Just like C11 Atomics can fail on ARM and PPC under some scenarios so the kernel doesn't use these as well. Its my understand the Kernel supports more platforms then the C standardization committee xD --- So the kernel likes to define its own primitives, and when you interface with it its is generally best to just use those definitions. Or if you want to use _standard_ types, you have to understand you are hurting portability.
- sqeaky 9y agoWhat platforms are we talking about? Anything actually used by consumers or business or is it all just stuff that has esoteric support by hobbyists and those creating custom and reviving super old stuff. I would imagine that if someone's platform doesn't support C11 at this point it pretty much hasn't been updated in 7 years and pretty much can't custom build GCC. I mean I know how to build GCC on a Sega Dreamcast so it has to be more esoteric than that. Also, not supporting C11 probably also means not supporting lots of other things that modern applications might want like Vulkan, IPv6 or multiple threads.
- AceJohnny2 9y agoThanks for your explanation :) One thing I still don't understand though: > This is because `stdint.h` isn't 100% compatible with _every_ platform Linux supports. This gets in hair brained definitions of pointers lengths on some obscure platforms. For example SPARC64's `long`, `long long`, `void` , and `uint64_t` aren't all the same size (`long long` is `uint64_t`, while void\ and `long` are `uint32_t`, but in kernel land `voidx` is `uint64_t`). In these cases, you just defined the variably-lengthed types (void* ) using the fixed-length types (uint64_t). This would just demonstrate that the fixed-length types are absolute, and IMO then good candidates to base absolute-sized types on. And yet that's still not good enough? A bit of googling brings up the book Linux Device Drivers 3rd Ed (2005)[1], in which chap11 specifically addresses the topic of types. It argues against the usage of standard C types (int, long, etc) specifically because of their size variability. That's all well and good, but it doesn't make any mention of stdint.h! A hypothesis comes up: maybe stdtint.h is meant to be a user-space header exposed by the system/compiler, and the kernel, having to be entirely bootstrapped, can't even depend on that? So it just redefines the types for itself? With the side-effect of exposing those to userspace at the API? [1] https://lwn.net/Kernel/LDD3/ https://lwn.net/Kernel/LDD3/
- zokier 9y agoPersonally I find the heavy use of ioctls in modern Linux APIs bit distasteful. Sure, its pragmatic and easy, but it really feels abusing the UNIX mantra of "everything is a file" when the only operation you can do for that "file" is some specific ioctls. I first noticed this in the very nice KVM article that ran on LWN few years back, and now again here. I really wish there was some more structured way of talking to the kernel, but I can understand that introducing a ton of new syscalls probably is not practical.
- vardump 9y ago> Personally I find the heavy use of ioctls in modern Linux APIs bit distasteful. That's how things work in Windows as well. That's how userland talks to kernel mode drivers. Well, except everything is an object.
- hossbeast 9y agoWhich has nothing to say about whether it's a good idea.
- Const-me 9y ago> That's how things work in Windows as well. GPU drivers are different. Basically, Windows have Direct3D already in the kernel, exposing relatively large API surface for the userland half of the driver. https://docs.microsoft.com/en-us/windows-hardware/drivers/display/windows-vista-and-later-display-driver-model-operation-flow https://docs.microsoft.com/en-us/windows-hardware/drivers/di...
- TazeTSchnitzel 9y agoDid Plan 9 try to fix this?
- secure 9y agoYes, see http://doc.cat-v.org/plan_9/4th_edition/papers/812/ http://doc.cat-v.org/plan_9/4th_edition/papers/812/ for details
- 9y ago
- mrb 9y agoUsing the Linux kernel API is too high level :) Back in 1999 I wrote a simple 3D engine that hooked into a lower level API: the code was calling directly into the VESA BIOS Extensions of the graphics card. This worked on Windows 98 I think, but not NT4. https://en.wikipedia.org/wiki/VESA_BIOS_Extensions https://en.wikipedia.org/wiki/VESA_BIOS_Extensions
- makapuf 9y agoYou used BIOS calls ? Luxury , I used VGA registers directly to get vga mode X back in the days. http://www.jagregory.com/abrash-black-book/ http://www.jagregory.com/abrash-black-book/ now that I call low level.
- mrb 9y agoYou win ;)
- a3f 9y agoYou had a VGA controller? That's nice. I had to design my own back in the days. https://github.com/a3f/r3k.vhdl/tree/Demo-v1/vhdl/io/vga https://github.com/a3f/r3k.vhdl/tree/Demo-v1/vhdl/io/vga
- makapuf 9y agoYou have an FPGA ? That's also nice, all I have is a bunch of resistors and a MCU :) https://hackaday.com/2014/02/23/the-bitbox-console-gets-upgraded/ https://hackaday.com/2014/02/23/the-bitbox-console-gets-upgr... (nice project btw !)
- em3rgent0rdr 9y agoThe frontpage mentions Wirth's Law: "software is getting slower more rapidly than hardware becomes faster". https://en.wikipedia.org/wiki/Wirth%27s_law https://en.wikipedia.org/wiki/Wirth%27s_law
- kodfodrasz 9y agoOne would expect some images in a graphics tutorial...
- unwttng 9y agoI notice there are no pictures
- unwttng 9y agoJust how low level _are_ these graphics?