杰哥的{教学，运维，编程，调板子}小笔记
修复绿联 UG307-95348 HDMI 采集卡颜色问题（二）
背景
经过 上文 的一系列修复，绿联 95348 终于是可以正确地还原 MateBook Pro 输出的 RGB 色彩了。但是，换到另一台运行 Windows 的笔记本上时，又出现了新的颜色问题，这篇博客就来探讨一下怎么解决新的问题。
颜色问题
现象
用着之前打过 patch、关闭 luma processing 和 chroma processing 的固件，给一台 Windows 机器采集的时候，出现了新的问题，颜色出现了新的偏差：
● 0,0,0 -> 16,16,16
● 255,0,0 -> 237,14,15
● 0,255,0 -> 13,236,12
● 0,0,255 -> 15,15,238
● 255,255,255 -> 234,234,234
在显卡软件里，可以看到这组偏差对应的是 YCbCr，用的是 Limited range。经过验算，这就是把 Limited range 的 YCbCr 当 Full range 来解析，导致的问题。如果用显卡软件切换到 RGB 4:4:4 Limited range：
● 0,0,0 -> 16,16,16
● 255,0,0 -> 232,16,16
● 0,255,0 -> 15,234,13
● 0,0,255 -> 15,16,234
● 255,255,255 -> 233,233,233
也是类似的问题，只有把颜色切换到 RGB 4:4:4 Full range 才可以正确采集。
虽然可以通过手动指定 RGB 4:4:4 Full range 模式来解决颜色问题，但如果没有装对应的软件呢？又或者像鸿蒙和 macOS（macOS 其实有私有 API 可以用）那样没有类似的设置入口呢？
于是就要看，显卡驱动都是怎么判断要选择什么模式的。
EDID
答案就在 EDID 里面。按照 CEA-861 标准，显示器通过 EDID 告诉显卡，它支持哪些颜色模式，比如是否支持 YCbCr 4:4:4 等等，又具体支持哪些分辨率，哪些时序。
然后显卡驱动挑选一个时序，让显卡按照一定的波形来把显示输出通过 HDMI 发送给显示器。此时发送的内容，就有颜色（RGB/YCbCr）以及范围（Full/Limited）之分。那这是怎么决定的呢？
首先，CEA-861 标准规定了一个默认值：对于 CE Timing，默认是 Limited；对于 IT Timing，默认是 Full。什么是 CE Timing 呢？CEA-861 的定义是，出现在标准的 Table 1 表格里，且 VIC 大于 1 的时序，都是 CE Timing。这些 VIC 可以在 这里 找到。那非 CE 的 Timing，就是 IT。
所以当显卡驱动选择了一个时序以后，就根据它是 CE 还是 IT 来决定默认是 Limited 还是 Full。但同时，显卡软件也允许用户自己选择颜色 range。那显示器是怎么知道显卡发送的到底是 Full range 还是 Limited range 呢？
答案是，HDMI 里有传递元数据的 AVI InfoFrame。它里面可以指定，RGB 用的是 Full range 还是 Limited range；YCbCr 用的是 Full range 还是 Limited range。当显示器看到这个信息的时候，就知道不该用默认值去解析了。
但是，并不是所有显示器都支持这个。所以，它还得先在 EDID 里通过 VCDB 来声明，它的 RGB 或 YCbCr，是否允许通过 AVI InfoFrame 指定 range。
解决方法
根据这些信息，就能想到解决方法了：把固件里的 EDID 换掉，全用 IT timing（比如用 CVT-RB），这样默认就是 Full range 了。这样确实工作了。
但是，实践中，又遇到了新问题：我的使用场景里，采集卡和教室的投影仪通过一个 HDMI Splitter 连到电脑上，此时就得兼顾采集卡的情况，而采集卡用的是 CE Timing，比如 VIC 97。结果就是电脑通过 HDMI Splitter 这么一通接了以后，又回到 Limited range 了。
那怎么办呢？如果采集卡能自己识别输入是 Full range 还是 Limited range，然后进行相对应的处理就好了。
怎么识别呢？刚才提到，AVI InfoFrame 里会携带这个信息。所以就修改 EDID，在 VCDB 里设置 QS=1，这样 AVI InfoFrame 里就会出现指定 Full range 还是 Limited range 的信息。然后经过逆向，发现 MS2130S 会在寄存器 0x3c4a 里记录这个信息，这样就可以自动检测了。
怎么处理呢？之前，我的做法是在 OBS 里去 Apply LUT，实现 Limited range 到 Full 的反向映射。但是，如果从 Limited range 的输入切换到 Full range，就得调整 OBS，很麻烦。
于是我就想到，利用已有的 luma processing 和 chroma processing 的 pipeline。根据之前的分析，已知这两个 pipeline 做的事情是：
● luma processing：
● chroma processing：
如果想要实现 Limited range 到 Full range 的映射，也就是 16-235 线性映射到 0-255，只需要：
● 0xfc90 设为 0xf0，对应 -16
● 0xfc91 设为 0x95，对应 255/219
● 0xfc92 设为 0x95，同样对应 255/219
● 最后把 0xfc8f 和 0xfc8e 都设为 0x00，打开 processing pipeline
最终的结果是，在 YCbCr 上的变换，对应到 RGB 上，正好就是 Limited range 到 Full range 的映射。这样就不用改 OBS 的 Filter，也可以达到一样的效果。
上面这些逻辑，如果写到固件里，当然是最好的，但还得避免 UVC brightness 等设置把这些寄存器的值覆盖掉；不过固件毕竟不是源码，大范围的汇编改动还是比较危险。
最后的解决办法是，写了一个程序，通过 hidapi 去轮询 0x3c4a 寄存器，根据它是 Full range 还是 Limited range 来调整内部的寄存器，这样无论输入是哪种 range，都可以采集到正确的颜色了。此外，我还在 EDID 里把 YCbCr 都去掉了，只保留了 RGB 的支持，这样就只需要考虑一种转换。
这样，无论是 MateBookPro，还是跑了 Windows 的机器，都可以准确地采集了。当然，还有一个遗留问题，就是苹果电脑，它依然会出现偏色的问题，具体的原因还没能找到。
source
修复绿联 UG307-95348 HDMI 采集卡颜色问题（二）
背景
经过 上文 的一系列修复，绿联 95348 终于是可以正确地还原 MateBook Pro 输出的 RGB 色彩了。但是，换到另一台运行 Windows 的笔记本上时，又出现了新的颜色问题，这篇博客就来探讨一下怎么解决新的问题。
颜色问题
现象
用着之前打过 patch、关闭 luma processing 和 chroma processing 的固件，给一台 Windows 机器采集的时候，出现了新的问题，颜色出现了新的偏差：
● 0,0,0 -> 16,16,16
● 255,0,0 -> 237,14,15
● 0,255,0 -> 13,236,12
● 0,0,255 -> 15,15,238
● 255,255,255 -> 234,234,234
在显卡软件里，可以看到这组偏差对应的是 YCbCr，用的是 Limited range。经过验算，这就是把 Limited range 的 YCbCr 当 Full range 来解析，导致的问题。如果用显卡软件切换到 RGB 4:4:4 Limited range：
● 0,0,0 -> 16,16,16
● 255,0,0 -> 232,16,16
● 0,255,0 -> 15,234,13
● 0,0,255 -> 15,16,234
● 255,255,255 -> 233,233,233
也是类似的问题，只有把颜色切换到 RGB 4:4:4 Full range 才可以正确采集。
虽然可以通过手动指定 RGB 4:4:4 Full range 模式来解决颜色问题，但如果没有装对应的软件呢？又或者像鸿蒙和 macOS（macOS 其实有私有 API 可以用）那样没有类似的设置入口呢？
于是就要看，显卡驱动都是怎么判断要选择什么模式的。
EDID
答案就在 EDID 里面。按照 CEA-861 标准，显示器通过 EDID 告诉显卡，它支持哪些颜色模式，比如是否支持 YCbCr 4:4:4 等等，又具体支持哪些分辨率，哪些时序。
然后显卡驱动挑选一个时序，让显卡按照一定的波形来把显示输出通过 HDMI 发送给显示器。此时发送的内容，就有颜色（RGB/YCbCr）以及范围（Full/Limited）之分。那这是怎么决定的呢？
首先，CEA-861 标准规定了一个默认值：对于 CE Timing，默认是 Limited；对于 IT Timing，默认是 Full。什么是 CE Timing 呢？CEA-861 的定义是，出现在标准的 Table 1 表格里，且 VIC 大于 1 的时序，都是 CE Timing。这些 VIC 可以在 这里 找到。那非 CE 的 Timing，就是 IT。
所以当显卡驱动选择了一个时序以后，就根据它是 CE 还是 IT 来决定默认是 Limited 还是 Full。但同时，显卡软件也允许用户自己选择颜色 range。那显示器是怎么知道显卡发送的到底是 Full range 还是 Limited range 呢？
答案是，HDMI 里有传递元数据的 AVI InfoFrame。它里面可以指定，RGB 用的是 Full range 还是 Limited range；YCbCr 用的是 Full range 还是 Limited range。当显示器看到这个信息的时候，就知道不该用默认值去解析了。
但是，并不是所有显示器都支持这个。所以，它还得先在 EDID 里通过 VCDB 来声明，它的 RGB 或 YCbCr，是否允许通过 AVI InfoFrame 指定 range。
解决方法
根据这些信息，就能想到解决方法了：把固件里的 EDID 换掉，全用 IT timing（比如用 CVT-RB），这样默认就是 Full range 了。这样确实工作了。
但是，实践中，又遇到了新问题：我的使用场景里，采集卡和教室的投影仪通过一个 HDMI Splitter 连到电脑上，此时就得兼顾采集卡的情况，而采集卡用的是 CE Timing，比如 VIC 97。结果就是电脑通过 HDMI Splitter 这么一通接了以后，又回到 Limited range 了。
那怎么办呢？如果采集卡能自己识别输入是 Full range 还是 Limited range，然后进行相对应的处理就好了。
怎么识别呢？刚才提到，AVI InfoFrame 里会携带这个信息。所以就修改 EDID，在 VCDB 里设置 QS=1，这样 AVI InfoFrame 里就会出现指定 Full range 还是 Limited range 的信息。然后经过逆向，发现 MS2130S 会在寄存器 0x3c4a 里记录这个信息，这样就可以自动检测了。
怎么处理呢？之前，我的做法是在 OBS 里去 Apply LUT，实现 Limited range 到 Full 的反向映射。但是，如果从 Limited range 的输入切换到 Full range，就得调整 OBS，很麻烦。
于是我就想到，利用已有的 luma processing 和 chroma processing 的 pipeline。根据之前的分析，已知这两个 pipeline 做的事情是：
● luma processing：
clip(clip(Y + fc90) * fc91/128)● chroma processing：
clip(rotate(ΔR, ΔB) * fc92/128)如果想要实现 Limited range 到 Full range 的映射，也就是 16-235 线性映射到 0-255，只需要：
● 0xfc90 设为 0xf0，对应 -16
● 0xfc91 设为 0x95，对应 255/219
● 0xfc92 设为 0x95，同样对应 255/219
● 最后把 0xfc8f 和 0xfc8e 都设为 0x00，打开 processing pipeline
最终的结果是，在 YCbCr 上的变换，对应到 RGB 上，正好就是 Limited range 到 Full range 的映射。这样就不用改 OBS 的 Filter，也可以达到一样的效果。
上面这些逻辑，如果写到固件里，当然是最好的，但还得避免 UVC brightness 等设置把这些寄存器的值覆盖掉；不过固件毕竟不是源码，大范围的汇编改动还是比较危险。
最后的解决办法是，写了一个程序，通过 hidapi 去轮询 0x3c4a 寄存器，根据它是 Full range 还是 Limited range 来调整内部的寄存器，这样无论输入是哪种 range，都可以采集到正确的颜色了。此外，我还在 EDID 里把 YCbCr 都去掉了，只保留了 RGB 的支持，这样就只需要考虑一种转换。
这样，无论是 MateBookPro，还是跑了 Windows 的机器，都可以准确地采集了。当然，还有一个遗留问题，就是苹果电脑，它依然会出现偏色的问题，具体的原因还没能找到。
source
Chips and Cheese
Talking Zen 6 with Mike Clark at AMD In-Depth
#ChipAndCheese
Telegraph | source
(author: George Cozma)
Talking Zen 6 with Mike Clark at AMD In-Depth
#ChipAndCheese
Telegraph | source
(author: George Cozma)
原来Linux默认调度器已经换成EEVDF好几年了
钱为什么这么好骗？
$30M Raised to Redo the CPU https://tendrils.co/blog/2026-11-10/30m-raised
Chips and Cheese
AMD’s Zen 6 Family: Feeding the Beast
#ChipAndCheese
Telegraph | source
(author: George Cozma)
AMD’s Zen 6 Family: Feeding the Beast
#ChipAndCheese
Telegraph | source
(author: George Cozma)
Locating the source of a mysterious beep https://simonwillison.net/2026/Nov/9/mysterious-beeps/
突然在想，弄一车大肥鱼干进neocloud是不是一种和干进币安类似的效果
杰哥的{教学，运维，编程，调板子}小笔记
升级 Ceph 集群到 20 Tentacle 版本
背景
之前一直用 Cephadm 维护了一个 Ceph 集群，作为一个 K8s 集群的存储，通过 Rook External Ceph Cluster 来维护。Ceph 出了一个比较严重的 CVE-2025-30156，需要把已有的 key 都 rotate 一遍，这里把这个过程记录一下。
升级过程
最开始的时候，Ceph 版本是 19.2.3，Rook 版本是 1.18.11，此时这个 Ceph 版本是有安全问题的，需要升级，核心就是上面的那个 CVE：原来的认证用的是 aes 算法，无论是客户端还是 Ceph 自己的各服务。但是，这个算法的实现有安全问题，居然用固定的 IV，还是 AES-128-CBC，所以需要换到新的 aes256k 上，然后把原来的 key 都淘汰掉。Ceph 的各服务和 Rook 自己的客户端都好说，升级版本以后，就可以替换为新的 key，麻烦的是，很多 CephFS 是通过 Linux 内核挂载的，而 Linux 内核直到 7.0 才支持 aes256k。旧版本内核，如果指定 aes256k 的 secret，会说 secret length 错误，无法挂载。
所以第一步，就是给各虚拟机都升级到了 7.0 的内核：trixie 和 trixie-security 都不够新，所以就用了 trixie-backports 的 7.2 内核。
升级完 Linux 内核后，就可以开始动手升级 Ceph 了，首先用 cephadm 升级 Ceph 到 20.2.5：
经过一段时间的等待，Ceph 的各服务都升级到了 20.2.5，并且 Cephadm 自动把服务用到的各种 key 都替换成了 aes256k。但是，还是有一些 key 需要手动操作，比如 client.admin。参考 Upgrading and Rotating CephX Keys，把 client.admin 的 key 给 rotate 掉：
对于 Cephadm，修改一台机器上的
剩下的需要 Rotate 的 key，就都是 Rook 需要的了：
● client.csi-cephfs-node
● client.csi-cephfs-provisioner
● client.csi-rbd-node
● client.csi-rbd-provisioner
● client.healthchecker
这些 Key 都保存在 rook ceph 用于 external cluster 的 namespace 里的各 secret，根据名字很容易找到。我把 Rook 升级到 v1.21.2 后，直接在 Headlamp 里手动做的替换，虽然官方也给了脚本，但是脚本有一些依赖装起来比较麻烦，有 APT 的依赖问题。以 client.csi-cephfs-node 为例，其实就是：
然后把新的 key，替换掉 rook-csi-cephfs-node Secret 里面的 adminKey。其他几个也是类似的。
把所有的 key 都 rotate 成 aes256k 后（通过看 key 的长度能看出是 aes 还是 aes256k），禁用旧的 aes key 的使用：
最后，ceph health 没有任何关于 insecure key 的 warning，就算迁移完成。
参考文档
● Upgrading and Rotating CephX Keys
● CVE-2025-30156: AES-CBC misuse in CephX facilitating authentication bypass
● Ceph CVE notice and Rook advisory
source
升级 Ceph 集群到 20 Tentacle 版本
背景
之前一直用 Cephadm 维护了一个 Ceph 集群，作为一个 K8s 集群的存储，通过 Rook External Ceph Cluster 来维护。Ceph 出了一个比较严重的 CVE-2025-30156，需要把已有的 key 都 rotate 一遍，这里把这个过程记录一下。
升级过程
最开始的时候，Ceph 版本是 19.2.3，Rook 版本是 1.18.11，此时这个 Ceph 版本是有安全问题的，需要升级，核心就是上面的那个 CVE：原来的认证用的是 aes 算法，无论是客户端还是 Ceph 自己的各服务。但是，这个算法的实现有安全问题，居然用固定的 IV，还是 AES-128-CBC，所以需要换到新的 aes256k 上，然后把原来的 key 都淘汰掉。Ceph 的各服务和 Rook 自己的客户端都好说，升级版本以后，就可以替换为新的 key，麻烦的是，很多 CephFS 是通过 Linux 内核挂载的，而 Linux 内核直到 7.0 才支持 aes256k。旧版本内核，如果指定 aes256k 的 secret，会说 secret length 错误，无法挂载。
所以第一步，就是给各虚拟机都升级到了 7.0 的内核：trixie 和 trixie-security 都不够新，所以就用了 trixie-backports 的 7.2 内核。
升级完 Linux 内核后，就可以开始动手升级 Ceph 了，首先用 cephadm 升级 Ceph 到 20.2.5：
ceph orch upgrade start --image quay.io/ceph/ceph:v20.2.5
经过一段时间的等待，Ceph 的各服务都升级到了 20.2.5，并且 Cephadm 自动把服务用到的各种 key 都替换成了 aes256k。但是，还是有一些 key 需要手动操作，比如 client.admin。参考 Upgrading and Rotating CephX Keys，把 client.admin 的 key 给 rotate 掉：
ceph mon set auth_allowed_ciphers aes,aes256k
ceph mon set auth_preferred_cipher aes256k
ceph auth get-or-create client.admin-backup mon "allow *" | tee ./client.admin-backup.keyring
ceph -n client.admin-backup -k ./client.admin-backup.keyring auth ls
ceph auth rotate --key-type=aes256k client.admin | tee ./client.admin.keyring
对于 Cephadm，修改一台机器上的
/etc/ceph/ceph.client.admin.keyring，把里面的 admin key 换了，然后分发到其他机器上：ceph orch client-keyring set client.admin "label:_admin"
剩下的需要 Rotate 的 key，就都是 Rook 需要的了：
● client.csi-cephfs-node
● client.csi-cephfs-provisioner
● client.csi-rbd-node
● client.csi-rbd-provisioner
● client.healthchecker
这些 Key 都保存在 rook ceph 用于 external cluster 的 namespace 里的各 secret，根据名字很容易找到。我把 Rook 升级到 v1.21.2 后，直接在 Headlamp 里手动做的替换，虽然官方也给了脚本，但是脚本有一些依赖装起来比较麻烦，有 APT 的依赖问题。以 client.csi-cephfs-node 为例，其实就是：
ceph auth rotate --key-type=aes256k client.csi-cephfs-node
然后把新的 key，替换掉 rook-csi-cephfs-node Secret 里面的 adminKey。其他几个也是类似的。
把所有的 key 都 rotate 成 aes256k 后（通过看 key 的长度能看出是 aes 还是 aes256k），禁用旧的 aes key 的使用：
ceph config set mon 'mon auth allow insecure key' false
ceph mon set auth_service_cipher aes256k
ceph auth wipe-rotating-service-keys
ceph mon set auth_allowed_ciphers aes256k
最后，ceph health 没有任何关于 insecure key 的 warning，就算迁移完成。
参考文档
● Upgrading and Rotating CephX Keys
● CVE-2025-30156: AES-CBC misuse in CephX facilitating authentication bypass
● Ceph CVE notice and Rook advisory
source
Daniel Lemire's blog
A performance trap: when store forwarding fails
source
A performance trap: when store forwarding fails
source
Daniel Lemire's blog
A performance trap: when store forwarding fails
A store does not go straight into the cache. Waiting for that write would stall the processor. It sits in a store buffer, and a later load can take its bytes from that buffer. That is store forwarding. Forwarding works when the load is the same size as the…
政府网站也开始用AI重构了
https://sbj.cnipa.gov.cn/
https://sbj.cnipa.gov.cn/
杰哥的{教学，运维，编程，调板子}小笔记
用 XRDP + X11 转发实现带音频的图形界面转发
背景
最近遇到一个需求，在机器 A 上跑一个图形界面程序，但因为是远程访问，所以传统的办法就是开个 X11 Forwarding，或者跑个 VNC/RDP Server。但我有音频转发的需求，本地是 macOS，又不好在机器 A 上装 XRDP+桌面环境，于是在机器 B 上跑 XRDP Server，在机器 A 上通过 X11 Forwarding + Unix Socket Forwarding 实现图形界面和音频在机器 B 上的播放，再通过 RDP 客户端在 macOS 上实现带音频的图形界面浏览。
具体实现方法
具体实现方法不难，主要是在机器 B 上做一些配置：
1. 安装 XRDP，配置桌面环境，我用的是 Xfce4
2. 安装 pipewire-module-xrdp，关闭 pulseaudio 服务，改为 pipewire + pipewire-pulse + wireplumber
3. 带 X11 Forwarding 连接到机器 A，同时通过 Unix Socket 转发 pulseaudio 的 Unix Socket：
然后在 SSH Session 里跑带图形界面的程序即可，它就会通过 ssh 转发的 X11 在 XRDP 的 DISPLAY 上显示，再通过 pulse/native 的 Unix Socket 播放音频。
最后，通过 RDP Client（Windows App）连接到机器 B，就可以在看到图形界面的同时，也有正确的音频了。
source
用 XRDP + X11 转发实现带音频的图形界面转发
背景
最近遇到一个需求，在机器 A 上跑一个图形界面程序，但因为是远程访问，所以传统的办法就是开个 X11 Forwarding，或者跑个 VNC/RDP Server。但我有音频转发的需求，本地是 macOS，又不好在机器 A 上装 XRDP+桌面环境，于是在机器 B 上跑 XRDP Server，在机器 A 上通过 X11 Forwarding + Unix Socket Forwarding 实现图形界面和音频在机器 B 上的播放，再通过 RDP 客户端在 macOS 上实现带音频的图形界面浏览。
具体实现方法
具体实现方法不难，主要是在机器 B 上做一些配置：
1. 安装 XRDP，配置桌面环境，我用的是 Xfce4
2. 安装 pipewire-module-xrdp，关闭 pulseaudio 服务，改为 pipewire + pipewire-pulse + wireplumber
3. 带 X11 Forwarding 连接到机器 A，同时通过 Unix Socket 转发 pulseaudio 的 Unix Socket：
DISPLAY=XRDP_DESKTOP_HERE ssh -X -Y -R /run/user/UID_A_HERE/pulse/native:/run/user/UID_B_HERE/pulse/native host_a然后在 SSH Session 里跑带图形界面的程序即可，它就会通过 ssh 转发的 X11 在 XRDP 的 DISPLAY 上显示，再通过 pulse/native 的 Unix Socket 播放音频。
最后，通过 RDP Client（Windows App）连接到机器 B，就可以在看到图形界面的同时，也有正确的音频了。
source
Daniel Lemire's blog
In C++, = default and {} are not the same constructor
source
In C++, = default and {} are not the same constructor
source
Daniel Lemire's blog
In C++, = default and {} are not the same constructor
You can write an empty default constructor as span() = default or as span() {}. It can have remarkable effects on performance. struct span { const char *p; int len; const char *end; span() = default; // or span() {} span(const char *s, int n) : p(s), len(n)…
Daniel Lemire's blog
Beating the compiler at signed 32-bit division
source
Beating the compiler at signed 32-bit division
source
Daniel Lemire's blog
Beating the compiler at signed 32-bit division
Dividing integers is slow on our processors. A 32-bit division costs: processor latency throughput Emerald Rapids about 12 cycles one every 6 cycles Zen 4 9 to 12 cycles one every 6 cycles Zen 5 10 to 13 cycles one every 6 cycles Arrow Lake performance core…
2026年CoLT也是标配了
CoLT: Coalesced Large-Reach TLBs, MICRO 2012
CoLT: Coalesced Large-Reach TLBs, MICRO 2012
极客湾也是用上topdown了
