企业官网建设流程全解析

机型：联想 ThinkBook 14 G5+ IRH（21HW）｜ i5-13500H ｜ Ubuntu 24.04.4 LTS + Windows 11 双系统
关键词：Type-C 无信号、DP Alt Mode 失效、USB-C 只有 USB 功能没有视频、HDMI 正常、EC 复位无效、BIOS 禁用内置电池、放电

〇、结论先行（TL;DR）

如果你也遇到「Type-C 口充电/USB 正常，但外接显示器一直无信号；换线、换口、换显示器、换系统都没用；HDMI 却完全正常」，不用急着报修，先试这一招：

BIOS →Configuration→Disable Building-in Battery（禁用内置电池）→ 机器自动关机 → 拔掉电源适配器和所有外接 → 长按电源键 30 秒放电 → 接电源开机 → 回 BIOS 把内置电池启用回来

我这边亲测一次成功，Type-C 的 DisplayPort 输出立刻恢复（4K@60）。下面把整个排查过程、原理和踩的坑都记录下来。

一、故障现象

起因其实是个小问题：笔记本挂起（sleep）唤醒后，外接显示器不亮。

排查这个问题的过程中，Type-C 的显示输出彻底挂了，具体表现：

1. 显示器走Type-C 一线通（显示器原生 Type-C 输入）→完全无信号，显示器提示"No signal"，然后进待机
2. 同一个 Type-C 口：USB 数据完全正常（显示器的 USB Hub 照样枚举，键鼠能用）
3. HDMI 口一切正常，能出 4K@60
4. 同一根线 + 同一台显示器，接另一台电脑完全正常→ 线和显示器都没问题
5. 换另一个 Type-C 口、Type-C 线正反插 → 全部无效
6. 进 Windows 测试 → 同样无信号→ 排除 Linux 驱动问题
7. 长按电源键 EC 复位、Thunderbolt 控制器 unbind/bind、显示器断电重启 → 全部无效

二、环境信息

三、先搞懂原理：Type-C 出图到底经过什么

“Type-C 直连"不等于"Type-C 视频信号”。Type-C 只是接口形状，一根线里同时跑三样东西：

笔记本 Type-C ───────── 同一根线 ───────── 显示器 Type-C │ ├─ CC 线 ：PD 供电协商 + 协商"高速线这轮给谁用"（Enter Mode / SVID 0xff01） ├─ D+ / D- ：USB 2.0 数据（不受 alt mode 影响，永远可用） └─ 4 对高速差分对 ：要么给 USB 3.x，要么给 DisplayPort —— 由端口 mux/redriver 切换 │ └─ 切给 DP 之后 → Intel i915 的 DP-x 连接器出图 → 显示器拉 HPD → 读 EDID

出图必须走完 4 步：

⚠️ 关键点：第 2、3 步跑在联想 EC/PD 固件里，操作系统完全看不到也管不了。这台机器上/sys/class/typec是空的，UCSI 设备USBC000:00一直处于waiting_for_supplier。所以任何"在系统里折腾驱动/内核参数"的努力都是白费——问题在系统之下。

四、排查过程（逐条排除）

4.1 看系统里端口到底有没有信号

# 四个连接器状态（card1 = Intel i915）forcinDP-1 DP-2 HDMI-A-1 eDP-1;doecho"$c:$(cat/sys/class/drm/card1-$c/status)"done# 输出：DP-1 disconnected / DP-2 disconnected / HDMI-A-1 connected / eDP-1 connected# EDID 长度（0 = 内核根本没读到显示器身份）cat/sys/class/drm/card1-DP-1/edid|wc-c# → 0# 同一根 Type-C 线上的 USB 设备是否还在（证明线是通的）lsusb|grep-i1a86# → QinHeng Electronics USB HUB（显示器内置 Hub）

结论：disconnected+ EDID=0 =DP lanes 根本没被接通，第 4 步压根没开始；而 USB 还在 = 第 1 步正常。“一条线里两个通路，一个活一个死”，这是整个问题的钥匙。

4.2 排除显示器、线、系统

• 同线同显示器接另一台电脑 → 正常 ⇒显示器和线排除
• HDMI 从这台笔记本出图 → 正常 ⇒GPU、i915、显示器面板排除
• 进 Windows → 同样无信号 ⇒Linux 驱动/UCSI 排除

到这里可以断定：故障在笔记本侧的 PD/mux 通路，而且不是操作系统层面的。

4.3 试试"复位"类操作（全部无效）

