企业官网建设流程全解析

我那块RK3588开发板，在机柜角落里已经连续跑了快两个月没有接显示器。平时SSH进终端敲命令倒是痛快，直到有一次要在板子上跑YOLOv8推理，程序里带了一个cv2.imshow窗口，才发现问题很现实：没有屏幕，这个窗口给谁看？让程序把检测结果存成图片再拉回本地，来回折腾效率太低，而且调试GUI程序、看ROS可视化、甩几个Qt界面上去，根本没法这样绕。

后来我把x11vnc配好之后，整个体验完全不一样了：远程打开VNC Viewer，看到的就是开发板当前那个真实桌面，鼠标点哪里，物理屏幕（如果插着的话）就同步到哪里。这个“真同步”正是x11vnc区别于其他方案的关键。这篇文章就把我的完整配置过程、踩过的坑、以及无显示器环境下的处理思路都写出来，希望能帮你少走弯路。

1. 为什么是x11vnc：先搞清楚各种远程方案的底层逻辑

很多人在给RK3588做远程桌面时，第一反应是装个VNC或者用xrdp。但用下来会发现，不同方案面对的需求完全不一样。选错方案，后面怎么调都不顺手。这里把我的选型过程讲清楚。

1.1 SSH + X11转发：只适合临时调试

Linux玩得多的朋友可能都知道，SSH可以加一个-X参数做X11转发，让开发板上跑的程序窗口直接显示到本地电脑上。这个方案对RK3588来说不是不能用，但它有几个先天短板。

X11协议是30多年前的设计，它的客户端和服务器之间传输的是“绘图指令”，而不是压缩后的图像数据。对于一个简单的按钮、一个文本框这没问题，但你要是跑一个带实时视频流的OpenCV窗口，或者Qt的上位机界面，X11转发的数据量会变得非常夸张，延迟高、卡顿明显，画面还经常撕裂。我实测过在板子上跑一个显示USB摄像头画面的程序，通过SSH转发到PC，帧率基本只有个位数。

这个方案只适合偶尔看一下程序窗口长什么样，不适合做日常的远程桌面使用。

1.2 xrdp：会话是“新开的”，不是“镜子”

xrdp在嵌入式板子上也很流行，很多RK3588的Ubuntu镜像甚至预装了。但你要知道xrdp的原理：它在系统里创建了一个或者多个独立的Xorg会话，用户远程登录后进入的是这个新的会话，而不是物理屏幕上正在运行的那个桌面。

这意味着什么？假如你在板子的物理桌面上打开了一个程序，然后用xrdp远程连进去，你会发现那个程序根本不在远端桌面上。反过来，你在xrdp远程会话里操作的东西，物理屏幕上也不会出现。两边各玩各的，数据不互通。

对于“我在板子上跑AI检测，想远程看看结果画面实时同步”这种需求，xrdp是做不到的。它更适合服务器多用户场景——每个人登录都有自己独立的虚拟桌面。

1.3 x11vnc：直接镜像真实桌面，所以才叫“真同步”

x11vnc的思路完全不同。它本身不创建桌面，而是直接挂在当前正在运行的X11显示服务器上，周期性地抓取屏幕像素变化，再通过VNC协议发送给远程客户端。

通俗点说：x11vnc就是一面镜子，你物理屏幕上是什么，远程客户端里就是什么。你在远程端用鼠标点开一个程序，这个操作会被x11vnc注入到真实的X11会话里，所以物理屏幕上也会同步打开这个程序。

这个特性对RK3588这样的开发板特别重要。因为很多时候我们需要看的就是“板子上当前这个会话”的实时状态——可能是检测算法的可视化结果，可能是调试工具的运行界面，也可能是某个图形化配置面板。x11vnc把你和开发板的物理会话拉到了一起，这就是标题里说的“真同步”。

选型结论很直接：如果你要的是一块嵌入式板子的真实桌面远程操控，而不是一个独立的虚拟桌面，x11vnc就是最对口的方案。

2. RK3588环境准备：从确认X11到安装依赖

RK3588平台本身比较特殊，它是arm64架构，不同开发板厂商给的镜像差异很大。有的预装的是Xorg会话，有的默认跑Wayland，还有的直接是无桌面服务器版。在装x11vnc之前，有几个前置工作必须先确认清楚，否则后面配置大概率翻车。

2.1 先确认你的系统会话是X11还是Wayland

