test(sandbox): 闭环脚本纳入整条输入链和 RMLVO

[Sunrisepeak]

compat.libinput 发布后补进依赖表(它把 compat.libudev + compat.mtdev 一起拉进来),运行期加两段:libinput 经 libudev 起 context 并枚举 seat,以及 RMLVO 按名字编译真布局(XKB_CONFIG_ROOT 未设时只报告 —— 没有数据集的机器不是这里任何东西的缺陷)。

断言拆成两种,因为两半根本不是同一个问题

	形态	判据	为什么
libudev	kind = "shared"	查来源	宿主有自己的 libudev.so.1,而 compat.libudev 故意用同一个 soname
libinput / libevdev / libmtdev / libxkbcommon / pixman	kind = "lib"	查缺席	对象并进消费者,正确构建下根本不该有 DT_NEEDED

把后者塞进原来那条「有没有解析到宿主」的 grep 是误导:它们永远匹配不到,而「没匹配到」会被读成「宿主没赢」,实际上是压根没东西可赢。

也没用 nm 查符号定义:strip 过的二进制没有 .symtab,会误报 FAIL;「没有共享库提供它」是同一主张的另一面,且不受 strip 影响。代码真在且能跑,由第 7 步证明。

实测

eco-2026-8-30-3,--sandbox --gpu,BRANCH=main:

===== 5. what the loader actually resolved =====
	libudev.so.1 => <project>/target/.../bin/libudev.so.1        ← 不是宿主那份
	libEGL.so.1 => <project>/target/.../bin/libEGL.so.1
	libGLESv2.so.2 => <project>/target/.../bin/libGLESv2.so.2
	...

===== 6. did anything come from the host? =====
  PASS: the host's copies were present and reachable, and none of them won

===== 6b. and the merged-in ones brought no shared library at all =====
  PASS: none of libinput/libevdev/libmtdev/libxkbcommon/pixman is a DT_NEEDED

===== 7. run it =====
  /dev/dri/renderD128   drm driver nvidia-drm    GL_VERSION OpenGL ES 3.2 Mesa 25.0.7
    glReadPixels         64 128 191 255 (wanted 64 128 191 255)
  /dev/dri/card0        drm driver simpledrm     gbm_bo_create 256x256 stride=1024
    glReadPixels         64 128 191 255 (wanted 64 128 191 255)
  reached EGL on a real device: yes
  drew and read the pixel back: yes

  -- input --
    libevdev  KEY_A -> KEY_A
    xkbcommon keycode 24 -> "q"
    libinput  assign_seat=0 fd=3 dispatch=0
    libinput came up on libudev: yes
    XKB_CONFIG_ROOT /home/speak/.xlings/subos/eco-2026-8-30-3/share/X11/xkb
    evdev/pc105/us  keycode 24 -> "q"
    the real us layout compiled: yes
  input chain answers: yes

===== RESULT =====
  PASS

libudev.so.1 那一行是这次新增里最有分量的:compat.libudev 故意用规范 soname,理由是 soname 复用能让源码构建与生态 payload 共存。这是那条判断第一次被放进「宿主有同名库、可达、就在 /usr/lib」的环境里正面检验 —— 而它赢了。

运行期那两条 libinput error: failed to find data files 是预期的(见 §10.9.2):quirks 数据集还没有提供方。枚举、事件、dispatch 全部正常,丢的是逐机型调校。

用法注释补了两条实测教训

1. 要装 xim:xkeyboard-config 才会真跑 RMLVO 那半,否则只报告。
2. 用 --add-xpkg 验过的包,跑这个脚本前必须清 store —— xlings 按 (name, version) 查找且忽略 namespace,残留的 local:foo@1.0 会让 xim:foo@1.0 的 install() 变成静默 no-op:payload 是空的,而 config() 照常跑并声明环境变量。在 xkeyboard-config 上撞过,看起来和「包坏了」一模一样。

文档

• §10.8.1 记录这次运行
• §10.10.1 记录 xim#733 那次回归:往 DISCOVERY 表加行同时是一次对现有提供方的改动 —— declare_subos_env 不传 only 就是「声明每一行」,所以 mesa 在表变长后开始声明它并不提供的键盘布局路径。检查清单因此是两项:新提供方要有两个调用,以及回头检查每个现有调用点传没传集合。