# wine-wayland: running DX9, DX11 and Vulkan games on pure Wayland

> wine-wayland is a Wayland display driver that lets Wine and DXVK run DX9, DX11, DX12 and Vulkan games without an X server, aimed at Arch and Manjaro users on AMD hardware who want to remove X11 and 32-bit libraries from their machine. It is a good fit for a Vulkan driven game on a wlroots or Weston compositor, and it does not work for anything that needs OpenGL or GDI.

**varmd/wine-wayland** — Wine-wayland allows playing DX9/DX11 and Vulkan games using pure wayland and Wine/DXVK.

- Repository: https://github.com/varmd/wine-wayland
- Stars: 856 · Forks: 15
- Language: C
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/varmd-wine-wayland

## A Wayland display driver that replaces the X server

The README opens with the definition. wine-wayland allows running DX9, DX11, DX12 and Vulkan games using pure Wayland and Wine/DXVK.

That last pair is doing the real work in the sentence. Wine is what executes the Windows binary, DXVK translates Direct3D calls into Vulkan, and this project supplies the display driver that lets the Wine stack present its windows through Wayland instead of asking for an X server. The result is a Windows game running in a Wayland session with no Xwayland in the middle.

The interesting part is what that removes. Wine's usual behaviour on a modern desktop is to run inside Xwayland, which means the machine still carries an X server, X11 client libraries and, for 32-bit Windows binaries, a whole set of 32-bit X11 packages.

The project is C code and the repository layout backs up the description of it as a driver. There is a winewayland.drv directory for the driver itself, a shims directory, a patches directory, a wineland directory holding the launcher and its web interface, and a PKGBUILD for the Arch package.

The audience is narrow and specific: a Linux desktop user who has decided that X11 should leave the machine, and who still wants to play Windows games.

## The motivation list is about removing X11, not about speed

The README gives five reasons for using wine-wayland, and reading them together clarifies the intent.

The first is being tired of dealing with X11 and not caring about launchers. The second is wanting to remove X11 related packages from the computer. The third is wanting to experience potentially faster and smoother gaming on Wayland. The fourth is being concerned about insecure X11 games that can spy on other apps running on X11. The fifth is wanting to remove all the lib32 packages while still being able to play most 32-bit games. The sixth is wanting a launcher that does not require GTK, QT or Electron.

Only the third claim is about performance, and it is hedged with potentially. The rest are about removing surface area from the system: fewer packages, fewer compatibility layers, and a smaller trust boundary for games that could otherwise read other applications running on the same X server.

That security point deserves a second look. The concern is specific and legitimate in shape: a Windows game running through Wine under Xwayland has access to the X server, and an X server by design lets clients observe other clients. Moving the presentation layer to Wayland changes that relationship.

The launcher requirement is the one that shapes the rest of the project. A launcher written in GTK, Qt or Electron would reintroduce exactly the kind of dependency stack the user is trying to escape, so wineland is built to avoid all three.

## The supported configuration list is short and honest

The requirements section lists four lines, and every one of them is a real constraint rather than a formality.

The operating system is Archlinux or Manjaro with Linux 6.14 or later. The graphics requirement is an AMD GPU with Vulkan and Wayland support and at least 4GB of VRAM, with Intel not tested. Mesa must have Wayland and Vulkan support. The compositor must be Weston based, tested on wayward, or wlroots based, tested on sway, with Gnome not tested.

The GPU line explains a lot about the design. DXVK translates Direct3D into Vulkan, so the driver path is Vulkan from end to end, and the tested hardware is the stack where that is known to work. The note that Intel is not tested tells you the project has a working configuration and an untested one, which is different from a project with no configuration at all.

The compositor list is the sharpest limit. A Weston based compositor, and a wlroots based one such as sway, are named as tested. Gnome is named as not tested. Since Gnome is the most common default desktop for many Linux users, this is the first thing to check, and it is the requirement most likely to end an evaluation before any installation happens.

## Three ways to install, including a launcher that installs nothing system wide

The launcher route is the interesting one. From version 6.11 it is possible to install only the wineland launcher without installing wine-wayland. The launcher then downloads wine-wayland, dxvk and mangohud from GitHub and runs games without a system wide installation of wine-wayland.

That reverses the usual order of trust. Instead of the system owning the Wine stack, the launcher fetches what a given game needs into its own directory.

Installing the launcher itself means downloading the package from the releases page and installing it with pacman.

```bash
pacman -U wineland*pkg*
```

The full package is downloaded the same way, and the README describes it as 64-bit only.

```bash
pacman -U wine-wayland*pkg*
```

If you want 32-bit games as well, the optional 32-bit package is installed alongside the 64-bit one.

```bash
pacman -U *wine-wayland*pkg*
```

Building from source is the same package recipe run locally, with makepkg doing the work and pacman installing the result, and a 32-bit build is a separate invocation with an environment variable set.

```bash
WINE_BUILD_32=1 makepkg
```

## A game needs a wrapper folder with a lowercase, space free name

Setting up a game through the launcher is a short sequence, and the one rule that trips people up is the naming requirement.

The wrapper folder holds the game, DXVK, Wine and the logs, and it is created under the launcher's data directory.

```bash
mkdir -p ~/.local/share/wineland/your-game
mv YourGameFolder ~/.local/share/wineland/your-game/
```

The name has to be lowercase with no spaces, and the README gives the Subnautica case as the example, where the folder is subnautica. Get that wrong and the launcher will not find the entry.

