drm_crtc_vb...nk_timestamp(9)

📦 version 7.3.1, in nixpkgs unstable

💖 drm_crtc_vblank_helper_get_vblank_timestamp(9) 💖

okay so bestie, welcome to section 9 of the Kernel API Manual — yes it's the kernel, yes it's a whole vibe, and the page title is literally drm_crtc_vb...nk_timestamp(9) (they truncated it in the header bc it's a long icon name and we respect the hustle ✨). This is the function that tells you exactly when a vblank happened, no guessing, no cap. 🎀

🌸 NAME 🌸

drm_crtc_vblank_helper_get_vblank_timestamp — the precise vblank timestamp helper. it's giving "I know exactly when the screen refreshed" energy and honestly? obsessed. 💅

✨ SYNOPSIS ✨

bool drm_crtc_vblank_helper_get_vblank_timestamp (struct drm_crtc *crtc
, int *max_error , ktime_t *vblank_time , bool in_vblank_irq );

that's the whole signature, bestie, copy it exactly, no typos, we do not miss a single character in this house 🫶

🦋 ARGUMENTS 🦋

  • crtc — the CRTC whose vblank timestamp you're trying to retrieve. it's the main character here, obviously. 👑
  • max_error — the desired maximum allowable error in timestamps, in nanoseconds. and on return it contains the true maximum error of the timestamp — so it comes in as your wish and leaves as the receipts. 😭
  • vblank_time — pointer to the time that should receive the timestamp. yes it's an out-param, yes it gets the glow-up. ✨
  • in_vblank_irq — true when it's called from drm_crtc_handle_vblank. some drivers need to apply some workarounds for gpu-specific vblank irq quirks if this flag is set. lowkey cursed but we move. 💀

🌈 DESCRIPTION 🌈

okay so what does it actually do: it implements calculation of exact vblank timestamps from the given drm_display_mode timings plus the current video scanout position of a CRTC. that's the whole bit. 🔥

and here's the slay part — you can use it directly as the drm_crtc_funcs.get_vblank_timestamp implementation of a kms driver, as long as drm_crtc_helper_funcs.get_scanout_position is implemented. plug and play, periodt. 💅

ngl there's a catch tho: the current implementation only handles standard video modes. for double scan and interlaced modes, the driver is supposed to adjust the hardware mode (taken from drm_crtc_state.adjusted mode for atomic modeset drivers) to match the scanout position reported. so like, do your homework, bestie.

also — and this is important — note that atomic drivers must call drm_calc_timestamping_constants before enabling a CRTC. good news tho: the atomic helpers already take care of that in drm_atomic_helper_calc_timestamping_constants. so you're covered, but now you know. 🙈

⭐ RETURN ⭐

returns true on success, and false on failure — i.e. when no accurate timestamp could be acquired. flop era only when the timestamp is genuinely unavailable, no cap. 😤

🎀 SEE ALSO 🎀

like, the whole vblank friend group showed up to the party. 🌸🦋

that's the page, bestie!! sourced from ./drivers/gpu/drm, dated October 2026, and living in section 9 of the Kernel API Manual — go forth and timestamp your vblanks precisely, ily, mwah 💜🧚‍♀️

📦 where this page comes from