x11vnc的“x11”已经说明了一切：它只能配合X11显示服务器工作。RK3588的很多Ubuntu镜像里，桌面环境默认跑的是Wayland，尤其是GNOME在较新版本里几乎默认就是Wayland会话。

如果你现在处于Wayland会话，直接启动x11vnc会报错或者黑屏。所以第一步先用SSH登录到板子，跑一条命令确认：

echo $XDG_SESSION_TYPE

输出结果是x11就可以继续；如果是wayland，有两个选择：一是登录界面切回Xorg会话（很多板载镜像在登录时有齿轮按钮可以选），二是直接改用Wayland对应的VNC方案（比如wayvnc），但这不是本文的重点。为了x11vnc能正常工作，我在板子上把会话固定切到了Xorg。

还有一点要注意：如果你是用SSH登录的，SSH终端里的$XDG_SESSION_TYPE可能读取不到，因为它依赖于你登录的用户会话。更可靠的方式是查看当前的显示服务器进程：

ps aux | grep -E "Xorg|Xwayland"

如果有Xorg进程，说明X11已经跑起来了；如果只看到Xwayland，说明还是Wayland环境。

2.2 安装x11vnc

RK3588的镜像基本都基于Ubuntu或Debian，arm64仓库里直接有x11vnc的包，不需要自己编译。安装命令：

sudo apt update sudo apt install -y x11vnc

装完之后可以验证一下版本：

x11vnc -version

实测下来Ubuntu 22.04和24.04的仓库里版本都够用，不需要折腾源码编译。不过如果你用的镜像源比较旧，安装后建议顺带跑一下sudo apt upgrade，避免依赖库版本冲突。

2.3 搞清楚显示编号和认证文件：x11vnc能不能连上的命门

X11系统里每个显示会话都有一个编号，通常第一个是:0，第二个是:1。x11vnc启动时必须要指定它要去镜像哪个显示编号，如果搞错，轻则黑屏，重则直接报错退出。

查看当前显示编号最直接的方法：

ls /tmp/.X11-unix/

这个目录下会出现类似X0、X1这样的条目，X0对应:0显示设备。在大多数RK3588板子上，本地物理桌面的会话就是:0。

真正麻烦的是认证文件。X11为了保证安全，默认会有一个授权机制——任何程序想连接显示服务器，必须持有对应的Xauthority文件。x11vnc作为“外部”程序，启动时需要把这个文件给它。

每个用户的Xauthority路径不一样，取决于桌面环境。GDM3经常在/run/user/1000/gdm/Xauthority，LightDM可能在/var/run/lightdm/root/:0，有的镜像则直接在用户家目录~/.Xauthority。手动一个个找太痛苦，好在x11vnc提供了一个guess参数让它自动猜测。

x11vnc -display :0 -auth guess

不过自动猜测也不是100%准，如果后面连接黑屏，就要手动定位正确的Xauthority路径。我在排查阶段用过的命令：

find /run /var /home -name Xauthority 2>/dev/null

找到之后可以手动指定：

x11vnc -display :0 -auth /run/user/1000/gdm/Xauthority

这一节的内容是整个配置里最核心的部分，后面实战配置和踩坑都会围绕这个问题展开。

3. 核心配置：一条命令跑通，再固化到systemd服务

环境确认没问题之后，接下来就是正式配置x11vnc了。我建议你先把命令手工跑通一遍，确认画面能出来、鼠标键盘能操作，再去做开机自启。一上来就写systemd服务，出了问题反而不容易排查。

3.1 设置访问密码并手工启动验证

VNC默认是不加密的，如果端口暴露在公网上，任何人都能连你的桌面。所以第一步先设置一个访问密码：

x11vnc -storepasswd

执行后会让你输入两次密码，默认生成在~/.vnc/passwd。如果提示目录不存在，先手动创建：

mkdir -p ~/.vnc

密码文件生成后，手工启动x11vnc试试：

x11vnc -display :0 -auth guess -forever -shared -rfbauth ~/.vnc/passwd -rfbport 5900 -noxdamage -o /tmp/x11vnc.log &

启动后用tail -f /tmp/x11vnc.log看看日志，出现number of connected clients: 0这类信息就说明服务已经在正常监听了。

这时候可以用另外一台电脑上的VNC客户端连接开发板的IP加端口5900，输入密码后，应该就能看到开发板的真实桌面了。

3.2 关键参数解析：为什么是这些参数

