背景 系统原本运行： 并安装了针对： 编译的自定义 i915。 运行状态： 随后系统更新提供： 以及： 这意味着旧模块不能继续使用。 一、为什么考虑 LTS Arch 普通： 更新频率较高。 而这种机器每次内核 release 改变后，都需要重新编译： 因此长期维护成本较高。 于是改用： 作为唯一主力内核。 需要注意： LTS 并不意味着永远不用重新编译模块。 只要： 发生变化，自定义 i915 原则上仍应重新编译。 但 LTS 的主线变化更保守，更适合作为长期维护基础。 二、安装 LTS 完整升级时安装： 当时实际得到： 运行 release： 三、升级后不要立即重启 这是整个维护流程中最重要的规则： 内核升级完成后，在新自定义 i915 准备完成之前不要重启。 此时： 旧内核已经加载的自定义 i915 仍然正常工作。 这为编译新模块提供了一个安全窗口。 四、获取精确 Arch linux-lts 源码 …
背景 另一台 Arch KDE 机器也采用： 但 SDDM 仍是 X11。 由于第一台机器已经验证： 可以稳定运行，于是将桌面层配置迁移过去。 一、可以复用的内容 例如： 以及： 还有： 等 Wayland Greeter 组件。 二、不能直接复制缩放比例 第一台机器可能使用： 第二台机器则可能是： 因此应该依据： 查看当前机器的实际配置。 不能简单把整个： 从另一台设备复制过来。 三、旧 Intel DDX 同样可以审计 第二台机器也曾安装： 但 Xorg 日志实际加载： 因此它同样属于： 的旧组件。 四、最重要的区别：不要复制硬件 workaround 第一台机器使用了： 这是针对具体内置面板行为得出的硬件 workaround。 第二台机器不存在相同故障。 因此绝不能因为： 就直接复制这个内核补丁。 可以复用的是： 不能复用的是： 这是维护多台 Linux 设备时非常重要的边界。
背景 显示时序问题解决以后，系统重新测试： 这一次启动稳定。 由此证明之前 SDDM Wayland 的高故障率其实是： 而不是 Wayland 本身存在根本故障。 一、原始 SDDM 状态 系统默认： 旧 HiDPI 配置： 并存在： 二、Wayland 配置 建立： 内容： 三、为什么移除 QT_FONT_DPI 在 X11 环境中常见： 但 Wayland 下缩放由 compositor/KWin 自己处理。 如果同时使用： 可能产生“双重缩放”。 因此 Wayland SDDM 中只保留： 四、统一 SDDM 和 Plasma 缩放 Plasma： 随后将 SDDM 对当前显示器的 KWin output 配置也调整为： …
背景 完成： 后，不能仅凭“成功启动一次”就判断问题解决。 需要验证： 一、首先检查运行态参数 读取： 必须看到： 如果仍然是： 说明当前运行的并不是修改后的 i915。 二、验证实际加载模块 应指向： 而不是： 同时： 应与： 一致。 三、启动时出现约 2 秒黑屏反而是预期结果 补丁生效后，启动过程中观察到两个明显的黑屏阶段： 第一次对应： 第二次对应： 这与补丁的： 完全一致。 因此这里的短暂黑屏不是故障，而是面板确实在等待完整 power-cycle interval。 四、DPMS 压力测试 补丁前： 而： 这一实验其实已经给 2000 ms 修改提供了非常强的直接证据。 因为它绕开了： 单独验证了： 这一变量。 五、连续自动重启测试 后来还设计了一个 systemd 测试服务，用于连续重启。 脚本每次： 连续成功记录： 六、第七次出现“FAIL”，但并不是屏幕故障 某次脚本输出： 服务随后自动停止。 但进入系统后人工立即读取： 同时自定义模块路径也正确。 因此这是： …
背景 已经通过独立实验确认： 对于目标机器的内置 eDP 面板过短。 实验结果： 因此决定修改 Linux i915 源码。 一、源码位置 相关实现位于： 关键赋值： 修改为： 实际也可以写成单行： 二、为什么使用 max() 这个修改不是： 而是： 逻辑相当于： 这样比直接： 更合理。 三、为什么不修改其他 PPS 参数 原参数例如： 实验只证明： 与故障高度相关。 没有证据表明： 存在问题。 因此遵循最小修改原则，只改变： 四、内核模块必须精确匹配当前内核 例如某次使用： 自定义模块的： 也必须是： 不能拿旧模块直接加载到： 甚至不能假设同一个主版本的小更新也兼容。 五、Arch localversion 很重要 Arch 内核源码不仅包含： 还会使用： 例如： 中的： 必须正确生成。 否则编译出的模块可能出现： 六、使用官方 Module.symvers 单独编译外部或局部模块时，一个关键文件是： …
问题背景 一台 Intel 平台笔记本安装 Arch Linux + KDE Plasma Wayland 后，内置屏幕偶发出现非常异常的显示状态： 这些异常主要发生在： 机器同时安装其他操作系统，可以方便进行交叉验证。 一个很重要的现象是： 其他操作系统长期使用基本正常，而 Linux 图形环境下更容易触发故障。 因此最初判断倾向于： 而不是简单的 LCD 面板物理损坏。 一、安全测试原则 在多次实验后发现，异常显示状态不宜长期保持。 尤其是绿屏状态，应立即关机。 黑屏和白屏虽然没有绿屏那么明显，但也不建议为了观察日志而让屏幕长时间保持异常，因为曾观察到： 因此后续测试采用原则： 一旦发生持续黑屏、白屏或绿屏，应尽快结束测试；绿屏尤其应立即断电关机。 二、首先排除基本硬件输出能力 Arch Live 环境中的纯命令行 TTY 多次启动均正常。 内屏在 TTY 状态下能够稳定运行，包括： 这非常重要。 因为故障状态下，DRM 软件层看到的参数往往也完全相同。 因此以下假设逐渐被削弱： 三、尝试过但没有解决问题的 i915 参数 排查过程中曾测试多项常见 Intel 显示参数。 PSR 测试： 早期曾看起来有所改善，但继续测试后仍然可以出现异常。 因此： …
问题现象 一台长期使用、经历过多次系统迁移、网卡变化或连接环境变化的 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 中卸载 Wacom 软件后，有时仍会出现以下现象： 这种情况通常并不是 Wacom 软件仍然完整安装，而是卸载程序没有把 Windows 中的注册信息、服务和 Driver Store 驱动包全部清理掉。 比较常见的残留可以分成四类： 因此，仅仅删除程序目录通常不能解决问题。 一、先确认 Wacom 软件是否真的已经卸载 首先检查 Windows 的软件卸载注册表： 如果没有结果，说明常规意义上的 Wacom 应用程序已经不存在。 接着检查程序目录： 如果这里也没有内容，而控制面板中仍存在 Wacom 项目，那么基本可以确定属于残留注册。 二、检查控制面板 CPL 残留 Windows 传统控制面板允许第三方软件通过以下位置注册控制面板组件： 读取： 典型的异常情况是： 但对应的 EXE 已经不存在。 这就是一个非常明确的失效注册项。 删除前建议备份： 然后只删除 Wacom 对应的值： 不同语言版本 Windows 中的值名称可能不同，因此实际操作前应先读取，而不是直接套用固定名称。 三、检查 Control Panel Namespace …
前言 Rime 本身是一套高度可定制的输入法框架。除了常规的拼音输入、词库管理和候选排序之外，还可以通过 Lua 扩展实现动态内容生成。 一个比较实用的例子，是输入特定拼音后直接生成当前日期、当前时间、星期等内容。例如： 可以分别得到类似： 这些内容不是提前写进词典的静态词条，而是在输入时调用系统时间动态产生。 这一功能最初在 Linux 环境下完成并稳定使用。之后需要将同样的能力迁移到 Windows 上的 Rime，也就是小狼毫 Weasel。 实际迁移过程并不是简单复制一个文件即可完成。Linux 与 Windows 的 Rime 前端、用户目录以及部署行为都存在差异，尤其是在 Windows 上还遇到了重新部署后 build 内容没有正确刷新的情况。 经过多轮检查和最小化修改，最终成功在 Windows 上完整复现了 Linux 下的动态日期时间输入功能。 一、Linux 下的实现结构 Linux 环境使用 Fcitx5 + Rime。 实际生效的 Rime 用户目录位于： 动态日期时间功能主要由三个部分构成： 完整调用链可以概括为： 这说明该功能本质上是一个 Rime Lua Translator。 二、rime.lua：注册 Lua 模块 Rime …
在一块外置 SSD 上同时安装 macOS、Windows 和 Linux 后，启动 macOS 时可能反复出现下面的提示： The disk you attached was not readable by this computer. 窗口通常提供三个选项： 与此同时，桌面上的 macOS 数据卷以及部分 Windows NTFS 分区可能仍然能够正常显示。这种现象并不一定代表硬盘损坏，更常见的原因是 macOS 扫描到了一个自己无法识别或无法挂载的分区。 使用场景 例如，一块 USB SSD 同时包含： 进入 macOS 后，桌面上可能正常出现类似： 这样的磁盘卷，但系统仍然弹出“磁盘不可读取”的警告。 这说明整块 SSD 并没有无法识别，而只是其中某一个分区没有被 macOS 正常处理。 为什么会出现这个提示 macOS 启动后，Disk Arbitration 会检测当前连接磁盘上的各个分区。 如果遇到 macOS 无法识别或无法挂载的文件系统，就可能弹出： …