Inside the launcher you click the blue joystick icon, then Edit on the card for your-game, enter the game name, the exe path in the form YourGameFolder/game.exe, and add -EpicPortal to the game options for Epic Games Store titles. MangoHud and other options can be set on the same screen. After Submit, you click Launch.

Once a game is configured, it can be launched from a terminal, which is useful when you want to see the output rather than the web interface.

```bash
wineland your-game
```

For troubleshooting, the README points at the log file inside the game folder, and for a game that refuses to start it suggests running wineserver -k and starting again, or clicking Launch again in the launcher.

## Cursor handling is what the environment variables are for

Wine under Wayland has a well known set of small annoyances with the pointer, and the README documents the switches for each of them rather than leaving you to guess.

If a game is not starting or there is no keyboard and mouse focus, the answer is to ask for the Vulkan only path.

```bash
export WINE_VK_VULKAN_ONLY=1
```

To hide the cursor in games that do not hide it themselves, for example when a controller is in use, there is a dedicated variable. A second one disables cursor locking for games that erroneously try to lock the mouse cursor, and a third enables cursor grab automatically in fullscreen.

```bash
export WINE_VK_HIDE_CURSOR=1
export WINE_VK_NO_CLIP_CURSOR=1
export WINE_VK_FULLSCREEN_GRAB_CURSOR=1
```

There is also a variable to put a game into fullscreen without pressing F11, and one to enable FSR. The README's notes on FSR are specific and worth reading before you chase a performance problem: disable any in-game fullscreen option, set the resolution lower than the monitor's resolution, and disable dynamic resolution options, then restart the game.

Cursor size and theme are set with the usual XCURSOR_SIZE and XCURSOR_THEME variables, and there is an experimental custom cursor option that disables size and theme when enabled.

Three keyboard shortcuts cover the manual cases: F11 for fullscreen, F10 when a game fails to restrict the cursor properly, and F9 for games such as No Man's Sky that draw their own cursor and need the pointer locked.

## No OpenGL, no GDI, and no declared licence

The caveats section is two lines long and both of them are structural.

No GDI apps support, though popups and simple launchers should work. And no OpenGL.

The second of those is the bigger constraint, because a great deal of Windows software, and a fair number of older games, expects an OpenGL context that DXVK does not provide. The first is more contained but still bites in the places the project already anticipates, since launchers are exactly the kind of small GDI utility that people expect to work.

The README also lists the games confirmed working, which is a long list including Subnautica, Civilization VI, Stellaris, Crusader Kings 2, Warframe and Path of Exile, with per-game notes such as adding -force-d3d11 for Ziggurat 1 and installing the bundled OpenAL32 for Dirt 3 since 7.21.

There is one licensing gap to flag. No licence is declared for this project, and the repository root holds a PKGBUILD, patches and the driver sources without a LICENSE file. That matters more than usual here, because the repository is a set of patches and shims against Wine, and the legal position on redistributed Wine components and DXVK is not something the README addresses. If you plan to distribute a package built from it, resolve that question first rather than assuming the permissive terms of the projects it wraps.

On maintenance, the last push to the repository was on 2026-05-12, and the latest release tag is v11.8.6 from the same day, with an earlier v10.5.3 from 2025-04-11 and v9.3.4 from 2024-03-02.

## Conclusion

wine-wayland suits an Arch or Manjaro user on an AMD GPU with at least 4GB of VRAM who wants to delete X11, the X11 libraries and the 32-bit package set and still play Vulkan backed Windows games, and the requirement list is short enough to check in a minute. It does not suit a machine with an Intel GPU, a Gnome session, or a game that depends on OpenGL or GDI, since the README states those gaps plainly. Before you install anything, confirm your compositor is Weston based or wlroots based, check that your Mesa build has Wayland and Vulkan support, and read the caveats section, because no GDI application support and no OpenGL are structural limits of the approach rather than bugs to be filed.

## FAQ

### What hardware does wine-wayland require?

The README lists Archlinux or Manjaro with Linux 6.14 or later, an AMD GPU with Vulkan and Wayland support and 4GB or more of VRAM with Intel not tested, Mesa with Wayland and Vulkan support, and either a Weston based compositor such as wayward or a wlroots based one such as sway, with Gnome not tested.

### How do I install the wineland launcher?

Download the package from the releases page and install it with pacman -U wineland*pkg*. From version 6.11 the launcher can run games on its own, downloading wine-wayland, dxvk and mangohud from GitHub without a system wide installation.

### How do I set up a game with wineland?

Create a wrapper folder under ~/.local/share/wineland with a lowercase name and no spaces, move the game folder into it, then add the game in the launcher with the exe path in the form YourGameFolder/game.exe. You can then start it with wineland your-game from a terminal.

### Does wine-wayland support OpenGL games?

No. The caveats section lists no OpenGL, and states that GDI applications are not supported, although popups and simple launchers should work. The project targets Vulkan backed titles through DXVK.

### What can I do if a game does not start?

The README suggests running wineserver -k and starting again, or clicking Launch again in the wineland launcher, and setting WINE_VK_VULKAN_ONLY=1 if the game is not starting or there is no keyboard and mouse focus. Logs are at your-game/log.log inside the wrapper folder.

## Sources

- [Issues](https://github.com/varmd/wine-wayland/issues)
- [README](https://github.com/varmd/wine-wayland/blob/master/README.md)
- [Releases](https://github.com/varmd/wine-wayland/releases)
- [varmd/wine-wayland on GitHub](https://github.com/varmd/wine-wayland)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/varmd-wine-wayland