ProtonUp-Qt 2.16 brings Wayland-native proton-wineland to a single click
The community Proton-fork manager adds a new compatibility tool, fixes a few annoying install bugs, and quietly rebuilds its own packaging.
ProtonUp-Qt, the free utility that Linux gamers lean on to install and juggle Proton and Wine compatibility forks, just got its biggest feature update in a while. Version 2.16.0 dropped today, and it adds support for proton-wineland, a newer, Wayland-first fork that most mainstream users couldn't reach with one click before.
It's a small tool by developer DavidoTek, but it quietly sits in the middle of how Linux gaming actually works. If you've ever grabbed a GE-Proton build by hand, untarred it into ~/.steam/compatibilitytools.d/, and hoped the folder naming matched what your launcher expected, you already know the chore this thing exists to kill.
The new release is more than the headline feature, though. Keep in mind that it also repairs a bug that left installs hanging forever, makes a niche VR fork discoverable again, and rewrites the entire way the AppImage gets built. Not cheap for a three-and-a-half-month release cycle.
A Wayland fork finally gets a front-door entry
Here's the interesting part. proton-wineland started life as "proton-cachyos-wineland," an experimental Wayland-native build rebased on the CachyOS team's Proton fork. As the Wayland patchwork grew, rebasing kept destabilizing things, so the project split off and now maintains its own Wine component, it picked up the proton-wineland name and became its own thing in the process.
Native Wayland support is arguably the single most contested front in Linux gaming right now. Valve's own Proton still defaults to the X11 path (winex11.drv); the Wayland-native winewayland.drv work came from Proton-EM and was only later absorbed as a hidden option in Proton-CachyOS. A dedicated, actively released Wayland-first Proton is a real signal that this stack is maturing, and now it lives one click away.
The PR that added it, authored by GitHub user neptuwunium, describes the new module as "almost 1:1 code to the proton-cachyos ctmod, but simplified." Worth flagging: the PR author also noted that ProtonPlus already supported wineland. The manager tools are in a friendly race to cover every new fork first, and this release is just one leg of that race.
GE-Proton 11 itself was a landmark year — a long-awaited Proton 11 rebase in June followed by seven point releases in under three months, each namedropping fixes for titles like Forza Horizon 5 and FFXIV. ProtonUp-Qt's whole job is making sure that flood of upstream releases is actually usable, so a new fork in the stable stream is a small but real convenience.
The fixes that actually get used
The headline feature draws the eye, but the install hang is the bug most people were tripping over.
GloriousEggroll's GE-Proton11-4 changed its archive's top-level folder name from GE-Proton11-N to GE-Proton11-N-x86_64. ProtonUp-Qt's "already installed" check looked at the bare version tag, so it never matched. The app then re-downloaded and re-extracted over the existing copy, and since tarball extraction opened read-only files without unlinking them first, it choked on a PermissionError deep in the NVIDIA libs and quietly hung at "Extracting…" forever. No error shown. Just an endless spinner.
The fix now recognizes the new folder layout and wipes stale files before extracting. A good, if mundane, illustration of how tightly downstream managers are coupled to upstream tarball layouts, one upstream naming decision, and half a community's installs brick.
Proton-RTSP had a better story. It was effectively invisible, buried behind the little-known "advanced mode" toggle in the About dialog. Contributor rs189 filed a bug noting plainly that he'd resorted to ProtonPlus just because ProtonUp-Qt hid RTSP, a loss he wasn't alone in feeling. DavidoTek conceded the tool was actually supported, just poorly surfaced, and the merged PR fixes the label, the download URL, and Heroic/Lutris integration while keeping the advanced-mode gate in place for now.
Then there's the Heroic launcher. Recent Heroic versions dropped the old library paths, so ProtonUp-Qt silently started listing only sideloaded games and dropped your GOG and Epic titles entirely. Contributor BeSilentBob pointed it back at Heroic's newer store_cache and legendaryConfig paths last week. Amazon store paths were left untouched, and the author admits those remain untested.
The under-the-hood rebuild worth worrying about
The quiet engineering change in this release is also the one that makes the maintainer a little nervous. The AppImage now builds through a mix of uv, Nix, and a pinned static runtime that drops the old libfuse2 requirement entirely.
That last detail matters more than it looks. Immutable Fedora spins like Kinoite and Silverblue have been dropping FUSE 2 support, which had quietly broken the previous AppImage for those users. ProtonUp-Qt's changelog warns plainly that the new build "could possibly be broken on some systems due to changed dependencies," and asks anyone hit to file an issue with console output.
That's the honest kind of warning you want from a maintainer, even if it means the flagship portable binary now runs on a fundamentally different dependency stack. There's also a new .zsync file now, so AppImage self-updates over partial transfers are finally possible.
For what it's worth, the package is roughly 57.8 MB, a meaningful jump over the previous AppImage, though still lean compared to the ~101 MiB Flatpak on Flathub. Head here for the full release note.
AI authorship, openly in the trailers
One detail that stands out in a project of this size is how openly it credits AI in its commit history. PR #636's description states it was "Co-authored by OpenCode and Claude Opus," and the squashed commits carry Co-authored-by: Claude Opus and Copilot agent trailers. DavidoTek even asked GitHub Copilot to review the PR twice before a balanced-effort review landed.
That kind of transparency is notable, and timely. Flathub only recently reversed its ban on AI-generated apps in favor of a disclosure requirement, and GE-Proton itself drew similar community heat when GloriousEggroll disclosed AI help in its June release notes. ProtonUp-Qt's unredacted trailers make it a live case study rather than a theory.
Where to get it
Install Flathub first, the Flatpak update typically lands a few days after the AppImage, or grab the direct download and run chmod +x if you'd rather run the containerized binary straight away. If you're on an immutable Fedora and something breaks, the maintainer wants the console output in a new issue, not a comment thread.
It's a fairly efficient release for the effort. The headline feature lands, the worst install hang gets fixed, and the packaging gets modernized, even if the rebuilt AppImage asks you to keep an eye out on the more exotic desktops. If you manage more than a couple Proton forks, 2.16.0 is worth the update.
