​编辑欢迎加入开源鸿蒙PC社区Harmony PC 开发者社区欢迎在PC社区平台申请新建项目OpenHarmony PC Developer - 开源代码托管,代码协作 - AtomGit如有项目源码可上传至 AtomGit 仓库并在博文内附上仓库链接。项目定位Synergy Core 用于在多台电脑之间共享键盘和鼠标。它的上游工程默认带有 Qt 图形界面、X11 屏幕工厂、DBus 以及桌面系统集成在 HarmonyOS PC 桌面端直接打开BUILD_GUIOFF并不能自动消除这些依赖也不能提供输入能力。本文记录 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_GUIOFF、BUILD_UNIFIEDON、BUILD_TESTSON、SYSTEM_GTESTOFF、CMAKE_SKIP_RPATHON并关闭激活、版本在线检查、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-coreexpected_version传入1.20.4。server/client 的完整输入注入还需要设备授权和两端网络拓扑不能用--help通过就宣称键鼠共享已完成。配方用shlex.join形成安全参数跨编译时can_runFalse会把消费者标记为未执行并返回返回值为 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并发请求中任何一个回调状态异常都应停止注入并清理本次申请。设备上的临时目录不能使用只读/tmpGoogleTest 流捕获应指向任务私有可写目录。安装后的 ELF 必须先签名再执行构建树里的“测试通过”字符串不能替代包内二进制的实际运行。若要接入 GUI应该另建 wxCore/ArkUI 窗口验证不要把BUILD_GUIOFF当作图形界面完成。新手适配教程环境、过程、结论与 FAQ环境高难点来自权限和角色而不只是编译构建机需要 Conan 2、CMake、Ninja、Python 和 HarmonyOS SDKhost profile 要固定为 OHOS/AArch64。Synergy 还依赖aws-lc/5.5.0并涉及 InputKit、Pasteboard/UDMF、多显示器几何和网络线程等平台能力。为了控制变量本配方关闭 Qt 图形界面先建立命令行 server/client 的最小闭包这不等于 GUI 或跨设备输入已经可用。目标设备上的输入注入通常还受系统授权、进程角色和安全策略限制因此必须把授权证据单独保存。过程先验证可启动再验证能协同预检aws-lc等依赖和源码摘要使用 OHOS profile 生成 CMake toolchain。编译无 GUI 的synergy-core对包内 ELF 签名后再复制到鸿蒙PC不要直接执行未签名产物。运行消费者脚本分别读取--version和--help确认版本为 1.20.4、帮助中包含 server/client 入口并检查脚本最终的唯一 PASS 行。若要证明真实协同必须另建授权后的 server/client 两端事务验证键盘、鼠标、剪贴板和多显示器行为其中任一角色未运行都不能把 CLI 2/2 扩大解释。记录候选 HEAD、补丁、授权回调、角色、运行 ID 和清理结果再采集完整鸿蒙PC桌面截图。结论诚实地表达“高难但未过度承诺”当前 2/2 只证明同一个 CLI 的版本和帮助契约synergy-core consumer checks passed不等于 server/client 已完成输入注入。高难性体现在同一源码要同时维护服务端和客户端角色输入捕获与注入需要不同权限剪贴板和显示几何还跨越多个系统子服务任何一个授权或回调边界出错都会让看似成功的构建失去实际意义。文章可以据此说明适配复杂度但必须明确哪些能力已有证据哪些等待新的设备事务。FAQQ为什么先关闭 GUIAQt、X11 和 DBus 会把桌面依赖带入构建先固定无 GUI 核心能隔离输入后端问题。Q2/2 是否代表 server 和 client 各通过一次A不是两个断言都来自同一 CLI 的 version/help 输出。Q能否用本地 Linux Synergy 截图A不能目标是鸿蒙PC截图必须包含目标桌面和对应版本终态。Q授权失败应如何写A保留失败阶段和原因不要只保留编译成功日志更不能把未执行的输入注入写成 PASS。运行截图以下图片来自同一台 HUAWEI MateBook ProHAD-W32的 HarmonyOS 6.1.0.117 图形会话。版本入口首先确认真机执行的是 Synergy Core 1.20.4、协议 1.8并回读返回码 0角色帮助入口进一步显示同一二进制如何分派server和client。这能证明 CLI 角色路由存在但还不能证明两台电脑已经完成输入注入第三张绑定设备上的已签名二进制大小与 SHA-256并把仍需 InputKit 权限和双机拓扑的边界写在画面内最后一张汇总--version与--help两项检查保留设置页、HiShell 和鸿蒙PC任务栏。结语Synergy Core 1.20.4 的鸿蒙PC桌面端适配关键不是删掉几个find_package而是把输入捕获、注入、显示几何和剪贴板都落到可验证的原生能力上。构建配置、状态测试、消费者测试和授权运行必须分层失败事务保持不可变成功事务绑定当前候选。这样后续接入真正的桌面窗口或多机协同功能时才能清楚知道哪些能力已在 HarmonyOS PC 上成立哪些仍需要新的设备证据。