CRC ABI(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… CRC ABI πŸ’…

ok so this is the CRC ABI page, straight out of the Kernel API Manual, section 9 β€” pull up a chair bestie, we're learning about frame CRCs today 🫢✨

🌸 the actual tea 🌸

DRM device drivers can hand userspace CRC info for each frame as it reached a given hardware component β€” and that component is what we call a CRC sampling "source". iconic little concept, no cap πŸ’–

Userspace gets to control CRC generation on a given CRTC by writing to the file dri/0/crtc-N/crc/control in debugfs, where N is the :ref:index of the CRTC<crtc_index>. Accepted values are source names (these are driver-specific, so like, ask your driver 😌) and the "auto" keyword, which lets the driver pick a default source of frame CRCs for this CRTC. slay.

Once frame CRC generation is enabled, userspace can capture the CRCs by reading the dri/0/crtc-N/crc/data file. Every line in that file has the frame number in the first field, followed by a number of unsigned integer fields holding the CRC data. Fields are separated by a single space, and the number of CRC fields is source-specific. read the room, read the file πŸ’…

⚠️ okay but the important caveat, bestie, listen: in some cases the CRC is computed in a specified way and on the frame contents as supplied by userspace (eDP 1.3). But in general, the CRC computation is performed in an unspecified way, and on frame contents that have already been processed in an also unspecified way. So userspace cannot rely on being able to generate matching CRC values for the frame contents that it submits. 😭 In this general case, the absolute maximum userspace can do is compare the reported CRCs of frames that should have the same contents. that's it. that's the whole vibe check.

On the driver side the implementation effort is minimal β€” drivers only need to implement drm_crtc_funcs.set_crc_source and drm_crtc_funcs.verify_crc_source. The debugfs files are automatically set up if those vfuncs are set. ✨ CRC samples need to be captured in the driver by calling drm_crtc_add_crc_entry. Depending on the driver and HW requirements, drm_crtc_funcs.set_crc_source may result in a commit (even a full modeset). lowkey a lot, but ok.

CRC results must be reliable across non-full-modeset atomic commits πŸ”₯ so if a commit via DRM_IOCTL_MODE_ATOMIC would disable or otherwise interfere with CRC generation, then the driver must mark that commit as a full modeset (drm_atomic_crtc_needs_modeset should return true). As a result, to ensure consistent results, generic userspace must re-setup CRC generation after a legacy SETCRTC or an atomic commit with DRM_MODE_ATOMIC_ALLOW_MODESET. periodt. πŸ’…


🌈 SEE ALSO 🌈


and that's the whole page, bestie πŸŽ€ shipped to you from ./drivers/gpu/drm, dated October 2026 β€” go forth and sample some CRCs fr fr πŸ’œπŸ¦‹

πŸ“¦ where this page comes from