On Projects For The Linux Graphics Subsystem — Hands

Once you’ve fixed a bug in your tinkering, send a patch to the dri-devel mailing list. The maintainers are harsh but fair – and desperately need people who have actually run their code on real hardware.

// Draw a simple gradient for (int y = 0; y < create.height; y++) for (int x = 0; x < create.width; x++) pixels[y * create.pitch / 4 + x] = (x * 255 / create.width) Hands On Projects For The Linux Graphics Subsystem

gcc kms_hello.c -ldrm -o kms_hello sudo chvt 2 # Switch to a free VT sudo ./kms_hello Add libinput to read mouse events and move a rectangle around the screen. Congratulations, you just wrote a micro-compositor. Project 2: Intercept and Inspect GEM Buffer Handles Goal: Trace which process is leaking GPU memory by hooking into the Graphics Execution Manager (GEM) via ftrace or a custom LD_PRELOAD library. Once you’ve fixed a bug in your tinkering,

#include <stdio.h> #include <fcntl.h> #include <unistd.h> #include <sys/mman.h> #include <drm_fourcc.h> #include <xf86drm.h> #include <xf86drmMode.h> int main() PROT_WRITE, MAP_SHARED, fd, map.offset); Congratulations, you just wrote a micro-compositor

The Linux graphics subsystem is often viewed as a terrifying labyrinth of acronyms: DRM, KMS, GEM, DRI, Mesa, VA-API, and Wayland. Most articles explain what these components are. This one is different. It is a project-based guide to touching the code, breaking things, fixing them, and understanding how pixels actually travel from your RAM to the screen.

Now go make your screen glitch in interesting ways.