Proton 10: Can't maximize windows
With Proton 10 I can't maximize any window on KDE Plasma (explorer.exe, notepad.exe etc.) Here's the log
Moved to wine repo https://github.com/ValveSoftware/wine/issues/287
This is also happening on my end with Proton 10 on Plasma Wayland 6.3.5. I also can't _un_maximize windows if they are already maximized.
This happens on the following setup as well
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.1
Graphics Backend: X11
If I attempt to maximize a window, it immediately unmaximizes itself. (Same issue unmaximizing one that was already maximized somehow)
Examples of some games this also affects:
- Battle.net client
- World of Warcraft client in windowed mode
- Steam and Non-Steam versions of The Binding of Isaac Rebirth/Afterbirth
Also this issue seems to be the the same as what we're having overall: https://github.com/ValveSoftware/Proton/issues/8691
Glad I found this issue, I thought I was the only one experiencing it.
My specs are:
Operating System: Arch Linux KDE Plasma Version: 6.4.3 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.1 Graphics Platform: Wayland
Affected applications I tested:
- Resonite
- Vrchat
- Astroneer
- Crab Champions
The native Wayland driver does not have this issue, you can resize freely on native Wayland. Of course you'd need a proton build with Wayland support, such as Proton-GE. (Though window decorations don't work, and instead use the wine decorations which looks... less than appealing.)
I'm not sure that's accurate. The guy right above you is having the same issue on wayland.
(Also switching to wayland isn't feasible for many people including myself)
The guy right above you is having the same issue on wayland.
Proton uses the x11 driver and therefore xwayland by default unless otherwise specified, I doubt the person above me enabled the wayland driver before, as its not included in proton 10 by default. (as previously mentioned proton-ge does have the native wayland driver, and I use proton-ge to run my games.)
(Also switching to wayland isn't feasible for many people including myself)
Yeah, that's quite unfortunate for everyone who is unable to switch. Though I personally wouldn't use it anyway as it disables window decorations (in my case for kde plasma) and uses wine window decorations instead which is pretty jarring.
(Sorry if I didn't format my comment correctly, I am no developer and don't really use github)
Reporting the same on Kubuntu 24.04 and on Proton Hotfix. In particular: KDE Plasma Version: 5.27.12, KDE Frameworks Version: 5.115.0, Qt Version: 5.15.13, Kernel Version: 6.14.0-24-generic (64-bit), Graphics Platform: X11, Processors: 16 × AMD Ryzen 7 5700G with Radeon Graphics.
i fixed this by disabling "Allow the window manager to decorate windows" in winecfg under Graphics tab at the cost of everything looking horrible
How do you open winecfg for a Steam game prefix?
How do you open winecfg for a Steam game prefix?
set the prefix as WINEPREFIX environment variable and use the wine distributed winecfg or there may be a steam distributed one in ~/.steam/steam/steamapps/common/Proton_version/files/bin?
Unfortunately I still can't maximize windows with this option
How do you open winecfg for a Steam game prefix?
set the prefix as WINEPREFIX environment variable and use the wine distributed winecfg or there may be a steam distributed one in ~/.steam/steam/steamapps/common/Proton_version/files/bin?
Better use protontricks instead, otherwise you're risking mixing different wine implementations and don't use container isolation which may break your Proton prefix:
protontricks -s NAME_OF_GAME
protontricks GAMEID winecfg
You could also try setting your launch options to
winecfg #%command%
You could also try setting your launch options to
winecfg #%command%
I don't think that works as intended, because this way winecfg would be run from outside the Proton environment. Actually, %command% contains the call to Proton itself. So it's not different from running your game prefix with system wine - which can break it.
Dumping %command% in a script actually looks like this:
$HOME/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- \
$HOME/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=359320 -- \
$HOME/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/_v2-entry-point --verb=waitforexitandrun -- \
$HOME/.local/share/Steam/steamapps/common/Proton - Experimental/proton waitforexitandrun \
$HOME/.local/share/Steam/steamapps/common/Elite Dangerous/EDLaunch.exe /Steam /novr
So everything you paste is still running outside of the container. You would instead need something that replaces the EXE path which Steam inserts for %command% with a custom command you want to run from within a custom launcher script.
Ah I misread how %command% worked then My apologies. I had thought it was just the executable call and the ENV was setup by the compatibility tool setting.
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Same issue here
Operating System: Fedora Linux 42 KDE Plasma Version: 6.4.4 KDE Frameworks Version: 6.17.0 Qt Version: 6.9.1 Kernel Version: 6.15.10-200.fc42.x86_64 (64-bit) Graphics Platform: Wayland
Games I tested on: RPG Maker XP Don't Starve Together (Forcing the use of Proton) Geometry Dash
Can anyone test if this happens on GNOME Wayland and/or other X11 desktop environments/WMs?
Not sure if this helps, but I have the same issue on:
Operating System: Arch Linux Cinnamon Version: 6.4.10 Kernel Version: 6.12.44-1-lts Display Server: X11
Games tested: Path of Exile Trove
I have this issue on Proton Experimental (whatever latest version Steam installs today, I assume experimental_10.0), but I noticed the issue first when updating GE-Proton to GE-Proton10-11 (and have the issue all the way up to GE-Proton10-15).
However, for me, Proton 10.0-2 (beta) and GE-Proton10-10 don't have this issue (I can maximize the game windows fine).
I'm not familiar with wine, so I could be wrong. But looking at the difference between: https://github.com/GloriousEggroll/proton-ge-custom/compare/GE-Proton10-10...GE-Proton10-11
I noticed they updated their wine version, and one commit stood out to me: https://github.com/ValveSoftware/wine/commit/253fb023de63c30390f050fc14faac1f69230cb9
experimental_10.0 also seems to have wine with the same commit.
I hope someone who is more familiar with proton/wine can look into this further
Unfortunately, I'm currently numerous versions with numerous games.
-
I'm using GE-Proton 10-10 for World of Warcraft currently and the issue still happens there.
-
I'm using the latest Proton Experimental for the Steam version of The Binding of Isaac and the issue happens there.
It's happened on every flavor of Proton 10 for me.
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi folks - Thank you for starting this thread. We've looked into the issues reported and there seem to be two issues.
-
Most folks here are on KDE and complaining that the "maximize" button from the KDE system title bar doesn't work. This issue is understood and due to one of the temporary hacks added with the Proton 10 rebase to workaround a KDE bug. Upstream KDE has been helpful and the fix on their end is shipped with KDE 6.4 (as far as I understand), so we are hopeful this hack can be removed with the next Proton rebase if not sooner :) In the meantime, hopefully using the in-game resolution controls will work for most circumstances.
-
@AVerwer What you found is a separate regression in the experimental branch that is Cinnamon specific. Thank you for the report! I looked into it and found the commit at fault, and I've asked the person who wrote it to take another look :)
Note for future readers - if you run across this thread and you are not using KDE or Cinnamon on Proton 10, please report on the game-specific issue or start a new meta-issue if the bug is impacting multiple games.
@alasky17 Thanks for your input! Could you please pinpoint exact commits of hacks that are causing regressions, so third-party packagers could revert them in their packages?
I'd like to second that request. I've been stuck playing with an unmaximized window for some months now. Building myself in the mean time is viable.
Once I started investigating, things were more complicated than I originally thought and it looks like there are actually multiple commits involved. Rather than give bad info, I'm doing a bit more digging first :)
Hi folks - WARNING: proceed with caution, breakage potential ahead!
I was able to revert the three commits below on the experimental_10 branch and restore the built-in maximize feature in the KDE title bar. This should also "fix" the maximize button on Cinnamon.
However, I basically immediately ran into some weird intermittent breakage ... there was a reason that we added these commits in the first place, particularly because the same visual effect can typically be achieved by using the in-game resolution settings (although I know not in all cases if the game menu doesn't show your native resolution). I would recommend not reverting these in any widespread application, at least for now. I'm going to do more work on this, and hopefully we'll be able to safely revert these without breaking any other game functionality in the near future :)
If you DO try to revert these and run into newly revealed bugs that only happen with the commits reverted, please let me know! Please respond here or tag me in your report. This information would be quite valuable in working to properly fix the bugs so that we can get rid of these hacks for good :)
https://github.com/ValveSoftware/wine/commit/5593ca793b6afc960deef190138d1be06e4e3286 - winex11.drv: Ignore fullscreen window config changes. https://github.com/ValveSoftware/wine/commit/253fb023de63c30390f050fc14faac1f69230cb9 - winex11.drv: Disable maximize when emulating non-native aspect ratio display modes. https://github.com/ValveSoftware/wine/commit/dfe45c50b5f71eb3827fe2277f35a2b75d828608 - HACK: winex11: Ignore KWin-originated maximized window state changes.
I haven't tested against much as the build JUST finished
Reverting just https://github.com/ValveSoftware/wine/commit/dfe45c50b5f71eb3827fe2277f35a2b75d828608 has allowed me to simply maximize the Window for both
- The Binding of Isaac Rebirth on Steam using compatibilitytools.d
- The Binding of Isaac Afterbirth from GoG using umu-launcher
- Battle.net client using umu-launcher
- World of Warcraft using umu-launcher
This was specifically against the 10.0-2d tag, which I'm not positive includes all three of the commits mentioned as one is as new as last week.
I've done more testing.
Building against 10.0-2d, I only need to revert:
https://github.com/ValveSoftware/wine/commit/dfe45c50b5f71eb3827fe2277f35a2b75d828608 - HACK: winex11: Ignore KWin-originated maximized window state changes.
Building against Experimental I needed to revert all three:
https://github.com/ValveSoftware/wine/commit/5593ca793b6afc960deef190138d1be06e4e3286 - winex11.drv: Ignore fullscreen window config changes.
https://github.com/ValveSoftware/wine/commit/253fb023de63c30390f050fc14faac1f69230cb9 - winex11.drv: Disable maximize when emulating non-native aspect ratio display modes.
https://github.com/ValveSoftware/wine/commit/dfe45c50b5f71eb3827fe2277f35a2b75d828608 - HACK: winex11: Ignore KWin-originated maximized window state changes.
Additional data point though probably irrelevant, for building GE-Proton against 10-15 I needed to revert the bottom two as it doesn't include the first https://github.com/ValveSoftware/wine/commit/253fb023de63c30390f050fc14faac1f69230cb9 - winex11.drv: Disable maximize when emulating non-native aspect ratio display modes. https://github.com/ValveSoftware/wine/commit/dfe45c50b5f71eb3827fe2277f35a2b75d828608 - HACK: winex11: Ignore KWin-originated maximized window state changes.
@alasky17 I've been running World of Warcraft with the Proton 10.0-2d as described in my previous post with the one commit reverted (as the wine build for that Proton build is prior to the other two). You said when you tested you did notice some intermittent breakage. I'm curious what you saw, both so I can look out for if I run into it, but also to see if it's something I can trigger as well.
I'm on KDE/Plasma 6.4.4 however, so if the overall issue was fixed in 6.4 that could also be why I've not run into anything thus far.
Edit: Sorry for off-topic post, I will make a proton build with the commits reverted and report back.
Spoiler: Old comment
@alasky17 My issue with Path of Exile 2 showing a black screen on startup under X11 + NVIDIA (580.82.07) + Vulkan Renderer on KDE Plasma 6.4.5 + KF6 6.18.0 + Qt 6.9.2 (openSUSE Tumbleweed 20250917, Steam from Flathub) as mentioned in #8296 persists in both normal proton experimental and proton bleeding edge as of 2025-09-19 18:56 UTC Starting in Windowed mode works, starting in full screen or switching to fullscreen will cause the game to hang.
Proton 10.0-2 beta works just fine and has none of the issues mentioned above.
Edit 2: I built Proton will all three 5593ca793b6afc960deef190138d1be06e4e3286 , 253fb023de63c30390f050fc14faac1f69230cb9 and dfe45c50b5f71eb3827fe2277f35a2b75d828608 reverted and PoE2 still locks up when set to fullscreen.
Zusi 3 (1040730) has the same issue