parsec-vdd: a standalone virtual display driver for Windows hosts

What parsec-vdd actually removes from your setup

The Parsec Virtual Display Driver is built by Parsec and normally appears as a feature of Parsec Teams and Warp. This repository repackages that driver as a standalone install, so you do not need the Parsec app to create virtual displays on a Windows host. The README states the driver is available on Windows 10 and later and that it can add up to three virtual displays to a machine you connect to.

The audience is narrower than "anyone with a monitor problem". It is people who stream from a machine that has no usable display: a cloud GPU instance, a Hyper-V or GPU-PV guest, a build server, or a gaming VM. The README also lists a privacy mode, where the remote session runs on a virtual display while the physical monitor stays on a separate local desktop. The pitch is not extra screen space for a laptop owner. It is a display target that exists so capture tools, launchers and encoders have something to attach to.

Driver, IOCTL channel and the one-second ping

The architecture is small and the README is explicit about it. A user-mode app talks to the driver over IO control codes and reads results back. Adding a display returns an index, and that index is what you pass later to unplug it. Up to 16 displays can be added per adapter, which is a higher ceiling than the three displays the product description mentions.

The part that shapes every integration is liveness. The driver must be pinged periodically to keep added displays alive, otherwise all of them are unplugged after about a second. That is not a tunable timeout you can raise in a config file; it is the contract. Any program that creates a display has to keep running and keep pinging, or the display disappears. The README's own diagram shows the app on one side and the driver on the other, with a solid IOCTL arrow and a dashed ping arrow.

There is also a deliberate gap in the API. The README says there is no direct way to manipulate added displays, and that you should call the Win32 Display API to change their display mode, pointing at the ParsecDisplay source as the example. So the driver creates and destroys the monitor, while Windows owns resolution, refresh rate and orientation. Two different layers, two different failure modes.

Installing the driver and creating your first virtual display

There is no package manager step. You pick a driver version from the table in the README, download the setup executable, and install it. The table maps versions to minimum OS and IddCx level: 0.38 needs Windows 10 1607 and is marked obsolete and prone to random crashes, 0.41 needs Windows 10 19H2 and is marked stable, and 0.45 needs Windows 10 21H2 with better streaming color but a warning that it may not work on some Windows. All three are listed as working on Windows Server 2019 or higher.

The fastest path is silent mode on the setup executable:

.\parsec-vdd-0.45.0.0.exe /S

If you would rather control the driver node yourself, unzip the setup with 7z. You get nefconw.exe and a driver folder containing mm.cat, mm.dll and mm.inf. The README gives this three-step sequence, run as administrator, to remove any existing node, create a new one under the display class, and install the INF:

start /wait .\nefconw.exe --remove-device-node --hardware-id Root\Parsec\VDA --class-guid "4D36E968-E325-11CE-BFC1-08002BE10318"
start /wait .\nefconw.exe --create-device-node --class-name Display --class-guid "4D36E968-E325-11CE-BFC1-08002BE10318" --hardware-id Root\Parsec\VDA
start /wait .\nefconw.exe --install-driver --inf-path ".\driver\mm.inf"

With the driver in place you have two ways to drive it. The ParsecDisplay app is a C# and WPF tray application that adds and removes displays, changes resolution, refresh rate and orientation, and takes screenshots. If you are writing your own host, the core API is a single C/C++ header, core/parsec-vdd.h, with a demo at core/vdd-demo.cc and fuller instructions in docs/VDD_LIBRARY_USAGE.md. Expect to see a new display appear in Windows display settings once the app or your program has added it and is pinging.

HDR is off the table, and the EDID is not yours to edit

The README's known limitations section opens with HDR, and it is blunt. Parsec VDD does not support HDR on its displays. The theoretical workaround is editing the EDID to include HDR metadata and a 10-bit or deeper color depth, but the README states you cannot flash the driver's firmware the way you would a physical monitor, and there is no registry setting to toggle it. Every IDD carries a fixed EDID block inside the driver binary that initializes the monitor specs.

That single constraint disqualifies the project for some streaming setups. If your workflow depends on HDR capture or HDR playback end to end, a virtual display from this driver is the wrong target, no matter how well the resolution and refresh rate match. The README does not document a workaround, and it does not document rollback either, so plan your driver version choice before you install rather than after.

The ping requirement is the second hard edge. A tool that adds a display and exits will look like it worked for about a second and then leave you with nothing. Anything you build on top of this header has to own a timer and a lifetime, which is a real design cost if all you wanted was a one-shot command.

parsec-vdd compared with a general-purpose virtual display driver

The obvious comparison is a general-purpose indirect display driver such as the Virtual Display Driver project. The difference is in what the software is optimized around. parsec-vdd is built by Parsec for Parsec client-connection sessions, and the README frames the whole design around that: the app starts controlling the driver when the user connects, sends IO control codes, and keeps the displays alive with pings. Resolution and refresh rate support up to 4K and 240 Hz is described in that streaming context.

A general-purpose VDD is typically aimed at persistent monitors you configure once and forget, with the driver itself owning more of the display's life. With parsec-vdd, the controlling process owns it. If your mental model is "install a driver, get a permanent extra monitor", parsec-vdd will surprise you the first time your script ends. If your mental model is "my streaming host needs a display that matches the encoder and goes away when the session does", the ping model is the feature, not the bug.

The README also lists Sunshine/Moonlight and Steam Remote Play as supported streaming paths, so this is not locked to Parsec's own client. That matters if you are choosing a host stack and do not want the virtual display to dictate which client you use.

Licence, maintenance and what an upgrade costs you

The repository is MIT licensed, which is permissive for the code in this repo. Note the split: the driver binaries themselves are downloaded from Parsec's builds server, not built from this repository, so the MIT grant on the repository is not the whole story for what you install. Check the terms attached to the driver download if you are redistributing it inside a product.

The last push to the repository was on 2026-05-15, and the most recent release listed is v0.45.1 from 2024-04-30. The repository is not archived, but the release cadence is slow, so treat the driver version table as the thing you are really maintaining. Upgrading from 0.41 to 0.45 buys better streaming color and costs compatibility on some Windows installs, per the README's own notes. Downgrading means running the nefconw removal step again before installing the older INF, because the device node persists otherwise. Budget for that on any machine you manage remotely: a driver swap on a headless host can leave you without a display to reconnect to.

Editorial conclusion

Adopt parsec-vdd if you run a headless Windows 10 or 11 host for Parsec, Sunshine/Moonlight or Steam Remote Play and need a display target whose mode matches your encoder. Do not adopt it if you need HDR, if you want displays that survive without a controlling process, or if your host is not Windows. Before installing, check which driver build your Windows version supports (0.41 is listed as stable, 0.45 as better color but less compatible), confirm the driver node is gone with the nefconw --remove-device-node command, and decide whether the ParsecDisplay app or your own ping loop will keep the displays alive.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nomi-san/parsec-vdd on GitHub
4. README
5. Releases