Closing Hyperion Stops the Cursor Flicker
The lag came back after this morning's fix. The mouse cursor was flickering with it. I wondered if I was chasing something Defender couldn't see.
The wondering-if-malware moment
After this morning's fix — killing fifteen leaked processes from my keyboard vendor's software stack — typing was instant again. I was pleased with myself. Then, later the same day, the lag returned. Not as bad. But there. And the mouse cursor was flickering in a way that felt off.
The paranoid frame surfaces on its own at that point. What if something is sitting on this box that Windows Defender can't see? Kernel rootkit. Firmware-resident. Zero-day. The kind of thing that would explain lag returning after a clean intervention.
I asked whether it was worth setting up a real malware scan — something that could catch what Defender might miss. The honest read came back: yes, in principle, malware can evade Defender. Kernel rootkits, firmware-level infections, zero-days with no signatures. It is not impossible. It is also not the highest-probability explanation, given that a userspace process fanning out to compete with the input pipeline was exactly what caused the morning's version of the same problem, from a different vendor.
But the paranoia deserved a real answer, not a shrug.
Three scanners
The setup:
- Malwarebytes Free. Best-known second-opinion scanner. Different signature engine to Defender. Catches PUPs, adware, modern crypter families that Defender's realtime engine routinely misses. Installed via
winget, hash-verified installer. - Sysinternals Autoruns with VirusTotal integration. Not a scanner in the classic sense — it enumerates every persistence hook across the system (services, drivers, scheduled tasks, WMI event consumers, Run keys, browser extensions, image hijacks — around fifty categories) and cross-checks each against VirusTotal's ~70 AV engines. If something has embedded itself in the autostart chain, this reveals it. Configured to send hashes only, no file uploads.
- Windows Defender Quick Scan. Baseline second pass on top of the always-on realtime engine.
Sysinternals Autoruns went first — under a minute for the enumeration, ten-odd minutes for the VirusTotal hash lookups. Zero flagged autoruns. Every VT lookup came back with 0 detections. The two entries that showed a single hit were both single-engine false positives on well-known legitimate updaters (an audio equalizer's update checker, and a driver-hiding tool by a signed vendor — clean by every other engine).
Defender Quick Scan next. Two minutes. Zero threats.
Malwarebytes last. Fifteen minutes of full sweep. One finding: PUP.Optional.AVBDiskSoft — a Potentially Unwanted Program flag on a DAEMON Tools Lite installer file sitting in my Documents folder. Not the installed program. The old installer file, kept from when I first put DT Lite on the machine, which contains bundled optional adware components that Malwarebytes categorises as PUP. A known-benign flag on a stored file, not on anything running.
Zero actual malware across three scanners with three different signature databases.
I was slightly disappointed. I had primed myself for a find. Getting nothing back means the boring explanation is the correct one — which is a real result, not an absence of one. It moves the primary suspect from suspect to confirmed.
The confirmation test
The top CPU consumer on the machine was hyperiond — the Hyperion NG daemon that drives my screen backlights. Hyperion works by screen-capturing the framebuffer in real time, chopping it into zones, computing the average colour per zone, and sending those colours out to the LED strip behind the monitor. Screen capture at capture-framerate is expensive. On my machine, hyperiond had accumulated something like 11,500 CPU-seconds over the course of the day — roughly one CPU core at 85% continuously.
Signed by hyperion-project. Path in Program Files. Legitimate. And the actual answer.
The test: I closed Hyperion. The mouse cursor flicker stopped. Reopen: it comes back. Close: gone. A reproducible symptom-toggle. That is the gold standard of "this is the cause" in a diagnostic — not correlation, not process-list ranking, but a repeatable on-off switch tied to the symptom.
Cursor flicker turns out to be a known signature of Hyperion's DXGI screen-capture backend competing with how Windows composites the hardware cursor overlay. It forces redraws that stutter the cursor rendering path. Same class of problem as the morning's Razer situation: userspace software fighting the input/render pipeline. Different vendor, different symptom, same shape.
The tradeoff
Hyperion is not a bug. It is the accepted cost of my screen backlights working. I chose to install it. I want the ambient lighting. What I now know is what it costs: roughly one CPU core continuously, occasional cursor flicker, and a measurable share of the lag I was chasing.
That knowledge is worth having. It lets me decide what to do about it.
The options divide into two shapes.
The first is software: run a lighter Ambilight backend. HyperHDR — a fork of Hyperion NG that targets modern DirectX 12 backends — reports 30-50% lower CPU in community benchmarks. Drop-in replacement, same LED hardware, same UX. Free to try. If it drops the cost enough, that is the whole fix.
The second is hardware: move the screen capture off the PC entirely. A Raspberry Pi with an HDMI splitter and a USB HDMI capture card sits between the PC's HDMI output and the monitor. The Pi captures the signal, runs Hyperion on itself, drives the same LED strip. Zero cost on the gaming PC. Around a hundred pounds in parts.
Except: the hardware version has an interesting constraint. Any DRM-protected content — streaming platforms, protected discs, some game protections — outputs an HDCP-encrypted HDMI signal that a Pi rig cannot legally capture. On DRM sources, the Pi's Ambilight goes dark or the source refuses to output. The reason software Hyperion does not have this problem is that it captures the framebuffer inside the PC, before HDMI output — before HDCP enters the picture. Netflix decrypts inside the GPU, renders to the framebuffer, Hyperion reads it, HDMI output happens afterward. DRM never engages with the capture.
So the honest tradeoff is: software Hyperion is expensive but works with everything. Hardware Pi rig is cheap after purchase but stops working the moment a stream is DRM-protected. Third-party HDMI-sync boxes that are licensed for HDCP are legal but cost £300-500 and do not use existing LED hardware. That is the plan doc's problem to solve.
What this exercise was actually about
Three things I want to keep from tonight.
A null malware result is a real result, not a disappointment. When you go looking for an exotic explanation and do not find one, the correct move is not to look harder in the same direction until you find nothing more times. It is to trust the finding and update the explanation you had.
A reproducible symptom-toggle test beats every heuristic. Process list rankings suggested Hyperion. Being able to make the flicker start and stop by closing and reopening a specific process confirmed it. Suspect versus cause is a large distance and this is what closes it.
Knowing what a thing costs lets you decide whether you want to keep paying it. Before tonight, Hyperion was a background daemon I ran and never thought about. Now I know it costs me roughly one CPU core continuously and a slice of my input responsiveness. That information changes what I am willing to consider. HyperHDR upgrade sits above zero on the effort scale but well below what I now know I am paying. The Pi rig with hybrid fallback for DRM sits at a hundred quid. Both look reasonable in a way they would not have this morning.
Sister pieces from earlier today: Fifteen Processes Watching My Keyboard — Gavin voice on the primary lag fix. The Physical Suspect — Nyx voice on the diagnostic pattern behind the audit.