晚上好 世界

晚上好 世界

早安

我在火车上想看我的paperwrite 5的时候，它屏幕坏了，我把它拆掉才发现是排线掉了，接回来就好了

本文由voyage200的 hermes-agent 代其撰写，不过voyage200本人仍对文章负责。

火影 T5G AMD（搭载 AMD Ryzen 5 5600H + NVIDIA RTX 3050 Mobile）本质上基于蓝天（Clevo）NH50/NH55（如 NH55Ax）公模。这类模具性价比极高，但官方往往只提供 Windows 版驱动（即官网上 270MB 的「综合控制中心-CV」，Clevo_ControlCenter_7.057.zip）。

在 Linux（我的主力机运行 Arch Linux + Linux 7.2 内核 + GNOME Wayland）环境下，默认没有专有控制程序，通常会面临两个烦人问题：

  1. 风扇策略不可控：默认保守的 EC 策略在负载升高时容易迟滞或突然起飞咆哮，日常码字又希望能有一套更安静的温控曲线；
  2. 键盘 RGB 无法调节：单区 RGB 背光无法改色，无法调暗甚至关不掉。

为了彻底解决火影 T5G 在 Linux 下的综合控制问题，我们逆向解包了官方 Windows 驱动包，理清了底层协议，并成功基于 Linux 开源生态打通了整套风扇曲线与键盘调色方案。以下是完整的逆向探查与配置排坑记录。

一、 官方 Windows 驱动包逆向剖析

官方下载的 Clevo_ControlCenter_7.057.zip 解压后是一套标准的 InstallShield 打包工程（包含 data1.cab、data2.cab 和 setup.exe）。通过 Linux 下的 unshield 工具解包 CAB 后，可以提取出其内部真正的核心载荷：

  1. ACPI 与 WMI 硬件通信桥：

    • 包含 AcpiBridge.sys、AcpiBridge1.sys 与 InsydeDCHU.dll；
    • INF 文件显示硬件 ID 为 ACPI\CLV0001 和 ACPI\CLV0002；

    • 底层通过 \\root\WMI 命名空间以及 ACPI DSM 方法与主板 EC 交互：

      • 0x63 / 0x64 / 0x6E：读取 CPU、GPU 及系统风扇的 RPM 转速与 PWM 占空比；
      • 0x68 / 0x69：设定手动风扇转速 / 恢复自动风扇策略；
      • 0x79（子命令 0x19）：切换蓝天官方性能模式（Quiet / Power / Performance / Entertainment）；
      • 0x67：控制键盘 RGB 颜色与亮度掩码。

  2. 键盘模块（Keyboard.appxbundle / LedKeyboardSetting.exe）：

    • 针对外挂的单键 RGB（Per-Key），驱动内置了 ITE Tech（048d:8297 / 048d:8910）USB HID 驱动；
    • 针对主板自带的整区/三区背光，直接走上述 ACPI 0x67 接口下发。

二、 Linux 方案选型：TUXEDO Control Center (TCC)

德国知名 Linux 笔记本厂商 TUXEDO Computers（以及欧洲贴牌商 XMG / Schenker）旗下大量游戏本均采购蓝天模具。他们官方开源并重金维护了一整套成熟的 Linux 方案：

  • tuxedo-drivers：内核 DKMS 模块，内置了 clevo_wmi、clevo_acpi、tuxedo_keyboard 以及风扇读写接口 tuxedo_io；
  • tuxedo-control-center（TCC）：图形化桌面控制中心与后台守护进程 tccd，提供无级风扇曲线调节、键盘 RGB 调色盘、性能模式切换等完整功能。

唯一的障碍与社区补丁

Tuxedo 原厂驱动在 tuxedo_compatibility_check.c 中加了 DMI 厂商白名单校验（若非 TUXEDO 机器直接退出）。
Arch Linux AUR 社区的 clevo-drivers-dkms-git 已经为我们打了补丁，强制 tuxedo_is_compatible() => true，完美移除了厂商硬件锁。

三、 Arch Linux 实装与排坑记录

1. 安装基础包

sudo pacman -S --needed base-devel linux-headers dkms
yay -S clevo-drivers-dkms-git tuxedo-control-center-bin

2. 踩坑一：模块加载语法误区导致 TCC 界面留白

在安装完成后启动 tccd.service，打开 TUXEDO Control Center 发现界面只有 Tux 图标，下方空白，风扇转速也无法调节。查看后台日志提示：

