郑博文
|
2022bbcca0
|
feat(agent-core): InputInjector 新增 mouse_move_rel 默认实现与分发
默认实现不注入但打印日志（与 v3 的 text() 同一条纪律）：Linux/X11 后端本轮
未实现相对移动，用户用相对模式操作 Linux 被控端时「指针纹丝不动」不能是静默的。
相对事件不得被降级成绝对移动——单测显式断言默认实现不产生任何注入调用
（否则 Linux 端会把「相对增量」当成「绝对坐标」解释，指针乱跳）。
|
2026-10-31 17:35:02 +08:00 |
|
郑博文
|
8ffe19cd5f
|
test(agent-core): v3 分发路径单测——默认后端不 panic、截断契约、空输入
新功能必须带测试，agent-core 此前无测试模块，v3 新增的 text 默认实现与
截断分支正好落在盲区里：
- 后端不实现 text() 时（Linux/X11 的真实形态）必须被正常调用且不 panic；
- 超 MAX_TEXT_UNITS 必须以截断后的长度到注入侧，未超限原样；
- 空 Text 仍会下发到后端——被控端不假设对端守规矩，线格式输入按不可信处理。
|
2026-10-30 12:11:28 +08:00 |
|
郑博文
|
5075888861
|
feat(agent): v3 文本注入用 KEYEVENTF_UNICODE，一次批量提交成对代理项
Windows 侧按官方 KEYBDINPUT 语义实现：置 KEYEVENTF_UNICODE 时 wVk 必须为 0、
wScan 即要送出的字符，系统合成 VK_PACKET 经 TranslateMessage 产出 WM_CHAR。
down 批与 up 批分两次 SendInput，且让同一段文本的 code unit 在输入队列里相邻，
使代理对能被远端合成一个字符（最终由真机 emoji 验收定论）。
agent-core 的 InputInjector::text 用默认实现记日志而非静默忽略：Linux 后端
本轮不做文本注入（X11 需 keysym/XKB 映射，另立循环），但用户对着 Linux
被控端打字不能「什么都没发生还没痕迹」。Windows 端走自己的 handle()，
不经 agent-core，故超限截断日志在两侧同源补齐。
日志只打长度，不打用户输入内容。
|
2026-10-30 11:29:25 +08:00 |
|
郑博文
|
f119300a57
|
feat(agent): 串行多会话——会话结束不再退出进程
问题（阶段 2 的硬阻塞）
accept() 只接一次，会话结束进程退出。阶段 1 一次验收看不出来，
但阶段 2 要反复测试输入，每测一次都要手动重启被控端。
（即公共阻碍清单里的 P5，此前判断为「只影响调试效率」，
现在它阻塞迭代，提前做掉。）
改动
1. main：会话体抽成 serve_session()，外层 accept 循环。
会话失败（含认证失败）只记日志不退出进程。
明确不做并发多会话：DXGI Desktop Duplication 每个输出仅允许一个
活动实例，第二个 DuplicateOutput 会让第一个收到 ACCESS_LOST。
2. 认证失败路径补 conn.closed() 等待（agent-core 已有同款修复，
此处同源补齐 = 手册 §6.1 第 1 条）：否则客户端只看到 connection
lost 而不是 AuthFail。
3. capture 循环加 tx.receiver_count()==0 守卫。
只靠「send 失败退出」不够——桌面完全静止时那个分支根本不发送，
线程会永远持有 duplication，下一个会话的 DuplicateOutput 直接失败
（表现为新会话黑屏）。agent-core 同源修复。
4. 会话收尾：finish 流 + drop 接收端 + 等采集线程退出（2s 超时）后才
返回，调用方才 accept 下一个连接。
验证（连续两个会话，中间不重启 agent）
会话1：收到帧 40/40，结论 ✅
agent 存活：✅
会话2：收到帧 40/40，结论 ✅
日志：session closed -> waiting for next connection -> peer connected
-> auth ok；stderr 有 [capture] no receiver, stop 证明线程真退出
|
2026-10-30 09:31:44 +08:00 |
|
郑博文
|
6e83bda8b8
|
perf(agent): 关键帧周期从 4s/10s 统一到 1s，缩短丢帧后的兜底恢复窗口
背景
协议 v2 与 vendor nvenc 补丁之后，KeyFrameReq 已成为**真正生效**的恢复主路径
（此前 NVENC 缺 FORCEIDR 标志，请求被静默忽略）。因此周期 IDR 的角色变了：
从「唯一恢复手段」降级为「兜底手段」，只用于防「请求连续丢失」这种极端情况。
既然是兜底，就没必要配得那么长。
问题：三处周期不一致，且都过长
- agent/src/capture.rs NVENC：gop_len = 240 帧 @60fps = 4 秒
- agent/src/capture.rs 软编： intra_period = 300 帧 @60fps = 5 秒
- agent-core/src/lib.rs Linux： intra_period = 300 帧 @30fps = **10 秒**
同一产品在三种编码后端上的恢复等待时间差 2.5 倍，且 Linux 端最差。
改动
- 新增 agent/src/capture.rs::INTRA_PERIOD_FRAMES = 60（Windows 两个编码器共用）
- agent-core 的 EncoderSettings::default() 改为按 max_fps 推导（1 秒对应帧数），
避免以后调帧率时周期又漂移
代价
IDR 是整帧内编码，实测一次约 95-120KB，而 P 帧约 3-10KB。1 秒一次 IDR 约
增加 0.8Mbps 开销，在 5Mbps 码率下可接受。
验证（dump_stream 观察 150 帧）
[ 0] seq=0 IDR ← 首帧
[ 60] seq=60 IDR ← 间隔精确 60 帧
[120] seq=120 IDR
@60fps 即每 1 秒一个自动 IDR，与 gop_len=60 配置一致。
|
2026-10-28 16:35:44 +08:00 |
|
郑博文
|
9e50bc6237
|
feat(common): 协议 v2——版本号 + 帧头 seq/keyframe + 长度下界校验
为接入安卓主控做准备，先把三端共享契约改到能承载多客户端。改动集中在
common/src/lib.rs，三端适配在同一提交内完成以保证可编译。
协议版本（PROTO_VERSION=2）
- ControlMsg::Auth/AuthOk 增加 proto_version 字段；认证顺序改为「先版本后验证码」：
版本不一致时字段布局可能不同，验证码的解析结果不可信
- 任一端版本不符即 AuthFail 并明确报错，把「连上了但行为诡异」变成「连不上且提示升级」
视频帧头（VideoFrameHeader）
- 新增 seq: u64（每次实际发送递增，含静止桌面重发）与 keyframe: bool
- keyframe 由新增的 common::h264_contains_idr() 从实际 Annex-B 码流判定，
不依赖编码器 API 推断——NVENC 与 openh264 规则不同，实际输出才是唯一可信来源
- 该字段是 MediaCodec 判断解码器重置时机的必要条件，避免客户端自己写 NAL 扫描
不可信输入防护
- read_video_frame 补齐长度下界：total 必须 >= 4，hlen 必须落在 [1, total-4]
- 旧实现只校验上界，构造 total<4 的帧会让接收端在 buf[0..4] 处 panic（进程级DoS）
- 测试从 0 增至 11 个，覆盖序列化往返与 6 类越界/损坏输入
顺带修复（与上述契约直接相关）
- 新增 common::split_video_frame()：静止桌面重发时复用载荷但重建帧头，
否则 seq/ts_ms 会停在上次发送时刻，破坏 seq 单调递增契约
- agent-core 与 agent 两端的静止重发路径均改用该函数
验证：cargo test -p common → 20 passed（9 signaling + 11 新增）
|
2026-10-28 16:05:41 +08:00 |
|
yu
|
9c340813a8
|
feat(agent): 新增 agent-core 与 Linux 被控端（X11 + XTest，纯新增不动 agent/）
本期只在新增文件里做，**未改动 Windows agent/ 一个字节**（与 NVENC 线并行，避免争抢）。
- 新增 agent-core：平台无关会话层 —— QUIC/TLS 握手、传输调优（沿用 512KB 发送窗口
结论）、验证码认证、会话/select 循环、latest-wins 单槽、输入分发，以及软件编码
视频管线（openh264）。同步跟进协议新增的 Pong{lost,sent} 下行丢包统计字段
- 新增 linux-agent：X11 GetImage 采集 + 整帧变更检测；XTest 注入 + 扫描码→X11
keycode 映射（主键区 = scancode+8，E0 扩展键必须查表，含单元测试）
- 协议零改动：复用 Set-1 扫描码与虚拟桌面归一化坐标，viewer 无需任何修改
- 新增端到端冒烟测试 tests/smoke.rs 与 scripts/linux-smoke.sh（自建 Xvfb，无需
图形桌面）：采集→编码→QUIC 解帧、认证（含错误码拒绝）、Ping/Pong（含丢包字段）、
静止桌面关键帧恢复、输入注入实证（注入后从另一条 X11 连接读回指针真实坐标）
- 该关键帧用例做过变异测试：把修复退回会失败、恢复后通过，确认断言有效
- .gitattributes：shell 脚本强制 LF（Windows checkout 成 CRLF 会导致容器内无法执行）
- 手册：修正已失效的工具链路径；补充 cargo 镜像；新增第 8 节（Linux）与 6.1 节
（三条待修问题，含两条 Windows 侧仍存在的关键帧缺陷）
验证：
- Linux(容器, USTC 源 + Xvfb): cargo test -p linux-agent 通过，2 passed
- Windows: 本期未改 agent/，default-members 未变，`cargo build --release` 行为不变
|
2026-10-23 13:31:08 +08:00 |
|