问题背景
一台 Intel 平台笔记本安装 Arch Linux + KDE Plasma Wayland 后，内置屏幕偶发出现非常异常的显示状态：
- 黑屏
- 全白
- 全绿
- 黑屏后逐渐出现绿色区域
这些异常主要发生在：
- Linux 内核接管显示输出时；
- 登录管理器切换到 Plasma 桌面时。
机器同时安装其他操作系统，可以方便进行交叉验证。
一个很重要的现象是：
其他操作系统长期使用基本正常，而 Linux 图形环境下更容易触发故障。
因此最初判断倾向于：
Linux DRM / i915 / 显示模式切换而不是简单的 LCD 面板物理损坏。
一、安全测试原则
在多次实验后发现，异常显示状态不宜长期保持。
尤其是绿屏状态，应立即关机。
黑屏和白屏虽然没有绿屏那么明显，但也不建议为了观察日志而让屏幕长时间保持异常，因为曾观察到：
黑屏
→
局部逐渐出现绿色
以及：
异常状态持续较久
→
恢复后短时间残留白色边缘因此后续测试采用原则：
一旦发生持续黑屏、白屏或绿屏，应尽快结束测试；绿屏尤其应立即断电关机。
二、首先排除基本硬件输出能力
Arch Live 环境中的纯命令行 TTY 多次启动均正常。
内屏在 TTY 状态下能够稳定运行，包括：
2560×1600
30 bpp
4 lanes
270 MHz port clock这非常重要。
因为故障状态下，DRM 软件层看到的参数往往也完全相同。
因此以下假设逐渐被削弱：
- 分辨率过高
- DP bandwidth 不足
- lane 数错误
- 30 bpp 本身不兼容
- 基础 eDP link 无法工作
三、尝试过但没有解决问题的 i915 参数
排查过程中曾测试多项常见 Intel 显示参数。
PSR
测试：
i915.enable_psr=0早期曾看起来有所改善，但继续测试后仍然可以出现异常。
因此：
PSR ≠ 根因Display C States
测试：
i915.enable_dc=0结果反而使问题更加明显。
因此取消。
eDP Voltage Swing
测试：
i915.edp_vswing=2同样没有改善，甚至更差。
取消。
四、Early KMS 与 Late KMS
曾经尝试将：
i915加入 initramfs，以启用 Early KMS。
实际结果并不好。
因此最终恢复为：
Late KMS并确认：
lsinitcpio /boot/initramfs-linux.img中没有 i915。
最终运行逻辑为：
内核启动
↓
挂载根文件系统
↓
从 /usr/lib/modules/... 加载 i915五、GRUB framebuffer 不是根因
也曾测试：
GRUB_GFXPAYLOAD_LINUX=text结果故障仍然存在，甚至更频繁。
因此恢复正常 framebuffer handoff。
最终可以确认：
GRUB 图形模式并不是这个问题的核心。
六、SDDM Wayland 曾经看起来非常可疑
系统最初使用：
SDDM X11
+
Plasma Wayland曾尝试将 SDDM 也切换为 Wayland。
当时失败概率非常高，例如连续测试中大部分启动出现异常。
因此一度怀疑：
SDDM Wayland或者：
X11 → Wayland交接过程是根因。
后来事实证明，这是一个典型的“相关但不是因果”的现象。
七、排除 xf86-video-intel
系统中曾安装：
xf86-video-intel但检查 Xorg 日志发现真正使用的是：
modesetting_drv.so而不是旧 Intel DDX。
随后删除：
sudo pacman -Rns xf86-video-intel故障仍然可以复现。
因此：
xf86-video-intel被排除为根因。
八、30 bpp 也不是根因
i915 日志曾出现：
intel_edp_fixup_vbt_bpp:
pipe has 30 bpp for eDP panel,
overriding BIOS-provided max 24 bpp这个信息最初很可疑。
但 TTY 在：
30 bpp
2560×1600
4 lanes
270 MHz状态下可以长期稳定运行。
因此：
30 bpp 本身并不能解释黑屏、白屏和绿屏。
九、检查 VBT 与 eDP 参数
通过 intel-gpu-tools 对 VBT 进行分析，可以看到：
Interface: eDP
Lane count: 4
PSR: disabled/not advertised
DP SSC: disabled相关信息没有显示出明显的链路配置错误。
这进一步将注意力从：
Link configuration转向：
Panel Power Sequencing十、DRM Debug：最关键的矛盾
启用：
drm.debug=0x116分别记录：
- 正常启动
- 黑屏启动
- 绿屏启动
结果出现了一个非常重要的现象：
无论屏幕最终正常还是异常，日志通常都会显示：
Clock recovery OK
Channel EQ done
DP Training successful
Link Training passed例如：
link rate = 270000
lane count = 4之后还可以看到：
pipe enabled
transcoder enabled
backlight enabled也就是说：
从 DRM/i915 的软件视角看，显示链路已经成功建立。
但物理屏幕却可能是：
black
white
green这意味着问题并不像普通的：
DP link training failure而更像：
显示器内部实际电源状态与驱动软件认知出现了分离。
十一、发现完整 Panel Power Cycle
详细分析启动日志后发现，i915 接管内屏时会进行完整的：
Backlight Off
↓
Pipe Off
↓
Panel Power Off
↓
等待
↓
DPLL Off / On
↓
Panel Power On
↓
等待
↓
AUX / DPCD
↓
Link Training
↓
Backlight On正常启动中可以看到类似：
wait_panel_power_cycle ... 495 ms remaining异常启动则可能出现：
489 ms remaining
492 ms remaining说明系统实际使用的最低 panel power-cycle 时间约为：
500 ms十二、启动期间其实进行了两次完整电源循环
进一步分析发现，从开机到桌面至少发生两次明显的 eDP 电源重置。
第一次：
Firmware
→
Linux
→
i915第二次：
SDDM
→
Plasma/KWin这与肉眼观察到的：
第一次明显黑屏
第二次明显黑屏高度对应。
换句话说：
每次启动至少存在两个触发故障的机会。
十三、决定性实验：在已经正常运行的 Plasma 中复现
真正锁定根因的实验并不是继续重启。
而是在一个已经完全正常运行的 Plasma Wayland 会话中主动执行：
kscreen-doctor --dpms off
sleep N
kscreen-doctor --dpms on分别测试不同的关闭时间。
结果非常明显。
0.5 秒
FAIL可以复现黑屏。
部分情况下随后会逐渐出现绿色区域。
1 秒
FAIL同样可以出现黑屏。
2 秒
先做少量测试正常，随后进行连续验证：
20 / 20 PASS3 秒
同样：
20 / 20 PASS5 秒
正常。
十四、这个实验排除了大量上层组件
因为测试发生在：
已经启动完成
+
已经进入 Plasma Wayland
+
桌面完全正常的情况下。
因此故障不再需要以下任何条件：
GRUB
Linux boot
SDDM
Xorg
X11 → Wayland
登录过程只需要：
eDP OFF
↓
短时间等待
↓
eDP ON就能够复现。
至此，问题已经基本被压缩到：
Panel Power Sequencing十五、直接读取 i915 Panel Timing
debugfs 提供：
/sys/kernel/debug/dri/<device>/eDP-1/i915_panel_timings读取：
sudo cat \
/sys/kernel/debug/dri/<device>/eDP-1/i915_panel_timings原始状态：
Panel power up delay: 200
Panel power down delay: 60
Panel power cycle delay: 500
Backlight on delay: 1
Backlight off delay: 200这里终于出现了与实验完全对应的数据：
驱动默认值：500 ms
实际实验：
0.5 s → FAIL
1.0 s → FAIL
2.0 s → PASS
3.0 s → PASS十六、最终判断
问题并不是：
i915 无法训练 DP link因为软件日志始终可以报告：
DP Training successful真正的问题更接近：
这块具体 eDP 面板在完全断电后，需要比 Linux i915 当前使用的 500 ms 更长的恢复时间。
如果驱动过早重新上电：
Panel Off
↓
约 500 ms
↓
Panel On面板内部状态机偶发无法正常恢复。
结果可能表现为：
黑屏
白屏
绿屏而 GPU 端仍认为：
Link Training successful十七、修复方向
最终决定不修改：
power_up
power_down
backlight_on
backlight_off只提高：
panel_power_cycle_delay的最低值。
目标：
500 ms
→
至少 2000 ms修改逻辑采用：
max(existing_value, 2000)而不是简单写死为：
2000这样如果固件本身未来提供了：
> 2000 ms仍然会尊重更大的硬件要求。
十八、经验总结
这次故障最值得记录的不是某一个内核参数，而是排查方法。
当出现：
DRM software state = normal
DP Training = successful
Pipe = active
Backlight = on
但：
Physical panel = abnormal时，不能只继续寻找：
link rate
bpc
resolution
PSR
DDX
Wayland还应该检查：
Panel Power Sequencing尤其是：
panel power cycle delay这是一个典型的“软件状态完全正常，但物理设备内部状态没有真正恢复”的问题。