背景
完成：
panel_power_cycle_delay
500 ms → minimum 2000 ms后，不能仅凭“成功启动一次”就判断问题解决。
需要验证：
修改是否真的生效
+
触发条件是否得到抑制
+
连续重启是否稳定一、首先检查运行态参数
读取：
sudo cat \
/sys/kernel/debug/dri/<device>/eDP-1/i915_panel_timings必须看到：
Panel power cycle delay: 2000如果仍然是：
500说明当前运行的并不是修改后的 i915。
二、验证实际加载模块
modinfo -n i915应指向：
/lib/modules/<kernel>/updates/i915.ko.zst而不是：
/lib/modules/<kernel>/kernel/drivers/gpu/drm/i915/i915.ko.zst同时：
modinfo i915 | grep '^vermagic:'应与：
uname -r一致。
三、启动时出现约 2 秒黑屏反而是预期结果
补丁生效后，启动过程中观察到两个明显的黑屏阶段：
约 2 秒第一次对应：
Firmware → i915第二次对应：
SDDM → Plasma这与补丁的：
minimum 2000 ms完全一致。
因此这里的短暂黑屏不是故障，而是面板确实在等待完整 power-cycle interval。
四、DPMS 压力测试
补丁前：
0.5 秒 off/on → 可失败
1 秒 off/on → 可失败而：
2 秒 → 20/20 PASS
3 秒 → 20/20 PASS这一实验其实已经给 2000 ms 修改提供了非常强的直接证据。
因为它绕开了：
boot
SDDM
Xorg
Wayland handoff单独验证了：
Panel Power Cycle Duration这一变量。
五、连续自动重启测试
后来还设计了一个 systemd 测试服务，用于连续重启。
脚本每次：
- 等待系统启动；
- 检查 panel timing；
- 等待 Plasma；
- 延迟一定时间；
- 记录 PASS；
- 自动 reboot。
连续成功记录：
PASS 01
PASS 02
PASS 03
PASS 04
PASS 05
PASS 06六、第七次出现“FAIL”，但并不是屏幕故障
某次脚本输出：
FAIL: panel power cycle delay is not 2000 ms服务随后自动停止。
但进入系统后人工立即读取：
Panel power cycle delay: 2000同时自定义模块路径也正确。
因此这是：
测试脚本假失败而不是显示故障。
七、假失败的原因
脚本只判断：
i915_panel_timings 文件已经可读取却没有确保：
PPS 初始化已经完全结束因此可能发生：
debugfs 文件出现
↓
脚本立即读取
↓
最终 PPS timing 尚未完成初始化
↓
误判这说明自动测试也需要理解驱动初始化时序。
八、为什么软件无法自动检测黑屏/绿屏
最棘手的一点是：
GPU 和 DRM 认为屏幕完全正常。
即使物理屏幕已经黑、白、绿，软件仍然可能显示：
eDP connected
pipe active
DPLL active
link training successful
backlight on因此无法简单写：
if DRM == OK:
screen == OK这也是为什么最终仍然需要人工观察。
九、验证结论应该如何表达
比较严谨的说法是：
2000 ms 补丁经过直接 DPMS 实验、连续启动测试和实际长期运行验证，表现出非常强的稳定性证据。
不应该表述为：
数学意义上的 100% 永远不会再次发生但从工程实践角度，已经足够作为长期 workaround 使用。