Hardware

Arch Linux 下 Broadcom BCM4350C0 蓝牙控制器初始化失败与 SMC 重置修复记录

在部分采用 Broadcom 蓝牙控制器的 Intel Mac 硬件上，Arch Linux 可能能够识别蓝牙硬件，却无法真正创建可用的 BlueZ 控制器。典型表现是系统已经加载蓝牙驱动、rfkill 也能看到 hci0，但 KDE 中没有蓝牙图标，bluetoothctl 无法列出控制器。 这类问题并不一定意味着 Linux 缺少驱动，也不一定需要额外安装固件。对于 BCM4350C0 这类通过 UART 连接的控制器，问题可能出在控制器自身保留的通信状态，尤其是 UART 波特率状态。 故障现象 系统已经安装并启用了 BlueZ： 结果显示： 说明用户空间的 Bluetooth 服务本身正常。 继续检查： 没有任何输出。 使用： 则显示： 这说明 BlueZ 服务虽然正常运行，但内核并没有成功向它提供一个可使用的 HCI Controller。 确认硬件是否存在 首先检查 rfkill： 可以看到： 这非常重要。 它说明： 因此问题并不是简单的 Bluetooth 开关状态。 再检查内核模块： …

Linux

用 DPMS 主动测试 eDP 面板断电重启：从随机黑屏到锁定 2000 ms 电源时序

在 Linux 显示故障排查中，很多问题很难复现。 尤其是内置 eDP 屏幕偶发出现黑屏、白屏、绿屏时，如果每次都依赖“重新启动系统看看会不会发生”，不仅效率很低，而且同时改变了太多变量： 很难判断究竟是哪一层导致了故障。 一次实际排查中采用了一种非常有效的方法： 在已经完全正常运行的 KDE Plasma Wayland 桌面中，主动关闭内置显示器，等待指定时间，再重新打开。 通过改变这个等待时间，最终直接找到了 eDP 面板的临界恢复时间，并把问题锁定到了 Panel Power Cycle Timing。 这是一种非常值得记录的显示器测试方法。 一、问题为什么难以定位 故障表现为内置屏幕偶发进入： 奇怪的是，即使物理屏幕已经明显异常，Linux DRM/i915 日志仍可能显示： 也就是说： 但： 这是一个非常关键的矛盾。 它说明不能简单依赖： 来判断物理面板已经真正恢复。 二、传统重启测试的问题 最初可以通过反复重启观察： 期间是否出现故障。 但这种方法有一个严重缺点： 每次重启都同时改变大量状态。 例如一次异常可能涉及： 如果只知道： 实际上几乎无法判断真正的触发条件。 因此需要设计一个实验，把其他因素全部固定，只改变一个变量。 三、关键思路：在正常 Plasma 中重新关开屏幕 KDE Plasma 提供了： 可以直接控制显示输出的 DPMS 状态。 最基本的测试： …

Linux

将 Arch Linux 从普通内核迁移到 LTS，并重新维护自定义 i915

背景 系统原本运行： 并安装了针对： 编译的自定义 i915。 运行状态： 随后系统更新提供： 以及： 这意味着旧模块不能继续使用。 一、为什么考虑 LTS Arch 普通： 更新频率较高。 而这种机器每次内核 release 改变后，都需要重新编译： 因此长期维护成本较高。 于是改用： 作为唯一主力内核。 需要注意： LTS 并不意味着永远不用重新编译模块。 只要： 发生变化，自定义 i915 原则上仍应重新编译。 但 LTS 的主线变化更保守，更适合作为长期维护基础。 二、安装 LTS 完整升级时安装： 当时实际得到： 运行 release： 三、升级后不要立即重启 这是整个维护流程中最重要的规则： 内核升级完成后，在新自定义 i915 准备完成之前不要重启。 此时： 旧内核已经加载的自定义 i915 仍然正常工作。 这为编译新模块提供了一个安全窗口。 四、获取精确 Arch linux-lts 源码 …

Linux

在另一台 Arch 机器上复用 SDDM Wayland 配置：哪些配置能复制，哪些不能

