环境：小米平板 5（codename nabu，SM8150，三星 UFS KLUFG8RHGB-B0E1）· Ubuntu 26.04 ARM64 内核：6.14.11-nabu-tmm（日常）/ 6.17.0-xiaomi-nabu-tmm-UFS-slowdown+（备用） 时间：2026-11-04 授权：文中驱动源码来自 sm8150-mainline/linux（GPL-2.0，作者 Nicola Guerrera）

TL;DR

• 平板顶部的磁吸无线充电芯片是 IDT P9418（实际读出的 Chip ID 是 0x9415），挂在 i2c-3 / 0x3b。
• 6.14.11 内核根本没有编这个驱动，所以笔吸上去毫无反应——不是硬件坏了。
• 6.17 内核自带驱动，但那个内核对这台机器只有 5V 慢充（平板充电几乎不可用），且 UFS 被降频。
• 最终方案：把 6.17 的 idtp9418 驱动移植到 6.14.11，自己编译一个 out-of-tree 模块， 让“快充 + 手写笔充电”共存。驱动侧改了两处，另外给上游驱动补了一个 SoC 重试逻辑。
• 顺带打通：手写笔蓝牙配对、GATT 信息读取、桌面小组件与 GNOME 顶栏插件的电量展示。

1. 背景与硬件

小米平板 5 的 Smart Pen 通过磁吸吸附在平板顶部短边，由平板内的线圈无线供电。Linux 下这条链路涉及三部分：

相关 GPIO（TLMM，/sys/kernel/debug/gpio 可看）：

驱动暴露的节点：

• /sys/class/power_supply/idtp9418/ → online、capacity、charge_control_end_threshold
• /sys/bus/i2c/devices/3-003b/ → chip_version、chip_status（vout/iin/temp/soc）、chip_powered

2. 第一层：为什么“没反应”

设备树里有节点，不代表有驱动。检查：

ls /sys/bus/i2c/devices/3-003b/          # 设备存在
readlink /sys/bus/i2c/devices/3-003b/driver   # 悬空 → 没有驱动绑定
modinfo idtp9418                          # 6.14.11 上：Module not found
sudo i2cdetect -y 3                       # 0x3b 无应答（芯片没被使能，正常）

结论：6.14.11 的模块目录里没有 idtp9418.ko，内核也没编进去。设备树节点成了“孤儿”。

小提示：芯片未上电时 i2c 不 ACK 是正常现象，不能据此判断硬件坏。

3. 第二层：6.17 上跑通

ESP 里已经装了 6.17 的 UKI（EFI/ubuntu/6.17.0-UFS-slowdown+.efi），rEFInd 选它启动，然后：

sudo modprobe idtp9418

笔吸上去（笔尖朝左），dmesg 立刻出现：

[idtp] Pen attached! Turning on reverse charging...
reverse charging start success
[charge-monitor] pen=1 soc=5

/sys/class/power_supply/idtp9418 出现，online=1，笔从 0% 一路充到 90%（约 18 分钟）。

为什么 6.14.11 没有、6.17 有？

• 6.14.11 构建于 2025-08-14，驱动首个提交在 2025-10-23 —— 时间上就不可能有。
• 6.17 构建于 2026-04-11，自然包含。
• 更麻烦的是设备树绑定也换了：6.14 的 dtb 用小米 BSP 风格属性名 （idt,irq / hall,int3 / hall,int4 / idt,reverse-enable / idt,reverse-booset-enable）， 驱动读的是新绑定（irq-gpios / pen-det-active-high-gpios / … / enable-gpios / boost-enable-gpios）。 所以直接拷 .ko 也 probe 不起来。

4. 笔的坑：SoC 0xFF、充电上限、电量口径

4.1 SoC 读到 0xFF 就停充

驱动 charge-monitor 每 2 秒读一次笔的电量，原逻辑：

if (!attached || soc < 0 || soc >= di->charge_limit)
    /* 停充 */

笔在刚上电的一小段时间内不响应电量查询（寄存器 0x3a 返回 0xFF）， 于是驱动 2 秒内就判定失败并停充——表现就是“吸上去闪一下就没反应”。

4.2 充电上限 85%

charge_control_end_threshold 默认 85，写值上限 95：

echo 95 | sudo tee /sys/class/power_supply/idtp9418/charge_control_end_threshold

笔的电量按 10% 台阶上报（80 → 90），会一步跨过 85，所以在 90 停下是正常的。

4.3 停充后 capacity 归 0

驱动的 POWER_SUPPLY_PROP_CAPACITY 在 !is_charging 时直接返回 0，所以停充后读 capacity 是 0， 不是电量真的掉了。

4.4 两种电量的口径

实测两者会差 10~20%，充满后（90%）又能对上——是刷新节奏不同，不是两套电量计。

5. 蓝牙：配对与能读到的信息

为什么 MIUI 吸上自动连，Linux 不会：MIUI 有小米笔系统服务，霍尔检测到吸附就主动唤醒并配对； Linux/BlueZ 没有这个服务，笔平时不广播（省电），必须长按笔上的按键约 5 秒进入配对模式。

bluetoothctl --timeout 120 scan on
# 长按笔按键，出现 Xiaomi Smart Pen 后：
bluetoothctl pair C0:2B:3D:70:C6:E9
bluetoothctl trust C0:2B:3D:70:C6:E9
bluetoothctl connect C0:2B:3D:70:C6:E9

笔的蓝牙地址是随机地址，重新配对会变，脚本里别硬编码，按名字匹配。

能读到的 GATT 信息（GATT 读需要 root，BlueZ 的 D-Bus 策略）：

sudo busctl --system call org.bluez \
  /org/bluez/hci0/dev_XX/serviceXXXX/charXXXX \
  org.bluez.GattCharacteristic1 ReadValue 'a{sv}' 0

没有序列号（0x2A25）和硬件版本（0x2A27）；压感/倾角不走蓝牙（走 NVT 触控）。

6. 第三层：给 6.14.11 编驱动

6.1 准备

# 1) 保存当前 6.14.11 的 config（IKCONFIG）
zcat /proc/config.gz > ~/nabu-build/config-6.14.11

# 2) 下载 6.14.11 源码（约 143MB）
curl -L -o linux-6.14.11.tar.xz https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.14.11.tar.xz
tar -xJf linux-6.14.11.tar.xz

# 3) 配置 + 准备模块构建（本机 arm64 原生编译）
cd linux-6.14.11
cp ../config-6.14.11 .config
make ARCH=arm64 olddefconfig
make -j8 ARCH=arm64 modules_prepare
make -s kernelrelease     # 6.14.11-nabu-tmm

关键点：kernelrelease 必须和运行内核一致（6.14.11-nabu-tmm），否则模块加载时 vermagic 不匹配。 本机 CONFIG_MODVERSIONS=n、CONFIG_MODULE_SIG=n，所以不需要 Module.symvers 的 CRC、也不校验签名。

6.2 设备树绑定差异（改驱动，不改 dtb）

6.14 的 dtb 用旧名字，所以把驱动的 GPIO 获取换成“按旧属性名查找”。 6.14 没有 devm_gpiod_get_from_of_node，改用 legacy API：

#include <linux/gpio.h>
#include <linux/of_gpio.h>

struct { const char *name; const char *prop; struct gpio_desc **gpio; unsigned long flags; }
gpio_map[] = {
    {"irq",                 "idt,irq",                 &di->gpios.idt_irq,              GPIOF_IN},
    {"enable",              "idt,reverse-enable",      &di->gpios.enable,               GPIOF_OUT_INIT_HIGH},
    {"boost-enable",        "idt,reverse-booset-enable",&di->gpios.boost_enable,         GPIOF_OUT_INIT_HIGH},
    {"pen-det-active-high", "hall,int3",               &di->gpios.pen_det_active_high,  GPIOF_IN},
    {"pen-det-active-low",  "hall,int4",               &di->gpios.pen_det_active_low,   GPIOF_IN},
};

for (int i = 0; i < ARRAY_SIZE(gpio_map); i++) {
    int gpio = of_get_named_gpio(di->dev->of_node, gpio_map[i].prop, 0);
    if (gpio < 0) return gpio;
    ret = devm_gpio_request_one(di->dev, gpio, gpio_map[i].flags, gpio_map[i].name);
    if (ret) return ret;
    *gpio_map[i].gpio = gpio_to_desc(gpio);
}

注意 idt,reverse-booset-enable 里的 booset 是 dtb 里就有的拼写，别手滑改掉。

6.3 编译与加载

源码树里没有 Module.symvers 时，modpost 会把所有符号报成 undefined。 MODVERSIONS=n 时这些符号在加载阶段由内核解析，所以可以直接：

make -C ~/nabu-build/linux-6.14.11 M=$PWD ARCH=arm64 KBUILD_MODPOST_WARN=1 modules

产物 idtp9418.ko 的 vermagic 必须是 6.14.11-nabu-tmm SMP preempt mod_unload aarch64。

安装并加载：

sudo cp idtp9418.ko /lib/modules/6.14.11-nabu-tmm/extra/
sudo depmod -a 6.14.11-nabu-tmm
sudo insmod idtp9418.ko        # 或 modprobe

加载后驱动自动绑定到 3-003b，/sys/class/power_supply/idtp9418 出现。 开机自动加载：/etc/modules-load.d/charge-stylus.conf 写一行 idtp9418。

6.4 重试补丁 v2

解决 4.1 的“0xFF 立刻停充”：

/* 笔刚上电时 SoC 可能暂时读不到（0xFF），先重试 ~30 秒再放弃 */
if (soc >= 0)
    di->soc_retry = 0;
if (!attached || soc >= di->charge_limit || (soc < 0 && ++di->soc_retry > 15)) {
    /* 停充，soc_retry = 0 */
}