那块命令虽然长，但每个参数都有它的作用，不是随手写的。逐个拆解：

-display :0：告诉x11vnc去镜像编号为:0的显示会话。如果你的板子桌面跑在:1，这里就要对应修改。

-auth guess：自动猜测Xauthority认证文件的位置。这个参数在GDM、LightDM等常见显示管理器下都比较好使，省去了手动找文件的麻烦。如果猜测失败，就手动指定路径。

-forever：默认情况下，第一个VNC客户端断开后x11vnc会跟着退出。加了这个参数之后，x11vnc会一直运行等待下一个客户端连接。对于远程调试场景，这个参数是必须的——你不可能每次都去板子上重新启动服务。

-shared：允许多个VNC客户端同时连接同一个桌面。不加这个参数的话，第二个客户端会把第一个挤掉。我在实验室环境里经常需要同事同时看一眼屏幕，所以加上了。

-rfbauth ~/.vnc/passwd：指定密码文件位置。

-rfbport 5900：VNC服务监听的端口。5900是VNC默认端口，客户端软件通常看到5900就可以省略端口号直接连。

-noxdamage：禁用XDamage扩展。XDamage本来是告诉x11vnc哪块区域画面变了、只传输变化区域，理论上能减轻带宽压力。但实测在RK3588的某些显卡驱动上，启用XDamage反而可能出现花屏或残影，所以直接禁用它。

-o /tmp/x11vnc.log：日志输出文件。看似不起眼，但后面排查问题全靠它。

3.3 固化到systemd：开机自启与异常自动重启

手工启动的服务每次重启板子就没了，不符合长期稳定运行的需求。我一般推荐用systemd来托管，这样既能开机自启，进程挂了还能自动拉起。

创建服务文件：

sudo nano /etc/systemd/system/x11vnc.service

内容如下：

[Unit] Description=x11vnc remote desktop service After=display-manager.service network.target [Service] Type=simple User=root ExecStart=/usr/bin/x11vnc -display :0 -auth guess -forever -shared -rfbauth /root/.vnc/passwd -rfbport 5900 -noxdamage -o /var/log/x11vnc.log Restart=on-failure RestartSec=3 [Install] WantedBy=multi-user.target

几个比较关键的细节：

为什么要加After=display-manager.service：x11vnc必须等桌面环境启动完成后再启动，否则它找不到Xorg会话，一启动就会失败。加上这个依赖关系，系统会先拉起显示管理器，再启动x11vnc。

为什么User=root：x11vnc要读取Xorg会话的Xauthority文件，尤其是在GDM环境下，认证文件的权限经常只对root或者gdm用户开放。直接使用root最简单，但如果你有安全洁癖，可以单独创建一个用户并给它对应的权限，代价是配置文件会更复杂。我实际用下来，在自己的局域网开发环境里root问题不大。

为什么Restart=on-failure：x11vnc有时候会因为网络异常或者客户端异常断开而退出，有了自动重启，就不用每次手动去板子上把服务拉起来。

配置写好后，先让systemd重新加载配置，再启动服务：

sudo systemctl daemon-reload sudo systemctl enable x11vnc.service sudo systemctl start x11vnc.service

3.4 防火墙放行

如果你板子上启用了ufw或者firewalld，记得放行5900端口，否则外部客户端连接会被拒掉。

sudo ufw allow 5900/tcp

这里有个经验：如果你只是为了远程调试，建议限制来源IP，只允许公司或家庭局域网网段访问，不要给0.0.0.0/0全开放。命令大概是：

sudo ufw allow from 192.168.1.0/24 to any port 5900

RK3588开发板不像云服务器有安全组，如果直接暴露在公网，任何扫描到5900端口的人都能尝试爆破你的VNC密码，那画面不敢想。

4. 无显示器环境的特殊处理：桌面起不来，一切都白搭

RK3588的板子大多数时候是真·无头环境——没有接HDMI显示器。这时候很多人会遇到一个很尴尬的局面：固件和系统都正常烧录了，SSH也能进，但远程连VNC时发现黑屏，甚至x11vnc服务直接起不来。原因在于：Xorg会话没有正常启动，或者启动后因为没有显示器导致分辨率异常。

这一节我把自己折腾很久的经验整理出来，分三个层次处理。

4.1 现象：无HDMI时桌面真的活着吗

先确认一个基础问题：板子没有接显示器时，桌面环境到底有没有启动？