背景 另一台 Arch KDE 机器也采用： 但 SDDM 仍是 X11。 由于第一台机器已经验证： 可以稳定运行，于是将桌面层配置迁移过去。 一、可以复用的内容 例如： 以及： 还有： 等 Wayland Greeter 组件。 二、不能直接复制缩放比例 第一台机器可能使用： 第二台机器则可能是： 因此应该依据： 查看当前机器的实际配置。 不能简单把整个： 从另一台设备复制过来。 三、旧 Intel DDX 同样可以审计 第二台机器也曾安装： 但 Xorg 日志实际加载： 因此它同样属于： 的旧组件。 四、最重要的区别：不要复制硬件 workaround 第一台机器使用了： 这是针对具体内置面板行为得出的硬件 workaround。 第二台机器不存在相同故障。 因此绝不能因为： 就直接复制这个内核补丁。 可以复用的是： 不能复用的是： 这是维护多台 Linux 设备时非常重要的边界。

Linux

KDE Plasma：将 SDDM 从 X11 迁移到 Wayland，并统一 HiDPI

背景 显示时序问题解决以后，系统重新测试： 这一次启动稳定。 由此证明之前 SDDM Wayland 的高故障率其实是： 而不是 Wayland 本身存在根本故障。 一、原始 SDDM 状态 系统默认： 旧 HiDPI 配置： 并存在： 二、Wayland 配置 建立： 内容： 三、为什么移除 QT_FONT_DPI 在 X11 环境中常见： 但 Wayland 下缩放由 compositor/KWin 自己处理。 如果同时使用： 可能产生“双重缩放”。 因此 Wayland SDDM 中只保留： 四、统一 SDDM 和 Plasma 缩放 Plasma： 随后将 SDDM 对当前显示器的 KWin output 配置也调整为： …

Linux

如何验证一个内核显示时序补丁：DPMS、连续重启与“假失败”

背景 完成： 后，不能仅凭“成功启动一次”就判断问题解决。 需要验证： 一、首先检查运行态参数 读取： 必须看到： 如果仍然是： 说明当前运行的并不是修改后的 i915。 二、验证实际加载模块 应指向： 而不是： 同时： 应与： 一致。 三、启动时出现约 2 秒黑屏反而是预期结果 补丁生效后，启动过程中观察到两个明显的黑屏阶段： 第一次对应： 第二次对应： 这与补丁的： 完全一致。 因此这里的短暂黑屏不是故障，而是面板确实在等待完整 power-cycle interval。 四、DPMS 压力测试 补丁前： 而： 这一实验其实已经给 2000 ms 修改提供了非常强的直接证据。 因为它绕开了： 单独验证了： 这一变量。 五、连续自动重启测试 后来还设计了一个 systemd 测试服务，用于连续重启。 脚本每次： 连续成功记录： 六、第七次出现“FAIL”，但并不是屏幕故障 某次脚本输出： 服务随后自动停止。 但进入系统后人工立即读取： 同时自定义模块路径也正确。 因此这是： …

Linux

单独编译 Arch Linux i915：为 eDP Panel Power Cycle 增加 2000 ms 最低延迟

背景 已经通过独立实验确认： 对于目标机器的内置 eDP 面板过短。 实验结果： 因此决定修改 Linux i915 源码。 一、源码位置 相关实现位于： 关键赋值： 修改为： 实际也可以写成单行： 二、为什么使用 max() 这个修改不是： 而是： 逻辑相当于： 这样比直接： 更合理。 三、为什么不修改其他 PPS 参数 原参数例如： 实验只证明： 与故障高度相关。 没有证据表明： 存在问题。 因此遵循最小修改原则，只改变： 四、内核模块必须精确匹配当前内核 例如某次使用： 自定义模块的： 也必须是： 不能拿旧模块直接加载到： 甚至不能假设同一个主版本的小更新也兼容。 五、Arch localversion 很重要 Arch 内核源码不仅包含： 还会使用： 例如： 中的： 必须正确生成。 否则编译出的模块可能出现： 六、使用官方 Module.symvers 单独编译外部或局部模块时，一个关键文件是： …