# 1) EC 复位：关机后长按电源键 20~30 秒# 2) Thunderbolt 控制器重新加载echo0000:00:0d.2|sudotee/sys/bus/pci/drivers/thunderbolt/unbindsleep3echo0000:00:0d.2|sudotee/sys/bus/pci/drivers/thunderbolt/bind# 3) 显示器断电 30 秒、Type-C 正反插、换线换口# 4) 电源逐个接通/断开（讨论 Type-C 供电角色）

全部无效。原因见 4.4。

4.4 为什么这些"复位"都没用？

因为只要内置电池还接在主板上，EC/PD 控制器就一直有电，它的 PD 状态机（以及端口 mux 的配置）不会被清空。长按电源键只能做到"EC 软复位"，恢复不了被锁死的 alt-mode 状态。

验证一下固件信息，确认没有遗漏的更新途径：

# 固件更新历史（有没有被后台刷过固件）fwupdmgr get-history# → No history# BIOS/EC 等固件设备清单（含 UEFI Device Firmware）fwupdmgr get-devices2>/dev/null|grep-A3"UEFI Device Firmware"# BIOS 版本cat/sys/class/dmi/id/bios_version# → LBCN29WW（2025-03-21）

4.5 真凶浮现：一次deep(S3) 挂起

既然 Type-C 之前是好的，就去翻内核日志，看它是什么时候没的：

# 所有挂起/恢复记录journalctl --no-pager|grep-E"PM: suspend (entry|exit)"# 关键输出（截取）：# Sep 26 14:35:29 PM: suspend entry (s2idle) → 14:35:32 suspend exit （只挂了 3 秒，没事）# Sep 26 14:53:31 PM: suspend entry (deep) ← 全机历史唯一一次 S3# （之后没有任何 "PM: suspend exit"）# Sep 26 15:01:37 ← 冷启动（说明这中间被强制断电了）# 统计一下到底挂起过几次 deepjournalctl --no-pager|grep-c"PM: suspend entry (deep)"# → 1journalctl --no-pager|grep-c"PM: suspend entry (s2idle)"# → 111

时间线（这是破案的关键）：

结论：这台机器默认s2idle（111 次全好），而deep(S3) 只在历史里出现过1 次，恰好就是出事那次，且没有恢复记录。S3 会把 Type-C/TCSS 控制器整个断电重来，而这台机器的 EC 固件没能把 DP Alt Mode 恢复回来，于是 PD/mux 状态被永久锁死。

五、根因分析

1. 触发：把mem_sleep从平台默认的s2idle改成deep(S3)，然后执行挂起。该机型的 S3 路径明显没有被良好验证（111 次挂起全是 s2idle，deep 只有这一次）。
2. 损坏点：S3 进入/（失败的）恢复过程让 Type-C 的 PD 状态机 + 端口 mux 停在中间态；之后 EC 再也不会重新协商Enter Mode。
3. 为什么不恢复：EC/PD 状态是"持久"的，普通关机/重启/EC 软复位都不清；必须让 EC 真正断电才能重新初始化。
4. 操作系统无能为力：整条 PD/alt-mode 逻辑不在 Linux（也不在 Windows）里，系统里没有任何可操作对象。

六、最终解决方案（重点，亲测有效）

6.1 核心思路

让主板的 EC/PD 控制器彻底断电一次。联想官方为此提供了 BIOS 选项Disable Building-in Battery：它会把主板与电池的通信切断，机器自动关机后，主板（含 EC/PD 控制器）就能完全放电。

6.2 操作步骤（严格按顺序）

1. 插好电源适配器（⚠️ 必须！禁用电池后，没有适配器无法开机）
2. 开机狂按F1（ThinkBook 常见 F1，不行就试 F2）进入 BIOS
3. 找到Configuration→Disable Building-in Battery（部分版本菜单叫Power/禁用内置电池）
4. 回车 → 选YES→机器自动关机
5. 拔掉电源适配器，并拔掉所有外接设备（Type-C 显示器线、扩展坞、USB 设备）
6. 长按电源键 30 秒（释放主板残余电荷）
7. 接上电源适配器→ 开机
8. 进 BIOS 确认内置电池已启用（多数机型接上适配器后自动恢复；若显示仍为禁用，手动启用回去）
9. 插入 Type-C 显示器 →问题解决✅

6.3 注意事项（血泪教训）

• ⚠️手边必须有原装/可用适配器再操作，否则禁用电池后只能干瞪眼（官方知识库明确写了这条）
• ⚠️ 恢复供电后记得回到 BIOS 把内置电池启用回来
• ℹ️ 该选项需要 BIOS 支持：部分机型 BIOS 里没有这一项，那就只能去联想服务站做硬放电，或直接报修

