关于 Redrix（HP Elite Dragonfly Chromebook）在 Linux 下的部分问题和解决方案
本文将记录我在 HP Elite Dragonfly Chromebook (redrix) 上运行 Linux 以来遇到的各种硬件问题和解决方案。随着时间推移，通过修改 EC 固件和内核更新，多个原本不可用的问题已经得到解决。希望这些经验能帮助到同样在非 ChromeOS 系统上使用这台机器的朋友。
| 功能 | 状态 | 方案概要 |
|---|---|---|
| 指纹识别 | ✅ | libfprint 补丁 |
| 摄像头 (IPU6) | ✅ | pipewire-libcamera + pw-v4l2 曲线救国 |
| USB4 / 雷电 | ✅ | 修改 EC 固件，禁用 AP Mode Entry |
| 休眠 / 睡眠 | ✅ | Linux 7.0 内核修复 |
| 侧边功能键 | ✅ | 修改 EC 固件，启用 MKBP SCI 通路 |
| 键盘背光 | ✅ | 修改 EC 固件，sysjump 后重注册驱动 |
| 触控板失灵 | ✅ | 随睡眠问题修复而消失 |
| 音频 | ⚠️ | 正常使用，暂停时有轻微爆音 |
| 个别组合键 | ❌ | 硬件按键矩阵限制，无解 |
| HP 隐私屏 | ❌ | 无软件开关，专用按键不可映射 |
| 符号 | 意义 |
|---|---|
| ✅ | 没有任何问题，或者瑕疵不影响使用 |
| ⚠️ | 存在影响使用的小问题 |
| ❌ | 存在大问题，或完全不可用 |
指纹识别 ✅
对libfprint打补丁后可以正常工作了。
至于具体要如何添加指纹、设置pam规则，这就是libfprint的内容了。
我也在AUR上打了一个包libfprint-crfpmoc-git。
IPU6摄像头 ✅
只要能通过 cam -l 发现摄像头，就问题不大。
$ cam -l 2>/dev/null
Available cameras:
1: 'hi556' (\_SB_.PCI0.I2C2.CAM0)
此时，虽然libcamera可以使用，但很多依赖传统v4l2的程序会出问题，
因为IPU6不提供经典可用的/dev/video0，而是分成小块，但每一个都不可用：
$ v4l2-ctl --list-devices
ipu6 (PCI:0000:00:05.0):
/dev/video0
/dev/video1
/dev/video2
... 省略很多杂乱的v4l2设备
面对这种情况，安装 pipewire-libcamera 包即可通过pipewire使用摄像头。
$ pw-cli ls Device | grep device.api -A2
device.api = "alsa"
device.description = "Alder Lake PCH-P High Definition Audio Controller"
device.name = "alsa_card.pci-0000_00_1f.3-platform-adl_rt5682_def"
--
device.api = "v4l2"
device.description = "ipu6"
device.name = "v4l2_device.pci-0000_00_05.0"
--
device.api = "v4l2"
device.description = "ipu6"
device.name = "v4l2_device.pci-0000_00_05.0.2"
--
device.api = "v4l2"
device.description = "ipu6"
device.name = "v4l2_device.pci-0000_00_05.0.3"
... 省略很多杂乱的v4l2设备
而pipewire是有pw-v4l2工具为传统的v4l2提供兼容的。
最终可以“曲线救国”：
$ pw-v4l2 v4l2-ctl --list-devices
ipu6 (PCI:0000:00:05.0):
/dev/media0
hi556 (platform:PipeWire-111):
/dev/video0
这里的/dev/video0就可以作为v4l2设备直接使用。
不想显式使用pw-v4l2，设置一下环境变量就好了：
$ LD_PRELOAD=/usr/lib/pipewire-0.3/v4l2/libpw-v4l2.so v4l2-ctl --list-devices
ipu6 (PCI:0000:00:05.0):
/dev/media0
hi556 (platform:PipeWire-111):
/dev/video0
小窍门
如果嫌弃 v4l2污染pipewire，可以通过如下配置文件隐藏杂乱的v4l2设备：
~/.config/wireplumber/wireplumber.conf.d/99-disable-v4l2.conf
wireplumber.profiles = {
main = {
monitor.v4l2 = disabled # 完全停用 V4L2 监视器
}
}
再重启pipewire：systemctl --user restart pipewire.service wireplumber.service
$ pw-cli ls Device
id 43, type PipeWire:Interface:Device/3
object.serial = "43"
factory.id = "15"
client.id = "41"
device.api = "alsa"
device.description = "Alder Lake PCH-P High Definition Audio Controller"
device.name = "alsa_card.pci-0000_00_1f.3-platform-adl_rt5682_def"
device.nick = "sof-rt5682"
media.class = "Audio/Device"
id 64, type PipeWire:Interface:Device/3
object.serial = "64"
factory.id = "15"
client.id = "41"
device.api = "libcamera"
device.description = "Unknown device"
device.name = "libcamera_device.0"
media.class = "Video/Device"
瞬间安静了
潜在的问题
通过ffplay看不明显：
通过原始的libcamera看，明显有点偏色：
这就很奇怪了，ffplay拿到的是libcamera -> pipewire -> v4l2 的好几手中转数据，怎么色彩上会更好呢？
不过我觉得这不会太影响体验，算作瑕疵吧。
USB4 / 雷电 ✅
通过修改 EC 固件，USB4/Thunderbolt 已可以开箱即用。原理和修复细节见：
https://github.com/acd407/chrome-ec/blob/redrix-rw/README.zh-CN.md#usb-pd-ap-mode-entryusb4--雷电自动协商
简而言之，原厂 EC 固件启用了 CONFIG_USB_PD_REQUIRE_AP_MODE_ENTRY，EC 不会主动协商 USB4/雷电模式，而是等待 ChromeOS 的 AP 端通过 host command 来控制模式切换。非 ChromeOS 系统上没有这个 AP 端组件，EC 就一直停在 USB3 模式。禁掉该选项后，EC 自主协商最优模式（USB4 > TBT > DP）。
实测搭载 RTX 3060 12G 的 ASM2464PD 显卡拓展坞，一切正常：
$ boltctl
● CYID TBT-U4
├─ type: peripheral
├─ name: TBT-U4
├─ vendor: CYID
├─ uuid: 0c634c17-2060-5b85-ffff-ffffffffffff
├─ generation: USB4
├─ status: authorized
│ ├─ domain: d81f8780-51ff-5621-ffff-ffffffffffff
│ ├─ rx speed: 40 Gb/s = 2 lanes * 20 Gb/s
│ ├─ tx speed: 40 Gb/s = 2 lanes * 20 Gb/s
│ └─ authflags: none
├─ authorized: 2026年05月27日 星期三 08时20分44秒
├─ connected: 2026年05月27日 星期三 08时20分44秒
└─ stored: 2026年05月17日 星期日 08时44分26秒
├─ policy: iommu
└─ key: no
$ lspci
...
2c:00.0 PCI bridge: ASMedia Technology Inc. ASM2464PD USB4 Device Controller 40G
2d:00.0 PCI bridge: ASMedia Technology Inc. ASM2464PD USB4 Device Controller 40G
2e:00.0 VGA compatible controller: NVIDIA Corporation GA106 [GeForce RTX 3060] (rev a1)
2e:00.1 Audio device: NVIDIA Corporation GA106 High Definition Audio Controller (rev a1)
...
$ nvidia-smi
Wed May 27 16:23:43 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 595.71.05 Driver Version: 595.71.05 CUDA Version: 13.2 |
+-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA Graphics Device Off | 00000000:2E:00.0 Off | N/A |
| 0% 27C P8 4W / 170W | 1MiB / 12288MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| No running processes found |
+-----------------------------------------------------------------------------------------+
受限于 ASM2464 PCIe Gen4 x4 的带宽上限（约 7.8 GB/s），RTX 3060 只能跑在 PCIe Gen3 x4 下（约 3.9 GB/s），有少许性能损失。日常使用和 CUDA 推理完全不受影响。
音频 ⚠️
参考chromebook-linux-audio，但存在瑕疵。
潜在的问题
当音频暂停播放后，默认5秒钟后pipewire会suspend，进入低功耗状态，以节省能源。
在这个过程中由于未明确的问题会出现啪的一声。
使用如下配置可以让pipewire迅速进入suspend，以让啪和暂停的动作联系起来，避免在安静时被吓一跳。
~/.config/wireplumber/wireplumber.conf.d/99-alsa-suspend.conf
monitor.alsa.rules = [
{
matches = [
{
## Matches all sinks.
node.name = "~alsa_output.*"
}
]
actions = {
update-props = {
## 0 disables suspend
session.suspend-timeout-seconds = 0.1
}
}
}
]
HP 隐私屏 ❌
Linux内核中应该是提供了底层的支持的，可见于drivers/platform/chrome/chromeos_privacy_screen.c。
$ ls /sys/module/chromeos_privacy_screen/
coresize drivers/ holders/ initsize initstate notes/ refcnt sections/ srcversion taint uevent
$ ls /sys/class/drm/privacy_screen-GOOG0010:00/
device@ hw_state power/ subsystem@ sw_state uevent
$ journalctl -b -k | grep -i "GOOG0010"
3月 04 14:25:39 cachyos kernel: Found 'privacy_screen-GOOG0010:00' privacy-screen provider
3月 04 14:25:40 cachyos kernel: chromeos_privacy_screen_driver GOOG0010:00: registered privacy-screen 'privacy_screen-GOOG0010:00'
但现在还不知道怎么用。
另外，HP 隐私屏占用了一个专门的按键，这个按键当前也是无法使用、无法重映射。
chrultrabook forum 上有讨论，可以进一步跟踪
ChromeOS 设备功能键 ✅
5 月 27 日更新
通过修改 EC 固件已完全修复。问题根因、原理分析和修复细节见：
https://github.com/acd407/chrome-ec/blob/redrix-rw/README.zh-CN.md#mkbp-host-event-事件传递侧边音量按键无效
简而言之，EC 有两条通知 AP 的硬件路径：GPIO 中断和 eSPI SCI。非 ChromeOS 系统上 GPIO 中断路径不通（/proc/interrupts 中 chromeos-ec 中断计数不增长），根因是 ACPI GPIO 中断映射配置不完整。修复方案是启用 SCI 路径作为备选，使 MKBP 事件通过 eSPI 虚拟线到达 AP。
原情况
这是按下按键时EC的日志，EC 侧完全正常：
[85746.715188 Button 'Volume Up' was pressed]
[85746.715768 mkbp buttons: 2]
[85746.876173 Button 'Volume Up' was released]
[85746.876759 mkbp buttons: 0]
[85747.582414 Button 'Volume Down' was pressed]
[85747.583371 mkbp buttons: 4]
[85747.821545 Button 'Volume Down' was released]
[85747.822581 mkbp buttons: 0]
但 AP 侧收不到事件，chromeos-ec 中断不增长：
$ cat /proc/interrupts | grep chromeos-ec
101: 19 IR-IO-APIC 101-fasteoi chromeos-ec # 按按键前后不变
个别组合键无法触发 ❌
我发现的是meta-ctrl-5和meta-ctrl-6。
在tty上用showkey命令监控键盘，按下meta-ctrl后挨个按1到9，很容易发现问题，其他的像meta-ctrl-4或meta-ctrl-7都可以响应，唯独5和6不可以。
Windows上同样不可用，怀疑是硬件连线的限制。
休眠、睡眠（S3、s0ix） ✅
5 月 27 日更新
在用 Linux 7.0 一个多月之后，我好像再也没有遇到过睡眠问题了，那就标记为正常了
3 月 10 日更新
事情起了一些变化，详见cros_ec_timeout。
原情况
这是一个大坑，所有类型的、无论是否合盖的睡眠，都不可用。
而且众所周知，关于关机、睡眠的问题都极难调试，难以稳定复现。
存在一些解决方案，但都不稳定。
重新加载内核模块的方法，十分容易造成painc，完全不推荐。
而使用ectool hostsleepstate freeze，有概率成功，但同时有重启的风险，也不推荐。
chrultrabook forum和github上有专门的讨论。
触控板失灵 ✅
5 月 27 日更新
我已经很久没有遇到过这个问题了，就标记为正常了
原情况
这个机器的触控板还是挺好的，全域压力触控板。
我偶尔碰到几回触控板失灵，似乎是在测试睡眠时发生的。暂时还不清楚确定的原因。
缓解办法
用 Chromebook 的十有八九同时在用keyd处理按键映射吧。
要先停止keyd，否则会导致驱动程序崩溃。
然后再重载hid_multitouch驱动程序：
modprobe -r hid_multitouch
modprobe hid_multitouch
失去键盘背光 ✅
5 月 27 日更新
通过修改 EC 固件已完全修复。问题根因、原理分析和修复细节见：
https://github.com/acd407/chrome-ec/blob/redrix-rw/README.zh-CN.md#键盘背光在-sysjump-后失效
简而言之，EC 从 RO sysjump 到 RW 时会清零 BSS 段，kblight.drv 变为 NULL。而键盘背光驱动的注册函数绑定在 HOOK_CHIPSET_STARTUP 上，该 hook 只在 AP 冷启动（S5→S4→S3）时触发，sysjump 后 chipset 已在 S0，不会触发。修复方案是在 HOOK_INIT 中添加 sysjump 后的重新注册路径。
浙公网安备 33010602011771号