如题，楼主大约在一个月前购入一台高贵的阿苏斯天选 5 Pro，拿回家后毫不犹豫驱逐了 Windows，换上我心爱的 ArchLinux刚开始使用基本正常（唯一的问题是休眠睡过去就醒不来了），键盘 RGB 背光控制也一切正常，直到某一天（我是两天前才发现，但实际出现问题肯定早于这个时间），楼主心血来潮想要换一下背光颜色，结果发现竟然报错了（如下图），并且 KDE 的键盘亮度调节滑块也神秘消失了，非常神奇。那经过一些研究，楼主已经找到了他的病根，下面就让楼主来带你直捣黄龙
ps：使用该笔记本遇到类似问题的吧友可以参考此帖解决。

如上图，这个报错是：
Error: org.freedesktop.DBus.Error.Failed: Asus Platform error: kbd_rgb_mode No such device (os error 19)
如果你注意力够集中，不难注意到，这是一个 DBus 服务报错，说找不到 kbd_rgb_mode 这个设备。在华硕笔记本上，用户通过安装 asus-linux 项目提供的 asusctl 软件包可以控制笔记本的各项拓展功能，包括键盘 RGB 背光。asusctl 软件包提供了一个叫做 asusd 的守护进程，它运行在 DBus 上，可以用命令行前端 asusctl 来与它通信，控制笔记本的行为。那这里显然是 asusd 报错了，因为控制 RGB 背光这个行为实际上是由 asusd 执行的。
再从具体报错上来看，它说找不到 kbd_rgb_mode 这个设备，这非常让人迷惑，说到什么什么设备，Linux 人的第一反应肯定是去 /dev 目录下看看，但是根据我的印象，从来就不存在什么 /dev/kbd_rgb_mode，以前键盘背光正常时也没有这玩意

没办法，看一看 asusd 的日志：
好嘛，同样的报错，找不到设备。经过我的一番搜查，华硕平台的各种功能是由两个叫做 asus_wmi 和 asus_nb_wmi 的内核模块实现的，与键盘背光相关的功能由 asus_nb_wmi 管理，在 /sys/devices/platform/asus-nb-wmi/leds/asus::kbd_backlight 暴露出接口，asusd 就是通过操作这个目录下的接口（文件）来实现背光控制的。
这里我就有理由怀疑这个驱动没有被正确加载，但是经查证并无此事。问题应该还在更深层次的地方。
这个目录下有这些文件：
看到了熟悉的东西，这里有个 kbd_rgb_mode，也就是最开始 asusd 报错说不存在的设备。我尝试用 cat 读这个文件，但是它说我权限不足（已经 sudo），看来这个文件是不能读的。结合之前的报错和这个命名，楼主大胆猜测：通过向这个文件写入某种格式的指令数据，就可以控制背光

但是这个数据格式咱是不知道的，网上也根本查不到资料。既然这个东西是内核驱动暴露出的接口，我们不妨去内核代码中找一找线索。
在 Github 上打开内核代码，全局搜索 kbd_rgb_mode，很快就能找到位于 drivers/platform/x86/asus-wmi.c 文件中的这个函数 kbd_rgb_mode_store：
看起来它就是处理我们写入数据的函数，写入的数据在 buf 参数中。可以看到它用 sscanf 来处理这个字符串，从 sscanf 格式可以看出，buf 是一个包含了 cmd, mode, r, g, b, speed 这 6 个数字的、空格分隔的字符串。
注释和代码已经指明，cmd 可以取 0 和 1 两个值，0 表示直接设置，1 表示保存设置到 BIOS。mode 可以取 9-12 的整数值，具体是干什么的不清楚，r, g, b 三个值自然就是颜色了，最后一个 speed 估计是动效模式的速度之类的。
不管那么多，我们先按照这个格式给他乱写一通看看：
我艹报错了没有那个设备，嗯，看来我们已经抓住问题的关键所在了。
到这里，已经可以确定不是 asusd 或者 asusctl 的问题，是内核驱动炸了。

内核代码都打开了怎么能止步不前，让我们继续干得深入一点
这个函数唯一能够返回错误的地方是这里：
我们的命令被交给 asus_wmi_evaluate_method3 这个函数处理，进入这个函数：
好在函数很简单，将一系列参数填入 bios_args 结构体，然后调用 wmi_evaluate_method 函数处理我们写入的的命令，如果无法执行命令，则返回 EIO（IO 错误），如果命令执行了但是失败了，则返回 ENODEV（没有那个设备）。
到这里，已经可以发现，绝对是因为这个 wmi_evaluate_method 函数返回了 ASUS_WMI_UNSUPPORTED_METHOD（不支持的方法），然后导致了错误。

考虑到这个问题是不久前才出现的，之前使用都正常，我有理由怀疑是哪个家伙给内核提交了什么代码，然后引发了问题。用 GitHub 的 blame，找一找最近的提交，尤其是关于这几个关键函数的修改，很快就能找到几个很可疑的提交。
2022 年 8 月 26 日，jwrdegoede 大佬实现了键盘背光这个功能：
2024 年 4 月 9 日，他进行了一些更新，支持了一些版本 TUF 本的 RGB 功能：
这个 patch 最终被合并到 6.10 内核，也就是我现在使用的内核。我高度怀疑就是这玩意把我的 RGB 搞崩了。正打算详细研究一下这个 patch 看看他到底干了什么时，又有了惊喜的发现：
这位 ij-intel 大佬应该也遇到了这个问题，它已经在两周前提交了一个补丁，明确指出 jwrdegoede 的那个提交引发了 RGB 功能的问题。虽然我不能确定他所说的是不是我目前遇到的这个问题，但是直觉告诉我，只要我把这个补丁干上去，99.99% 能轻松秒杀

查阅了内核邮件列表，在这个补丁下，Ilpo Järvinen 大佬回复到：
嗯，看来这个补丁已经去 Linus 那里了，顺利的话，它会在 6.11 内核被合并。现在 arch 内核最新版是 6.10，按照内核周期加上 arch 的更新周期，不久之后 arch 就能滚到 6.11 内核，到时候这个问题应该就会被修复。
但是楼主已经急不可耐了（主要是想验证一下这个补丁是不是针对这个问题的），就在今晚已经把这个补丁手动干上去，并编译了新的内核进行测试。
结果当然是，轻松秒杀RGB 功能恢复正常。
接下来就只需等 6.11 内核进官方仓库了，届时问题就会完全解决。

完结撒花

好好好

👍🏻

牛的牛的 没想到排查问题查到内核头上这个笑话是真的