很多RK3588的Ubuntu镜像默认会在有HDMI显示器接入时才启动图形会话。如果没接屏幕，显示管理器（比如GDM3、LightDM）可能压根不会创建Xorg会话，或者只创建一个“假”的会话但无法正常渲染。这种情况下，不管你怎么调x11vnc参数，看到的都是黑屏。

验证方法很简单：

ps aux | grep -E "Xorg|Xwayland" | grep -v grep ls /tmp/.X11-unix/

如果没有任何Xorg相关进程，说明桌面会话确实没起来，那就不是x11vnc的问题，而是Xorg的问题。

4.2 硬件方案：EDID模拟器，最省心的无头神器

只要你是长期无显示器使用，我第一个推荐的就是HDMI EDID模拟器——淘宝上十几块钱一个的东西，头长得很像HDMI防尘塞，插到开发板的HDMI输出口上，系统会认为有一台显示器接入了，从而正常初始化Xorg会话并输出一个合理的默认分辨率。

EDID是显示器向显卡上报自己支持的分辨率、刷新率等信息的协议。EDID模拟器就是伪造这些信息，让GPU以为自己接了一个真实显示器。

我买过几款，实测下来常见分辨率支持都没问题。需要注意的是选一个支持1920x1080以上的，因为有些便宜的只支持1080p，倒也能用，但VNC画面在高分屏下的细腻程度会差一些。

插上EDID模拟器之后，重启系统，再用上面命令检查Xorg进程，基本就正常了。这个方法简单粗暴，对任何平台都有效，不会因为内核或者设备树配置问题翻车。

4.3 软件方案：改内核参数或者虚拟输出

如果不想买硬件，也可以试试纯软件方案，但这个跟板子固件的具体实现强相关，我不保证每块板子都能成功。

一种思路是给内核的DRM模块指定默认输出模式，在启动参数里加上类似：

video=HDMI-A-1:1920x1080@60D

这个参数的含义是让HDMI-A-1接口在没有物理显示器的情况下，也按1920x1080@60Hz来初始化虚拟输出。不同板子对应的显示接口名不一样，有的叫HDMI-A-1，有的叫DP-1，需要根据实际情况调整。修改启动参数的方法是在u-boot或extlinux配置中调整cmdline，这个跟你的引导方式有关，我在这里不展开太多。

如果你用的是支持Xorg虚拟显示的系统，也可以尝试用xrandr创建一个虚拟模式：

xrandr --fb 1920x1080

这个命令会把帧缓冲调整为1920x1080，无论当前是否有物理输出。但这里有个前提：Xorg确实已经启动了，只是分辨率异常。如果压根没有Xorg会话，这个命令也救不了你。

4.4 从源头保证桌面上线：自动登录与无人值守启动

解决了Xorg是否存在之后，还有一个问题：板子重启了，但没人去登录界面点一下“登录”，桌面会话会一直停在登录管理器画面。这种情况连接VNC顶多看到一个登录界面，关键是没法输入密码或者输入不了。

稳妥的做法是设置自动登录，让系统开机后自动进入桌面会话。不同显示管理器配置位置不同，GDM3在/etc/gdm3/custom.conf里，LightDM在/etc/lightdm/lightdm.conf里。

GDM3的自动登录配置示例：

[daemon] AutomaticLoginEnable=true AutomaticLogin=你的用户名

LightDM类似的配置：

[Seat:*] autologin-user=你的用户名 autologin-user-timeout=0

配置好后重启系统，检查Xorg进程是否自动启动，确认没问题后再去连接VNC。这一步的重要性在无头环境下怎么强调都不过分——因为你不自动登录，就等于没有桌面会话，x11vnc只能对着登录窗口干瞪眼。

5. 客户端连接与实测：从Windows、手机到浏览器

服务端配好后，客户端连接就相对简单了。但这里还是有一些细节值得讲讲，尤其是连接方式的选择、不同客户端的表现差异、以及实际跑AI可视化时的手感。

5.1 用VNC Viewer连接

Windows、macOS、Linux下我推荐用RealVNC Viewer或者TigerVNC，手机端推荐bVNC。连接的时候输入开发板的IP和端口：

192.168.x.x:5900

第一次连接会提示加密方式，VNC的加密比较弱，确认网络是在可信环境里就可以继续。输入密码后进入桌面。理论上如果前面配置没问题，此刻你应该能看到板子桌面的实时画面。

