写的很好啊，有很多点我也有类似的经历。

我补充一点关于定责和复盘这些非技术的事情。因为这些年我做过一线、负责人和老板，所以各个角度都有体验。定责复盘，实际上可以分为负责人（项目、组织经理）向老板汇报、向团队成员复盘两个部分，只是经常放在一起，而且以前者居多。

我的建议是负责人要勇于承担责任，团队成员的失误就是负责人的失误。即使承担责任压力很大，也切忌甩锅。（开发、测试和运维团队之间可以适当相互帮忙背锅，分担一下压力。）从老板的角度上说，损失已经发生了，也不会非要把直接责任人找出来开掉。老板也需要台阶下，不然后续还怎么继续展开工作。从权责对等的角度上讲，如果一个团队总是不粘锅，那它就不重要，所以是极有可能最先被优化掉的那个。

作为负责人，向团队成员做技术复盘的时候，更要注意对事不对人。本质上换个人并不能解决根本问题，能解决问题的只有排除人为失误的可能。那种出事临时工背锅的思路是不利于带团队的，人心散了。

tuned-adm 看一下，切换到 latency-performance 之类的配置试试。这个东西替代了之前 power profile 。

另外 fedora 默认 selinux 开启可能会有一点影响，这个我隐约有个印象测试能差 5%，记不清了。

@shalingye #21

考虑先实现出来吧，就用系统的 api 这样可以覆盖所有情况，延迟和性能的问题先不去处理。

粗略估计 4k 120hz 10bit 无压缩每帧数据量在 30MB 左右，单帧时间 8.3ms ，单从数据量上来说，如果是通过某种网络协议传输是没有带宽压力的，主要困难是延迟，发送接收涉及编解码。obs 有个 ndi 实现（现在叫 DistroAV ），就是在一台设备上采集，然后通过网络将数据传输到另一台设备上进行编码，可以参考一下它去掉网络开销的延迟水平。



共享内存的路线，Linux 的实现方式大概是这样的：

1. Linux 宿主机内核驱动 virtio 实现了 IVSHMEM

2. Linux 虚拟机或者 windows 虚拟机也通过 virtio 的驱动模块启用 IVSHMEM

3. 虚拟机和宿主机通过指定相同的物理地址实现内存共享（ IVSHMEM 本质是虚拟 PCI 设备）

4. 虚拟机内的特定应用（你要开发的）将 framebuffer 封装好后写入 IVSHMEM 的特定区域（手动管理）

5. （可选）宿主机应用通过 IVSHMEM 读取对应的 framebuffer 并做后续处理



这里可以看到 IVSHMEM 实际只是非常粗糙的共享内存机制，还需要在它的基础上实现用它完成 fb 数据交换。之前提到的 looking-glass 就是实现了一个叫 KVMFR 的模块，在 IVSHMEM 的基础上封装了一个用于 fb 数据交换的接口（硬件设备），同时实现了宿主与虚拟机之间的同步、锁，另外它用来做数据交换的格式是 dma-buf ，这样宿主机上的窗口合成器可以直接使用。之后，虚拟机的采集应用（ obs/ffmpeg/系统采集）直接将数据写入 KVMFR 。

如果你要在 windows 实现类似的功能，需要把 vmbus 当作 IVSHMEM ，然后在上面实现一个 windows 版本的 KVMFR 。



估计这样表述应该就清楚了，由于我对 windows 不是特别了解，所以上面的方案不一定正确。

@kuanat #19
@shalingye #16

中间发不出来的一段是关于如何获取 framebuffer 的。通过系统 api 会有二次复制的延迟，通过显卡特定 api 更合适。

@kuanat #18
@shalingye #16


最后再回到之前说的共享内存方案。实际上 framebuffer 的数据结构某种程度上说是硬件相关的。也就是说，即便在虚拟机和宿主机之间通过虚拟设备共享了内存，一方面要对接这个虚拟内存的读写接口，另一方面需要将 framebuffer 封装成一种统一的格式。这样在宿主机上，用于显示虚拟机内容的窗口可以直接将 framebuffer 提交给窗口管理器进行合成，即再次 DMA 到显卡。

如果我说得不是很清楚的话，可以参考 https://looking-glass.io/ 这个项目，它的核心实现是 KVMFR https://github.com/gnif/LookingGlass/blob/master/module/kvmfr.c 这个模块，基于 IVSHMEM 完成我之前说的流程。理论上 windows 上实现相同效果的原理是一样的。

@kuanat #17
@shalingye #16

