wslg不支持跨架构gui调试，因其仅兼容x86_64/aarch64二进制，且绕过display依赖wayland/rdp链路；跨架构gui需改用x11转发+vcxsrv等方案。
WSLg是否支持跨架构GUI调试
不支持。WSLg本身只运行在x64或ARM64的Windows宿主上，且其内置的Weston + XWayland仅面向与Windows ABI兼容的Linux二进制（即x86_64或aarch64架构的ELF）。当你尝试在WSL2中运行riscv64或arm32等非原生架构的GUI程序（比如交叉编译出的LVGL模拟器、QEMU内嵌GUI），wslg.exe会直接报错或静默失败——它根本不会把这类进程交给Wayland合成器处理。
为什么DISPLAY设置对WSLg无效
因为WSLg不走X11转发路径，也不依赖DISPLAY环境变量。它是通过自研RDP后端把Wayland客户端画面“推”到Windows桌面，整个链路绕过了传统X Server。你设export DISPLAY=:0或export DISPLAY=172.28.0.1:0，对wslg.exe启动的进程完全无影响；反而可能干扰其他X11工具（如VcXsrv）的判断逻辑。
- WSLg启动GUI应用时，自动注入
WAYLAND_DISPLAY和XDG_RUNTIME_DIR，这两个才是关键变量 -
DISPLAY只在启用X11转发（如配合ssh -X或第三方X Server）时起作用 - 若同时装了VcXsrv又开了WSLg，两个服务会争抢端口或导致
xdg-open行为异常
真正能跑跨架构GUI的替代方案
必须绕过WSLg，改用X11转发+轻量X Server。核心思路是：让跨架构程序作为X Client，把绘图指令发给Windows侧运行的X Server（如VcXsrv或Xming），由后者完成渲染。这和WSLg的Wayland/RDP路径互斥，但兼容性更广。
- 在Windows安装
VcXsrv，启动时勾选“Disable access control”，并允许防火墙通行 - 在WSL2中执行：
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0 - 确保目标程序链接的是
libX11.so而非Wayland库（例如LVGL模拟器需加-DLV_USE_WAYLAND=OFF -DLV_USE_X11=ON） - 运行时若提示
Cannot open display，大概率是DISPLAY地址不对，或VcXsrv未监听TCP连接
VSCode里调试跨架构GUI程序的关键配置
VSCode的launch.json不能直接调用wslg.exe来启动跨架构二进制，而要靠预启动脚本注入DISPLAY并确保X11转发就绪。
- 在
.vscode/launch.json中使用preLaunchTask执行shell脚本，内容为：export DISPLAY=172.28.0.1:0 && /path/to/riscv64-unknown-elf-gdb --tui ./build/app.elf - 务必关闭WSLg自动启动：在
/etc/wsl.conf里加[interop] guiApplications=false，否则wslg.exe会劫持所有GUI调用 - 如果程序依赖OpenGL（如glfw+x11），需额外安装
mesa-utils和libgl1-mesa-glx，并确认VcXsrv启用了OpenGL加速选项
跨架构GUI调试真正的瓶颈不在VSCode或WSL2，而在X11协议本身的带宽和延迟。动画类应用（如LVGL demo）会明显卡顿，这不是配置问题，而是协议层限制。需要实时反馈的场景，建议回归原生架构编译，或改用WebAssembly+Canvas模拟器替代。