这里有一个小常识：x11vnc传输的是帧缓冲差异数据，带宽占用和画面的变化频率直接相关。如果桌面静止，网络流量几乎为0；如果播放视频或者拖动窗口，流量会飙升。局域网环境下体验很不错，我实测在RK3588上远程操作Qt界面和在PC上本机操作几乎没有肉眼可见的延迟差。

5.2 实测跑YOLOv8可视化窗口

我的核心使用场景是在板子上跑YOLOv8推理，程序里用cv2.imshow显示检测结果。在接好x11vnc的情况下，远程打开VNC Viewer，能看到的就是实时刷新的检测画面，每一帧框和标签都清晰可见。帧率受限于VNC编码和网络带宽，实测在1080p CBR下大约能到20-25fps，做视觉调试完全够用。

如果想要更流畅的体验，有两个调整方向：

一是降低x11vnc的编码质量，比如加-quality 8参数，画质会有轻微损失，但帧率会明显提升。二是把客户端里的色彩深度调低，用16位色而不是24位色。

如果你同时在本地跑了一个USB摄像头RTSP推流，再通过VNC看结果画面，这时网络带宽才是真正的瓶颈。我建议把摄像头图像和VNC走不同网段或者使用千兆交换机，避免互相干扰。

5.3 只有浏览器也能连：noVNC方案

有时候临时在别人电脑上，不想装VNC客户端，这时候noVNC会很方便。noVNC是一个纯HTML5实现的VNC客户端，跑在浏览器里，通过WebSocket与noVNC代理服务通信，代理再把数据转给x11vnc。

简单的做法是安装novnc包：

sudo apt install -y novnc

然后启动它：

/usr/share/novnc/utils/novnc_proxy --vnc localhost:5900 --listen 6080

浏览器打开http://开发板IP:6080/vnc.html，输入密码即可连接。走noVNC时浏览器端建议用Chrome或者Edge，Firefox也可以用但个别版本对WebSocket的支持有小问题。

不过要注意：noVNC默认不带加密，和裸VNC一样，只适合可信内网环境。

5.4 多显示器与单屏指定

部分RK3588开发板的HDMI和DP可以同时接两个屏幕，Xorg里对应多个显示输出。x11vnc默认镜像的主屏是整个虚拟屏幕拼接后的画面，如果你只想共享其中某一个屏，可以用-clip参数。

比如：

x11vnc -display :0 -clip xinerama0

xinerama0表示第一个物理头。这个参数在双屏场景下比较实用，尤其是你在主屏上跑GUI调试程序、副屏放着日志，远程端只想看主屏时。

6. 踩坑记录：黑屏、断连、卡顿的完整排查链路

很多朋友跟我说，按照教程配了x11vnc，但连接后要么黑屏、要么闪断、要么卡成PPT。这些坑我基本都踩过一遍，直接把我实际排查的思路写在这里。

6.1 黑屏：九成是DISPLAY或XAUTHORITY没配对

连接VNC后如果画面全黑但鼠标可以动，通常不是x11vnc没启动，而是它没有成功抓取到正确的桌面内容。

排查步骤：

1. 在板子上运行echo $DISPLAY，确认环境变量是不是:0或者:1。
2. 用ps aux | grep Xorg看Xorg进程实际用的是哪个显示编号。
3. 重点检查auth文件是否正确。一个简单粗暴的办法是直接用-auth guess，如果不行，就手动找到Xauthority文件路径，指定上去。

我遇到的最典型的案例是：用户是test这个普通账号，但桌面是GDM3启动的，Xauthority文件放在/run/user/121/gdm/Xauthority（这个编号随机），普通用户手动读不到，所以x11vnc启动时得给-auth指定具体路径。

6.2 连接后操作不了：鼠标键盘无响应

能看见桌面但点击没反应，大概率是权限不够。x11vnc默认注入键鼠事件的时候，如果当前的X11会话不允许外部程序注入，就会操作失败。

最常见的情况是桌面环境启用了“屏幕锁定”，锁屏时X11会封锁输入注入。解决思路：

一是把x11vnc的systemd服务用户设为root，同时配合-auth guess，这样它读取到的认证权限更高，在锁屏界面也能注入键鼠事件。

二是干脆关闭屏幕锁，对开发板调试环境来说，物理安全风险可控，锁屏带来的只有麻烦。

6.3 卡顿和花屏：damage、quality、defer的搭配