我之前回复的是满足第二个要求的方法。先不考虑虚拟机里的视频信号从哪里来的，假设你已经获得了实时 framebuffer 流，可以走网络协议，同时由于宿主机和虚拟机在一起，也可以走共享内存。技术上说，所有走网络协议的方案因为存在编解码、封装，都不可能比直接内存共享延迟更低。就拿 kvm 常见的虚拟化方案来说，SPICE 是个网络协议，但与 qxl 搭配的时候，使用的是共享内存。

从原理上说，kvm 这边直接用 SPICE 就可以了。我搜了一下 vmbus 的文档，虽然提到了共享内存，但我感觉用它来共享 framebuffer 需要做的工作还很多。

@shalingye #16

如果我没理解错的话，你的需求是这样的：宿主机上运行的虚拟机，然后宿主机的某个客户端窗口，显示虚拟机的视频输出内容。

为了达到目标性能要求，一方面需要虚拟机本身能够实现高分辨率高刷新率，另一方面这个达标的显示输出能够在宿主机上正确还原，中间的通信延迟要足够低（输入设备还在宿主机上并没有直通到虚拟机）。



为了达到第一个要求，一般有两个方案：

1. 使用半虚拟化驱动设备，比如 qxl ，virgl 还有一些都属于这种，在虚拟机里面使用虚拟的显卡设备，这个设备会将渲染指令传递给宿主机，通过宿主机执行后再将结果传回虚拟机

2. 直通物理显卡或者利用 sriov 直通物理显卡虚拟出来的显卡

我对 windows 不熟悉，猜测 windows 的几个实现原理上应该都是上面两个思路。



不知道触发了什么关键词，我二分一下拆开回复。

@kuanat #68

vscode 不行哈哈，原因就是 #73 说的。

Linux 这边 virtio 也有类似的需求和实现方案。

我个人的理解是：

- 如果虚拟机内部是虚拟的 gpu ，那么就可以直接共享内存，宿主机直接访问虚拟机内虚拟 gpu 的 framebuffer

- 如果虚拟机内部有直通的 gpu ，那就只能从 framebuffer 入手抓取视频源（比如 nvfbc ），然后再共享给宿主机

应该不存在比直接内存映射更高效的 IPC 方式了。

我认为是 vscode 的锅，因为我的印象里这个功能 gopls 很早就有了，不过我现在主力是 neovim ，待我验证一下。

这是个业务或者说工程问题，不全是技术问题。因为不像 Java 用 BigDecimal 比较多，Go 这边没有习惯性做法，所以主要靠约定，剩下的是如何执行。无论哪种语言，计算这类纯技术问题都是小事，与业务结合的部分才是大事。

我这里说几个技术人员可能不太熟悉的业务需求或者是需要注意的点：

- 最理想的是用 Go 自定义数据结构，在数据结构上实现相应的运算方法。这样可以避免代码上的出错。这里比较关键的点是，计算过程肯定是高精度/整型（对应 BigDecimal ），同时一定要支持 split 操作，主要是处理类似 1 拆成 0.33+0.33+0.34 的业务需求，这种在会计、税务场景很常见。

- 根据全流程数据交换的环节来定义精度和数据格式。一般推荐的是比常见货币最小单位更精确一点，或者支持自定义。传递过程中使用字符串，做好格式转换。说到底还是靠约定，为了方便执行可以独立成库强制所有上下游都使用特定实现。

- 有需要的话提前考虑多币种支持，比如订单系统如果可以支持多币种，数据库和业务逻辑都要做 schema 调整。通常的业务需求来说，多币种就是多账本，如果最初设计成单账本后期修改会很痛苦。

- 推荐使用 event driven 架构来做 cqrs ，即用事务的方式持久化变动，实时状态由历史计算推导得出。类似银行卡只记录进出，余额是算出来的。好处一方面能和通常的消息队列架构方便对接，另一方面整个业务的可靠性、灾难恢复都好做。有 olap 需求也容易改造。

我在过去几年的代码库里检索了一下，只找到了一种涉及到 defer 里面修改返回值操作的反例。严格来说，这个代码编写方式是 named return 的问题，而不是 defer 的问题。

前面提到的 defer 里修改返回值的情况是：

// fn 函数签名 fn() (err error)

defer func() {
err = writer.Close()
}()

这样就会覆盖掉原本 err ，所以还要新增变量特殊处理一下。

defer func() {
closeErr := writer.Close()
if closeErr != nil {
// 特殊处理
}
}()

这样看起来就很蠢对吧，所以代码规范里就直接禁止了在 defer 里写逻辑。我确实想象不出来正常的业务代码里有什么一定非要在 defer 里处理的逻辑不可。个人的观点是，这个和三元逻辑操作符差不多，都是不适合工程上团队协作使用的。