Linux

Arch Linux 下内置屏幕随机黑屏、白屏、绿屏：一次 eDP 电源时序故障的完整定位

问题背景 一台 Intel 平台笔记本安装 Arch Linux + KDE Plasma Wayland 后，内置屏幕偶发出现非常异常的显示状态： 这些异常主要发生在： 机器同时安装其他操作系统，可以方便进行交叉验证。 一个很重要的现象是： 其他操作系统长期使用基本正常，而 Linux 图形环境下更容易触发故障。 因此最初判断倾向于： 而不是简单的 LCD 面板物理损坏。 一、安全测试原则 在多次实验后发现，异常显示状态不宜长期保持。 尤其是绿屏状态，应立即关机。 黑屏和白屏虽然没有绿屏那么明显，但也不建议为了观察日志而让屏幕长时间保持异常，因为曾观察到： 因此后续测试采用原则： 一旦发生持续黑屏、白屏或绿屏，应尽快结束测试；绿屏尤其应立即断电关机。 二、首先排除基本硬件输出能力 Arch Live 环境中的纯命令行 TTY 多次启动均正常。 内屏在 TTY 状态下能够稳定运行，包括： 这非常重要。 因为故障状态下，DRM 软件层看到的参数往往也完全相同。 因此以下假设逐渐被削弱： 三、尝试过但没有解决问题的 i915 参数 排查过程中曾测试多项常见 Intel 显示参数。 PSR 测试： 早期曾看起来有所改善，但继续测试后仍然可以出现异常。 因此： …

Windows

清理 Windows NetworkList 中不断累积的“网络名称 2、3、4”历史记录

问题现象 一台长期使用、经历过多次系统迁移、网卡变化或连接环境变化的 Windows 电脑，可能会出现这样的网络名称： 或者： 甚至几十条。 这些记录并不一定意味着系统中保存了几十个 Wi-Fi 密码。 真正的 Wi-Fi 配置和 Windows 的 NetworkList 网络历史记录，是两个不同的系统。 这一区别非常重要。 一、Windows 实际上保存了两类网络信息 WLAN Profile Wi-Fi SSID、密码、加密方式、自动连接设置等主要由 WLAN Profile 保存。 查看： 输出类似： 这些配置包含真正的 Wi-Fi 连接参数。 删除： 会导致保存的 Wi-Fi 配置一起消失。 如果目标只是整理“网络 2、网络 3”之类的历史名称，通常不应该执行这个命令。 NetworkList Windows 还维护另一套网络识别数据库： 其中最重要的两个区域是： Profiles 负责保存 Windows 曾经识别到的网络身份。 Signatures 则负责保存识别这些网络时使用的一些特征，例如： 于是，即使 Wi-Fi …

Windows

Windows 卸载 Wacom 后仍残留控制面板项目与驱动，如何完整清理

问题现象 Windows 中卸载 Wacom 软件后，有时仍会出现以下现象： 这种情况通常并不是 Wacom 软件仍然完整安装，而是卸载程序没有把 Windows 中的注册信息、服务和 Driver Store 驱动包全部清理掉。 比较常见的残留可以分成四类： 因此，仅仅删除程序目录通常不能解决问题。 一、先确认 Wacom 软件是否真的已经卸载 首先检查 Windows 的软件卸载注册表： 如果没有结果，说明常规意义上的 Wacom 应用程序已经不存在。 接着检查程序目录： 如果这里也没有内容，而控制面板中仍存在 Wacom 项目，那么基本可以确定属于残留注册。 二、检查控制面板 CPL 残留 Windows 传统控制面板允许第三方软件通过以下位置注册控制面板组件： 读取： 典型的异常情况是： 但对应的 EXE 已经不存在。 这就是一个非常明确的失效注册项。 删除前建议备份： 然后只删除 Wacom 对应的值： 不同语言版本 Windows 中的值名称可能不同，因此实际操作前应先读取，而不是直接套用固定名称。 三、检查 Control Panel Namespace …