FanControlWorker: onStart: Fan API not available
KeyboardBacklightListener: Detected no keyboard backlight

原因分析：
Linux 下 modprobe 的语法是 modprobe [模块名] [参数...]。如果敲成：
sudo modprobe tuxedo_keyboard tuxedo_io clevo_wmi clevo_acpi
内核会把后面三个名字全部当作参数传给 tuxedo_keyboard 并全部忽略！导致关键的 tuxedo_io（提供 /dev/tuxedo_io 节点）和 clevo_acpi 根本没进入内核。

正确做法：逐个单独加载核心模块：

sudo modprobe tuxedo_io
sudo modprobe clevo_wmi
sudo modprobe clevo_acpi

模块加载后，重启后台服务：

sudo systemctl restart tccd.service

再看日志，风扇与性能模式瞬间满血激活：

FanControlWorker: initializeFanControl: tuxedo-io available
FanControlWorker: initializeFanControl: Detected 3 fans
FanControlLogic: Setting tableCPU / tableGPU
ODMProfileWorker: Setting ODM profile 'performance'

在 TCC 界面点击 Profiles，已经可以随心所欲自定义 CPU / GPU 的温度-风扇转速阶梯曲线了！

四、 键盘背光探秘：单区 RGB 到底能不能硬件呼吸？

在排查键盘背光时，驱动成功握手并在内核日志中打印：

tuxedo_keyboard: Set keyboard enabled to: 1
tuxedo_keyboard: Set keyboard backlight mode on CUSTOM

在驱动加载的瞬间，我的键盘背光熄灭并重置为纯白色，同时 /sys/class/leds/rgb:kbd_backlight/ 成功出现！在控制中心也可以自由拖动调色板改色。

但当我尝试测试动效时，发现了一个经典疑问：为什么执行 echo 1 | sudo tee /sys/devices/platform/tuxedo_keyboard/kbd_backlight_mode 会报“权限不够”？火影 T5G 单区键盘到底支不支持硬件呼吸？

为了彻底搞清这个问题，我们直接进行了双向源码反编译：

1. Linux 内核驱动源码求证

查看 clevo_keyboard.h 驱动源码发现：

static void clevo_keyboard_init_device_interface(struct platform_device *dev)
{
    // 只有 3 区 RGB (0x02) 才会创建该 sysfs 动效节点！
    if (clevo_leds_get_backlight_type() == CLEVO_KB_BACKLIGHT_TYPE_3_ZONE_RGB) {
        device_create_file(&dev->dev, &dev_attr_kbd_backlight_mode);
    }
}

报“权限不够”不是因为 sudo 权限不足，而是虚拟文件系统里压根就没有这个文件！ 驱动作者在识别到单区 RGB（1_ZONE_RGB，类型值 0x06）时直接跳过了动效节点的创建。

2. 官方 Windows 控制中心反编译验证

我们利用 dnfile 和 dncil 深入反编译了火影官方 LedKeyboardSetting.exe 的 CIL 字节码，在 Page_LED_Device.Open_UI 中找到了答案：

ldfld this.kbType
ldc.i4.2            ; 若为 3 区 RGB (Type 2)
call Init_UI_RGB()  ; 加载包含呼吸(Breath)、波浪(Wave)、循环(Cycle)的特效面板

ldfld this.kbType
ldc.i4.6            ; 若为 单区 RGB (Type 6, 即火影 T5G AMD)
call Init_UI_ALL()  ; 仅加载单色调色板，动效面板直接隐藏剥离！

终极结论：
可以彻底死心，不必再折腾固件硬件呼吸了。 火影 T5G AMD 的单区 RGB 在主板 EC 固件中压根就没有烧录硬件呼吸波形微码，即便在 Windows 官方系统下也只有静态纯色。

但这丝毫不影响我们在 Linux 下的使用体验：

  • 原生调色与控光：直接使用 Linux 标准 Multi-Color LED 子系统，在 TUXEDO Control Center 图形界面点选即变色，或者终端一行命令秒切：

    # 变冰蓝
echo "0 255 255" | sudo tee /sys/class/leds/rgb:kbd_backlight/multi_intensity
# 调暗亮度 (0 - 255)
echo 120 | sudo tee /sys/class/leds/rgb:kbd_backlight/brightness
  • 软件呼吸（甚至比硬件更细腻）：如果真的喜欢呼吸效果，在 Linux 下写个极轻量的 Python 脚本循环调节 brightness，正弦波插值平滑呼吸，CPU 占用不到 0.1%，刷新率和过渡甚至优于硬件自带微码。

