MASTER AND AUTHENTICATION(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸŽ€ master and authentication(9) πŸŽ€

okay so this is from the Kernel API Manual, section 9, and it's literally the whole lore drop on how DRM keeps track of who's in charge of your GPU. bestie, this is the group-chat admin system of the kernel. let's get into it πŸ’…


✨ the actual tea (DESCRIPTION) ✨

struct drm_master is the thing that tracks groups of clients with open primary device nodes. think of it as the little crown πŸ‘‘ that a group of besties shares.

for every struct drm_file that has at least once successfully become the device master β€” whether that happened through the SET_MASTER IOCTL, or implicitly by opening the primary device node when nobody else was the current master at that time β€” there exists one drm_master. this is recorded in drm_file.is_master so everyone knows who's who πŸ“

all the other clients out here? they just have a pointer to the drm_master they're associated with. no crown, just a link in the group chat 🫢

also huge: only one drm_master can be the current master for a drm_device. one. single. main character. πŸ’€ and that crown can be switched:

  • through the DROP_MASTER and SET_MASTER IOCTLs, or
  • implicitly, through closing/opening the primary device node

see also drm_is_current_master β€” it's the vibe check for "are you actually the master rn" 🌈

clients can authenticate against the current master (if it matches their own) using the GETMAGIC and AUTHMAGIC IOCTLs. and together with exchanging masters, this is what allows controlled access to the device for an entire group of mutually trusted clients. mutuals only, no gatecrashers πŸ™ˆ ✨


πŸ’« SEE ALSO πŸ’«


that's the whole thing, no cap 🧚 from ./drivers/gpu/drm, dated October 2026 β€” slay, and good luck out there with your masters, bestie πŸ’– 🌸

πŸ“¦ where this page comes from