欢迎加入开源鸿蒙PC社区：Harmony PC 开发者社区
欢迎在PC社区平台申请新建项目：OpenHarmony PC Developer - 开源代码托管,代码协作 - AtomGit
如有项目源码，可上传至 AtomGit 仓库，并在博文内附上仓库链接。

项目定位

Synergy Core 用于在多台电脑之间共享键盘和鼠标。它的上游工程默认带有 Qt 图形界面、X11 屏幕工厂、DBus 以及桌面系统集成；在 HarmonyOS PC 桌面端，直接打开 BUILD_GUI=OFF 并不能自动消除这些依赖，也不能提供输入能力。本文记录 1.20.4 的无 GUI 原生后端接线：命令行 server/client 具备在鸿蒙PC上启动的构建边界，输入、屏幕几何和剪贴板的目标实现分别对应 InputKit、原生多显示能力以及 Pasteboard/UDMF。完整注入和跨设备拓扑仍需授权后的独立真机验证，不能从构建结果推断已经完成。

适配配方、补丁和测试文件托管在 AtomGit 仓库 中，主源码使用 Synergy 官方 1.20.4 release，依赖 aws-lc/5.5.0 保持现有 OpenSSL API 和 TLS 行为。本文只把 AtomGit 作为代码托管品牌，不引用旧的代码托管入口；实际构建前仍应核对当前仓库提交、源码摘要和依赖的 Conan revision。

原生后端解决了什么

后端按能力拆分成键盘、鼠标、滚轮、快捷键、屏幕监视、拦截器和注入器。服务端捕获输入，客户端注入输入，两种角色的代码路径分别校验，不能因为一个授权请求成功就默认另一种角色也有权限。InputKit 的 actionTime 只作为事件时间，不被当成可信的注入来源；是否能在目标镜像获得相应授权，需要另外的设备记录。

多显示器部分需要维护每个显示的几何和指针位置；把宽坐标直接转换成较窄整数可能溢出，因此适配先做有限值和范围检查，再做宽整数相加和舍入。剪贴板交换使用 Pasteboard/UDMF，写入追踪、延迟热键清理和回调关闭都采用显式状态机，确保回调不会在后端资源释放后继续访问对象。服务端和客户端的任务栏/状态接收器也改为命令行可用的实现，且必须等日志系统初始化后再写日志。以上是实现和状态检查边界，不等同于当前设备已经开放全部输入、剪贴板和多显示能力。

构建时常用选项是 BUILD_GUI=OFF、BUILD_UNIFIED=ON、BUILD_TESTS=ON、SYSTEM_GTEST=OFF、CMAKE_SKIP_RPATH=ON，并关闭激活、版本在线检查、CLI11 和 TOML++ 等非必要组件。Qt、X11 屏幕源和其他非鸿蒙平台测试源只在目标平台能力不匹配时排除；上游测试没有被改成“无条件通过”。GoogleTest 只作为构建期测试源码，不导出到 Conan 包。

一个可直接运行的包消费者

先用版本和帮助输出验证安装后的命令行合同，再进入需要 InputKit 权限的 server/client 流程。下面的脚本与本版本 test_package/test.sh 使用同样的检查方式：

#!/bin/sh
set -eu

binary=${1:?synergy-core binary is required}
expected_version=${2:?expected version is required}

version_output="$("$binary" --version)"
case "$version_output" in
  *"synergy-core v$expected_version"*) ;;
  *) printf '%s\n' "unexpected version: $version_output" >&2; exit 1 ;;
esac

help_output="$("$binary" --help)"
case "$help_output" in
  *"Usage: synergy-core <server | client>"*) ;;
  *) printf '%s\n' "unexpected help output" >&2; exit 1 ;;
esac

printf 'synergy-core consumer checks passed\n'

在鸿蒙PC设备上运行时，binary 应指向包内签名后的 synergy-core，expected_version 传入 1.20.4。server/client 的完整输入注入还需要设备授权和两端网络拓扑，不能用 --help 通过就宣称键鼠共享已完成。配方用 shlex.join 形成安全参数；跨编译时 can_run=False 会把消费者标记为未执行并返回，返回值为 0 也不能当成目标执行证据。

验证结果的时间和身份

当前归档的 r96 目标事务记录为上游 174/174、原生状态检查 10/10、打包消费者 2/2，释放和 postrelease 均通过，任务进程清零。状态检查覆盖坐标范围、显示输出清理和平台后端脚本能力；2/2 消费者断言针对同一个已安装命令的版本和帮助输出，并没有分别启动 server 与 client。此前 r79 曾在授权后于 PROBE_BEFORE 因 monitor registration 失败而真实终止，旧失败不能被抹掉，也不能与 r96 的新输入拼接。