七、验证结果

修复后（重启后实测）：

forcinDP-1 DP-2 HDMI-A-1 eDP-1;doecho"$c:$(cat/sys/class/drm/card1-$c/status)";done# DP-1: connected ← 回来了！# DP-2: disconnected# HDMI-A-1: connected# eDP-1: connectedcat/sys/class/drm/card1-DP-1/edid|wc-c# → 256（EDID 正常读取 = 真的协商成功）xrandr|grep-E"^(DP|HDMI|eDP)"# DP-1 connected primary 3840x2160+0+0 ← 4K@60# HDMI-1 connected 3840x2160+3840+0# eDP-1 connected 2880x1800+7680+0

Type-C 的 DP Alt Mode 完全恢复，4K@60 正常出图，USB Hub 也照常工作。

八、踩坑与经验总结

✅ 该做的

1. 先分层看现象：Type-C 出问题，先lsusb看 USB 通路、cat /sys/class/drm/cardX-DP-x/status看 DP 通路、edid | wc -c看有没有读到显示器。“一条线里两个通路一活一死”基本就锁定 PD/mux。
2. 先跨系统验证（Windows 试一次），能迅速把"驱动问题"和"固件/硬件问题"分开。
3. 翻PM: suspend entry (deep/s2idle)日志，挂起相关的显示故障十有八九和它有关。
4. 真复位要"断电池"：EC 软复位 ≠ 真正断电，Disable Building-in Battery才是关键一招。

❌ 别做的

1. 不要把/sys/power/mem_sleep设成deep（尤其笔记本平台默认给的是s2idle时）。

cat/sys/power/mem_sleep# 我这款修好后是：[s2idle] deep# 如需查看/切换（不持久，重启复位）：# echo s2idle | sudo tee /sys/power/mem_sleep

2. 不要用"反复禁用/启用外接输出"来模拟插拔测试——这等于反复把 Type-C 上的 DP 链路 down/up，会加重 PD 状态机的负担。（这是我这次的血泪教训：排查中途做过几轮输出通断，虽然当时验证还是好的，但确实让 PD 状态重新协商过多次。）
3. 刷 BIOS / PD 固件时绝对不能中断：PD 固件升级画到一半关窗口，会导致Type-C 口永久损坏（社区已有实例）。升固件务必：接电源、勿断电、勿关窗口。

九、参考链接

1. 联想官方知识库《Thinkbook、扬天、ThinkPad 部分笔记本禁用内置电池的方法》——BIOS 路径Configuration → Disable Building-in Battery及"必须接适配器"的注意事项
2. 知乎《笔记本 Type-C 口接 Type-C 转 DP 线连显示器无信号问题》——同为雷电/Type-C 出图无信号、HDMI 正常，最终靠"BIOS 禁用内置电池 + 放电"解决
3. 知乎《解决 Type-C 扩展坞转 HDMI 和 DP 无信号问题》——针对"之前用得好好的、某天突然不行"的场景，强调禁用内置电池这一步
4. CSDN《【ThinkBook 16+ 电脑重做系统 type-c 接口部分功能失效解决方案】》——ThinkBook 同系机型：充电/外接硬盘正常、接显示器无信号，最后靠 BIOS 禁电放电解决
5. CSDN《ThinkBook16 G4+ ARA 开启 USB4 注意！PD 固件升级中途关窗口会弄坏 Type-C 口》——PD 固件升级中断会永久损坏 Type-C 的实例
6. CSDN《Lenovo Vantage 解决 ThinkBook 16+ 2025 type-c 显示器无信号问题》——另一种成因：独显直连模式禁用核显导致 DP Alt Mode 失效（集显机型不受影响）
7. GitHub issues：omarchy#11908（USB-C 扩展坞挂起后外接屏不回来）、aquamarine#403（USB-C DP-alt 重新插拔后不再识别）——英文社区同类现象

写在最后：这类"USB 好、视频死"的 Type-C 故障，90% 的精力会浪费在操作系统层面。正确的顺序应该是：

先用内核连接器状态 + USB 枚举把故障分层 → 跨系统验证排除驱动 → 查挂起日志找触发点 →直接上 BIOS 断电池放电→ 再不行才考虑固件/硬件。

希望这篇记录能帮你少走几小时弯路。如果对你有帮助，欢迎点赞 + 收藏，也欢迎在评论区补充你遇到的现象和解决办法 👍

记录时间：2026-09-26 机型：ThinkBook 14 G5+ IRH (21HW) 系统：Ubuntu 24.04.4 LTS / Windows 11