五、 功耗与温控协同：ryzenadj 与 TCC 是否冲突？

很多 AMD 笔记本用户（包括我自己）会使用 ryzenadj 限制温度墙，比如配置开机自启 systemd 单元：

[Unit]
Description=RyzenAdj Power and Thermal Limit
After=multi-user.target suspend.target hibernate.target hybrid-sleep.target

[Service]
Type=oneshot
ExecStart=/usr/bin/ryzenadj --tctl-temp=75

[Install]
WantedBy=multi-user.target suspend.target hibernate.target hybrid-sleep.target

两者冲突吗？答案是：完全不冲突，天作之合。

  • ryzenadj --tctl-temp=75：工作在物理硬件最底层，直接通过 PCI 写入 AMD 芯片内部的 SMU（系统管理单元协处理器），属于硬件级熔断兜底（一旦触碰 75°C 强制限流）；
  • TUXEDO Control Center：工作在操作系统与 EC 层，只负责 Linux 内核 CPU 调度器（cpufreq governor）以及蓝天 EC 的风扇 PWM 曲线映射。

两者搭配时：ryzenadj 负责守住芯片温度上限，TCC 负责在温控范围内根据自定义曲线安安静静地排热，互不干涉，相得益彰。

六、 后台拉扯排查：TCC 与 GNOME power-profiles-daemon 的冲突与解决

在使用 TCC 过程中，查看日志可能会发现类似如下的警告：

tccd: CpuWorker: Unexpected value core11 maximum scaling frequency => 3301000 instead of 4280985
tccd: CpuWorker: Incorrect settings, reapplying profile

冲突铁证与原理剖析

  • TCC 侧：TCC 守护进程内部有一个 CpuWorker，默认每 10 秒巡检一次 CPU 核心频率上限、scaling_governor 调度器以及 EPP（Energy Performance Preference）；
  • GNOME 侧：GNOME 桌面环境默认自带的 power-profiles-daemon（PPD） 也在后台管理这些相同的 sysfs 节点。
  • 冲突表现：当 GNOME 的 PPD 根据电池或电源滑块调低 CPU 频率（如将 core11 限制到 3.3GHz）时，TCC 的 CpuWorker 发现当前频率与 TCC 配置不符，立刻认定为 Incorrect settings 并强行覆写改回 4.28GHz。两者在后台形成反复争夺的“打架”拉扯状态。

两者能力对比与取舍

  • power-profiles-daemon：仅提供粗粒度的“省电/平衡/性能”三档，功能简陋，既不能调风扇曲线，也不能管键盘背光，更无法联动蓝天模具的硬件模式；
  • TUXEDO Control Center：专为蓝天/Tuxedo 模具定制，不仅支持按“插电/电池”无缝自动切换性能档位，还具备精细的主频上下限控制、风扇曲线和键盘背光管理，完全是 PPD 的绝对超集。

推荐解决办法：彻底屏蔽 PPD

直接停止并屏蔽 power-profiles-daemon，让 TCC 全权负责机器的电源与散热调度（这也是 TUXEDO 官方推荐方案）：

# 停止并彻底屏蔽（mask 可防止 GNOME 再次自动唤醒它）
sudo systemctl stop power-profiles-daemon.service
sudo systemctl mask power-profiles-daemon.service

屏蔽后，GNOME 右上角快捷托盘的电源三档滑块会自动隐藏，所有电源调度均由 TCC 精确统一管理，干净稳定无冲突。

(注：如果你极度依赖 GNOME 顶栏滑块，备选方案是在 TCC 左下角 Settings 中将 CPU Frequency Control 切换为 Deactivated，让 TCC 仅控制风扇和背光，不再干涉 CPU 频率。)

七、 固化开机自动加载

最后，为了确保每次重启或休眠唤醒后驱动自动就绪，添加自动加载配置文件：

sudo tee /etc/modules-load.d/tuxedo.conf << 'EOF'
tuxedo_compatibility_check
tuxedo_keyboard
clevo_acpi
clevo_wmi
tuxedo_io
EOF

并确保守护进程开机启动：

sudo systemctl enable tccd.service