前面提过-noxdamage能解决一些花屏问题，如果画面依然卡，还需要关注另外两个参数：

-defer：VNC更新的延迟毫秒数，默认是20。如果网络质量不佳，可以提高这个值，比如-defer 50，减少网络包数量，以牺牲轻微延迟为代价换取稳定性。

-wait：两次屏幕轮询之间的间隔。默认是20毫秒，如果画面中有大量变化（比如视频播放），可以适当降低到10，会更跟手一些；如果只是静态界面，调高到30反而更节省CPU。

RK3588的CPU性能其实不差，编VNC画面不吃力，真正的瓶颈往往在网络带宽和客户端解码。我建议先用局域网测试，确认内网环境下没问题，再排查是不是路由器无线速率导致的卡顿。

6.4 断连后端口占用，服务起不来

x11vnc异常退出后，有时候端口还没有释放，这时候再启动服务会提示Address already in use。

处理方法：

fuser -k 5900/tcp

把占用端口的进程杀掉，然后重新启动服务。systemd服务的话，直接sudo systemctl restart x11vnc一般也能处理。

另外提一下，如果日志里出现FAILED_VIEWER之类的信息，说明有客户端连接后因为认证失败断开了，这通常是密码输错。密码文件损坏的话，重新执行x11vnc -storepasswd覆盖一遍即可。

6.5 锁屏黑屏与GDM登录界面的特例

最后一个容易踩的坑是锁屏界面黑屏。有时候桌面正常，但长时间不操作后屏幕熄灭了，这时候x11vnc抓到的画面就是黑的。可以把屏幕息屏时间禁用，或者用-display :0 -auth guess -noxdamage -forever配合来保证即使锁屏，x11vnc也能正常传递画面。

如果桌面环境压根没自动登录，停在GDM登录界面，那你远程看到的也只是登录框画面。这种情况就回到第4.4节，把自动登录配置好，一劳永逸。

7. 进阶加固：别让你的板子裸奔在网络上

x11vnc本身不加密，VNC协议也有历史悠久的认证漏洞，如果板子的5900端口直接暴露给公网，风险其实不小。长期使用的话，我建议做以下几层加固。

7.1 SSH隧道，端口不暴露就是最好的安全

内网环境里最简单可靠的做法是不让x11vnc监听外网端口，只让它监听本机回环地址：

x11vnc -display :0 -localhost -auth guess -forever -rfbauth ~/.vnc/passwd -rfbport 5900

然后使用SSH隧道来转发本地机器的5900端口到开发板：

ssh -L 5900:localhost:5900 user@开发板IP

这样x11vnc只对localohost开放，公网扫描根本扫不到这个端口，所有流量走加密的SSH通道，安全性直接拉满。代价是多了一条SSH命令，但收益明显。

7.2 TLS加密：不想用SSH隧道时的选择

x11vnc 0.9.x以上版本支持SSL/TLS加密，可以为VNC流量套层壳。不过需要先生成证书，并且VNC Viewer客户端也要能接受这种加密方式，兼容性不如SSH隧道来得通用。我自己的实践是内网用SSH隧道就够了，跨公网的话会用TLS加端口转发。

7.3 日志管理与长期巡检

x11vnc的日志如果不做处理，长时间运行会变得很大。systemd服务的日志交给journald管理，用起来也很方便：

journalctl -u x11vnc.service -n 50

手工启动的日志可以在启动参数里加-o /var/log/x11vnc.log，再配合logrotate定期切割。这样万一出了问题，翻日志定位很快。

7.4 关于性能调优的私人总结

最后聊一点性能相关。RK3588上有4个A76大核，跑x11vnc的时候它会占其中一两个核心。如果你的AI推理任务本身已经把CPU吃得很满，再加VNC编码，可能会对推理性能有轻微影响。

我的做法是给x11vnc进程绑核，避免它和大核抢占资源：

taskset -c 4-5 /usr/bin/x11vnc ...

这样它跑在固定的CPU核心上，其他任务不受干扰。实测下来推理帧率几乎无波动，远程桌面依然流畅。如果你有大量AI任务在板子上跑，这个技巧会很有用。

RK3588无显示器环境下跑x11vnc，最关键的就三件事：X11桌面会话真实的活着、认证文件正确匹配、systemd守护服务稳定运行。解决掉这三件事，远程桌面基本就可以“车到山前必有路”了。希望这篇文章能给你一些实际的帮助，少折腾几天。