实测：吸附后第 2 秒笔就报出 soc=20，充电继续。

7. 展示层：终端小组件与顶栏插件

7.1 终端小组件

~/.local/bin/watch_battery.sh（桌面上有启动器“电池实时电压”）：

• 充电中：● 充电中 10% 0.85 W 54 °C 上限 85%
• 未充电：○ 未充电（蓝牙电量 80%）
• 没有驱动：不可用（本内核无 idtp9418 驱动）

功率 = vout × iin（从 chip_status 读，raw 值按 mV/mA 解释）。 注意：驱动每读一次 chip_status 会 dev_info 打日志，所以每 60 秒才读一次。

7.2 GNOME 顶栏插件

本地扩展 batteryvitals@local，在电池数值旁显示 笔XX%：

• 充电中：绿色，用 WPC 值
• 未充电但蓝牙连着：灰色，用 BLE 值（upower，3 分钟刷新一次）
• 都没有：隐藏（原来的 笔— 容易被看成“笔一”，已去掉）

大坑：GNOME Shell 对扩展 JS 有会话级模块缓存。 gnome-extensions disable/enable、重装 zip、改 version 都不会重新加载代码， 必须注销重登（或重启）才生效。

8. 两个内核的对比与取舍

结论：6.14.11 自编模块后是“快充 + 笔充电”两全，日常用它；6.17 退居备用。

9. 踩坑清单 / 给后来者

1. 设备树有节点 ≠ 有驱动：先看 /sys/bus/i2c/devices/*/driver 是否悬空。
2. 先确认内核版本与驱动提交时间的先后：6.14.11 比驱动早两个月，不可能有。
3. DT 绑定在新旧树之间会漂移：BSP 属性名 vs mainline 属性名，移植时要么改驱动、要么重打 dtb/UKI。
4. devm_gpiod_get_from_of_node 在 6.14 已不存在：用 of_get_named_gpio + devm_gpio_request_one + gpio_to_desc。
5. vermagic 必须逐字匹配；CONFIG_MODVERSIONS=n 时不需要 Module.symvers，KBUILD_MODPOST_WARN=1 可绕过 modpost。
6. 驱动可能在笔刚上电时读到 0xFF：给重试窗口，别第一次失败就放弃。
7. 无线充的 SoC 是粗粒度、会跳；BLE 电量更细但充电时可能不刷新。两者差 10~20% 正常。
8. GNOME 扩展改完必须重新登录，disable/enable 不重载模块。
9. 启动额度：nabu 的 ABL 每启动一次扣 slot-retry-count，7 次上限；频繁切内核有风险， 能接 PC 时用 fastboot set_active a 补满。
10. 6.17 在三星 UFS 上要降频补丁（201.5MHz），否则可能黑屏/不稳。

10. 附录

10.1 常用命令

# 笔是否在充
cat /sys/class/power_supply/idtp9418/{online,capacity}

# 芯片遥测（vout/iin/temp/soc，raw）
cat /sys/bus/i2c/devices/3-003b/chip_status

# 芯片版本（OTP/APP 固件版本）
cat /sys/bus/i2c/devices/3-003b/chip_version

# 驱动日志
sudo dmesg | grep -i idtp | tail -20

# 蓝牙电量
upower -e | grep bluetooth
upower -i /org/freedesktop/UPower/devices/bluetooth_generic_dev_XX

# 模块
modinfo idtp9418
lsmod | grep idtp

10.2 关键文件

10.3 实测数据

本文记录于 2026-11-04，所有命令均在小米平板 5（nabu）+ Ubuntu 26.04 上实测。 驱动源码来自 sm8150-mainline 社区，遵循 GPL-2.0。

最后更新：2026-11-04 20:05 机器：Xiaomi Pad 5（nabu）· Ubuntu 26.04 ARM64 · UFS: SAMSUNG KLUFG8RHGB-B0E1 内核：6.14.11-nabu-tmm（快充 + 手写笔充电，自编 idtp9418 模块）/ 6.17.0-xiaomi-nabu-tmm-UFS-slowdown+（自带笔驱动，但只有 5V 慢充） 覆盖：启动与 fastboot 自救 · 充电（含手写笔无线充/蓝牙）· Waydroid 与安卓应用 · 宿主音频 · 亮度音量同步 · 桌面工具链（Markdown 查看 / dsh）

0. 速查总表

第 1 部分 · 系统与启动

1.1 启动链与分区

ABL（打过 dualboot 补丁）→ boot_a 里的 bootmanager（TWRP-LINUX）
    → ESP(sda31) 上的 rEFInd（菜单 5 秒）→ EFI/ubuntu/*.efi
    → 内核 → root=PARTLABEL=linux (sda32)

• ESP：/dev/disk/by-partlabel/esp（334MB，sda31），含 EFI/ubuntu/6.14.11.efi、6.17.0-UFS-slowdown+.efi
• 根分区：linux（sda32，458GB，挂 /）
• boot_a：TWRP-LINUX（dualboot bootmanager），不要随意刷
• anti:1（防回滚已开启，别刷旧固件）

1.2 A/B 槽：只有 7 次启动额度

实测事实（2026-11-02）：

• 每次启动 slot-retry-count:a 减 1（实测 5 → 4，一次完整启动）
• fastboot set_active a 把它重置为 7，同时清掉 slot-unbootable
• slot-successful:a 永远是 no：Ubuntu 侧没有任何东西上报"启动成功"
• 减到 0 → ABL 把该槽标记 unbootable → 没有可启动的槽 → 停在 fastboot （11/02 那次事故就是这么来的）
• 槽元数据不在 AP 可读分区：108 个 <128MB 分区哈希对比，set_active a 前后只有 logfs 变化（UEFI 日志）；misc 恒为那 15 个字节、devinfo 全零。 结论：存在 AP 访问不到的保护区（UFS LUN / RPMB / ABL 自有存储），Linux 侧写不了"启动成功"
• fastboot oem off-mode-charge 1 能写入（连带把 charger-screen-enabled 置 1）， 但挡不住插电自动开机，对保住计数没用

建议节奏：

• 计数到 4 会弹通知，此时还剩 3 次余量，找方便的时间补
• 平时尽量用挂起代替关机，能显著减少启动次数
• 别在没接 PC 的情况下重启

1.3 掉进 fastboot 怎么救

# 只读确认
fastboot getvar current-slot        # 期望 a
fastboot getvar slot-retry-count:a
fastboot getvar slot-unbootable:a
fastboot getvar slot-successful:a

# 恢复
fastboot set_active a
fastboot reboot

补完计数：

nabu-boot-count reset     # 计数清零，重新开始算 7 次

1.4 内核怎么选

• 日常推荐 6.14.11（快充可用），充电头用 18W
• 要给手写笔充电只能切 6.17，代价是 UFS 限速、只能用 5V 慢充（见 2.4）
• rEFInd 菜单只有 5 秒，注意别选错

1.5 已装工具与数据文件

数据位置：

• ~/.local/share/nabu-charge.csv — 1Hz 充电日志（10MB 自动轮转）
• ~/.local/share/nabu/boot-count — 启动计数
• ~/.local/share/nabu/part-hashes-before.txt — 分区哈希基线（考古用，可删）

第 2 部分 · 充电

2.1 v_offset 坏掉是主要故障

坏掉后 dmesg 会刷：FAULT_INT / volt_fault_detected (volt_qual=0) / vac_ov_control_work / stop charging ↔ start charging 循环。

原因：v_offset 是 ln8000 驱动内部算的 ADC 偏置。输入电压瞬时跌落时 （大功率 PD 头在 PPS 下调压、电荷泵换工作点），驱动会算出负值，后续所有电压换算全错 → 误判"输入电压不合格" → 反复停充。坏值不会自己恢复，只在驱动初始化时重算。

恢复：拔掉充电器重新插上（驱动重新初始化，v_offset 回到 ~390）。

# 判断是否在坏状态
journalctl -k -n 20 | grep -o 'v_offset=[0-9]*' | tail -1
sudo dmesg | grep adc_vin | tail -2

⚠️ 绝对不要 unbind/rebind ln8000 驱动 实测 echo 1-0051 > /sys/bus/i2c/drivers/ln8000_charger/unbind 触发内核 oops： free_irq → power_supply_unregister → kernfs_remove_by_name_ns 三个 WARNING， 接着 NULL pointer dereference，整机死机，只能长按电源重启。

2.2 充电头与线：低电量才是风险点

实测规律（2026-11-02 当天）：

• 低电量时充电电流最大（实测冲到 −5.1A），电荷泵输入电流大、VBUS 更容易跌落， 一跌就是 PD hard reset → v_offset 被写坏 → fault 循环
• 电量上来后电流自然回落（恒流转恒压），链路就稳了
• 建议：低于 ~30% 用 18W 或 5V 头；充到 40% 以上再换大功率头，100W 也能长时间稳定
• 18W 也不是绝对安全（出现过 5V 合约下同样写坏的情况），核心仍是"坏了就拔插"

补充（11/03–11/04 实测）：

• 拔线/插线的瞬间也会出现一次 v_offset 溢出（adc_vin 同时掉到 5~7V）， 这是正常瞬变：重新插入时驱动会重新初始化，不影响充电
• 真正危险的是插着电、充电过程中被写坏：此时会一直卡在 fault 循环，必须拔插一次
• 26 小时里没有重启，A/B 计数没被消耗
• 低电量（6~8%）那次的现场：tcpm 电压 0V、电池 +1.5A 放电，重插后立刻恢复 −3.6A
• 开机前/休眠中线已插着 → 只协商到 5V（11/04 12:36 复现两次）： tcpm 只在"重新接入"时做 PD 协商。线如果先插着再开机（或休眠中插电）， 它直接以 Type-C 5V 初始化，之后不会自己重试 PD，重启也无效 （因为开机时线还插着，又按 5V 初始化一遍）。 实测：休眠插电 → 5V；v_offset 被写坏、不充；重启后仍是 5V； 真正拔插一次 → 立刻 9V / −4.8A 快充，v_offset 回到 434
• 判断有没有 PD：cat /sys/class/power_supply/tcpm-source-psy-*/usb_type
  • C [PD] PD_PPS = 有 PD（9V）
  • [C] PD PD_PPS = 只有 Type-C 5V，没 PD ← 需要拔插
