omarchy 远程桌面方案解读：把 Sunshine/Moonlight 从游戏串流补完为真正的远程桌面
omarchy 远程桌面方案解读把 Sunshine/Moonlight 从游戏串流补完为真正的远程桌面【免费下载链接】omarchyBeautiful, Modern Opinionated Linux项目地址: https://gitcode.com/GitHub_Trending/om/omarchy本文基于 omarchy 仓库中的 plans/remote.mdPlan: Remote — finish Sunshine/Moonlight into a real remote desktopRevision 1展开并结合仓库内已有的安装/卸载脚本、Hyprland 窗口规则、菜单配置与手册文档进行佐证。omarchy 是一个以 Hyprland 为核心、Beautiful, Modern Opinionated 的 Linux 发行整合项目。本文讲解该项目如何把当前仅用于游戏串流的 Sunshine/Moonlight 组合端到端补完成支持虚拟显示器、终端配对、独立音频与安全卸载的远程桌面方案读者可从中掌握其架构决策、命令设计、虚拟显示器与音频管理机制以及分阶段落地与测试策略。一、现状这是一个游戏串流引导程序还不是远程桌面在进入新设计之前先看 omarchy 当前已经在仓库里沉淀了什么。这些是 plans/remote.md 判断只差最后一步的事实基础。1. Moonlight 客户端已预装且有专属窗口规则moonlight-qt随发行预装并且 Hyprland 为它配了一条窗口规则default/hypr/apps/moonlight.luao.window(com.moonlight_stream.Moonlight, { fullscreen true, idle_inhibit fullscreen })这条规则让 Moonlight 窗口一出现即全屏并抑制空闲熄屏——这是当串流会话进行时桌面不要睡过去的基础保证。2. 主机安装脚本已存在bin/omarchy-install-service-sunshine安装脚本会做四件事安装包并启用用户态 systemd 单元、打开防火墙端口、安装 Sunshine Admin Web 应用、向 Hyprland autostart 追加启动行。关键常量如下bin/omarchy-install-service-sunshineTCP_PORTS(47984 47989 48010) UDP_PORTS(5353 47998 47999 48000 48002 48010) PRIVATE_CIDRS(10.0.0.0/8 172.16.0.0/12 192.168.0.0/16) UFW_COMMENTomarchy-sunshine SUNSHINE_ADMIN_URLhttps://localhost:47990防火墙只对 RFC1918 私有网段10/8、172.16/12、192.168/16和tailscale0接口放行 TCP 47984/47989/48010 与 UDP 5353/47998–48010并且 ufw 规则统一带omarchy-sunshine注释以便按注释精确拆除。安装结尾执行omarchy-pkg-add sunshine systemctl --user enable --now sunshine3. 手册已对外宣传manual/26-gaming.md26 号手册既讲了用预装的 Moonlight 客户端串流 Windows 上的 Sunshine 主机也写了一句用omarchy install service sunshine把 omarchy 机器变成主机——注意这里的主机语义是游戏串流主机。4. 卸载脚本是半对称的bin/omarchy-remove-service-sunshine卸载脚本会 disable 单元、卸载包、移除 Web 应用、删除 autostart 行sed清理、按注释关闭 ufw 端口。由此 plans/remote.md 给出了核心判断仓库里已经存在的是一套游戏串流引导程序而不是远程桌面。差别集中在一个词上——虚拟显示器。二、七道差距用户在端到端流程中逐个撞上的坑计划按用户实际遇到的顺序梳理出七个问题点一个守护进程两条启动路径。安装脚本既执行systemctl --user enable --now sunshine又把o.launch_on_start(sunshine)追加进~/.config/hypr/autostart.lua。每次登录systemd 用户管理器按上游单元WantedBygraphical-session.target、Restarton-failure启动一份Hyprland autostart 又通过uwsm-app启动第二份——抢端口失败的一方反复崩溃、刷满 journal。autostart 行本是为防止单元缺少WAYLAND_DISPLAY买的保险但 omarchy 并不需要uwsm 会在到达graphical-session.target之前把会话环境导入用户管理器default/systemd/user/ 下所有会话单元都依赖这一点。配对是整条链路最弱的环节。首次连接需要在浏览器里指向https://localhost:47990并带着--ignore-certificate-errors点过自签名证书警告再发明一组用户名/密码最后把 Moonlight 上的 PIN 抄进网页表单——三次 UI 跳转外加一次证书警告而协议层面这只是一次带认证的 POST。串流劫持物理屏幕。Sunshine 捕获的是真实显示器。所谓远程桌面变成看你办公椅上那块屏幕而在无显示器连接的机器上则什么都看不到。没有虚拟显示器游戏串流与远程桌面的分水岭就不存在。音频全有或全无。Sunshine 捕获默认声卡的 monitor 源于是串流里能听到桌面音箱正在播放的声音桌面也能听到远程会话的一切声音两路互相串扰。菜单里没有入口。尽管手册在宣传default/omarchy/omarchy-menu.jsonc 中没有任何 Sunshine 条目——Install Service 下没有Remove 下也没有。功能对用户不可见除非他已经知道那条命令。与 Tailscale 存在安装顺序耦合。tailscale0的 ufw 规则只在安装那一刻接口存在时才会添加omarchy-install-service-tailscale对 Sunshine 的端口一无所知。先装 Sunshine、后装 Tailscaletailnet远程访问的全部意义所在就被静默关闭了。卸载只有一半对称。omarchy-remove-service-sunshine关端口、删 Web 应用和 autostart 行但留下~/.config/sunshine/配对状态、凭据、apps并且对本计划将新增的虚拟显示器与音频管线一无所知。三、方案总貌与边界一条被祝福的路径计划的整体形态非常收敛一条被祝福的路径——Sunshine 做宿主、Moonlight 做客户端——端到端走完。端到端意味着从菜单里选中 Sunshine在终端里用 PIN 完成配对从 LAN 或 tailnet 上的任意 Moonlight 客户端连入落在按客户端分辨率定制的专属远程工作区或刻意镜像物理屏听到会话的音频但不会在桌面外放断开连接不遗留任何孤儿窗口卸载后不留任何痕迹。所有这一切都保持在安装器早已定对的姿态之内——端口只向私有网络与 tailnet 开放永不面向公网。改动范围是重构两个现有脚本、新增一个小的sunshine命令组先例是tailscale组、托管 Sunshine 配置的一小片、菜单条目、为存量安装准备的迁移、测试和手册章节。不引入新的守护进程也不引入仓库现有包之外的任何新软件包。被否决的路线以及为什么计划明确否决了五类替代方案理由对理解技术选型很重要wayvnc 或 xrdp/VNC-RDP 链wayvnc 确实能通过 wlr-screencopy 捕获 Hyprland但 VNC 默认不加密、纯软件编码、指针延迟高再叠 xrdp 等于加一层协议翻译Hyprland 的 wlroots 分支一旦漂移就会崩。没有硬件编码在延迟、续航、保真度上全面输给 Sunshine而且配对、虚拟显示器、音频仍然要自己解决。RustDesk虽然已打包且内置中继很诱人但它在 Hyprland 主机上实际不可用——它依赖org.freedesktop.portal.RemoteDesktop门户而xdg-desktop-portal-hyprland并没有实现它上游 issue 长期未关闭。为一个在自己的合成器上无法承载主机的方案背书不能作为 v1。等待 RemoteDesktop portal同理。Sunshine 完全绕开门户——捕获走 wlr-screencopy、输入走 uinput包自带 udev 规则——这正是它今天能在 Hyprland 上工作的唯一原因。waypipe只转发单个 Wayland 应用不是桌面属于不同产品。从零自研 Fluid 等价物定制串流栈是协议、编解码、客户端矩阵的多年工程omarchy 的杠杆是集成品味而不是重新发明 NVENC 协商。无登录的远程登录模式gnome-remote-desktop 那条路Sunshine 挂在运行中的会话上而 Hyprland 没有可供挂载的系统守护模式好在 omarchy 的 SDDM 自动登录意味着机器开机即有会话真正的约束只剩全盘加密的密码提示计划把它列入开放问题而非掩盖。四、设计一单一守护进程、单一启动路径systemd 用户单元胜出。它具备Restarton-failure重启、journal 日志、可供守卫与状态命令查询的干净is-active答案并且由于 uwsm 会把WAYLAND_DISPLAY等导入用户管理器当graphical-session.target拉入该单元时图形环境已经完备。因此安装器保留systemctl --user enable --now sunshine不再触碰autostart.lua同时新增一个按 epoch 命名的迁移放在 migrations/删除既有用户~/.config/hypr/autostart.lua中的o.launch_on_start(sunshine)行让双启动问题不仅在新装机上消失也在存量机器上消失。移除脚本在接下来一个版本周期内保留其sed清理作为双保险之后也可以一并删除。五、设计二捕获后端——显式声明 wlr-screencopyomarchy 会在其托管的~/.config/sunshine/sunshine.conf区块写入capture wlr而不是让 Sunshine 自己去探测。两条结构性理由KMS 捕获读取真实 DRM CRTC需要二进制具备CAP_SYS_ADMIN而且从根本上无法看到虚拟输出——无头的 Hyprland 输出没有 CRTC。Sunshine 曾直接在有头连接器上崩溃修复后也只是跳过而跳过等于不可捕获。既然虚拟显示器是本计划的中心件KMS 无论那点边际延迟优势有多大都被淘汰。wlr-screencopy 是 Hyprland 真正维护的接口hyprland.portal声明了 ScreenCast/Screenshot/GlobalShortcuts/InputCapture捕获是一等公民能捕获包括无头输出在内的任何输出无需任何 capability 位并且把同一批 dmabuf 喂给 VAAPI/NVENC。输入侧无需决策Sunshine 通过其包安装的 udev 规则、在合成器之下用 uinput 注入输入所以主机侧缺失 RemoteDesktop portal 无关紧要。六、设计三命令面——一个sunshine命令组生命周期命令对留在原地omarchy-install-service-sunshine与omarchy-remove-service-sunshine延续 Install Service 的习惯用法1Password、Dropbox、Tailscale 都住在这里手册已经写明了这条路线。仓库的setup-前缀语义是可反复运行的交互向导如omarchy-setup-security-sshd而 install/remove 是一次性的生命周期操作改名反而无益。新增的是一组sunshine动词纳入GROUP_DESCRIPTIONS表述为GROUP_DESCRIPTIONS[sunshine]Sunshine remote desktop hosting正如tailscale在拥有 install 之外的动词后赢得了自己的组命令角色说明omarchy-sunshine-pair用户终端配对流程见下节omarchy-sunshine-clients用户列出已配对客户端用 gum choose 选择后单个/全部解绑走/api/clients/list、/api/clients/unpairomarchy-sunshine-mode用户dedicated \| mirror \| --status显示模式切换--status供菜单checked守卫读取夜灯功能的传统omarchy-sunshine-display内部标记# omarchy:hiddentrue是 Sunshine 调用的 prep-cmd do/undo 钩子普通用户不直接调用omarchy-installed-service-sunshine内部隐藏谓词镜像omarchy-installed-service-tailscale包已装且单元 active所有命令都按 agents/skills/command-metadata.md 携带# omarchy:summary...元数据如# omarchy:summaryInstall Sunshine and open Moonlight streaming ports for LAN and Tailscale.并由omarchy commands --check校验其诚实性。七、设计四配对——终端里的 PIN而不是浏览器里的证书警告Sunshine 的 Web 管理端之所以存在是因为多数发行版没有更好的选择。omarchy 可以靠两个事实做得更好凭据可以非交互设置sunshine --creds user password配对是一次带基本认证的POST /api/pin调用body 为{pin: ..., name: ...}。安装时单元启动之前安装器生成随机密码执行sunshine --creds omarchy password并把密码以 0600 权限存入~/.local/state/omarchy/sunshine/credentials。用户不再需要发明 Web 凭据首次接触的浏览器仪式消失。托管配置同时显式写入origin_web_ui_allowed pc让 :47990 只应答 localhost——ufw 规则本来就不含 47990只开 47984/47989/48010 TCP 与流媒体 UDP 区间现在 Sunshine 自己也同意这个边界。配对命令omarchy-sunshine-pair是 bash gum提示用户输入 Moonlight 正在显示的 PIN 与客户端名然后执行curl -sk -u omarchy:$(credentials) \ -X POST https://localhost:47990/api/pin \ --data {pin: ..., name: ...}成功则报告被拒则重新提示。对回环地址使用-k加基本认证是安全的——被担保的传输目标是 localhost而 Sunshine 与 Moonlight 之间配对协议自带的证书固定certificate pinning不受影响。安装器收尾时把用户导向这条命令而不是自动打开 Web 应用。Sunshine Admin Web 应用本身保留作为面向专家、做单应用微调的逃生舱Sunshine 的 UI 确有深度但安装器不再自动打开它。八、设计五虚拟显示器——本计划的核心这是全文最关键的部分。hyprctl output create headless name能给 Hyprland 一个没有玻璃贴着的真实输出wlr-screencopy 会像捕获任何其他输出一样捕获它。把它接进 Sunshine 按应用per-app的 prep-cmd do/undo 对串流就变成了一个自有的工作区。omarchy 托管~/.config/sunshine/apps.json内置两条应用条目这两条同时也是模式的全部故事Remote Desktopomarchy-sunshine-mode dedicated的默认目标prep-cmd 的 do 运行omarchy-sunshine-display upundo 运行omarchy-sunshine-display down。没有 detached command——应用就是桌面本身会话与客户端连接等长。This Screenmirror无 prep-cmdSunshine 捕获当前聚焦的物理显示器。用于把桌面屏幕投给会议室或操作一台你本人也坐在前面的机器。omarchy-sunshine-display up依次做三件事创建固定命名的输出hyprctl output create headless sunshine。固定名很重要——自定义名是受支持的没有它 Hyprland 会在每次会话里臆造HEADLESS-2、HEADLESS-3……导致没有任何配置能瞄准它。按客户端尺寸设定Sunshine 会把SUNSHINE_CLIENT_WIDTH、SUNSHINE_CLIENT_HEIGHT、SUNSHINE_CLIENT_FPS导出进 prep-cmd计划注明这些名字与上游文档逐字一致因此hyprctl keyword monitor sunshine,${SUNSHINE_CLIENT_WIDTH}x${SUNSHINE_CLIENT_HEIGHT}${SUNSHINE_CLIENT_FPS},auto,1让手机得到手机形状的桌面、让 MacBook 得到 Retina 形状的桌面。关键约束这是运行时hyprctl keyword而不是monitors.lua编辑——该输出是临时的绝不能渗入用户声明的显示器配置否则 omarchy 默认的hl.monitor({ output ... })兜底规则会用错误的缩放把它认领走。把空工作区移过去并聚焦取下一个空闲工作区编号连同输出名一起记入~/.local/state/omarchy/sunshine/这样down才能精确知道自己创建了什么。串流打开在干净桌面上物理显示器保留自己的工作区与自己的用户。omarchy-sunshine-display downundoSunshine 在客户端不干净断开时也会执行则谨慎地反向操作。Hyprland 删除输出时会把它上面的工作区疏散到幸存的显示器上——那是安全网不是计划本身。因此在hyprctl output remove sunshine之前down先把远程会话打开的任何窗口移到已记录的工作区编号该编号随输出消失而幸存上避免窗口散落到 Hyprland 随便挑中的某块屏幕然后再删输出。若根本不存在物理显示器真正的无头盒子down仍然删除输出工作区暂居边缘直到下一次up为它们重建家园——而这恰恰就是下一次连接时会发生的事。up同时自愈崩溃会话残留的sunshine输出会被删除重建而不是被直接信任。计划还诚实声明了两个需要在 rollout 中验证而不是事后发现的注意点其一Sunshine 通过output_name挑选要捕获的输出其 wlr 后端的匹配语义数字枚举 id 对名字符串必须在随附的 2026.516 构建上钉死——设计意图是sunshine输出存在就捕获它否则捕获聚焦的物理显示器若output_name无法按应用表达这一点回退方案是omarchy-sunshine-mode在切换模式时重写全局output_name并重启单元粒度更粗但确定性强。其二无人坐镇的机器也可被连接遇到全盘加密SDDM 自动登录前的密码提示时存在真实边界问题移交开放问题列表而非掩盖。九、设计六音频——镜像不变专属模式获得私有声卡镜像模式什么都不改Sunshine 捕获默认声卡的 monitor两头听到同一个声音——这本来就是镜像的含义。专属模式获得一个私有 sinkomarchy-sunshine-display up通过 PipeWire 的 pulse 层加载一个 null sinkpactl load-module module-null-sink sink_namesunshine-audio ...模块 id 记入状态托管配置写入virtual_sink sunshine-audio于是 Sunshine 在串流期间把默认 sink 切到它、结束后恢复先前的默认down负责卸载该模块。这个后果是刻意为之、值得直说的专属模式串流期间这台机器的音频属于远程会话——应用播进虚拟 sink串流带走它桌面的音箱保持安静。在单用户机器上这正是不偷走本地音频的正确解读真正在用这台机器的人是握着 Moonlight 客户端的那位。替代方案——在同一把座椅的两个并发用户之间按应用切分音频——是 PipeWire 理论可表达、却没有人愿意维护的多席位功能。十、设计七安全姿态——在正确的姿势上再收紧现有防火墙姿态是好部分保持原样TCP 47984/47989/48010 与 UDP 5353/47998–48010 只对10/8、172.16/12、192.168/16和tailscale0开放带omarchy-sunshine注释移除时按注释拆除此点在两个现有脚本中均已落实bin/omarchy-install-service-sunshine、bin/omarchy-remove-service-sunshine。在此基础上再加五层安装顺序耦合通过抽取修复Sunshine 的 ufw 规则抽成一个幂等的内部 helper 供安装脚本调用omarchy-install-service-tailscale在 Sunshine 已装时于收尾重跑它反过来亦然——Sunshine 安装器本就处理 Tailscale 先装的顺序。无论哪个服务后到tailnet 规则都存在。origin_web_ui_allowed pc且永远不为 47990 开 ufw 规则管理面靠两个独立机制都只回环可达。托管配置显式写upnp offSunshine 链接了 miniupnpc远程桌面主机永远不该请求路由器向公网开洞。漫游访问的答案只有一句用 Tailscale而不是端口转发。凭据存于~/.local/state/omarchy/sunshine/credentials0600 权限通过配置文件/标准输入传给 curl而不是出现在ps可见的 argv 里。配对信任模型沿用 Sunshine 自己的客户端证书固定在 PIN 交换期间建立omarchy 不引入自己的证书并移除用户唯一被训练成点过证书警告的地方。十一、设计八托管配置与用户配置的边界Sunshine 的配置属于用户与~/.config下的一切一样。omarchy 拥有sunshine.conf中一个由分隔线界定的区块含capture、output_name、virtual_sink、origin_web_ui_allowed、upnp由安装器与omarchy-sunshine-mode幂等地写入同时按名称托管apps.json中的两条内置条目——安装时重新生成其余时间不动。这样用户在管理 UI 里添加的 Steam Big Picture 条目会被保留。移除脚本只删除 omarchy 自己写的东西然后用 gum confirm 提议是否彻底清除~/.config/sunshine/包括配对状态——因为移除服务通常意味着这台机器不再是主机但绝不能静默摧毁某人打算跨重装保留的配对。十二、设计九菜单集成——按 docs/menu.md 约定按菜单约定新条目一律不加aliasesdocs/menu.md 说明aliases留给既有习惯入口守卫用when/checked/disabled这类 bash 条件表达install.service.sunshine—— 形如{icon: ..., label: Sunshine, disabled: omarchy-pkg-present sunshine, action: omarchy-launch-floating-terminal-with-presentation omarchy-install-service-sunshine}。这是早就该有的目录行装上后和所有 Install 行一样变灰打 ✓。remove.service.sunshine—— 镜像条目带when: omarchy-pkg-present sunshine没有可移除的东西时整行隐藏。setup.sunshine—— 仅安装后存在when: omarchy-pkg-present sunshine的子菜单Pair Client浮窗终端 →omarchy-sunshine-pair、Clients→omarchy-sunshine-clients、Dedicated Display/This Screen两行带checked守卫读取omarchy-sunshine-mode --status因两行同时读取它需在GUARD_READERS注册这是菜单守卫测试强制要求的以及AdminWeb 应用从安装器自动打开降级为菜单一行。菜单守卫机制本身有据可查when/checked/disabled都是 bash 条件checked成功时追加 ✓ 表示当前正是此选择docs/menu.md。这正是 default/omarchy/omarchy-menu.jsonc 中setup.network.dns.*、setup.monitors等现有条目的写法。十三、设计十客户端侧与作用域边界Moonlight 已预装、已有窗口规则、已在启动器里。作为客户端去连 omarchy 主机就是本计划的终端配对流程加一个 PIN。一个连接 helper用选择器包装moonlight-qt stream host Remote Desktop虽然便宜但时机未到——Moonlight 自己的网格 UI 本就记忆主机在没人要求之前就包装它是过度装饰plans/dots 计划所警告的那种。手册会记录这条 CLI 单行命令供快捷键爱好者使用仅此而已。从 omarchy 反向连到 Mac 或 Windows 机器是真实的邻近缺口但明确不属于本计划那是不同的协议栈对 Windows 用 FreeRDP/Remmina对 macOS 除了 VNC 没有像样的、不同的信任模型、不同的设计中心纯客户端、无主机工作。硬缝进来会两头稀释若有需求那是将来的plans/rdp.md而本计划的手册章节会点名 Remmina让今天的答案至少可被发现。RustDesk 基于前述主机侧原因保持默认不安装。十四、设计十一卸载对称性omarchy-remove-service-sunshine重构为撤销本计划创建的一切停止并禁用单元若状态显示有活动会话则运行omarchy-sunshine-display down删输出、卸载 null sink、疏散工作区关闭带注释的 ufw 规则移除 Web 应用清除遗留 autostart 行删除~/.local/state/omarchy/sunshine/提议清除~/.config/sunshine/卸载包。菜单无需拆卸——每个条目都以包存在为守卫会自行消失。未清除配置的重装会带着既有配对回来这正是两段式拆除的正确语义。十五、Rollout三个阶段、测试与验证关卡Phase 1 —— 把已有之物做对单启动路径 删除 autostart 行的迁移安装时生成凭据托管配置写入origin_web_ui_allowed/upnp/capture终端配对omarchy-sunshine-pair、omarchy-sunshine-clients补齐 Install/Remove 菜单行ufw helper 抽取与 Tailscale 交叉调用。可独立发布且已经是一个更好的产品。Phase 2 —— 真正的远程桌面omarchy-sunshine-displaydo/undo、托管apps.json、omarchy-sunshine-mode、音频 sink、setup.sunshine菜单。以设计中的两个验证关卡为闸门针对随附构建的output_name语义、以及真实硬件上显示器增删震荡下的断连/重连行为。Phase 3 —— 打磨omarchy-sunshine-clients的解绑流程、文档、验收覆盖。测试策略分四层纯逻辑 shell 测试计划落在test/shell.d/sunshine-test.sh托管配置块幂等性、apps.json 生成时保留用户条目、ufw 参数构造、display up/down状态文件往返、mode--status输出CLI 元数据经omarchy commands --check校验菜单守卫走 test/shell.d/ 既有menu-test.sh/menu-guards-test.sh约定如 bar-widget-contract、menu 类既有测试所示范的契约风格图形验收按 agents/skills/acceptance-tests.md 在 ISO 虚拟机中进行从菜单安装、单元 active、端口开放、display up创建并按尺寸设定输出、down不遗留孤儿窗口每状态截图、移除后无单元/规则/状态残留。真正的流协商需要一个 Moonlight 客户端作为 PR 中如实标注的手动清单项。文档交付新增 manual/52-remote-desktop.md注意该章节属于计划目标产物当前仓库尚未创建——托管搭建、配对、两种模式、Tailscale 漫游、FDE/无头注意点、面向 Windows 目标缺口的 Remmina 指路manual/26-gaming.md 收窄回游戏串流并链接过去docs/增加一份关于托管配置块与状态文件的简短参考供未来的迁移知道 omarchy 拥有什么。十六、七个开放问题计划以七个开放问题收尾划定 v1 的诚实边界wlr 后端下output_name的语义——是 id 还是名字、Sunshine 何时相对 prep-cmd 执行枚举输出。设计假设up运行后按会话解析若随附构建不符模式切换回退为重写配置 重启单元。Phase 2 以此答案为闸门。剪贴板同步——上游已表态不做纯文本剪贴板同步曾被提案并关闭为 not plannedMoonlight 也没有承载它的传输通道。omarchy 侧桥接两台 omarchy 机器经 Tailscale 走 wl-clipboard可造但那是带安全面的新同步守护进程对 Mac/Windows/手机客户端毫无帮助且有范围蔓延之嫌。倾向v1 明确列为非目标仅在成为独立计划时重议。全盘加密下的无头启动——LUKS 密码挡住了无显示器主机所需的会话。TPM 自动解锁或远程解锁是独立的安全设计。v1 记录该限制还是并入 TPM 方案Sunshine Admin Web 应用去留——当配对、客户端、模式都有了第一方表面之后它是专家逃生舱还是本计划意在终结的浏览器习惯镜像模式几何——客户端与物理分辨率不一致时让 Moonlight 缩放默认还是用同一组 prep-cmd 环境变量把物理显示器模式切到匹配缩放不扰人切模式才是游戏串流人群的预期。顶栏存在感——dropbox/tailscale 式的插件显示串流中并提供断开操作当有人从自己正坐着的机器上向外串流时确实有用但插件是另一门手艺倾向 v2。登出远程会话守卫——down是否应改为关闭远程会话打开的窗口而非重新安置它们作为共享桌面机器的隐私立场倾向不绝不自动销毁用户窗口。结语plans/remote.md 展示的是一条克制而完整的工程路径不引入新协议、新守护进程或新包而是把仓库里已有的 Sunshine/Moonlight 资产重新缝合——systemd 单元独占启动、wlr-screencopy 显式声明、固定命名的 headless 输出与按客户端尺寸的虚拟显示器、预置凭据与终端 PIN 配对、专属模式私有音频、loopback-only 管理面与upnp off最后用分三阶段的 rollout 与多层测试把它压稳。对于想在 omarchy 上获得局域网与 tailnet 内真正的远程桌面的人来说这正是当前仓库里最权威的路线图与设计说明书。【免费下载链接】omarchyBeautiful, Modern Opinionated Linux项目地址: https://gitcode.com/GitHub_Trending/om/omarchy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考