How do I find the video memory region(s) representing what's on my screen, from within the Linux kernel?

About 5-20 times a day I am presented with brief visual glitches and heisenbugs caused by race conditions that only occur under high I/O load. These disappear off the screen far too quickly for me to grab a camera in time, so I am looking to find/build a screenshotting/screen-recording tool that acts/responds with the lowest possible delay after I press a hotkey/shortcut. Critically, this tool's high-responsiveness needs to be negligibly (ideally not at all) impacted by high I/O activity, like 10-second load averages of 20-40. A fair argument could be made about loading PREEMPT_RT and running Xorg and a homemade screenshot dæmon as realtime. This would work... except for the bit about running X realtime; I actually do want to get work done on my computer. :) Thing is, I can confidently run any code I like in realtime on my computer, just by putting it inside the Linux kernel. So, kernel module time!! To reiterate my question, ### **How do I find, access and grok the memory region(s) representing the pixels on my screen, all from within a Linux kernel module?** I've found that trying to read /dev/fb0 while X is running just produces a black image, so that apparently won't work. Unfortunately https://dri.freedesktop.org/docs/drm/gpu/index.html doesn't show anything obviously related to framebuffer read-back, but I have no experience with this API, so I don't really know what I'm looking for. I accept that driver-specific code will likely be needed (since there's unlikely a driver-agnostic canonical spot in memory representing what's actually on screen), and this fine. I'm using an Intel-GPU-based machine at the moment, and I am happy to start specifically coding for that. FWIW, [I asked a differently-worded version](https://stackoverflow.com/questions/42748390/directly-accessing-video-memory-within-the-linux-kernel-in-a-driver-agnostic-man) of this question just under two years ago. That question only attracted one comment about HDCP and was never answered, but as I am still dealing with this problem up to 20 times a day even two years later, I'm having another go. (My current approach (scrot launched by i3's hotkey binder) very often takes up to 20 (!!) seconds to take a single screenshot on systems experiencing high I/O load.)