• 5V 下不是完全不能充：PMIC 旁路能给约 0.6A（ln8000 present=0），慢但不断电
• 软件侧改 input_current_limit 无效，已试过；port_type 切换也推不动 typec

2.3 怎么判断现在稳不稳

# 最近 1 分钟有没有 fault（0 = 稳）
journalctl -k --since '1 minute ago' | grep -c 'FAULT_INT has occurred'

# 20 秒内 Type-C 掉线次数（0~1 = 稳）
timeout 20 udevadm monitor --subsystem-match=typec 2>/dev/null | grep -c port0-partner

# v_offset 是否在正常区间
journalctl -k -n 20 | grep -o 'v_offset=[0-9]*' | tail -1

2.4 手写笔无线充电（IDT P9418，2026-11-04 打通）

一句话：笔能无线充。6.17 自带驱动；6.14.11 原来没有，2026-11-04 已自编模块补上（见本节末尾更新）。

用法

1. 用 6.17 内核启动（rEFInd 选 6.17.0-UFS-slowdown+）
2. 笔笔尖朝左吸到平板顶部短边（方向反了不充）
3. 看状态：

cat /sys/class/power_supply/idtp9418/{online,capacity}
sudo dmesg | grep idtp | tail -5
# 正常应看到：
#   [idtp] Pen attached! Turning on reverse charging...
#   reverse charging start success
#   [charge-monitor] pen=1 soc=5

桌面「电池实时电压」小组件已加上手写笔一行（~/.local/bin/watch_battery.sh）： ● 充电中 12% 上限 85% / ○ 未充电 / 不可用（本内核无驱动）。

实测（11/04 19:52）：笔放到完全没电（0%），吸上后 0% → 5% → 10%（约 5%/分钟）。

已知坑

• SoC 读失败会永久停充：charge-monitor 读到 soc=-1（寄存器 0x3a 返回 0xFF）就打印 stopping reverse charging 并停掉；之后只有把笔取下再吸一次才会重新开始。 重新 modprobe/probe 都不会自动续充（probe 里没有启动充电的路径）。
• 停充后 online=0、capacity=0、chip_powered=0，但霍尔仍显示"已吸附"，别被骗。
• 电量为 0 的笔刚吸上时最容易触发；先充到 5~10% 再重新吸附基本就稳了。
• 2026-11-04 20:37 新现象（待验证）：蓝牙配对之后，每次吸附都是 reverse charging start success → 连续 soc is default 0xFF → 约 6 秒内停充； 配对前同样的笔从 0% 一路充到 90% 完全正常。怀疑是蓝牙连接状态下笔不响应无线充握手 （或笔发热保护）。验证方法：断开蓝牙再吸附，看是否恢复；如果恢复，就说明是 BLE 干扰。
• 充电时笔的触控输入会被 NVT 驱动主动关掉（pen_charge_state_notifier），画不了是正常的。
• 反向充电从平板电池取电（约 5W），长时间吸附会掉电。

为什么只有 6.17 有 / 能不能移植到 6.14.11

• 时间线：6.14.11 编于 2025-08-14；驱动首个提交在 2025-10-23（sm8150-mainline/linux 863ef95e）；6.17 编于 2026-04-11。所以 6.14.11 不是"没开配置"，是根本没有这份代码。
• 设备树绑定也换了：6.14 的 dtb 用小米 BSP 属性名 （idt,irq / hall,int3 / hall,int4 / idt,reverse-enable / idt,reverse-booset-enable）， 驱动读的是新绑定（irq-gpios / pen-det-active-high-gpios / pen-det-active-low-gpios / enable-gpios / boost-enable-gpios）。直接拷 .ko 也 probe 不起来。
• 移植可行，但要动内核：
  1. 需要 6.14.11 的源码树（本机没有，PPA 只发二进制；/lib/modules/6.14.11-nabu-tmm/build 指向作者机器 /home/themojoman/develop/nabu/linux，已失效）；
  2. 驱动 794 行，只用 gpiod / regmap / power_supply，6.14 的 API 够用；
  3. 用同 config（/proc/config.gz）编模块，vermagic 要对上 6.14.11-nabu-tmm； 本机 CONFIG_MODVERSIONS=n、CONFIG_MODULE_SIG=n，所以编出来能直接加载；
  4. 最省事：改驱动读旧属性名（不动 dtb/UKI）；否则要改 dtb 再用 ukify 重打 UKI；
  5. 真正的风险在电源栈：6.14 是 ln8000 电荷泵 + PD 9V，6.17 是 smb5 5V， p9418 的反向升压共享 VBUS，没在 6.14 上验证过。
• 取舍：留 6.17 → 能充笔，但只能 5V 慢充、UFS 限速；回 6.14.11 → 快充，但笔不能充。

2026-11-04 21:20 更新：6.14.11 也能充笔了（自编模块）

原来的结论“只有 6.17 有驱动”已过时——给 6.14.11 编了一个 out-of-tree 的 idtp9418 模块， 装上后 6.14.11 也能正常给笔无线充电，平板仍是 9V/3A 快充，两不耽误。

• 模块位置：/lib/modules/6.14.11-nabu-tmm/extra/idtp9418.ko，开机由 /etc/modules-load.d/charge-stylus.conf 自动加载
• 源码：~/nabu-build/{idtp9418.c,idtp9418.h}，改了两处：
  1. DT 属性名换成 6.14 dtb 里的旧名字（idt,irq / hall,int3 / hall,int4 / idt,reverse-enable / idt,reverse-booset-enable）
  2. GPIO 用 legacy API（of_get_named_gpio + devm_gpio_request_one + gpio_to_desc）， 因为 6.14 没有 devm_gpiod_get_from_of_node
• 编译：linux-6.14.11 源码树 + 本机 /proc/config.gz，vermagic=6.14.11-nabu-tmm 与原内核一致； KBUILD_MODPOST_WARN=1 跳过缺失的 Module.symvers（MODVERSIONS=n，加载时不校验）
• 实测：笔 0% 吸上后稳定充电（vout 6.75V / iin 128mA ≈ 0.85W / 52~54°C），0%→5%→10%； 蓝牙同时连着也没再出现 0xFF停充
• 结论：6.14.11 现在“快充 + 笔充电”两全，不用再为笔切 6.17

2.5 手写笔蓝牙（2026-11-04 配对成功）

为什么 MIUI 吸上就自动连，Linux 不会：MIUI 有小米笔系统服务，霍尔检测到吸附就主动唤醒笔并按私有流程配对； Linux/BlueZ 没有这个服务，笔平时不广播（省电），必须长按笔上的按键让它进入配对模式。

配对步骤

1. bluetoothctl 里 scan on（或设置 → 蓝牙里保持扫描）
2. 长按笔上的按键约 5 秒
3. 出现 Xiaomi Smart Pen 后 pair → trust → connect

bluetoothctl --timeout 120 scan on     # 长按笔按键期间扫描
bluetoothctl devices | grep -i pen
bluetoothctl pair C0:2B:3D:70:C6:E9
bluetoothctl trust C0:2B:3D:70:C6:E9
bluetoothctl connect C0:2B:3D:70:C6:E9

笔的蓝牙地址是随机地址（random），重新配对可能变，脚本里别硬编码 MAC，用名字匹配。

能读到的信息（GATT）

• 没有序列号（0x2A25）和硬件版本（0x2A27）；压感/倾角不走蓝牙（走 NVT 触控）
• GATT 读取要 root（BlueZ D-Bus 策略）： sudo busctl --system call org.bluez <path> org.bluez.GattCharacteristic1 ReadValue 'a{sv}' 0
• 电量普通用户可读：upower -e | grep bluetooth，再 upower -i <path>

两种电量的区别

现在面板/小组件的显示逻辑

• 充电中：笔XX%（绿，WPC 实时）+ 功率/温度
• 未充电但蓝牙连着：笔XX%（灰，BLE，顶栏 3 分钟刷新一次）
• 都没有：不显示（原来的 笔— 容易被看成“笔一”，已去掉）

第 3 部分 · Waydroid 与安卓应用

3.1 最终结论速查

3.2 当前生效的配置（持久化）

1. /var/lib/waydroid/waydroid.cfg

[properties]
ro.hardware.audio.primary = waydroid

作用：让 Android 加载 /vendor/lib/hw/audio.primary.waydroid.so，而不是 default 空壳。

2. /var/lib/waydroid/overlay_rw/system/init.environ.rc

内容是在原文件基础上，在 on early-init 块里插入两行：

on early-init
    export PULSE_RUNTIME_PATH /run/xdg/pulse
    export PULSE_LATENCY_MSEC 60
    export ANDROID_BOOTLOGO 1
    ...

作用：

• PULSE_RUNTIME_PATH —— 让所有 Android 服务（含 audio HAL）继承 pulse socket 路径
• PULSE_LATENCY_MSEC —— 给 libpulse 客户端设缓冲延迟。不设这一行，HAL 会持续欠载（XRUN），表现为声音断续或干脆没声，且症状很迷惑：宿主自己也播放时，设备被"带"起来，Android 的声音会顺带响几秒

