INC-2026-05-23-002: Prevention

What Went Well

  • External monitor test was the breakthrough diagnostic — proved Hyprland was alive and isolated the failure to eDP-1 specifically

  • DRM topology check (/sys/class/drm/) revealed eDP-1 was on the Intel GPU, correcting the NVIDIA misdiagnosis

  • Journal analysis surfaced the definitive PSR timeout error after userspace workarounds failed

  • dots-quantum stow symlink meant hypridle config changes persisted without manual file management

  • The verify-before/change/verify-after pattern caught a correct sed edit on the first try

What Could Be Improved

  • Check the journal FIRST, not last: The Timed out waiting PSR idle state error was in the journal the entire time. Two failed workarounds could have been avoided by reading the i915 errors before hypothesizing about DPMS or DRM re-initialization.

  • Never assume which GPU drives a display on hybrid laptops: Always verify with /sys/class/drm/ before attributing display issues to a specific driver. The NVIDIA CRTC error was a red herring that wasted an entire diagnostic cycle.

  • PSR is a known regression vector: i915.enable_psr=0 is a well-documented workaround for Intel GPU display issues. It should be in the troubleshooting checklist for any eDP-related display problem after a kernel upgrade.

  • Test display power cycling after kernel upgrades: A simple hyprctl dispatch dpms off && sleep 3 && hyprctl dispatch dpms on smoke test would catch PSR regressions immediately.

Key Takeaways

  • i915.enable_psr=0 is the first thing to try for eDP black screen after kernel upgrade — PSR hangs are the most common i915 display regression class

  • Check /sys/class/drm/ to identify which GPU drives each display — never assume on hybrid GPU laptops

  • Read the journal before writing workarounds — journalctl -b | grep -iE 'i915|drm|psr|crtc|pipe' would have found the root cause in one command

  • External monitor connection is a definitive diagnostic — if it works, the compositor is alive and the issue is display-pipeline-specific

  • Three failed workarounds before the right fix — each one was plausible but addressed symptoms, not the kernel-level root cause

Related