21.1.16.1-fork.2 — WSL2 vsock Transport & Mouse Capture (Unofficial)

This is an unofficial release based on marchaesen/vcxsrv 21.1.16.1. It adds a zero-config Hyper-V vsock transport for WSL2, and includes the mouse patches from 21.1.16.1-fork.1.

• Upstream: Issue #80 (vsock — PR to follow) · PR #78 + Issue #77 (mouse — pending review)
• Implementation notes: Implementation notes · 修复笔记
• Docs: User guide · 使用指南

What's New: WSL2 vsock transport (-vsock)

X11 traffic between WSL2 and VcXsrv no longer has to travel over TCP (NAT + localhost forwarding). A single new flag moves it to a Hyper-V socket — a channel purpose-built for VM↔host communication that bypasses the TCP/IP stack entirely: lower latency under input-heavy load, unaffected by VPN switching or sleep/wake, and effectively zero configuration. This puts VcXsrv's display responsiveness under WSL2 on par with WSLg and the commercial X410, while staying fully open source.

Problem	Before	After
vsock never worked for WSL2	The listener binds a wildcard VM id that WSL2's utility VM refuses to match; the exact id it needs changes on every WSL start and was only discoverable with admin tools	-vsock detects the running WSL2 VM automatically (wsl.exe -- wslinfo --vm-id) — no admin rights, no "Hyper-V Administrators" group
WSL restart broke the connection	The VM id changes on every wsl --shutdown or reboot	Self-healing: a watcher notices the new VM instance and rebinds the listener in ~1.5 s — VcXsrv keeps running
Multiple displays collided	The display number was ignored on bind; every instance fought over the same vsock port	Port = 106000 + display (:0 → 106000, :1 → 106001)
Listener on by default	Wildcard listener on every machine: cookie-free access for any local VM, plus log noise on non-Hyper-V hosts	Off unless -vsock, -vmid, or -listen hyperv is given

Also included (from fork.1): relative mouse mode & cursor confinement (PR #78) — SDL2 games, emulators, and 3D/CAD tools capture the mouse correctly; no SDL_MOUSE_RELATIVE_MODE_WARP=1 workaround needed.

Requirements

• WSL2, Store WSL 2.0+ (check with wsl --version)
• socat ≥ 1.7.4 in the distro (sudo apt install socat)
• Without -vsock, this build behaves exactly like upstream plus the fork.1 mouse patches — no behavior change for existing users; on WSL1 it silently falls back to TCP

Quick Start

1. Windows: vcxsrv.exe :0 -multiwindow -clipboard -wgl -vsock
   (XLaunch users: add ExtraParams="-vsock" to config.xlaunch instead)
2. WSL2:

   socat UNIX-LISTEN:/tmp/.X11-unix/X0,fork,mode=777,forever,retry=10,interval=2 VSOCK-CONNECT:2:106000 &
   export DISPLAY=:0

3. Run any X app. To confirm the path: ss --vsock | grep '2:106000' shows ESTAB while the app runs.

Autostart (.bashrc / systemd), WSLg coexistence (/tmp/.X11-unix/X0 already taken → use display :1), multiple instances, and troubleshooting: see the user guide (中文).

Verified

End-to-end on Windows 11 + Store WSL2 (Ubuntu):

Test	Result
X11 handshake over vsock	SUCCESS, cookie-free (local-client trust)
Two instances :11 / :12, both -vsock	Both connect, on 106011 / 106012 (display-offset fix)
WSL VM restarted while server keeps running	Listener auto-rebound to the new VM id; clients reconnect
Default start (no -vsock)	No vsock listener; TCP path unchanged (no regression)

Upstream

All credit for the base X server and the original hyperv transport goes to marchaesen/vcxsrv. If this build helps you, the most useful thing you can do — more than starring the fork — is leave your test results on Issue #80 and PR #78; confirmed user reports are what moves the review forward.

21.1.16.1-fork.1 — Relative Mouse Mode & Cursor Confinement (Unofficial)

WSL2 users: get 21.1.16.1-fork.2 instead — it includes everything in this build plus the zero-config WSL2 vsock transport (Issue #80). This build remains for testing the mouse patch in isolation.

This is an unofficial release based on marchaesen/vcxsrv 21.1.16.1.

• Upstream PR: #78 (pending review)
• Related issue: #77
• Implementation notes: English · 中文

What's New

Problem	Before	After
No relative displacement data	XI_RawMotion events never generated	Hardware-level relative deltas fed via WM_INPUT → winEnqueueRawMotion()
Cursor not confined on grab	XGrabPointer with confine_to had no effect	ClipCursor() applied with 1px padding on grab, released on ungrab
Cursor not hidden on grab	XFixesHideCursor had no effect	ShowCursor(FALSE) loop on grab, restored on ungrab

SDL2 applications no longer need the SDL_MOUSE_RELATIVE_MODE_WARP=1 workaround.
These are DDX-layer improvements for standard X11 features. They benefit any XInput2 or XGrabPointer client — most commonly SDL2 games and 3D/CAD tools running via WSL, but applicable to any X11 app on VcXsrv.

Tested With

Application	Platform	Mode	Result
dosbox-staging 0.82	WSL1/WSL2	seamless + capture	Pass
AssaultCube 1.3	WSL1/WSL2	capture + release	Pass
crispy-doom 5.11	WSL1/WSL2	capture + release	Pass

Usage

No extra setup required beyond upstream VcXsrv. After install just run:

vcxsrv.exe -multiwindow -clipboard -wgl

For dosbox-staging on WSL: if the cursor stays still in seamless mode, set export XDG_CURRENT_DESKTOP=WSL before launching — SDL2 uses this to decide whether to enable X11 mouse integration.

Upstream

All credit for the base X server goes to marchaesen/vcxsrv. If this patch helps you, the most useful thing you can do — more than starring the fork — is test PR #78 and leave your results there; confirmed user reports are what moves the review forward.