⚠️ 注意：这两个补丁放在 overlay 里。如果执行 waydroid init -f 且走到 preinstalled images 分支，overlay 会被清空，补丁需要重新加。

3.3 验证音频是否正常（几条命令）

# 1. HAL 是否加载正确
adb shell getprop ro.hardware.audio.primary     # 应输出 waydroid
PID=$(adb shell pidof android.hardware.audio.service | tr -d '\r')
sudo waydroid shell -- sh -c "grep -oE '[^ ]*audio\.primary[^ ]*\.so' /proc/$PID/maps"
# 应输出 /vendor/lib/hw/audio.primary.waydroid.so

# 2. HAL 环境里有没有 pulse 路径和延迟参数
sudo waydroid shell -- sh -c "tr '\0' '\n' < /proc/$PID/environ | grep PULSE"
# 应输出：
#   PULSE_RUNTIME_PATH=/run/xdg/pulse
#   PULSE_LATENCY_MSEC=60

# 3. 播放时看宿主 PipeWire 有没有 Waydroid 的音源
wpctl status | sed -n '/Streams:/,/Video/p'
# 应看到 "Waydroid" + output_FL/FR -> Speaker playback [active]

# 4. 想确认送出去的不是静音，可以录 sink 监听
pw-record --target=61 /tmp/mon.wav      # 61 是 sink 节点 id，用 wpctl status 查
# 静音时峰值 0；有声时峰值明显大于 0

# 5. 【关键】播放时检查 ALSA 是否在欠载
cat /proc/asound/card1/pcm0p/sub0/status | head -1
# 正常：持续 state: RUNNING
# 异常：SETUP / XRUN 来回跳 —— 这就是断续无声的元凶，加 PULSE_LATENCY_MSEC 解决

3.4 正确的启停方式（重要）

启动（推荐）

# 普通用户身份，不要 sudo
export XDG_RUNTIME_DIR=/run/user/1000
export WAYLAND_DISPLAY=wayland-0
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

sudo systemctl start waydroid-container
waydroid session start &
waydroid show-full-ui

或者直接点桌面「Waydroid 安卓」图标（启动脚本会处理这些）。

停止

waydroid session stop        # 会连容器一起停

⚠️ 如果容器「起来了但几十秒后自己死」

不要用 systemctl restart，走完整重建：

waydroid session stop
sudo systemctl stop waydroid-container
sudo rm -rf /var/lib/waydroid/lxc
sudo waydroid init          # 重新生成 LXC 配置，不重新下镜像
sudo systemctl start waydroid-container
waydroid session start &    # 普通用户

这条是今晚反复踩坑总结出来的：单纯 restart 必挂，重建 lxc 目录后能稳定启动。

3.5 事故复盘（别重蹈覆辙）

事故 1：chown -R 毁掉 /data（最严重）

为了「修复权限」，对 ~/.local/share/waydroid/data 执行了 chown -R neko:neko。

后果：

• Android 的 system 用户恰好也是 uid 1000，所以 /data/system 等文件没事
• 但 keystore 是 uid 1017，/sdcard 是 1023，各 app 是 u10xxx —— 全被改成 1000
• keystore2 打不开 persistent.sqlite → abort → system_server 崩 → init 重启 → 无限循环
• 现象就是「能看到手机正在启动，几秒后重启」

教训：永远不要对整个 /data 做递归 chown。 需要修单个目录时，先确认它应有的 uid：

事故 2：改 init.waydroid.rc 导致容器起不来

尝试在 /system/etc/init/init.waydroid.rc 的 service vendor.audio-hal 块里加 setenv PULSE_RUNTIME_PATH ...，结果容器直接起不来（LXC 运行 40 秒后退出）。

正确做法是改 init.environ.rc 的全局 export（本记录 3.2）。

事故 3：lxc.environment 不生效

在 config_base 里加 lxc.environment = PULSE_RUNTIME_PATH=... 后容器能启动，但 Android init 不会把 LXC 的环境传给它的服务，HAL 的 /proc/<pid>/environ 里依然没有。

事故 4：用 sudo 启动 session

sudo waydroid session start 会让 DBus 调用超时（NoReply），表现为「管理器根本没反应」，极容易误判成 Waydroid 坏了。

3.6 网络相关

机器访问 SourceForge / GitHub Release 极慢（实测 SourceForge 单流 325 B/s，8 线程合计 3 KB/s）。

用 Clash 代理（FlClash GUI，混合端口 7890）后正常：

# 首次初始化镜像
sudo env https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 \
     no_proxy=ota.waydro.id waydroid init -f

注意：

• no_proxy=ota.waydro.id 让元数据走直连（有时节点反而连不上 GitHub Pages）
• 走代理实测 6–8 MB/s，912 MB 系统镜像几分钟能下完
• 如果没有代理，可以用 /etc/waydroid-extra/images 预置 system.img + vendor.img 跳过下载

3.7 adb / 文件传输

sudo waydroid adb                           # 开启容器内 adb
adb connect 192.168.240.112:5555
adb devices                                 # 应显示 device

如果显示 unauthorized，把宿主公钥灌进去：

D=~/.local/share/waydroid/data
sudo mkdir -p $D/misc/adb
sudo cp ~/.android/adbkey.pub $D/misc/adb/adb_keys
sudo waydroid shell -- setprop ctl.restart adbd
adb disconnect 192.168.240.112:5555; adb connect 192.168.240.112:5555

日常传文件用桌面「安卓文件传输」工具（GTK4 写的，支持拖拽、双向、目录浏览），或：

adb push 文件 /sdcard/Download/
adb pull /sdcard/DCIM/xxx.jpg ~/图片/

3.8 关键路径清单

3.9 常见现象对照表

3.10 一次性恢复脚本（保留数据）

#!/bin/bash
# 保留 /data 和镜像，只重建运行环境
export XDG_RUNTIME_DIR=/run/user/1000
export WAYLAND_DISPLAY=wayland-0
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

waydroid session stop 2>/dev/null
sudo systemctl stop waydroid-container
sleep 2
sudo pkill -f /usr/bin/waydroid
for m in $(mount | grep waydroid | awk '{print $3}' | sort -r); do sudo umount -l "$m"; done
sudo rm -rf /run/waydroid-lxc /var/lib/waydroid/lxc

sudo waydroid init
sudo systemctl start waydroid-container
sleep 6
waydroid session start &
sleep 40
waydroid status

3.11 游戏闪退排查：碧蓝航线（2026-11-03，进行中）

现象

点「碧蓝航线」图标 → 图标闪一下 → 黑屏 → 回桌面。启动后 1~5 秒必退， Unity 会话计数一度累积到 11 次，全部失败。

结论（一句话）

不缺资源、不缺内存、不是网络、也不是安装包损坏。 是 app 自己的加密脚本包没被解密/加载出来，Unity 只能拿 APK 里那套"壳"元数据跑空场景， 脚本全部解析不到，于是进程主动 exit(1) 自杀。

⚠️ 一个必须记住的坑：ro.build.type 别改 user

属性伪装第一版顺手把 ro.build.type 也改成 user，重启后开机弹 「Android 系统：您的设备内部出现了问题。请与您的设备制造商了解详情」：

E/Build: Vendor interface is incompatible, error=1
E/ActivityTaskManager: Build fingerprint is not consistent, warning user

原因：AOSP 的 Build.isBuildConsistent() 在 IS_ENG || IS_USERDEBUG 时直接返回 true（短路）。 改成 user 后不再短路，而这张镜像的 VINTF HAL 矩阵本来就不匹配， VintfObject.verifyWithoutAvb() 返回 1 → 必然判不一致 → 弹窗。

结论：ro.build.type 必须保持 userdebug。 已撤回，弹窗消失。其余伪装可留。

当前生效的伪装（已验证系统无异常）

两边必须同步写——只改 cfg 不生效；跑 waydroid init 又会重写 LXC 配置（3.4 那条"必挂"路径）。

[properties]
ro.build.fingerprint = Xiaomi/nabu/nabu:13/TKQ1.220829.002/V14.0.5.0.TKXCNXM:user/release-keys
ro.build.tags = release-keys
ro.product.waydroid.brand = Xiaomi
ro.product.waydroid.manufacturer = Xiaomi
ro.product.waydroid.device = nabu
ro.product.waydroid.name = nabu
ro.serialno = 8H2X9K3LM

实测变化：brand waydroid→Xiaomi、manufacturer Waydroid→Xiaomi、 device/name →nabu、fingerprint 112 字符→71 字符、tags test-keys→release-keys。

顺带修掉一个真问题：原来 ro.build.fingerprint 有 112 字符 > PROP_VALUE_MAX(92)， native 层 __system_property_get("ro.build.fingerprint") 一律拿到空串 （日志里 E libc: The property ... is too large for __system_property_get()）。 现在是 71 字符，native 也能正常读到。

备份：/var/lib/waydroid/waydroid.{cfg,base.prop,prop}.bak-20261103-192221

回滚：

sudo cp -a /var/lib/waydroid/waydroid.cfg.bak-20261103-192221 /var/lib/waydroid/waydroid.cfg
sudo cp -a /var/lib/waydroid/waydroid_base.prop.bak-20261103-192221 /var/lib/waydroid/waydroid_base.prop
waydroid session stop; sudo systemctl start waydroid-container; waydroid session start &

改完属性后：症状变了，但没修好

