Feature Request

An alternative Proton using Wayland would be excellent to test and get useful feedback, without jeopardize those who don't use Wayland yet.

Maybe this could also help in some way with Gamescope.

https://github.com/varmd/wine-wayland/

Wine Wayland support PR is in review step by step. Now there is part 2.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2476

Onto phase 3
https://gitlab.winehq.org/wine/wine/-/merge_requests/2712

part 4
https://gitlab.winehq.org/wine/wine/-/merge_requests/2944

Part 10.3, vulkan only presentation
https://gitlab.winehq.org/wine/wine/-/merge_requests/4522
And mouse look support
https://gitlab.winehq.org/wine/wine/-/merge_requests/4593

Both of these appear to have landed for 9.0-rc1

This comment outlines the features still missing.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4522#note_54220

Could someone consider making a fork like Proton-ge for people that want to try it in the meantime but don't feel like Wine compiling from source? Could also be good for getting more people using the driver and finding bugs, I don't think it's ready to upstream though for sure but it seems it's at the point where it's usable for some games

There isn't keyboard input yet, i'd wait until that's merged before people should even bother testing honestly.

well already done just test it

Proton 9 beta is already out and it seems to lack winewayland.drv at all. Why not turn it on? I understand that things like launchers are broken right now in wayland, it's not suitable for everyone, but still people want to test and play games in wayland native environment plus it might help nvidia users, just hide it under some PROTON_WAYLAND=1 variable.

Proton 9 beta is already out and it seems to lack winewayland.drv at all.

Which is kinda sad. It’s the one feature I was looking forward to.

I agree that it should at least be available to the user to enable if they want to. I've been testing Wine 9 with the Wayland driver for the past couple months, other than some quirks and issues with launchers and keyboard/mouse inputs, it works great for rendering and displaying games in a smooth manner. A PROTON_WAYLAND=1 variable like stated above would be great.

would absolutely love to see this added to proton 9, its a pain using tkg proton to use the wayland driver because you have to go into the registry editor for each game to enable wayland

@zeak-z
Are you building your own proton-tkg or using the ones available on proton-up qt

This exists, I got it working with some registry edits. Seems fairly stable if the same launches with it, some don't and just crash or don't make a window, also no mouse input only keyboard or controller and cursor uses default GTK light theme. Oh yeah, and mangohud or the Steam FPS overlay doesn't work so I have no idea how well it's running, but seems the same as XWayland. Also I wouldn't report bugs upstream to Wine it's a month out of date now
https://github.com/Melechtna/Proton-with-Wayland

… why would I run some random person’s build when nothing works with it?

@zeak-z Are you building your own proton-tkg or using the ones available on proton-up qt

proton-up qt, i just wish it didnt require registry editing each game...

Has anyone suggested just making it a environment variable to up stream Wine?

… why would I run some random person’s build when nothing works with it?

Because, it has Wayland support. Duh, I wasn't aware that proton-tkg had it enabled

FWIW if anyone wants to build 9.0 you have to add the --with-wayland flag to the wine build config (the easy part), but you first need to build a custom proton SDK with libxkbregistry included and follow the steps here to add the lib to your runtime https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/slr-for-game-developers.md#running-in-a-modified-platform-or-sdk-environment. Unfortunately I tested risk of rain 2 which ran fine but refused to use the mouse at all, and the CS2 workshop tools which failed on CSwapChainVulkan::CreateSwapChain->SDL_Vulkan_CreateSurface->vkCreateWin32SurfaceKHR but rendered the UI correctly besides the viewports.

… why would I run some random person’s build when nothing works with it?

Because, it has Wayland support.

It has no working mouse. Like, wat.

@alterNERDtive You're not being constructive. This repo IS the current state of wayland in proton. It's not in 9.0 because that's the current state of wayland in proton. If that doesn't work for you, don't use it and wait until it gets a more complete implementation. If you want to get involve, you can test it, identify the reasons why some things are not working and help. That repo is meant for development and testing, not for day to day use. When it's gonna be ready for day to day use, it's gonna be advertised as so.

Wine Wayland has working mouse support.

@alterNERDtive Maybe, but not proton. Wine is a different project. I opened this issue so we can discuss about the plans and the progress, not to ask "when is done?" or "why not done?". It's actually nice there exists a repo with a wayland implementation in progress. If you wish, I can ping you once wayland support is more to the beta level and ready to try, where some games gets actually playable. Other than that I would like to keep this discussion for constructive and helpful comments only. Thank you for understanding.