至此，火影 T5G AMD 游戏本在 Arch Linux 下成功获得了比 Windows 原版更轻巧、更自由、更安静的「综合控制中心」完整体验！

截至 2024年10月，Gemini APP 不为香港提供服务。
梯子节点换成美国、日本之类的地区就好了。

2026 2 10 勘误

香港现在可以访问gemini。访问不了主要和香港地区无关 和路线有关系，有些路线被拦了。

主诉

我在国内网络环境，通过ssh连接 阿里云国际型轻量应用服务器实例 时，遇到极其严重乃至掉线的卡顿

😷：为什么不用梯子走SSH，而要直连？
👩‍💻：我试过用梯子代理 SSH 流量。我有两个梯子。一个不稳定（连一会就断了）、一个无法使用（貌似封SSH协议了）。

👩‍💻：我也试过用阿里云的 Workbench 一键连接，是个 网页版 Terminal ，延迟很低。

👩‍💻：而且看UI是基于vscode相关代码二开的，开文件也是vscode同款编辑器、高亮，好评。

👩‍💻：但根本没有针对linux系统测试过，硬编码了Droid Dans Mono这种字体，，，，，而且有时候开个文件也不稳定、在这里面用 zellij 也没法全屏使用（因为我使用 css 强制修改了字体）。搞得我越用越生气，越感觉是在浪费自己的时间。

More...

我会傻傻地 上网搜索，搜索出来 --ozone-platform 这个命令行参数可以指定用 x11 还是 wayland,在以前，我只会做到这里，妥协地改 .desktop 文件（我不太想改 .desktop 文件，因为.desktop 文件一般是由包管理器负责部署的，直接改，不"通知"包管理器的话以后可能会出问题，而且 chrome 这边PWA也会生成 .desktop 文件）。

但现在，我们可以直接派 Agent 过去调查 chromium 的源代码：

使用 deepseek 的 claude code：
2025-11-17T15:24:15.png

● Ozone 平台在启动时选择 X11 和 Wayland 的具体逻辑如下：

  构建时配置

  在 build/config/ozone.gni:59-90 中定义了默认平台选择：
  - Linux 桌面：默认使用 x11 平台
  - ChromeOS：默认使用 x11 平台
  - Fuchsia：默认使用 flatland 平台
  - 其他情况：默认使用 headless 平台

  运行时选择逻辑

  在 ui/linux/display_server_utils.cc:50-70 中的 SetOzonePlatformForLinuxIfNeeded() 函数：

  1. 命令行参数优先：如果已指定 --ozone-platform，直接使用该值
  2. Wayland 检测：
    - 检查 XDG_SESSION_TYPE 环境变量是否为 "wayland"
    - 如果是，自动选择 wayland 平台
  3. X11 回退：如果没有指定平台且不是 Wayland 会话，默认选择 x11

  环境检测

  在 ui/linux/display_server_utils.cc:72-87 中的检测函数：
  - Wayland：检查 WAYLAND_DISPLAY 环境变量或 $XDG_RUNTIME_DIR/wayland-0 套接字文件
  - X11：检查 DISPLAY 环境变量

  平台初始化流程

  在 ui/ozone/public/ozone_platform.cc:32-43 中：
  1. 通过 GetOzonePlatformId() 获取平台 ID
  2. 使用 PlatformObject<OzonePlatform>::Create() 创建对应平台实例
  3. 平台列表在构建时由 generate_ozone_platform_list.py 生成

  总结：Ozone 优先使用命令行参数，其次根据桌面环境自动选择 Wayland（当检测到 Wayland 会话时），否则默认回退到 X11。

好耶～～！我们现在就知道了 chrome 原来是根据 XDG_SESSION_TYPE 选择 X11/Wayland 的。

我们就可以把 XDG_SESSION_TYPE 改到 wayland 之外的值

2025-11-17T15:34:03.png

启动 chrome ，它真的按照 Agent 说的那样使用 X11 （Xwayland） 了！

虽然 Agent 写代码现在不太行，但让它看现有代码效率比自己看要高。

2026.1.20 更新

哈哈，flatpak 那边的chrome是可以通过 echo "--enable-features=TouchpadOverscrollHistoryNavigation" > ~/.var/app/com.google.Chrome/config/chrome-flags.conf 把命令行参数放到文件 chrome-flags.conf，也可以生效的，这样就不需要配啥环境变量了，这也是 AI 浇我的！