• BgcPluginManager ... onlyDownloadAndInstall() 的 NullPointerException 不再出现
• 游戏仍在同一处 exit(1)，Download/ 依旧为空
• 对照（19:40 更正，重要）：同机 com.bilibili.priconne（公主连结）能正常进主界面（实测 pid 在跑， topResumedActivity=com.bilibili.priconne/.MainActivity），而且它挂的是同一套反外挂 （libthemis.so / libcustom_rules.so / libbili.so / libmsaoaid*.so）， B站 SDK 采到的设备档案同样是 is_emu=001000、is_debug=1。 它 exit-info 里的 EXIT_SELF 全部来自 :GP7Service / :GP7Worker 子进程且 status=0（正常退出）， 和碧蓝航线"主进程 status=1 自杀"完全不是一回事。 → 模拟器识别、反外挂拦截、环境本身，都不是本次闪退的原因。

→ 属性伪装既不是必要条件也不是充分条件：公主连结在同样的 is_emu=001000 + 同一套反外挂下能正常跑， 说明这些特征本身不致命。改属性没修好游戏，现在保留它只是为了顺手修掉 "fingerprint 112 字符导致 native 读不到"这个真实缺陷，随时可按上面的命令回滚。

要继续往下查可选的路

1. 换 Android 11（LineageOS 18.1）镜像复测 —— 重装级操作，流程见 3.4 / 3.10；
2. 用 debuggable 重打包 APK 附加调试 —— 会毁签名、有封号风险，不建议；
3. 放弃在 waydroid 里跑这个游戏，用真机或官方 PC 端。

19:44 两处更正 + 最新进展

更正 1：公主连结的下载不在 /sdcard。 它把资源下到了内部目录，共 11 GB：

/data/data/com.bilibili.priconne/files/   a/ 3.6G  v/ 2.9G  m/ 1.6G  s/ 1.5G  b/ 1.4G  manifest 55M

之前只看 /sdcard/Android/data/.../files/Download（4 KB）就断定"它没下载也能跑"，结论作废。 查这类游戏的资源体积要直接 du -sh /data/data/<pkg>，别只看外部目录。

更正 2：碧蓝航线并不是"点开必闪退"。 做完整清理（pm clear + sudo rm -rf /sdcard/.../Android/data/com.bilibili.azurlane）后， 它能正常弹出用户协议页并存活数十秒，pss=315MB / rss=501MB（Unity 确实起来了）：

19:42:42  am_proc_start 29769  (首次启动，弹出协议页)
19:43:22  29769 EXIT_SELF status=1  (未点"同意"，exit)
19:43:30  am_proc_start 30990  (被重新拉起，再次弹协议页)
19:43:34  30990 EXIT_SELF status=1
19:43:37  31315 (仅 XprefProvider content provider)

→ 之前"秒退"里有一部分是外部残留目录（/sdcard/.../files/il2cpp 还在）让启动器误判状态造成的。 清理干净后偶尔能走到协议页，但不稳定。

19:47 实测：协议框抢不到。 清数据后连续 3 次尝试"启动 + 连点同意"（坐标 1314,990， 从截图量出来的按钮中心），三次都没点中：进程在 4~10 秒内就 exit(1)，截图取回来时已回到桌面。 协议框只在 19:42 那一次实例里稳定出现过（活了约 40 秒），之后的启动因为协议已记录， 直接进 Unity → 脚本缺失 → 4 秒死。

稳定的失败循环（可复现）：

启动 → Unity 载 level0 → BLHX.* 脚本全 missing + 序列化布局不匹配(32/56) → exit(1) → 被再次拉起 → ...

结论：卡点不在"同意"这一步。 签协议只是把流程往后推了一格，真正的死点在 Unity 载入壳场景， 要过这一关只能让解密脚本包 scripts64.ys 成功加载——目前没有黑盒手段能做到。

19:52 用宿主 gdb / strace 取证（不用改 APK）

关键结论：exit(1) 是 Java 层从网络回调线程里调用的。

容器里的进程在宿主上可见（ps -eo pid,args | awk '$2=="com.bilibili.azurlane"'）， 有 sudo 就能直接 ptrace，完全不需要 debuggable 重打包：

# 1) 找到宿主侧 PID
PID=$(ps -eo pid,args | awk '$2=="com.bilibili.azurlane"{print $1; exit}')

# 2) 在 exit_group 上断点，抓退出时的调用栈
sudo gdb -p $PID -batch -ex "catch syscall exit_group" -ex "continue" -ex "info threads" -ex "bt 25"

# 3) 看它打开了哪些文件（找缺失的资源）
sudo strace -f -p $PID -e trace=openat,openat2 -o /tmp/az.trace

抓到的东西：

抓包（tcpdump -i waydroid0）显示启动期间访问的全是 443/TLS， SNI 里有 p.biligame.com（补丁服务器）、api.biligame.net、line1-sdk-app-api.biligame.net、 game.bilibili.com、s1.hdslb.com。没有任何资源下载流量，但补丁接口是访问过的。

→ 合并起来看：大概率是补丁/SDK 接口的某个响应让客户端决定退出（版本、风控、实名或维护）， 而不是本地解密失败。要看到响应内容必须 MITM（装 CA，且很可能撞证书固定）。

20:10 突破：协议页 WebView 渲染线程崩溃，用命令行开关修好了

之前"协议框只闪一下就消失"的真相不是 UI 抢不到，是 WebView 渲染线程把自己崩了：

pid 2696, tid 2831, name: RenderThread >>> com.bilibili.azurlane
signal 0 (SIGSEGV), code 1 (SEGV_MAPERR), Cause: null pointer dereference
#00 libwebviewchromium.so   (webview.apk!libwebviewchromium.so)

对应更早的 E libEGL: eglMakeCurrentImpl error 3008 (EGL_BAD_DISPLAY) 和 E/OpenGLRenderer: Device claims wide gamut support, cannot find matching config。 WebView 在走 GPU 合成时崩在 Mesa/gbm 上。

修复：给 WebView 一个命令行参数文件（全局生效，所有用到 WebView 的 app 都受益）

adb shell "echo '--disable-gpu-compositing' > /data/local/tmp/webview-command-line"

• 只写 --disable-gpu-compositing：协议页正常渲染、进程不崩（实测截图正常）
• 写成 --disable-gpu --disable-gpu-compositing：不崩，但页面渲染成白块——不要用这个
• 回滚：adb shell rm /data/local/tmp/webview-command-line

修好之后，协议流程能完整跑通：

agreement.start.api → agreement.page.view → agreement.page_load.api
→ agreement.agree.click → agreement.finish.api
→ patch_req_config → patch_config_net_success → bgc_plugin

但随后仍卡在同一个老毛病（见下节）： BgcPluginManager.onlyDownloadAndInstall() on a null object reference → exit(1)。 所以 WebView 只是第一道坎，资源准备那道坎还在。

20:10 期间的两次容器宕机（教训）

为了装 MITM 证书改了 overlay_rw/system/etc/security/cacerts/，需要重启容器才生效。结果：

• 普通 systemctl restart 开始随机失败，症状是 zygote 崩： JNI FatalError: set_sched_policy(0, -1) failed: Operation not permitted （cgroup 只读，和 3.9 表里那条一致）
• 容器崩过一次之后，残留挂载会让后续启动全部失败，必须先清干净： systemctl stop → umount 所有 waydroid 挂载 → rm -rf /run/waydroid-lxc /var/lib/waydroid/lxc → waydroid init → start
• waydroid init 会 rmtree 掉 overlay_rw（源码 images.py: remove_overlay）， 所以放在 overlay 里的证书每次重建都会丢——这就是 MITM 方案在这里走不通的根本原因
• 另外 pkill -f /usr/bin/waydroid 会匹配到自己的命令行，把自己杀掉，别这么写

结论：这个环境不适合做需要重启容器的实验。做之前先想清楚怎么恢复。

20:12 试过但无效：把缓存配置里的 bgc_plugin 关掉

思路：files/cdn_s.0 里 sdk_switch.bgc_plugin = 1，怀疑关掉能绕过那个 null manager。

文件结构（已确认）：Java 序列化头（27 字节）+ 一段 6753 字节的 JSON 串，无尾部校验和， 所以可以等长替换 "bgc_plugin": 1 → "bgc_plugin": 0，不破坏格式：

# 备份
sudo cp -a .../files/cdn_s.0 /tmp/
# 等长替换（用 python 校验 JSON 仍可解析、长度不变）
# 再 chattr +i 防止被启动时的刷新覆盖
sudo chattr +i .../files/cdn_s.0

结果：NPE 照样出现，onlyDownloadAndInstall() 依旧打在 null 上。 → sdk_switch.bgc_plugin 不是那个 manager 为 null 的原因。 已回滚（chattr -i + 还原备份，确认 bgc_plugin=1、大小 6780 未变）。

附：这次用到/可复用的取证命令

adb connect 192.168.240.112:5555
adb logcat -b all -d -v threadtime | grep -E "CRASH|BgcPlugin|Unity|has died"
adb shell dumpsys activity exit-info com.bilibili.azurlane
# adb root 在 waydroid 不可用（会回 “not available in Waydroid”），直接走宿主文件系统
sudo ls ~/.local/share/waydroid/data/data/com.bilibili.azurlane/
sudo ls ~/.local/share/waydroid/data/data/com.bilibili.azurlane/shared_prefs/
sudo cat ~/.local/share/waydroid/data/data/com.bilibili.azurlane/shared_prefs/device_data.xml
# 看 il2cpp 元数据里到底有没有游戏类
sudo strings -a ~/.local/share/waydroid/data/media/0/Android/data/com.bilibili.azurlane/files/il2cpp/Metadata/global-metadata.dat | grep -c BLHX

完整时间线与字段级证据另存： ~/文档/deepseek-harness/default-workspace/azurlane-crash-分析报告.md

3.12 异环（UE5）黑屏：库初始化阶段就崩了（2026-11-03）

现场

