Building Virtual Displays on Linux with EVDI

Ever needed a screen that doesn't physically exist? Maybe you're building a remote desktop tool, a screen-sharing utility, or something that needs to capture what's being drawn on a display. On Linux, that's not something you can just conjure up from userspace. EVDI (Extensible Virtual Display Interface) is a kernel module that gives you exactly that: a virtual display you can add, remove, and pull screen updates from.

What It Does

EVDI is a Linux kernel module that enables management of multiple screens, letting userspace programs take control over what happens with the image. In practice, it's a virtual display you can create on demand and receive screen updates for, all from within an application that uses the libevdi library.

The project ships source for two main pieces: the evdi kernel module itself and libevdi, a wrapper library that applications use to send and receive information from the kernel module. There's also pyevdi, a Python wrapper for libevdi, if you'd rather work in Python. Because EVDI is a driver compatible with the standard Linux DRM subsystem, the displays it creates can be controlled with familiar tools like xrandr or the display settings applets in Unity, Gnome, and KDE.

Why It's Cool

It slots into the DRM subsystem like a normal display. This is the detail that makes EVDI practical. You don't need special tooling to configure the virtual screen—your existing display management tools just work with it. That lowers the barrier for anyone building on top of it.

You get both a kernel module and a userspace library. The split means the heavy lifting happens in the kernel (where display management belongs), while your application talks to a clean wrapper API. DisplayLink's own user mode driver uses this same arrangement to send and receive information from the kernel module.

Python is a first-class option. The pyevdi wrapper means you can spin up virtual displays from a Python script rather than wrestling with C bindings yourself. For prototyping or scripting, that's a real convenience.

The project is honest about its limitations. The README is upfront that EVDI isn't a complete driver for DisplayLink devices—it needs the driver for full functionality. It also notes that communication between the kernel module and libevdi isn't access-controlled or authenticated yet, and flags that as a future enhancement. That kind of transparency is refreshing.

Packaging is handled across distros. EVDI ships as a deb package or standalone installer paired with the DisplayLink driver on Ubuntu. Beyond that, a community-driven GitHub project generates RPM packages for Fedora, CentOS Stream, Rocky Linux, and AlmaLinux, and there's an AUR package for Arch users. You're not stuck on one distribution.

How to Try It

1. Check your kernel version. The minimum supported is 4.15. DisplayLink has verified the module compiles and works with Ubuntu variants of kernels up to 6.15, though other distributions or newer kernels may need extra development work.

2. For detailed installation instructions, refer to module/README.md in the repository.

3. If you want the full DisplayLink experience, grab the latest deb package or standalone installer from the DisplayLink downloads page—just remember EVDI alone won't drive DisplayLink hardware.

4. Once installed, you can control virtual displays with standard tools like xrandr, or create them programmatically with pyevdi.

5. For API details, the libevdi documentation lives at displaylink.github.io/evdi.

The source and full instructions are at github.com/displaylink/evdi.

Final Thoughts

EVDI is a focused piece of infrastructure rather than a turnkey product—it's aimed at developers building display-related tooling who need a virtual screen primitive on Linux. If you're on Ubuntu and using DisplayLink hardware, the packaged path is straightforward. If you're on another distribution, the community packaging efforts help, but you may hit kernel compatibility snags. The maintainers explicitly welcome help ensuring EVDI works beyond Ubuntu, so if you run into issues on Fedora or Arch, that's a contribution opportunity rather than a dead end. It's a solid foundation, and the project's roadmap (authentication for the kernel-library channel, among other things) suggests it's still evolving.

Follow @githubprojects for more developer tools and open source projects.