当然我这里的规范还有一条，interface 写 named return ，这样注释可以对应到参数名。

我印象有个说法是 go 早期是手搓编译器，named return 能方便代码生成。其实我觉得这个特性除了支持 naked return 之外没什么意义，属于某种设计失误，但也有可能是我没理解到位。

作为多年 Linux 用户，我支持 Firefox 的主要原因就是不想让 Chrome 一家独大，至少 uBlock Origin 在 Firefox 是全功能的。

性能方面 Firefox 确实离 Chrome 有点差距，不止体现在 benchmark 里面，体感就够了。比较明显的就是 bili 播放弹幕比较多的视频，都是硬件加速的情况下，Chrome 对 gpu 的利用要好很多。（准确说是 chromium ，官方 chrome 是不支持硬件加速的）

使用方面 Firefox debug 可比 Chrome 舒服太多了。

@yadam #6

关于 2 中你的处理原则是合理的，ctrl down 一定要在用户按下的时候就响应，而不是等到再按下其他键的时候才发送按下事件。这里主要的问题是，很多软件会希望获得 modifier 的状态，或者 modifier key 的按下释放事件。比较常见的除了 alt 触发菜单，还有把 ctrl 或者空格当作 push-to-talk ，把 ctrl+alt 作为虚拟机的跳出按键，你在设计的时候可以思考一下，因为历史遗留原因和软件开发的多样性，软件到底是检测 modifier 状态，还是检测按键事件，或者是检测 keysym 可能需要不同的处理方式。

我在 AHK 那边看到过一个处理逻辑，就是交叉释放，比如你在 alt+h 这个场景，正常逻辑是先发送 alt down ，再拦截 h ，发送 alt up ，发送 left 这样，在发送 alt up 之前插入 ctrl down ，然后 alt up ，ctrl up 这样，就不会被认为是按下了 alt 键又松开。可能目前只有这样的 hack 方式才能解决。



配置文件方面，我更倾向于把改键应用分为两类，当前语境下的映射类建议用静态配置文件，自动化意义上的 AHK 建议用 DSL 自定义语法。后者的话工作量比较大，因为有 quickjs 的存在，我觉得反倒很适合直接拿来用。如果主程序是 c 的话，lua 是个不错的选项。

映射类的配置文件，我个人比较喜欢 keyd 的 ini 方式。重点不在格式上，而是 keyd 对于 layer 功能实际上是有默认的，就是配置里没有写的，直接 fallback 到原始按键上。本质上这些配置还是存在的，只是不需要使用者去写了。你看 #5 那个写法，符合直觉而且好写好懂。如果你要设计的话，可以提前想象一下，类似长短按，按下生效一次，按下自动重复，按下切换 layer 需要什么样的语法。我之前尝试过，无一例外都把自己绕晕了……



另外有些功能在 de/wm 阶段处理 keysym 可能更容易，gnome 的话有 keyboard shortcuts 可以自定义，只是可以绑定的功能比较有限。如果你用过类似 sway 这样的纯窗口管理器，会发现 keysym 触发特定功能能满足大部分 AHK 的常见需求。

dmesg 里面找 checksum error ，大概是这么个字符串，因为我这好久没出过错记得不是很清楚了。

我大致看了一下你的实现，讲道理你是个狠人啊……你不仅给 libevdev 做了 binding ，还内嵌了 quickjs 用来做配置自定义。因为我经常给自己的设备做固件写驱动，所以改键这部分还算比较熟悉，随便说一点想法。

1.
通过 uinput 虚拟输入设备，拦截物理设备事件（独占），映射完成后通过虚拟设备输出事件，这是唯一正确的做法。另一个我认为哲学上不那么正确的做法是，原物理设备不管，只重新映射事件。更准确的说法是这是处理两种不同需求的做法，前者的重点在于映射，后者的应用场景是脚本化、自动化，比如 AHK 这种，两者有重合的地方，但实际上是两种不同的设计方向。

2.
在这个“正确”的设计下，需要处理很多 corner cases ，我随便举一个类似方案很容易踩的坑：很多 gui 应用响应 alt 呼出菜单，假如有个改键逻辑是 alt+h 映射为 left ，当用户按下 alt 的时候，需要原样输出 alt 按下，同时设置 modifier ，之后按下 h ，此时以完全拦截，然后重新映射的视角来看，应该先释放 alt ，然后插入 left 。这时就会触发 alt 按下又释放的事件，就会被 gui 应用响应到。同时用户也没有办法再输入 alt+j 这个组合，这就给如何设计配置文件语法带来了挑战。