• 包名 com.hottagames.yh.laohu（注意：com.hypergryph.endfield 是明日方舟终末地，别搞混），版本 1.4.0
• 引擎：Unreal Engine 5（com.epicgames.unreal.GameActivity），libUnreal.so 有 241 MB
• 症状：点开是「黑屏」——其实是停在 Android 12 启动闪屏（黑底 + 图标）， 进程 10~20 秒后 SIGSEGV，exit-info 里是一长串 reason=2 (SIGNALED) status=11

取证（宿主 gdb 抓崩溃现场）

PID=$(ps -eo pid,args | awk '$2=="com.hottagames.yh.laohu"{print $1; exit}')
sudo gdb -p $PID -batch -ex "continue" -ex "bt 18"

Thread 1 "agames.yh.laohu" received signal SIGSEGV
#0..#14  libUnreal.so
#15  __dl__ZN6soinfo17call_constructorsEv ()        <- 静态构造函数
#16  __dl__Z9do_dlopenPKciPK17android_dlextinfoPKv ()
#17  __dl___loader_dlopen ()

崩的那条指令（pc - 库基址 = 0x289D97C，用 info proc mappings 算的）：

ldr  x10, [x10, #2408]     ; 取全局表
ldr  x0,  [x10]            ; x0 = 0   <- 表项还没建
strb w10, [x9, #1192]      ; 置"已初始化"标志
str  x8,  [x0, #16]        ; 空指针写 -> SIGSEGV

结论：不是"渲染不出画面"，而是 libUnreal.so 被 dlopen 时， 静态构造函数往一个还没初始化的全局注册表里挂对象，直接空指针写死了——引擎 main 根本没进。

排除项

判断

库级初始化失败，在 waydroid 这种容器里基本无解：要么是 UE5 对这套 Android 13 + Mesa 的兼容问题， 要么是 ANO 反外挂注入让静态初始化炸了。 换 Android 11 镜像不一定能好（不是渲染问题，是加载问题），不建议为它重装。

想要跑异环只能真机 / PC 端。

官方配置要求（2026-04-23 公测，官网 FAQ）

我方设备：骁龙 860（≈855+）、Android 13、存储 483 GB → 名义达标，但只到"最低"线， 即使能启动，UE5 开放世界在这颗 855 级 SoC 上也基本跑不动。

官方对"移动端下载完打开就闪退"的建议是卸载重装并保持前台完整更新； 但本例崩在 libUnreal.so 静态构造（见上），APK 完整、无分包（1.4 GB 单包、splits=[base]）、 页大小 4 KB 正常，所以重装大概率无效。

参考：雷电模拟器能跑（官方设置文档， 要求 14.0.5.1+、6 GB 内存 4 核），但那跑的是 x86 Windows 模拟器，与 waydroid 的 arm64 路径不同。

20:27 按官方建议卸载重装 —— 实测无效

sudo cp <app>/base.apk ~/yh_base.apk      # 先备份 1.4 GB 安装包
adb uninstall com.hottagames.yh.laohu
adb install -g -r ~/yh_base.apk           # 17 秒装回
adb shell am start -n com.hottagames.yh.laohu/com.epicgames.unreal.GameActivity

结果：一模一样——停在 Android 启动闪屏（黑底+图标）→ 十几秒后 reason=2 (SIGNALED) status=11（SIGSEGV）→ 再次拉起 → 再崩。

坐实了：不是安装/资源/配置问题，就是 libUnreal.so 在这套容器里静态初始化失败。 这条路到此为止。

第 4 部分 · 宿主音频

4.1 系统级音频杂音：卡顿时有电流声（与 Waydroid 无关）

现象

• 界面卡顿（切大页面、加载重内容）时，声音里出现明显电流声 / 噼啪声
• 退出卡顿页面、或暂停后重新播放，往往就恢复
• 跟 Android 无关，宿主播放音乐视频同样会出现

排查（先排除「四扬声器不同步」）

Xiaomi Pad 5 的 4 颗 CS35L41 功放由同一条 TDM 链路、2 声道驱动：

# /usr/share/alsa/ucm2/Xiaomi/nabu/HiFi.conf
#  - Internal Speakers : CS35L41 driver : MultiMedia1 <-> QUAT_TDM_RX_0
SectionDevice."Speaker" {
    PlaybackChannels 2
}

用户态只有一条 2 声道流，驱动/硬件层已经同步，不可能由软件造成四扬声器不同步。真不同步会表现为声像偏移、低频抵消发闷，而不是随负载出现的爆音。

真正原因（两层，第二层才是根因）

第一层：没有实时优先级

journalctl --user -u pipewire | grep -c 'out of buffers'     # 曾达 164 次
ps -o rtprio,comm -p $(pgrep -x pipewire)                    # RTPRIO  -  ← 没有 RT

第二层（根因）：音频图量子被压到 512

default.clock.quantum 只是偏好值，压不住客户端请求的低延迟。某个客户端（浏览器等）要 512 帧，整张图就掉到 512：

R   48    512  48000  ...  ERR 3225    ← 扬声器 sink，错误持续累积
R  108    720  48000  ...  ERR 163     ← Waydroid 流，周期 720 帧
              ↑ 512 与 720 不成整数比 → 实时重采样 + 高错误率

表现就是声音时好时坏、突然像"炸麦/机器人说话"，取决于当时连进来的是哪个客户端。这一点比单纯欠载更迷惑人：它不随负载变化，而是随"谁在放声音"变化。

修复

（1）实时优先级（辅助）—— /etc/security/limits.d/25-pw-rlimits.conf 已给 @pipewire 组 rtprio 95：

sudo usermod -aG pipewire neko     # 需要重新登录/重启才生效

注意：实测这台机器上即使 ulimit -r 是 95，chrt -f 80 仍返回 EPERM，PipeWire 拿不到 SCHED_FIFO。所以不要指望这一项，主战场是下面的量子。

（2）把量子钉死（关键） —— ~/.config/pipewire/pipewire.conf.d/10-stability.conf：

context.properties = {
    default.clock.quantum       = 1024
    default.clock.min-quantum   = 1024    # 关键：设成 512 等于没设
    default.clock.max-quantum   = 4096
    default.clock.force-quantum = 1024    # 关键：强制，忽略客户端请求
}

min-quantum 和 force-quantum 两行缺一不可——只改 quantum 就是这次的弯路，客户端照样能把图压到 512。

临时生效（不重启）：

pw-metadata -n settings 0 clock.force-quantum 1024

验证

# 看量子是否被钉住
pw-metadata -n settings | grep -E 'force-quantum|min-quantum'

# 看错误计数是否停止增长（隔 10 秒读两次对比）
timeout 8 pw-top -b -n 3 | grep -E 'alsa_output|Waydroid'
# ERR 列不再增长 = 稳定

实测：修前 sink ERR 一路涨到 3225；固定 1024 后 10 秒、30 秒两次采样均零增长。

注意

• 不要单独重启 PipeWire：Waydroid 的 pulse socket 是绑定挂载进容器的，PipeWire 一重启容器里那个 socket 就变陈旧的 inode，Android 立刻没声音。要么重启整机，要么重启 PipeWire 后走3.4「完整重建」把容器重拉一遍。
• quantum 1024 ≈ 21 ms 延迟。看视频/听歌无感；打音游觉得延迟大可以降到 512，但那就回到"容易被客户端拖下去"的老问题。
• 这台机器的延迟预算：PULSE_LATENCY_MSEC 60（Waydroid 侧）+ quantum 1024（系统侧）是两处独立缓冲，调一处不影响另一处。

4.2 外放调音：把 MIUI 的杜比参数搬到 Linux

结论

杜比的算法搬不过来（Android AudioEffect + 厂商 DSP 标定，且授权绑定），但调音参数是明文：/vendor/etc/dolby/dax-default.xml（DAX3 Android，format 3.x）。单位是 1/16 dB，-192 就是 −12 dB。

nabu 的曲线在 469 Hz–2.25 kHz 是一串 −7…−9 dB 的坑，本质是减法校正，不是"增强"。另外 ieq_balanced/warm/detailed 三条曲线在 agate/fuxi/marble/zircon 四台机上完全一致，说明它们是杜比 bundle 的通用音色，逐机差异在 audio-optimizer-bands（有的机型这一段全是 0，校准被放进 HAL/DSP 二进制）。

踩过的坑：滤波器级联 ≠ 曲线

第一版把 20 个频点直接映射成 20 个 Q=1.2 的 peaking 滤波器。频段只隔 1/3–1/2 倍频程，每个滤波器同时也在削邻居，级联后：

• 曲线上 1 kHz = −7.6 dB
• 实际级联 ≈ −20 dB
• 整条链路平均 −12 dB（满幅粉噪逐样本跑 biquad 仿真验证）

为了把响度找回来又加了 +4 dB 补偿增益——这就是"音量 50% 以上炸麦"的来源：补偿增益把信号重新推回功放（CS35L41）的保护边缘。

教训：点值曲线要么用 FIR，要么拟合成少量宽滤波器再级联；不能把每个点当成独立 biquad 直接串起来。

修法：9 段宽滤波 + 零补偿 + 保险限幅

• 最小二乘把曲线拟合成 9 个 Q=1.0、一倍频程间距的 peaking（63/125/250/500/1k/2k/4k/8k/16k），拟合误差 ±2 dB
• 不加补偿增益；EQ output-gain = −2 dB 留余量
• 限幅器只当安全网：−1 dBFS、5 ms lookahead、20 ms release，正常播放不动作
• 60 Hz 高通，限制小板喇叭的低频行程

仿真（满幅粉噪）：peak −6.0 → −14.5 dBFS，rms −18.5 → −25.7 dBFS。100% 音量也不会超过直通路径，从原理上不会再炸。

代价：同音量下比直通轻约 7 dB，靠音量旋钮补。

现状

systemctl --user status easyeffects-dolby.service
systemctl --user restart easyeffects-dolby.service
systemctl --user disable --now easyeffects-dolby.service   # 不要了

easyeffects -b 1    # 全局旁路，A/B 对比
easyeffects -b 2    # 恢复
wpctl set-default 48   # 临时把默认输出切回扬声器（绕过 EE）

想更响

在 EasyEffects 里加 Limiter → Input gain，每次 +2 dB，加到开始炸就退一格。不要靠改 EQ 抬增益——那等于把级联过深的问题再引回来。

第 5 部分 · 亮度与音量同步

5.1 waydroid-sync：组件、主控与音量映射

让 Ubuntu 与 Android 的亮度、音量互相跟随。

组件

systemctl --user status waydroid-sync
systemctl --user restart waydroid-sync
systemctl --user disable --now waydroid-sync     # 不要了就关掉
journalctl --user -u waydroid-sync -f            # 实时看同步事件

音量：不能 1:1 对齐

两端音量是相乘关系：

实际听到 ≈ 宿主音量% × 安卓媒体音量%

所以「宿主 50% + 安卓 50%」实际只有 25%。1:1 同步会让音量莫名其妙变小。

解法是把非主控端钉住，主控端的数值就等于实际音量。

主控端由脚本顶部常量选择：

MASTER = "auto"      # 默认：谁被拖动谁生效，另一端归满——两边都能正常调
HOST_PIN = 100.0     # 固定主控模式下钉住的一端

# MASTER = "android"  # 安卓固定主控（宿主钉满）
# MASTER = "host"     # 宿主固定主控（安卓钉满）

默认 auto：你动哪边，哪边就保持住；另一边自动归满，保证"两端乘积 = 你这次调的数值"。

代价是没被调的那一侧会显示 100%。这在相乘结构下无法避免——两个滑块不可能同时显示真实值，总有一端要让位。

如果希望某一端永远固定（例如只在安卓里调音量），可以切换成 "android" 或 "host"：

实测教训：钉死某一端（不管哪一端）都会让那边的音量条失效。"android" 模式下的原话是"没法把音量调大了，默认就是满的"；"host" 模式下则是"宿主这边的应用都不能调音量了"。所以默认用 auto。

启动归一化

开机时两端可能都在半路（各 60%，实际 36%）。守护进程启动时把乘积算清并搬到主控端：

[19:50:45] 启动归一化：实际音量 53% → 安卓 53% / 宿主钉 100%

响度不变，只是把账本统一到主控端。

一个无法避免的副作用

在安卓里拖音量条，松手后会弹回满格（因为真正被调的是宿主音量）。这是相乘结构决定的：两个滑块不可能同时显示真实值。

亮度

应用内调亮度时，SurfaceFlinger 会设置覆盖值，守护进程读到后直接写宿主背光；退出应用后覆盖消失，自动回落到全局设置同步（并做基线重对齐，避免跳变）。

# 查看某个 app 是否设置了窗口亮度
adb shell 'dumpsys SurfaceFlinger | grep -m1 displayBrightness'
#   displayBrightness=nullopt   → 没有 app 在控制
#   displayBrightness=0.35      → 有 app 设了 35%

注意：不是所有播放器都用窗口亮度。有的（如部分 B 站版本）用半透明黑色遮罩"调暗"，那种在 SurfaceFlinger 里没有任何数值可读，无法桥接——因为它只是往画面上盖了一层黑，不改任何亮度参数。

另外，Waydroid 没有虚拟背光，Android 的亮度设置本身不会让画面变暗；现在它是通过同步去驱动宿主 backlight，才产生实际效果。

关键实现细节

• 回读后存基线：Android 的媒体音量上限不是固定的——有时是 15，音量保护策略生效时会钳到 10。写完必须回读真实值存起来，否则会出现"设了又改回去"的振荡
• 上限必须动态解析：cmd media_session volume --stream 3 --get 返回 volume is N in range [0..MAX]，要按返回的 MAX 换算百分比。写死 10 会把拖到顶算成 150%，宿主被钳到 100% 并莫名跳满（这个坑踩过一次）
• 忽略"被应用恢复到满格"：安卓侧被钉在 100%，有些应用/系统会自己把音量恢复满格。这类变化要忽略，否则会被误判成用户调节，导致宿主突然跳到 100%
• 按变化方向判断：只有一侧变了、另一侧没变才触发同步，两边都变就都不动
• adb 自愈：容器重启后 adbd 可能没开，守护进程每 30 秒最多尝试一次 sudo waydroid adb
• 容器没起时不报错：只记一行日志，等待容器就绪

第 6 部分 · 桌面工具链

6.1 看 Markdown：现状与结论

不要装 apostrophe。 apt 里是 3.4（2022 年的代码），在 Ubuntu 26.04 上直接坏：ApostropheTextView 的 markup 控制器没初始化成功，每次布局回调都抛异常，窗口永久「未响应」，正文永远不渲染，连 WebKit 子进程都没起来。日志特征：

apostrophe/text_view.py:327 in _on_size_allocate
    self.markup.update_margins_indents()
AttributeError: 'ApostropheTextView' object has no attribute 'markup'

2026-11-03 装过一次确认无解，已 apt remove --purge 卸载并把 mime 默认还原。真要个桌面编辑器再另找（Qt 系的 ghostwriter / retext 没这个问题），但日常看文档用 dsh 就够。

6.2 dsh Web GUI：文件树与文档预览

启动 dsh web，浏览器打开它打印的地址（本机是 http://127.0.0.1:3080）。

• 右侧栏 →「文件」面板：树根是当前会话的工作目录（默认 ~/文档/deepseek-harness/default-workspace），只能往下，不能向上浏览。这是设计限制：Host 的目录列举按会话根做包含检查，不是配置项。
• 点任意文件 → 开一个「文档预览」标签，内容由浏览器渲染，不依赖本地编辑器。支持 markdown（表格、代码块、相对路径图片、YAML frontmatter）、代码、图片、PDF、docx/pptx（本地转 PDF）、xlsx/csv、HTML。
• 预览按页懒加载、文件改动自动刷新，所以改文档时不用手动重载。
• 注意：读取接口本身不限制工作区，限制的只有「列目录」。所以既有文件能被预览，只是文件树里走不到。

6.3 自写插件：@local/dsh-open-file

在「文件」面板标题栏加一个按钮（箭头进文件夹的图标），弹出系统文件选择框、默认定位 ~/桌面，选中的文件直接用内置预览打开，不受工作区限制。

工作方式：Host 只负责「弹框、把你亲手选的那个绝对路径返回」，Client 把路径包成 dsh-resource://file/session/<会话id>//home/neko/桌面/xxx.md 再交给内置预览（首部 // 表示绝对路径）。安全边界：

• 路由只接受 GET，只接受 Sec-Fetch-Site: same-origin（跨站 403），同一时刻只开一个对话框（409）。
• 不接受任何路径参数，返回值只能来自对话框，伪造地址伪造不出文件。

装进的是 profile web（~/.dsh/profiles/web），pnpm add <目录> 建的是软链接，所以改源码目录里的文件就是改生效文件；改完刷新页面即可，模块版本没换就重启 dsh web。

6.4 装 dsh 插件的前置：pnpm

install_bundle 内部跑 pnpm add，本机最初没有 pnpm，会直接失败：

Command failed with ENOENT: pnpm add '...'
spawn pnpm ENOENT

sudo npm i -g pnpm@10   # 装到 /usr/local/bin/pnpm
pnpm --version          # 10.34.9

另外两条和这次相关的清理经验：

• 不要用 apt autoremove 清空间。 本机有一批被标成「自动安装」但你在用的包（deepin-wine、exagear、caribou 等），autoremove 会一起带走。卸载单个包用 apt remove --purge <pkg> 就够。
• 卸 apostrophe 时留下了 pandoc 等 4 个包共约 210 MB（当时作为依赖被拉进来）。pandoc 本身是通用文档转换工具，留着有用；确实不要就 apt remove pandoc pandoc-data python3-pypandoc python3-regex。

附录

A. 事故时间线（2026-11-02）

B. 不要做的事

C. 命令备忘

# ---- 启动 / 槽位 ----
fastboot set_active a && fastboot reboot
cat ~/.local/share/nabu/boot-count
nabu-boot-count reset

# ---- 充电 ----
cat /sys/class/power_supply/qcom-battery/status
cat /sys/class/power_supply/qcom-battery/current_now   # 6.14: 负=充电  6.17: 正=充电
cat /sys/class/power_supply/qcom-battery/capacity
journalctl -k -n 20 | grep -o 'v_offset=[0-9]*' | tail -1
timeout 20 udevadm monitor --subsystem-match=typec 2>/dev/null | grep -c port0-partner

# ---- Waydroid ----
waydroid session stop
sudo systemctl start waydroid-container
waydroid session start &
waydroid show-full-ui
waydroid status

# ---- 音频 ----
pw-metadata -n settings | grep -E 'force-quantum|min-quantum'
timeout 8 pw-top -b -n 3 | grep -E 'alsa_output|Waydroid'
wpctl status | sed -n '/Streams:/,/Video/p'

# ---- 文档 / dsh ----
gio mime text/markdown                      # 当前用什么打开 .md
sudo npm i -g pnpm@10                       # dsh 装插件的前置（只需一次）
dsh web                                     # 启 Web GUI，浏览器访问它打印的地址

D. 参考

• Waydroid 音频 HAL 无 PULSE_RUNTIME_PATH：https://github.com/waydroid/waydroid/issues/2333
• Waydroid 官方文档：https://docs.waydro.id/
• Waydroid 安装源：https://repo.waydro.id（已确认支持 Ubuntu 26.04 resolute）

E. 局域网访问 DSH（黑屏救援用）

systemctl --user status dsh-lan        # 绑定 192.168.31.41:3081 的实例
cat ~/桌面/dsh-局域网地址.txt          # 带 token 的最新 URL

• token 每次重启都会变，URL 以桌面那个 txt（或 ~/.local/share/nabu/dsh-lan-url.txt）为准
• 所有设备必须连同一个实例：DSH 的会话同一时间只能被一个进程驱动， 连到别的实例会报"当前会话已被占用"
• 只监听局域网 IP，别在路由器上映射到公网（URL 等价于以 neko 身份执行命令）

F. 电源键与休眠显示

行为（2026-11-04 实测定稿）：

为什么这么绕：这块屏有两个坑，单独用系统默认逻辑都会踩到——

1. GNOME 的 power-button-action 默认是 suspend，按电源键唤醒时同一个按键事件又触发一次挂起，表现为"按了没反应、要多按几次"；
2. /sys/class/drm/card0-DSI-1/dpms 是 只读 的（-r--r--r--），root 也写不进去；真正控制显示开关的是 mutter 的 PowerSaveMode（0=亮，1=暗，3=关）。
3. 偶尔从挂起恢复后，mutter 认为屏亮着、但面板没重新初始化，屏幕实际是黑的。

当前机制：

手动操作：

# 强制点亮（黑屏时最有用）
sudo /usr/local/bin/nabu-wake-display --resume

# 看电源键/点亮动作的日志
journalctl -t nabu-wake-display -n 20

# 看每次唤醒的显示状态
sudo tail -20 /var/log/nabu-resume.log

撤销回系统默认：

sudo systemctl disable --now nabu-wake-display nabu-display-on-resume
gsettings set org.gnome.settings-daemon.plugins.power power-button-action 'suspend'

注意：撤销后就会回到"按电源键可能唤不醒、要多按几次"的老状态。

G. 待分析：合上盖子偶尔不触发息屏（2026-11-04 记录）

现象：合上平板套时，有时正常挂起息屏，有时合好几次都没反应（用户原话："不太灵敏"）；打开盖子时唤醒倒是正常。

已确认的事实：

• 霍尔传感器工作正常，内核会报 EV_SW / SW_LID：

  14:04:04  gpio-keys type=5 code=0 value=1   ← 合上
  14:04:10  gpio-keys type=5 code=0 value=0   ← 打开

• logind 也正常处理：

  14:04:04  systemd-logind: Lid closed.
  14:04:04  systemd-logind: Suspending...
  14:04:05  PM: suspend entry (s2idle)

• 失败的几次完全没有 SW_LID 事件（60 秒抓取 0 条），说明不是 logind/GNOME 的问题， 而是磁铁→霍尔这一层偶尔没被触发。
• /etc/systemd/logind.conf 里 HandleLidSwitch 是注释状态（默认 suspend），未被改动。

可能原因（待验证）：

1. 套子里的磁铁位置/强度不够，合上时霍尔电压没跨过阈值（换了保护套可能就正常）
2. gpio-keys 的 debounce 或阈值配置
3. 合上速度太快/角度不对，磁铁没到位

下次排查用的命令：

# 实时看霍尔事件（合上/打开盖子）
sudo timeout 60 python3 ~/.local/share/nabu/lidcap.py

# 看 logind 有没有收到
journalctl -f | grep -iE 'Lid|suspend entry|suspend exit'

# 历史记录
journalctl | grep -c 'Lid closed'

临时对策：合上后如果没息屏，按一次电源键手动挂起；或者把自动挂起时间调短。

已保存的抓取数据：~/.local/share/nabu/lid-capture-20261104.log

现已全面更换为zhaokugua.com

谨此通知

一般只跳转单一固定页面的话，只需要传入shortLink参数即可精准跳转到某一个页面，但是这种shortlink是编码后的链接，看不出来参数等信息，还有很多是需要加参数才能精准跳转的页面用这种方式就做不到。因此还有使用AppID和path跳转的方式。

    joinChannel(event) {
      wx.navigateToMiniProgram({
        "shortLink": "#小程序://卡拉彼丘手游/LvdUNdJ7mb8zayG"
      })
    },

AppID在小程序右上角三个点里查看详情就能看到，但是path去哪里看呢？

这有几个前提条件：

首先保证小程序可以被正常搜索到，未开放搜索能力或者搜索功能被封禁的小程序是看不到的。

准备好一个可以正常进入编辑公众号文章的公众号账号。

如何查找小程序的AppID

1. 找到你要找path的小程序，点击右上角三个点，点击小程序名称。

2. 点击小程序的简介进入详细信息页，这里面就有小程序的AppID信息。

如何查找小程序某个页面对应的Path

1. 打开微信公众平台（mp.weixin.qq.com），登录公众号的账号。

2. 点击新的创作里的“文章”，进入文章创作页面。

3. 点击上方的小程序按钮，点击“去搜索”，输入小程序名称或者appid进行搜索，搜到了点下一步。

4. 点击“获取更多路径”，在输入框中输入你的微信账号，即可开启十分钟的可以复制小程序任意路径的功能。

5. 进入小程序对应页面，点击右上角三个点就能看到复制页面路径的按钮，点击就可以复制路径了。如果有参数的话这里的参数也会一同复制到粘贴板，比如卡拉彼丘手游的扭蛋集卡页面就是pages/home/home.html?tab=lottery

注意：直接复制的path是有.html的，要把这个去掉才能正常跳转！

然后在自己的微信小程序里即可使用wx.navigateToMiniProgram的API里填上对应的AppID以及path参数即可跳转到对应的页面。

      // 需要变化参数跳转不同页面的需要AppID和path
      wx.navigateToMiniProgram({
        "appId": "wx8bdd206c6778298d",
        "path": "pages/home/home?tab=lottery"  // path里可以传参，比如此处的tab=lottery
      })

当时好像花了四五千块吧，记得是联想家悦系列的普通台式机 联想 家悦 U2135A

1440x900最高75hz的屏幕，1G的DDR2内存，160G的希捷硬盘，AMD速龙3600，还有128M显存的nVIDIA Geforce7100GS

这显卡不仅是入门级性能菜鸡，关键还没有主动散热，仅靠鳍片被动散热，刚好碰到了烧显卡的通病，没多久就拆下来了

然后这台电脑剩下的大部分时间都是64M显存的核显在工作（更菜鸡了

最早预装的还是vista系统，当时加了太多动画特效导致在这台菜鸡电脑上贼卡，没几天就被换成了盗版winxp（

后来xp停止维护又被我升级过win7和win10，当年还是ghost装机时代哈哈

由于实在是太卡了，玩4399网页小游戏都要选一些小型的，不然也会卡

后来考上市里的一中有了一千块钱拿来升级电脑，全靠咸鱼捡垃圾组了个GTX650战神，甚至还买了个全新的打印复印一体机和手机（

当时很火的三人一狗终于也是能玩上了（别提有多激动了

哈哈现在还在玩三人一狗（6怎么还没出！

如今工作了，有点自己赚的钱也算是能实现儿时的梦想了

RGB最强游戏主机，启动！

本来想去年十月左右就组一个的，大学的老笔记本还能凑活用就一直没动，刚好要出新一代50系显卡就想着买新不买旧不如等一等。

然后等到1月发布，各种耍猴涨价之后实在忍不住了，2月装出来了，只不过显卡暂时拿4080s过渡。

选的是水冷卡，所以就做了个CPU和显卡全水冷的方案（

显卡是测出风的，当时刚好还是冬天比较冷还能烤烤腿（

用着4080s看上去好像也比较高端了，但是配的是4K屏还总想着拉满画质开光追啥的就总感觉不够用要换90（

再后来5090终于降价了一点然后实在憋不住了就换了（没想到后面还在猛降价，甚至比二手4090都便宜

然后我终于获得了我的9800X3D+RTX5090神机（

9800X3D毕竟核心数少一些，多核处理方面还有生产力上总归是要差一点的，但是就看上了这个X3D的超大缓存带来的游戏帧数提升，小学微机课上就学过CPU里的缓存比金子都贵，速度是最快的。

实际用下来感觉可能游戏编译着色器的时候回比其他U慢一些，进游戏之后的帧数确实高。

不过编译着色器的时候感觉还是有点积热问题，拿360水冷压也有70度左右总感觉有点压不住（比起之前的电脑动不动100℃+好太多了

然后就是5090，因为之前用过4080s所以还是能感觉到有些区别

一是并不是买了5090所有画质就都能拉满，有些没优化的游戏5090全拉满也跑不了多高的帧数，还是得看厂商优化

二是有些确实能跑满但是功耗实在是太高了，动不动四五百瓦功耗，已经赶上半个空调了，夏天太热了（还得降画质降点功耗玩

三是待机功耗高，现在啥都不干，5090的待机功耗就能达到六七十瓦，之前4080s待机功耗也才二十出头！甚至跑一些游戏才七八十瓦功耗，不愧是电老虎（

不过之前4080s跑不满的游戏能全拉满是真的爽啊（

视频剪辑也有巨大提升，开了GPU加速编码，几分钟的4K视频渲染导出就要几秒钟，之前从没想过能这么快

还有超大32G显存，目前还没找到有什么游戏能完全吃满，就算把怪猎荒野开全高4K200%渲染倍率和DLAA，只能跑30帧但是显存只能吃25G（

现在画质都拉满了，游戏都能随便玩了，全都是顶级画质了

总感觉还是少了点什么

总是怀念之前大学宿舍一起开黑的时光...

果然，游戏要求最高的配置还是朋友啊...