How to Manage Linux Games with Lutris 0.5.22

Lutris 0.5.22 is a timely way to tidy up a Linux game library that has outgrown a single store. The open-source game manager’s February 2026 release added a small but meaningful set of platform and runner improvements: Steam Family and ZOOM Platform sources, an Azahar runner, updated emulator runners, Wine’s native Wayland driver option, and a Proton workflow that uses Proton-GE through umu by default. The 0.5.22 follow-up also fixed Python compatibility issues and updated release targets. This is not a new game; it is a practical release for players who want one launch point for native Linux games, Windows titles, emulators, and older software.

The official project homepage is lutris.net. It describes Lutris as a video-game preservation platform: a place to keep collections playable across hardware generations by combining open-source compatibility layers, emulators, and engine reimplementations. That framing matters. Lutris is not a replacement for Steam, GOG, or your emulator; it is the library and installation layer that can organize them.

Why Lutris 0.5.22 matters

The headline changes are about coverage rather than a radically redesigned interface. Steam Family support lets shared games appear alongside the rest of a Steam library. ZOOM Platform adds another source for DRM-free and classic PC games. For emulation, Azahar joins the runner list, while existing TIC-80, EasyRPG, mGBA, Rosalie’s Mupen GUI, Ruffle, 86Box, Dolphin, and other components receive updates across the release series.

Windows-game users get the most interesting infrastructure changes. Lutris can use Proton-GE launched through umu as the default for its Wine runner, letting umu handle Proton-GE updates instead of treating a manually downloaded compatibility build as a permanent file. The release also passes Esync, Fsync, and DXVK choices through to Proton and enables DXVK’s integrated D8VK path in Proton. On Wayland desktops, the Wine runner exposes an option for Wine’s native Wayland driver.

These features are not a guarantee that every game works. Anti-cheat, launchers, codecs, copy protection, GPU drivers, and game-specific patches still decide compatibility. The useful change is that the choices are easier to manage per game, and the same library can contain native, Wine, Proton, and emulator entries without forcing you to remember a separate launch command for each.

Install Lutris safely

The official downloads page recommends Flatpak for a self-contained installation:

flatpak install flathub --user -y net.lutris.Lutris

Launch it with:

flatpak run net.lutris.Lutris

Flatpak is a sensible first choice if you want the current application without mixing a third-party repository into your base system. It also avoids installing every Wine and driver prerequisite into the host just to start the client. The trade-off is that sandbox permissions can affect access to external game libraries, removable disks, or helper tools. If a library is on another filesystem, review the Flatpak permissions rather than assuming a missing game is a Lutris bug.

On Ubuntu, Elementary OS, and Linux Mint, the project provides a .deb through GitHub releases. Fedora has Lutris in its official repositories:

sudo dnf install lutris

Arch Linux and Manjaro users can use the Arch Extra package:

sudo pacman -S lutris

The official downloads page lists additional instructions for Debian, openSUSE, Solus, Clear Linux, Mageia, Gentoo, CentOS, and Slackware. Prefer those instructions to a random install script. If you install the tarball or run from source, do not use setup.py install; upstream warns that it does not fully install Lutris and makes removal difficult.

Before installing Windows games, update the graphics driver and confirm Vulkan works. Native Linux games and emulators have different requirements, but Wine and Proton titles generally need a working 64-bit Vulkan stack. On a laptop with hybrid graphics, test the GPU selected by the game before diagnosing Lutris itself.

Connect libraries without losing control

At first launch, treat integrations as optional. You do not need to connect every store. Add only the services you use, then allow the client to import the relevant entries. The official documentation says that a linked Lutris account stores a token rather than your login credentials; the token is kept at ~/.cache/lutris/auth-token for a traditional installation. Flatpak paths differ, so use the sandboxed application’s information when auditing files.

Steam remains the easiest first test because its library metadata is familiar. Steam Family is especially useful if shared titles have been invisible in a manually maintained launcher list. ZOOM Platform support is more interesting for preservation-minded users: it gives DRM-free and classic titles another place in the same interface. Check ownership and installer provenance for each source; Lutris can automate an installation, but it does not turn a store purchase into a universal license.

For manually added games, supply the executable and working directory deliberately. Keep game data in a predictable location such as ~/Games or a dedicated mounted library. Avoid scattering prefixes and installers across temporary directories. A clean layout makes backups, migrations, and troubleshooting much easier.

Choose the right runner

A runner is the piece that launches a game. The Linux runner handles native executables. Wine and Proton translate Windows APIs, while emulators handle console and computer software. Lutris’ central value is letting each entry use an appropriate runner and a separate configuration.

For a native Linux game, start with the Linux runner and do not add Wine just because Lutris offers it. For a Windows game with a known Proton community configuration, try Proton-GE through the normal Lutris workflow. Let umu manage the Proton-GE build when the release offers that path. For an older Windows title, a Wine runner may be more predictable than Proton. For a console game, install the matching emulator runner and verify that firmware and BIOS files come from a lawful source.

Do not change five variables at once. If a game fails, record the runner version, GPU, desktop session, and launch log. Then change one setting—runner build, DXVK, synchronization mode, or a launch option—and test again. This turns a mysterious “doesn’t launch” problem into a reproducible configuration.

A practical first setup

1. Install Lutris from Flatpak or your distribution’s supported package.
2. Open the runner manager and install only the runner families you need.
3. Add one native game or a DRM-free title as a baseline.
4. Import one store library, then verify a single game before importing everything.
5. For a Windows game, select a current Proton-GE or Wine build and keep the per-game settings close to defaults.
6. Create a desktop or Steam shortcut only after the game launches reliably.
7. Back up the game files, prefixes, installers, and Lutris database before moving to another disk.

When a game is missing, first check its source filter and hidden-games view. Recent Lutris releases added controls for hiding a source’s games from the main Games view, and 0.5.22 supports transparent custom banners and cover art. A missing tile can be a view setting rather than a failed import.

Troubleshooting on Linux

If Lutris opens but a game does not, run it with debug output where appropriate and inspect the game log. Confirm the executable path, working directory, and prefix architecture. Then check Vulkan with your distribution’s tools and make sure the game is using the intended GPU. On Wayland, test the native Wayland driver only after the default path works; it is a useful experiment, not a universal performance switch.

For Flatpak, inspect permissions when the client cannot see a library. For a package installation, check that Wine, 32-bit graphics libraries, and Vulkan components match your distribution’s recommendations. Avoid copying random DLLs into a prefix from forum posts. Such fixes can mask the real dependency problem and make future updates harder.

Keep the collection portable

Lutris keeps configuration, runner, and game metadata in user directories, but the exact locations depend on packaging. Before migrating, identify the game files, prefixes, installers, saves, pga.db, and any custom media. Close Lutris before copying. Preserve paths where possible, or use the client’s import and configuration tools instead of editing YAML or SQLite by hand.

The best reason to try 0.5.22 is not the version number alone. It is the combination of library sources, more runners, and better Proton plumbing in a single open-source client. Start with one game, keep the runner choice explicit, and let Lutris become a searchable inventory rather than another layer of unexplained magic. For Linux players with mixed libraries, that is a useful upgrade in workflow even when individual games still need individual testing.