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 状态。 最基本的测试： …