Replying to https://github.com/ValveSoftware/Proton/issues/4638#issuecomment-1964659764

were did you get libxkbregistry? the steam runtime proton sdk seems to be based off a version of ubuntu / debian that does not have a version of libxkbregistry

Replying to [#4638 (comment)](https://github.com/ValveSoftware/Proton/issues/4638#issuecomment-1964659764)

were did you get libxkbregistry? the steam runtime proton sdk seems to be based off a version of ubuntu / debian that does not have a version of libxkbregistry

You have just have to add it to the SDK's dockerfile package installation list here: https://github.com/ValveSoftware/Proton/blob/1ef9a3674bae0e50ece8b8d074fc76ae94dacb82/docker/proton.Dockerfile.in#L54

Just add libxkbregistry-dev and libxkbregistry-dev:i386 to the list of packages there and build the SDK. Then when that is finished it can be used for compiling proton. Then to add the libraries to the runtime export the docker image and copy the libraries into the runtime.

@PeakKS btw did you have to do modify anything for steam runtime on the local system? I can launch proton with wayland but if it runs inside the steam runtime then it can only use Xwayland same thing happens if i launch system wine inside steam runtime as well

I would love to see experimental Wayland support (preferably behind an env var like PROTON_WAYLAND=1).

nVidia users could really benefit from this because nVidia is refusing to implement implicit sync.

I get that it's gonna be buggy but as long as it's locked behind an experimental option that shouldn't be an issue right?

The wayland features are included in wine 9.5. They seem to work pretty well for playing Star Citizen on Wayland with an Nvidia card.

I would love to see experimental Wayland support (preferably behind an env var like PROTON_WAYLAND=1).

nVidia users could really benefit from this because nVidia is refusing to implement implicit sync.

I get that it's gonna be buggy but as long as it's locked behind an experimental option that shouldn't be an issue right?

I feel like Wine should have this upstream instead of just Proton, having to edit a registry file is rather annoying. I would prefer if I could just set something like that system wide, that would just leave Krita and Steam in XWayland I guess

When fractional scaling is enabled on GNOME, all XWayland windows are blurry due to scaling. That's one issue the Wayland driver for Wine would fix.

Another great reason for this - a decent few Wayland compositors such as Hyprland-via-aquamarine, wlroots-based compositors, and GNOME and COSMIC soon, moving over to in-built HDR, colour management, and wide gamut colour profile handling. Using a native Wayland driver would let this be much more easily communicated just using Proton, without the need to run a micro-compositor like Gamescope, and a few registry changes per Wine prefix for about a hundred games in a library, just to communicate HDR to all of them. That along with the fact that XWayland just downright causes issues regarding blur, flicker, stuttering, box shadows and more, within Wayland environments, mentioned previously, would be a decent backing as to a native Wayland driver.

Wine 10.0 stable is coming out this week with the wayland driver on by default (simply by unsetting DISPLAY on Wayland+Xwayland systems or running a pure wayland session), which means Proton 10 might be the time to finally bring-up wayland support.

I've finished so many games to 100% completion using Wine exclusively with the Wayland driver, since Wine 9.0 release candidates. I can confidently say that other than some edge case scenarios, most notably launchers being broken (see [wine bug #57635](https://bugs.winehq.org/show_bug.cgi?id=57635)) and some games with intro videos refusing to play (see Spider-Man Remastered bug), it's perfect for playing games. It's ready for prime time in my opinion.

The keyboard and mouse input issues (inputs not registering or not having mouselook) have been fixed, at least in the dozen or so FPS games I tried. So that's not an issue like back in 9.0-rc1 times.

At the very least, Wine should be built using --with-wayland and include winewayland.drv. It could be behind a PROTON_WAYLAND=1 env variable if need be. But it should be included for sure.

More than a year of testing experience here, from 32-bit to 64-bit games, DX9 to DX12.

The keyboard and mouse input issues (inputs not registering or not having mouselook) have been fixed, at least in the dozen or so FPS games I tried. So that's not an issue like back in 9.0-rc1 times.

I've been testing the Wayland driver a lot lately and can confirm that most of the time it works. The biggest issue I see is with MMOs that use the hold right click and move mouse to rotate the camera. This shows https://bugs.winehq.org/show_bug.cgi?id=57430 on KDE and Gnome Wayland and potentially https://bugs.winehq.org/show_bug.cgi?id=57448 (not my reported issue).

The biggest issue I see is with MMOs that use the hold right click and move mouse to rotate the camera. This shows https://bugs.winehq.org/show_bug.cgi?id=57430 on KDE and Gnome Wayland and potentially https://bugs.winehq.org/show_bug.cgi?id=57448 (not my reported issue).

Well, I'm literally playing World of Warcraft Classic right now, I'm typing Alt+Tabbed out of the game. Everything mouse related works, can hold right click and move, or hold left click and look around while moving. GNOME 47.3 on Wayland, Wine 10.0-rc6.

I do not have a WoW subscription right now. I can confirm the issue for Guild Wars 2 on 10.0-rc4 on my system - if you have a bit of disk space and fast connection would you mind testing it with GW2 (it's free)?

EDIT: Just tested with a WoW trial and it shows the same issue on my system - Fedora 41, Gnome 47.3 Wayland, Wine 10.0-rc4, AMDGPU (mesa stable) started through Lutris or starting purely native with a clean prefix. I'll look into this - maybe it's related to scaling / VRR / ...

Do Valve people who are responsible for Proton even read these threads? What is the point of this issue tracker existing?

Really hoping to at least get the option to use the wayland driver soon. My system has been having major performance issues with Xwayland ever since the 565 nvidia drivers, and my only option is to use gamescope, which sadly doesn't work perfectly for some games

Having recently moved back to Sway, and wlroots-based WMs, Wayland support is in dire need, given how haphazard and unsafe it is to run rootless XWayland sessions in any case, and also the support for X11 and XWayland is dropping rather fast anyway. With how the general community has been moving towards Wayland due to X11 development stagnation, hopefully we'd actually see some development. Has anyone tried running Proton-GE with Wayland enabled recently, does that still work, or was it patched out the same time that Valve patched Wayland support from their Proton implementation?

Has anyone tried running Proton-GE with Wayland enabled recently, does that still work, or was it patched out the same time that Valve patched Wayland support from their Proton implementation?

Not Proton-GE specifically, but CachyOS Proton includes an option to use Wayland. Overall:

• Many games have issues with mouse input; not a problem if you're on gamepad
• Frame pacing and latency seem to be better (going by feeling alone), but framerate in the worst case can take a hit up to 10%
• Many games used to quickly hang on Nvidia, but the 575 drivers (currently in beta) include a fix for that
• This should go without saying, but steam overlay does not work

All in all, currently it's great for single-player latency-sensitive games that you control with a gamepad; wider use requires further improvements. Let's hope Proton 10 brings some!

Small addition: in exceptional cases I've seen gamepad (Radiant Silvergun) and audio (Riven) break as well. No idea what these games do differently.

Another release without either WoW64 prefix mode nor native wayland driver.
I'm giving up

What's the status of this issue with Proton 10 beta 1? I couldn't find anything in the changelog :(

Another release without either WoW64 prefix mode nor native wayland driver. I'm giving up

I believe that the Wayland driver for Wine currently doesn't offer the same level of usability as the X11 driver.

I believe that the Wayland driver for Wine currently doesn't offer the same level of usability as the X11 driver.

That doesn't matter. Nobody asks to make the Wayland driver enabled by default. Just make it available to be enabled by some kind of environment variable of registry key.

Assuming valve haven't made any changes to wine, the wayland driver is enabled in wine 10 by default, you can use it with an environment variable (DISPLAY=0) but from my testing it doesn't look like I can run any games with that set

Assuming valve haven't made any changes to wine, the wayland driver is enabled in wine 10 by default, you can use it with an environment variable (DISPLAY=0) but from my testing it doesn't look like I can run any games with that set

Trying to enable wayland in regedit also doesnt work so far either, proton just ignores it or instantly closes, valve must have disabled both of these ways of enabling it

valve must have disabled both of these ways of enabling it

They probably just disabled the Wayland driver at build time.

The issue in pressure vessel:

pressure-vessel-wrap[54296]: W: No colon found in DISPLAY=

valve must have disabled both of these ways of enabling it

They probably just disabled the Wayland driver at build time.

Not nice

I'm hoping, that at the very least when a GloriousEggroll -version of this Proton 10 appears, it will finally have the Wayland-driver included. This is getting so frustrating. XWayland is frankly unusable in many situations, especially when I have monitors of different scaling on wlroots, which already makes XWayland difficult to use (I need to use a very specific patched version of wlroots to make this all work)...

This simple fact forces me to play half of all the games I play on gamescope and with cursor forcibly locked onto the screen, which in turn makes playing videogames cumbersome with two monitors. Especially when the clipboard between gamescope and wlroots doesn't even work (it's not implemented), so I can never paste anything out of the game, or into it!

I would love to test-drive Proton with a Wayland driver for the games which would require gamescope for me, maybe even try to figure out workarounds to make it work for me, but Valve seems to be insistent on making it borderline impossible.

You can just download the latest build from https://github.com/Frogging-Family/wine-tkg-git/actions/workflows/proton-arch-nopackage.yml, unpack it into ~/.steam/root/compatibilitytools.d or the equivalent for flatpak, and then restart steam.

You can just download the latest build from https://github.com/Frogging-Family/wine-tkg-git/actions/workflows/proton-arch-nopackage.yml, unpack it into ~/.steam/root/compatibilitytools.d or the equivalent for flatpak, and then restart steam.

Thanks! This seems to still run XWayland for me somehow. Is there anything else I need to do to force Wayland native?

You have to prepend DISPLAY= to the launch options.

Putting my two cents here again, as I've mentioned this already twice (once this year, once last year).

I unfortunately doubt there will be any Wayland support in official Proton from Valve anytime soon, as the biggest blockers for it are other game launchers not rendering correctly (completely black) when using Wine Wayland, for example, Battle.net:

https://bugs.winehq.org/show_bug.cgi?id=57635

The same issue is present in Ubisoft Launcher too. Only EA App seems to work natively on Wayland. Have not tested Epic Games myself.

Games work great on native Wayland, that's true, I've been testing Wine Wayland since Wine 9.0 release candidates and it has only gotten better from there. I play almost all my games natively on Wayland with Proton TkG, absolutely no issues. Even NVIDIA on Wine Wayland is fixed now, with beta driver 575.51.02:

Fixed a bug that could cause the applications that use the VK_KHR_present_wait extension to hang on Wayland.

Wine Wayland also recently got clipboard and icon support in Wayland windows:

https://gitlab.winehq.org/wine/wine/-/merge_requests/7613
https://gitlab.winehq.org/wine/wine/-/merge_requests/6938

Those are really big milestones for Wayland. In my opinion, Wine Wayland is ready for prime time, except for one issue.

As Valve is trying to be an open platform and allow users to enjoy their games from other storefronts as well, Wine Wayland currently not working with the likes of Battle.net, Ubisoft Launcher, etc, is a big blocker for them, imo. This is just my speculation, but it could very well be the case.

If you want to play World of Warcraft from Battle.net on Wine Wayland, you have to click exactly where the "Play" button is, cause the launcher itself is black, but the game itself can actually run natively on Wayland, if you can find the play button...

So until other launchers work on Wayland, I'm not holding onto Valve implementing it into Proton anytime soon.

(Same can be said about NTsync, I guess we'll see once SteamOS ships with a 6.14 base and Wine side merges NTsync support as well, Proton could have NTsync too, but Valve prefers fsync currently)

Edit: Just so there is no confusion, I completely agree that winewayland.drv should at the very least be included in Proton. Maybe lock it behind a PROTON_WAYLAND=1 environment variable or something like that. So users who want to utilize it can do that.

I'm just explaining why Valve isn't enabling it in Proton. Which is the most likely reason, imo.

Again, I'm just asking for a choice, that's not hard to understand.
I don't care if wayland.drv isn't ready "for prime time" because of a few launchers or a few other issues, I don't care.
I'd like to have the native Wayland driver because I'm sick and tired of XWayland's issues.

I believe that the Wayland driver for Wine currently doesn't offer the same level of usability as the X11 driver.

No way, it's still in development and it became almost fully usable only starting from WINE 9.3.

I think it would be interesting to have the ability to test a Wayland driver in proton. Even if not selected by default, would bring many new testers and new issues could be reported.

Even if it will be a worse option for most games, it may improve the experience in some of them. Having such option enabled via an environment variable would be a great addition.

I definitely second the opinion of having the Wayland driver accessible via an envvar. I myself would be ready to do a lot of testing and reporting, since I am very excited about it. At the end of the day, the objective of this all is to get rid of one translation layer while eventually gaining in terms of raw performance, latency and features.

Opening the driver up to more users (even if it is locked behind an environment variable, same as upstream wine) would not only let the people curious to try it out actually use it, but also get more people to report issues with the driver, I 100% think valve should consider winewayland for proton 10

Those are really big milestones for Wayland. In my opinion, Wine Wayland is ready for prime time, except for one issue.

As Valve is trying to be an open platform and allow users to enjoy their games from other storefronts as well, Wine Wayland currently not working with the likes of Battle.net, Ubisoft Launcher, etc, is a big blocker for them, imo. This is just my speculation, but it could very well be the case.

A possibly even bigger issue is the lack of support for Steam overlay and all associated functionality, like screenshots and game recording - which is not even inherent to Proton itself and technically applies to any game using Wayland directly, but something that people would understandably be quite upset about stopping working after an update. Not enough of a reason to not add an environment variable toggle IMO, but something that definitely needs to be fixed before native Wayland backend could be made default.

In terms of overlay, there is a wlr_layer_unstable_v1/2 layer protocol for Wayland, that is supported by a decent few major wlroots-based Wayland WMs. Many apps already use it, from most program launchers, dmenu variants, notification centres, etc! I'm building a few mods for games privately that overlay with this protocol as such. It shouldn't be that hard, most work goes into allowing configuration of input capture dependent on the overlay design use purposes. In terms of other launchers, we have ways of embedding clients in popups, utilising things like GTK webkit, I do think that a lot of this can be done, and we could find ways to work around companies refusing to work their launchers on Linux, such as EA DRM-locked stuff, or simply implement a new term of service regarding software support, that DRMs have to support at the least browser embedding for webkit translation, to be valid, etc. However if we're talking about games that already support Wine on Linux through Xorg already, the translation to Wayland will be quite easy, from what of my experience. Wine in Wayland works quite similar to Wine on Xorg in terms of compatibility, and there shouldn't be much work required to translate it. This is my opinion, from someone who doesn't work at Valve though, so various legal complications may hinder this progress, even if I'd hope at the least anything that does support Wine should be quite easily translated over. Even anticheats work on Wayland now so, there's not much holding up the development back besides big microsoft monopoly attempting to force us all to use proprietary paid software lol~

Also, as a follow up on the screenshots and recording: we have xdg-desktop-portal to communicate secure requests, which can then go through to grim, slurp, etc to send screen cap request to the Wayland comps. For screen recording we can gpu screencast from the comp to a live stream or to a file, so that does exist as well.

In terms of overlay, there is a wlr_layer_unstable_v1/2 layer protocol for Wayland

No, Steam overlay shouldn't use any Wayland protocols at all. It should be an in-process thing, something similar to MangoHud.

Also, this protocol only works in Wlroots based compositors.

Replying to https://github.com/ValveSoftware/Proton/issues/4638#issuecomment-2842079458

I don't understand the env variabile part. It's not that the Wayland backend is default enabled in upstream wine either, you need to unset DISPLAY to make the switch. So why take the effort to revert it?
Sometimes Valve resembles those Linux geeks who just say NO without an actual reason.

In terms of overlay, there is a wlr_layer_unstable_v1/2 layer protocol for Wayland

No, Steam overlay shouldn't use any Wayland protocols at all. It should be an in-process thing, something similar to MangoHud.

Also, this protocol only works in Wlroots based compositors.

Actually it works in KWin and COSMIC as well. The only major compositor that doesn't support it is (as usual) Mutter. But that's probably a dealbreaker on it's own

Just for fairness, i post the answer ivyl gave me on the Linux Gaming Dev Discord.

No effort was taken here, it is not enabled and the Steam runtime SDK used for the build lacks some of the wayland libraries. It's also not ready for the prime time, not by far. Sadly just enabling winewayland is far from trivial due to Proton's downstream changes and SDK. It would also be a significant maintenance burden. IMO it makes more sense for us to spend dev and QA time working on winewayland upstream and other features that improve overall compatibility instead of sinking time into half-baked, disposable solutions. It's ready when it's ready and that's not now. Tinkerers will find a way in the meantime.

And if you are wondering, tkg builds both on upstream and the valve tree.
GE builds against the valve tree too, so i won't keep my hopes high there.

Replying to https://github.com/ValveSoftware/Proton/issues/4638#issuecomment-2845811100

what about WoW64?

what about WoW64?

It might be similar: the usability of Wow64 is also low. The last time I used Wow64, several games failed to start.

It might be similar: the usability of Wow64 is also low. The last time I used Wow64, several games failed to start.

In my case, last time was two years ago (and several games failed to start, plus winetricks didn't like it), what about yours?

Replying to https://github.com/ValveSoftware/Proton/issues/4638#issuecomment-2845811100

I feel like this is the most reasonable and well-explained answer in this whole thread so far. It does make me sad, but I do understand it. I frankly just wish Valve (or anyone involved in contributing in this) would put aside 10 minutes from time-to-time to actually address this here, and report on progress.

I frankly just wish Valve (or anyone involved in contributing in this) would put aside 10 minutes from time-to-time to actually address this here, and report on progress.

There is nothing to report because no one in Valve is working towards it.

I frankly just wish Valve (or anyone involved in contributing in this) would put aside 10 minutes from time-to-time to actually address this here, and report on progress.

There is nothing to report because no one in Valve is working towards it.

I don't honestly think so. At the very least they are heavily contributing on upstream wine.

I don't honestly think so. At the very least they are heavily contributing on upstream wine.

But not in wayland driver. It's all done by the Collabora guy Alexandros Frantzis.

What I don't understand is that Gamescope is based on Wayland and yet there are no efforts towards enabling Wayland in Proton.

But I'm sure they'll get to it eventually. It appears that they are currently busy getting SteamOS stable on non-Steam-Deck devices.

Last time I used the Wayland driver, I ran into some very minor issues with non-US keyboard layouts. Wine's Wayland driver is not ready to be default, but it should be made available in Proton so that all these remaining issues can be found and fixed.

Last time I used the Wayland driver, I ran into some very minor issues with non-US keyboard layouts.

FYI: https://bugs.winehq.org/show_bug.cgi?id=57097#c7 (delete if it's too off-topic)

It might be similar: the usability of Wow64 is also low. The last time I used Wow64, several games failed to start.

In my case, last time was two years ago (and several games failed to start, plus winetricks didn't like it), what about yours?

Half a year ago.

I have a proton-tkg configured with proton 10, wayland only and ntsync. Works with most games I tried (most old games don't start, though), I didn't get wow64 to run.

Please valve, X11 is deprecated and Wayland is the way to go. Most people I know use wayland (even for gaming) and you already have experience with gamescope. I can't be that hard for you.

However, great work with proton and linux gaming in general nonetheless.

I have a proton-tkg configured with proton 10, wayland only and ntsync. Works with most games I tried (most old games don't start, though), I didn't get wow64 to run.

Please valve, X11 is deprecated and Wayland is the way to go. Most people I know use wayland (even for gaming) and you already have experience with gamescope. I can't be that hard for you.

However, great work with proton and linux gaming in general nonetheless.

It's more complicated to implement Wayland support in wine and this works is already active. But take a lot of times. You can see works here https://gitlab.winehq.org/wine/wine/-/merge_requests?scope=all&state=opened&search=wayland

You can see works here

Maybe it's not completely done (it never is with Open Source software), but it's already good enough to start testing it.

Since Proton 10 with Wayland patches hit CachyOS repos, here are some news from testing:

• Mouse input issues are mostly gone; only problems I've encountered are related to scrolling
• There's still some FPS loss compared to XWayland - however, I've observed similar things with native Wayland-capable applications, so it might be here to stay outside of Proton's control
• Riven's audio now works
• Radiant Silvergun still inexplicably refuses to accept joystick input - keyboard controls now work

All in all, it's obviously still not quite there, but it's a nice improvement.

Proton GE for all of us! https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/GE-Proton10-1

Proton GE для всех нас! https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/GE-Proton10-1

Hello! I don't really understand, with the new update, is it possible to enable hdr without gamescope?

Proton GE для всех нас! https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/GE-Proton10-1

Hello! I don't really understand, with the new update, is it possible to enable hdr without gamescope?

Bro it's written, PROTON_ENABLE_HDR=1

We recently updated the HDR support in the Arch wiki to reflect the recent development changes, and have restructured it to be a lot more user-oriented. Please do check it out: https://wiki.archlinux.org/title/HDR_monitor_support.

Proton GE для всех нас! https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/GE-Proton10-1

Hello! I don't really understand, with the new update, is it possible to enable hdr without gamescope?

I don't think so!
As I just tried with Proton10-4 and:
PROTON_ENABLE_WAYLAND=1
Which is a mandatory requirement for:
PROTON_ENABLE_HDR=1
And it stops with this:
err: DxvkInstance::createInstance: Failed to create Vulkan 1.1 instance
Commenting or removing the PROTON_ENABLE_WAYLAND=1 of course doesn't stop and runs the game.
Since this is mandatory for HDR support it's pointless to have the other environment variable.
I think I will just have to wait for other updates of Proton GE.

I've got HDR working natively on wayland without gamescope, works both with proton-GE 10 and proton-TKG in wayland mode on an Nvidia graphics card (Geforce 3080, open 575-driver).

It's key to have mesa 25.1 or https://github.com/Zamundaaa/VK_hdr_layer installed because you need the VK_EXT_swapchain_colorspace and VK_EXT_hdr_metadata extensions. Otherwise wine/proton wayland will not recognize your HDR metadata, see also 2.1 Vulkan HDR WSI in the Arch documentation.

I'm currently on mesa 25.0 so I still rely on the VK_hdr_layer from Zamundaaa, so I can't tell if mesa 25.1 will work but I assume it does.

It's working well for me, too, in several different games on an AMD card, but it has a couple of problems. The biggest is that I have multiple monitors and most of the games show up on the wrong monitor and then can't be moved. The Steam overlay not working is also quite annoying, and HDR color outside of the game is really dark and simultaneously washed out in GNOME.

Replying to https://github.com/ValveSoftware/Proton/issues/4638#issuecomment-2949777866

I tested only PROTON_ENABLE_WAYLAND and it worked for a while.
Then all of a sudden it stopped working with err:vulkan:wine_vkCreateInstance Failed to create instance, res=-7
The game in question is Rocket League with DXVK under proton-ge 10.1 through 10.3 running on KDE Arch Linux / Manjaro with AMD RX 6600 XT GPU.

I tried troubleshooting what got updated that made it stop working but I haven't found any clues so far.
My first guess was that updating to proton-ge 10.4 broke it but even after rolling back to all 10.x proton-ge versions I still get the same error. I even tried switching from official mesa 25.0.5 to mesa-tkg 25.2.0_devel and still nothing.

If anyone has some troubleshooting tips I am all ears.

Replying to [#4638 (comment)](https://github.com/ValveSoftware/Proton/issues/4638#issuecomment-2949777866)

I tested only PROTON_ENABLE_WAYLAND and it worked for a while. Then all of a sudden it stopped working with err:vulkan:wine_vkCreateInstance Failed to create instance, res=-7 The game in question is Rocket League with DXVK under proton-ge 10.1 through 10.3 running on KDE Arch Linux / Manjaro with AMD RX 6600 XT GPU.

I tried troubleshooting what got updated that made it stop working but I haven't found any clues so far. My first guess was that updating to proton-ge 10.4 broke it but even after rolling back to all 10.x proton-ge versions I still get the same error. I even tried switching from official mesa 25.0.5 to mesa-tkg 25.2.0_devel and still nothing.

If anyone has some troubleshooting tips I am all ears.

Rocket league got broken for me as well in the steam deck + xwayland. Apparently for me the error is a failure to create the vkswapchainkhr object.

As a user of NVIDIA graphics cards, I've noticed that certain game launchers (such as EVE online) (most of which should be based on CEF) (of course the game itself has very good proton support) don't support hardware acceleration well, and when trying to enable wayland with the proton provided by cachyos, it can even result in the window blacking out or simply not displaying.

@zerodegress For anyone else wondering, if the launcher window is black when using the Wayland driver, use --in-process-gpu argument as launch parameter. Like SDL_VIDEODRIVER=wayland gamemoderun %command% --in-process-gpu . This fixes Battle.net, but I don't know about others. AFAIK, Ubisoft Connect is still black even with the argument.

@zerodegress For anyone else wondering, if the launcher window is black when using the Wayland driver, use --in-process-gpu argument as launch parameter. Like SDL_VIDEODRIVER=wayland gamemoderun %command% --in-process-gpu . This fixes Battle.net, but I don't know about others. AFAIK, Ubisoft Connect is still black even with the argument.

This is probably because of the lack of cross process rendering support in winewayland. (I believe this is still the case in the modern day) https://bugs.winehq.org/show_bug.cgi?id=56014#c1

Honestly, games run better and crash less for me when using PROTON_ENABLE_WAYLAND. Just wish the overlay worked in it.
AMD GPU

Can report the same with multi-monitor and Hyprland especially, it's XWayland implementation is a bit buggy to say the least and Wayland seemingly just works better now. Really wish the flag was a part of normal Proton, seems like no brainer could just set it in my configs and forget it

I've generally used gamescope for pretty much every Proton-based game for years now, but native Wayland runs so much better that I've stopped using it anywhere that I can. The only major problem is that without the overlay, Steam Input doesn't work, so any game that I use a controller with has to be played through gamescope. I've tried nesting a Wayland game inside of Wayland gamescope, but the native Wayland gamescope backend gets stuck in an infinite loop on startup and the Wayland SDL backend doesn't work on GNOME if --expose-wayland is enabled. The x11 backend does, but at that point there's not much point in the game itself using Wayland inside of a nested X server. And that still breaks anyways with specific games like HD2, which, in that game, breaks in-game purchases.

TL;DR: Native Wayland overlay support would be very much appreciated. if it's at all possible. Barring that, better Wayland support in gamescope would be a good workaround for most things.

Thanks for the suggestion, @Anuskuss, but I don't think that that'll work for my use case. I'm using a Steam Controller. Without Steam Input, it won't be customizable, and it's almost completely unusable without customization in most games. Unless I'm wrong and that'll still work.

Steam Input doesn't work, so any game that I use a controller with has to be played through gamescope

@DeedleFake i use this: https://github.com/C0rn3j/sc-controller it works fine on wayland ge-proton and you can use it even outside of steam. Very few distros have it in their repo tho

I tested last month WINE-Wayland in Proton-GE with Plasma 6.5.4 and it worked great!
What is the holdup here?
If it works in Proton-GE can't it be easily be fixed here too with the same fix or similar?

I tested last month WINE-Wayland in Proton-GE with Plasma 6.5.4 and it worked great!
What is the holdup here?
If it works in Proton-GE can't it be easily be fixed here too with the same fix or similar?

I believe that the real blockers are the Steam overlay and Steam input. If you play with keyboard and mouse it's okay, but with a controller it's a mess with wayland right now...

I tested last month WINE-Wayland in Proton-GE with Plasma 6.5.4 and it worked great!
What is the holdup here?
If it works in Proton-GE can't it be easily be fixed here too with the same fix or similar?

I believe that the real blockers are the Steam overlay and Steam input. If you play with keyboard and mouse it's okay, but with a controller it's a mess with wayland right now...

I haven't tried with a controller.
But thanks for giving me the idea to test that too!

As a lot of games run through proton rather than native Linux, for the Steam machine to properly support "out of the box" HDR which is more likely to be important to users thereof than Steam Deck users, Proton must attempt to use Wayland by default.
The Steam machine also has a deep relation to controllers (particularly the Steam Controller) so the whole Steam input controller issues will need to be fixed.

As a lot of games run through proton rather than native Linux, for the Steam machine to properly support "out of the box" HDR which is more likely to be important to users thereof than Steam Deck users, Proton must attempt to use Wayland by default. The Steam machine also has a deep relation to controllers (particularly the Steam Controller) so the whole Steam input controller issues will need to be fixed.

Steam Machine will handle HDR and controllers just fine without the Wayland driver in place.

As a lot of games run through proton rather than native Linux, for the Steam machine to properly support "out of the box" HDR which is more likely to be important to users thereof than Steam Deck users, Proton must attempt to use Wayland by default. The Steam machine also has a deep relation to controllers (particularly the Steam Controller) so the whole Steam input controller issues will need to be fixed.

Steam Machine will handle HDR and controllers just fine without the Wayland driver in place.

The steam machine is being marketed as a desktop pc. meaning you will be using the desktop mode which is in a x11 session, which means no HDR in desktop mode. the user will have to use the gaming steam mode if they want to use hdr without hassles.

Which is designed to be a console UI experience not a desktop experience. if valve wants people to buy this as a desktop pc then HDR and wine wayland need to be enabled by default and kde plasma needs to be on a newish version to provide a good HDR experience + kernel 6.19 for even better color on displays.

@pollux78 https://github.com/ValveSoftware/SteamOS/issues/2081

@pollux78 ValveSoftware/SteamOS#2081

already know this, it hasnt been enabled to my knowledge, not even in the unstable branch of steamos yet. whats the reason for linking this exactly?

Steam Machine will handle HDR and controllers just fine without the Wayland driver in place.

Note this is phrased this way for comedic effect. I'm not actually mad or anything.

WRONG.
X11 does not support HDR. No ifs ands or buts.
The application must be running as Wayland (not X11 and with XWayland) AND the session must be Wayland for HDR.

Replying to https://github.com/ValveSoftware/Proton/issues/4638#issuecomment-3939448600

sort of, but not really, the steam deck oled already supports HDR in gamescope. Probably some secondary communication going on outside of x11 to make that work. But the steam deck def does support HDR in gamescope for proton games

Replying to https://github.com/ValveSoftware/Proton/issues/4638#issuecomment-4323656890

Gamescope is a micro Wayland compositor, valve supports the color management protocols in gamescope for HDR to work correctly. The desktop mode in kde plasma x11 does not and never will support HDR.

Valve have switched to the Wayland session for kde plasma in steamos in the beta versions, kde plasma supports the color management protocols in Wayland so HDR can be enabled and configured.

What's left is wine Wayland to be enabled by default and HDR within in wine to be enabled by default then the user will only need to enable it in the display settings and you will get HDR in games in the desktop mode.