本地正式 finish、平台 AI Review、当前 HEAD CI 和提交仍是独立门禁。归档中还保留了“本地构建通过但 target execution 未运行”的阶段性记录；阅读报告时必须同时看 run_id、候选树、补丁数量和目标执行字段。一次成功的跨编译不能代替真实 InputKit、Pasteboard 或多显示器运行。

资源和安全边界

HarmonyOS PC 上的输入授权要 fail-closed：并发请求中任何一个回调状态异常，都应停止注入并清理本次申请。设备上的临时目录不能使用只读 /tmp，GoogleTest 流捕获应指向任务私有可写目录。安装后的 ELF 必须先签名再执行，构建树里的“测试通过”字符串不能替代包内二进制的实际运行。若要接入 GUI，应该另建 wxCore/ArkUI 窗口验证，不要把 BUILD_GUI=OFF 当作图形界面完成。

新手适配教程：环境、过程、结论与 FAQ

环境：高难点来自权限和角色，而不只是编译

构建机需要 Conan 2、CMake、Ninja、Python 和 HarmonyOS SDK，host profile 要固定为 OHOS/AArch64。Synergy 还依赖 aws-lc/5.5.0，并涉及 InputKit、Pasteboard/UDMF、多显示器几何和网络线程等平台能力。为了控制变量，本配方关闭 Qt 图形界面，先建立命令行 server/client 的最小闭包；这不等于 GUI 或跨设备输入已经可用。目标设备上的输入注入通常还受系统授权、进程角色和安全策略限制，因此必须把授权证据单独保存。

过程：先验证可启动，再验证能协同

1. 预检 aws-lc 等依赖和源码摘要，使用 OHOS profile 生成 CMake toolchain。
2. 编译无 GUI 的 synergy-core，对包内 ELF 签名后再复制到鸿蒙PC，不要直接执行未签名产物。
3. 运行消费者脚本，分别读取 --version 和 --help，确认版本为 1.20.4、帮助中包含 server/client 入口，并检查脚本最终的唯一 PASS 行。
4. 若要证明真实协同，必须另建授权后的 server/client 两端事务，验证键盘、鼠标、剪贴板和多显示器行为；其中任一角色未运行，都不能把 CLI 2/2 扩大解释。
5. 记录候选 HEAD、补丁、授权回调、角色、运行 ID 和清理结果，再采集完整鸿蒙PC桌面截图。

结论：诚实地表达“高难但未过度承诺”

当前 2/2 只证明同一个 CLI 的版本和帮助契约，synergy-core consumer checks passed 不等于 server/client 已完成输入注入。高难性体现在：同一源码要同时维护服务端和客户端角色，输入捕获与注入需要不同权限，剪贴板和显示几何还跨越多个系统子服务；任何一个授权或回调边界出错，都会让看似成功的构建失去实际意义。文章可以据此说明适配复杂度，但必须明确哪些能力已有证据，哪些等待新的设备事务。

FAQ

Q：为什么先关闭 GUI？ A：Qt、X11 和 DBus 会把桌面依赖带入构建，先固定无 GUI 核心能隔离输入后端问题。Q：2/2 是否代表 server 和 client 各通过一次？ A：不是，两个断言都来自同一 CLI 的 version/help 输出。Q：能否用本地 Linux Synergy 截图？ A：不能，目标是鸿蒙PC，截图必须包含目标桌面和对应版本终态。Q：授权失败应如何写？ A：保留失败阶段和原因，不要只保留编译成功日志，更不能把未执行的输入注入写成 PASS。

运行截图

以下图片来自同一台 HUAWEI MateBook Pro（HAD-W32）的 HarmonyOS 6.1.0.117 图形会话。版本入口首先确认真机执行的是 Synergy Core 1.20.4、协议 1.8，并回读返回码 0：

角色帮助入口进一步显示同一二进制如何分派 server 和 client。这能证明 CLI 角色路由存在，但还不能证明两台电脑已经完成输入注入：

第三张绑定设备上的已签名二进制大小与 SHA-256，并把仍需 InputKit 权限和双机拓扑的边界写在画面内：

结语

Synergy Core 1.20.4 的鸿蒙PC桌面端适配，关键不是删掉几个 find_package，而是把输入捕获、注入、显示几何和剪贴板都落到可验证的原生能力上。构建配置、状态测试、消费者测试和授权运行必须分层；失败事务保持不可变，成功事务绑定当前候选。这样后续接入真正的桌面窗口或多机协同功能时，才能清楚知道哪些能力已在 HarmonyOS PC 上成立，哪些仍需要新的设备证据。