3.
配置文件用 js 这样的动态语言是一个可选的方向，但我不确定是不是个好的做法，比较直观的缺陷就是可读性和 debug 。以我对现有的各个实现的观察来看，应用提供 sane defaults 是非常重要，它可以极大简化配置文件的编写。特别是当你想实现类似 qmk layer 之类的功能的时候，全拦截重映射实际上要求每个按键都是重映射过的，配置文件如果要把所有逻辑都写一遍体验会不太好。

4.
获得当前活动窗口的名字是个看起来简单实际上复杂的事情，首先底层是 xorg 还是 wayland 要区分一次，xorg 稍微好解决一点，wayland 要做全兼容，大概主流的 mutter/kwin/wlroots 都要兼顾。各个实现对于 foreign-toplevel-manager 这个协议的态度差别很大。要么对 gnome 用 dbus ，对 kde 用 script api 一个一个适配，要么等各家支持相关协议。

5.
ctrl+c/v/x 映射到 ctrl+insert/shift+insert/shift+delete 是一个思路，但不是唯一的思路，比如你可以直接 super+c/v/x 映射到 XF86 的 copy/paste/cut ，更接近 mac 的逻辑。这方面 sway 这样的 wm 比起 gnome 这样的 de 要容易。另外 linux 的 clipboard 目前也是 wayland 协议的一部分，除此之外还有 primary selection 能用，可以发挥想象力。

6.
在这种系统调用层面上，go/rust 或者其他语言都差不多，只有不是 c 都会有 ffi 的问题。我只是单纯觉得，binding 都写了，不如直接写 c 了。另外不用 c 的话 IPC 带来的延迟会比较明显。




PS

下面写给对改键这个事情感兴趣的人看的。

首先明确几个概念 scancode/keycode/keysym ，scancode 是设备产生的硬件信号，经过内核 udev/evdev 之后转化为 keycode ，keycode 由内核空间传递到用户空间后，由桌面/窗口管理根据键盘 layout 转换为 keysym ，也就是应用程序获得的输入。

现在能够接触到的键盘类设备，只要不想专门做驱动，都会按照 linux headers 头文件（ input-event-codes.h ）定义的 keycode 去做，不然就是给自己找麻烦。当然像笔记本、游戏设备就需要自定义使用头文件里没有的 scancode/keycode 映射了。

以当前的 linux 生态来说，整个按键输入流程是这样的，硬件产生 scancode ，在内核空间经过 udev/evdev 处理映射为 keycode ，通过 /dev/input/eventX 暴露给用户空间。用户空间有 xorg/wayland 两个大的框架，对应的实现分别是 xorg-input-evdev 和 libinput ，注意前者虽然名字有 evdev 但实际上是用户空间的，意思是它利用 evdev 机制，此二者都是操作内核暴露的 /dev/input/eventX 接口，然后根据环境 locale/layout ，将 keycode 转换为 keysym 。由于目前 xorg 的实现也都过渡到 xf86-input-libinput 上面了，所以可以认为，用户空间就是 libinput 。此阶段之后，上层的桌面/窗口管理器可以获得特定的 keysym ，进一步传递给活动窗口应用。



综合上面的背景信息，可以说理论上有三个，但实践中只有两个可以做改键的位置。第一个是在内核空间通过 udev 规则改写 scancode 和 keycode 的映射，说它没有实践意义是因为这是设备厂家要做的事情。剩下两个有实践意义的，一个是 keycode 转 keysym 的阶段，另一个是 keysym 传递给应用窗口的阶段。

如果继续观察市面上已有的各种改键工具，会发现在 keycode 转 keysym 的阶段完成映射的方式，传统基于 xorg-input-evdev 的实现都只能支持 xorg ，而基于 libinput 的可以同时支持 xorg/wayland 。

至于为什么 keysym 传递给应用窗口这个实现也会存在，原因很简单，用户有针对特定应用改键的需求，而这个需求是前一种方式不能独立完成的。

所以现在改键就剩一种方式了，就是虚拟 uinput ，然后拦截物理设备事件做映射。区别就是要不要识别当前应用，以及如何识别。至于在 keysym 传递过程做映射，只有纯 wm 能实现，一般 de 是不开放这个自定义的。

部署和配置更新可以考虑 ansible ，中心式管理没有更简单的了，有 ssh 就行，没有性能需求。

ip 变动的话一般要靠设备主动汇报，一般负责心跳的模块顺便就做了。我这里之前用的方案是 ansible inventory 是通过外部接口调取的。

再补充一点，bios 里的选项位置是固定的，所以并不需要 OCR 之类的手段。多数时间只需要判断对应位置的选项是不是有高亮或者反色即可，即只需要判断当前光标是否选中了目标。