昨天发了帖子之后，承蒙各位佬友错爱，都在等我翻车，那我就来更新一下后续。
自从昨天将主力机清盘重装为 CachyOS 之后，的确遇到了几个明显的问题，供佬友们参考：
显示问题，HDMI 限速
我的笔记本上有一个 HDMI 口，两个 C 口，其中有一个被电源占用，所以我一直是用 HDMI 线连接显示器的，在 Windows 下没有什么问题，高刷和 freesync 都可以正常使用，就是 HDR 开了之后发灰，一般不看番不玩游戏的时候都关着的。
我照同样方式连接 Linux 时，发现 HDR 的支持意外地好，大部分 SDR 场景下肉眼几乎看不出区别，除了一些 UI 里非常浅的灰线会更不明显，其实我认为本来设计得就有点太浅了说的就是你，B站，而且查了一下这个问题在修了，GNOME Mutter 中的 tone mapping 算法还在持续改进。
所以我觉得可以长期开 HDR 了，直接白嫖随时观看 HDR 内容的方便。然而却发现没有高刷了，可变刷新率倒是存在的，可是打开也是最高 60 帧，让 AI 查了一下，原因是
HDMI Forum 在 2024 年正式拒绝了 AMD 发布支持 HDMI 2.1 的开源驱动程序的提议，导致 Linux 上 AMD GPU 只能使用 HDMI 2.0 的带宽限制，4K 最高 60Hz
AMD 在 2026 年 5 月向 Linux 内核提交了 HDMI 2.1 FRL（固定速率链路）支持的补丁，并已合并到 Linux 7.2 内核中。
然而 7.2 可能要到八月底才能正式发布，而且 FRL 与 VRR 可变刷新率是冲突的。
DP
于是我就尝试 C 口 DP 输出，昨天拿了一根老线，黑屏，京东下单新线，今天到了，就可以用了，没任何问题。我对比了一下，唯一的区别就是新线上标了个 DP 1.4，其他完全一样，甚至都是一个牌子的，样子也一模一样，铝合金模具用的是一个。我不知道是这个原因还是老线坏了。
反正目前的情况就是
然而我发现了几个问题，那就是
- HDR 显著不如 HDMI 下好用，SDR 内容发黄，没法看，不能长期开了。
- 你也看到我没有开 VRR，原因是开了之后，重启时有概率导致显示器死机！你没听错，就是显示器本身的固件死机！第一次发生的时候我的左半边显示器直接不亮了，电脑关机后显示的无信号提示也是只有右边一半，我还以为是屏幕挂了，把我吓坏了，我想着重装个系统还能把硬件外设损坏？还是说我移动的时候碰坏了？但是我一想挂也不可能正正好在中间吧，刚好把一半的驱动线路给烧了？不会是显示器卡 Bug 了吧？于是我把插线板断电等待并重启了一下，就好了
所以我现在只是正常用 4K 160HZ SDR，色彩管理我注意到 Linux 会自动使用显示器回报的 icc 文件，在 Gnome 里就能正常地查看，不过这方面我不太懂，不知道是否准确。我注意到目前 DP 是 RGB 格式，是不是 HDMI 是 YCbCr 格式，所以 HDR 效果会不一样。
网卡问题，WOL 不支持
原本我在 BIOS 中打开网络唤醒之后，在 Windows 下就可以正常工作，所以我以为网络唤醒只需要配置 BIOS 即可，可是换成 Linux 之后发现居然没法唤醒成功了。
查阅之后发现，需要操作系统同时在关机时也把网络唤醒打开，否则网卡还是会睡死。
于是键入 nmcli connection modify "连接名" 802-3-ethernet.wake-on-lan magic
然而，重启后sudo ethtool是有Wake-on: g输出了，可是关机后还是无法唤醒成功。
查阅网卡型号之后发现，我笔记本使用的国产网卡虽然写了 GNU 开源驱动，但是合入 Linux 主线失败了，独立的大代码库不符合 Linux 开发规范，一直没有被主线接受。社区开发者发现与现有的一款网卡驱动高度兼容，所以就 wrapper 了一层，跑了起来，但是 WOL 这样的高级功能自然是没有的，不仅如此，初始化时还主动关掉了 WOL 硬件。开发者也没有支持的计划，只是说"could be implemented in the future"
让 AI 分析了一下，其实支持 WOl 本身可能只需要 50 行代码，可是我完全没有 kernel/裸金属/嵌入式开发经验，无法为补丁负责，Linux 又是是贡献驱动的，不是需求驱动的，我给维护者发邮件估计也很难获得相应。未来这个功能花时间去学可能成本过高，所以就这样吧。我也不想用 AUR 上的官方驱动，因为不知道什么时候滚动有可能冲突，内核层面还是不要做这种不确定的更改。
我需要使用 WOL 主要是因为合盖启动，所以我现在被迫更改了我的桌上布局，只能让笔记本打开着落灰。
AUR问题，微信维护者战争
想装 QQ 和微信来着，结果一查，QQ 还好，无非就是好几个原版、魔改版、沙盒版竞争，互相正常 Conflict。
结果微信呢，居然出现了包括但不限于：更改上有、把自己的包伪装成别人的包、强行合并包名等等一系列 drama，甚至 Archlinux 中文 Wiki 都发生了编辑战，现在 wiki 上还在喷投票数最高的那个包。
所以我现在完全不敢信任 AUR 上的任何 QQ 或微信包名，因为不知道什么时候就有可能被从原维护者手上抢走了，然后给我来一个更新。
所以我现在准备用 Flathub 上的 QQ 和微信，听说都没什么毛病，挺稳定的，而且是 GitHub 式的共识协作，由 Flathub 自动构建、可审计。虽然不是官方的，但至少靠谱多了，官方的 deb rpm AppImage 都不能自动更新。
