Add POST/DELETE/GET /vms/{name}/display plus the open_display/close_display/display_status/display_ready SDK methods, so a script can open and close a VM's display window like the GUI's Connect button.
Readiness is a latched flag, not a frame-channel probe: connecting to the guest frame service is itself becoming the display's single consumer, so polling it would steal the slot and blank the display. The guest agent reports the display driver state over the agent channel (idd_status) and the host latches it as idd_ready; asb_vm_idd_ready = running && agent_online && idd_ready. The Linux agent reports idd_status:ok once the user session is up (Mutter compositing).
The display window is daemon-owned (per-VM table keyed by unique_id), gated on a visible window station, and self-tears-down on the X button; displayOpen is read from the live window state, so it is honest however the window closed.
tools/linux — Linux-side build of AppSandbox guest components
Everything in this tree compiles on a Linux box and produces artifacts that the Windows AppSandbox host needs in order to stage a Linux VM. The components:
| Subdir | What it builds | Where it ends up in the guest |
|---|---|---|
agent/ |
5 userspace daemons (ELF) | /usr/local/bin/appsandbox-{agent,audio,clipboard,display,input} |
dxgkrnl/ |
Hyper-V GPU paravirt kernel module | /lib/modules/<kver>/updates/dxgkrnl.ko (or DKMS) |
asb_drm/ |
Stub DRM driver for KMS capture | /lib/modules/<kver>/updates/asb_drm.ko (or DKMS) |
wsl-mesa/ |
(optional) Mesa with d3d12 + dzn | tarball extracted to /opt/wsl-mesa/ |
wsl-deps/ (Microsoft's proprietary libd3d12.so etc.) is not built
here — it's fetched by the Windows host from Microsoft's public NuGet feed
into C:\ProgramData\AppSandbox\wsl-deps\. See tools/wsl-deps/README.md.
Build
Prereqs (Ubuntu 26.04+; package names may differ on other distros):
sudo apt-get install -y \
build-essential dkms zstd \
linux-headers-$(uname -r) \
libdrm-dev libasound2-dev libxcb1-dev libxcb-xfixes0-dev
Then from this directory:
make
That builds the 5 daemons, both kernel modules against your running kernel,
and installs them under tools/linux/dist/:
tools/linux/dist/
├── appsandbox-agent ← strip'd ELF
├── appsandbox-audio
├── appsandbox-clipboard
├── appsandbox-display
├── appsandbox-input
└── modules/
└── <uname-r>/
├── dxgkrnl.ko
└── asb_drm.ko
dist/ is gitignored — it's only valid on this machine for this kernel.
Other targets:
| Target | What it does |
|---|---|
make compile |
builds in place but doesn't copy to dist/ |
make agents |
builds only the userspace daemons |
make modules |
builds only the kernel modules |
make clean |
removes *.o, *.ko, daemon ELFs from source dirs |
make distclean |
clean + removes dist/ |
Transfer to the Windows host
This step is manual on purpose — there's no assumption of network connectivity between your Linux build box and the Windows machine that runs AppSandbox.
After a successful build, get dist/'s contents over to your Windows host
and place them at:
<appsandbox-repo>\release\resources\linux\
The simplest approach is a tarball:
tar -C dist -czf ~/asb-linux.tar.gz .
Then transfer asb-linux.tar.gz to the Windows host by whatever means you
normally use to move files between these two systems (USB stick, shared
filesystem, file-share VM, scp, manual upload — whatever works for your
setup). On the Windows side, in your appsandbox checkout:
mkdir release\resources\linux
tar xzf C:\path\to\asb-linux.tar.gz -C release\resources\linux\
tar.exe ships with Windows 10+; if it isn't on your PATH the Git for
Windows / 7-Zip / WinRAR equivalents all handle .tar.gz fine.
How the staged files reach a running VM
release/resources/linux/is a committed staging dir on the Windows side — same model as the existingrelease/resources/appsandbox-*.exefiles used for Windows guests.AppSandbox.vcxproj's PostBuildEvent xcopiesrelease/resources/intobin/<cfg>/resources/next toAppSandbox.exeandAppSandboxCore.dll. That happens on every build, so a rebuild after copying the new files makes them runtime-visible.- When you create a Linux VM,
disk_util.c::iso_create_resources_ubuntubuilds acidata.isowithuser-data(autoinstall) + anextras/tree that includes everything from<exe_dir>/resources/linux/. - On first boot of the VM, autoinstall mounts the cidata ISO, copies
extras/into/opt/appsandbox/, then runssetup.shviacurtin in-target.setup.shinstalls the agent ELFs into/usr/local/bin/, the kernel modules into/lib/modules/<kver>/updates/, wires up systemd units, and enables them.
Kernel module version skew
Kernel modules built here only load against an identical kernel version
in the guest (uname -r must match exactly). If the guest is on a different
kernel from your build machine, setup.sh automatically falls back to the
DKMS build path — it copies the source from extras/dxgkrnl/src/ to
/usr/src/dxgkrnl-<ver>/ and runs dkms install. DKMS handles future
kernel upgrades automatically. The committed .ko is just a fast path.