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?

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.

1. 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.

2. @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.

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

@Ketrel I only have tested for a bit. The intermittent issue I referenced was games not going back properly to windowed mode after fullscreen mode. When I set the resolution to non-native and went from windowed -> fullscreen -> windowed, multiple games had the same failure. The game's window size would change to the windowed resolution, but the game inside would still be rendering like fullscreen, so only part of the game was visible in the small window.

@DarkWav Thank you for the update - I already suspected your issue was different, but it is great to have confirmation :)

@Ketrel I only have tested for a bit. The intermittent issue I referenced was games not going back properly to windowed mode after fullscreen mode. When I set the resolution to non-native and went from windowed -> fullscreen -> windowed, multiple games had the same failure. The game's window size would change to the windowed resolution, but the game inside would still be rendering like fullscreen, so only part of the game was visible in the small window.

Hmm, I'm not sure I could test on that one personally. I'm curious though as an alternative/hack/fix/etc once you're in that broken state you described, if you change the game's resolution, does it correct that state? If so would a better "fix" be to in the event of going from fullscreen -> windowed to emit a resolution changed event?

@Ketrel Its a very complicated and fragile area of code, and it is unclear if the problem is on the Wine side or the kwin side. Someone is looking into this :) ... the disablement was originally to fix other issues which do seem (at least mostly) fixed by kwin 6.4. It is great that you're seeing things working well now without the hack :)

Has there been any headway on this? At my last build off of 49877a23027 on the experimental_10.0 branch, reverting those applicable of those three commits still works. I haven't done a newer build as of yet, but I always have a worry that some newer change will depend on having it not reverted.

@Ketrel We are still planning to revert these as soon as we are confident things are fixed "properly" so that the hacks are no longer needed. That is the ultimate goal for all hacks, especially this one which has such obvious negative side-effects. The original no-minimization hack was never designed/intended as a permanent solution 👍

How funny, I have the opposite issue on linux mint 22.3 with KDE 5.27.12. I can't resize the window as it constantly goes back to maximized mode, if I mode it to a different monitor it just maximized to that one too.

How funny, I have the opposite issue on linux mint 22.3 with KDE 5.27.12. I can't resize the window as it constantly goes back to maximized mode, if I mode it to a different monitor it just maximized to that one too.

I think that's the same issue. Before I used a version where I reverted those, it wasn't that I couldn't maximize, it was that any change I initiated would undo. If it started maximized, I couldn't unmaximize. If it started unmaximized, I couldn't maximize.

With the current proton experimental 3adde3189a3f24eec3447202749143a25c502da1

I can no longer get those three commits to cleanly revert.

dfe45c5 reverts, but 253fb02 and 5593ca7 show merge conflicts when I try

@Ketrel (And everyone else impacted by this bug) Have you tried Proton 11 beta yet? Proton 11 beta should fix this problem entirely, and hopefully we should be able to close this issue 🤞 You will need either kwin 6.4 (with Wayland) or kwin 6.6 (with X11) for ideal behavior. The root bug was fixed with those KDE versions, and so we were able to revert the hacks entirely for Proton 11 beta 🥳

@Ketrel (And everyone else impacted by this bug) Have you tried Proton 11 beta yet? Proton 11 beta should fix this problem entirely, and hopefully we should be able to close this issue 🤞 You will need either kwin 6.4 (with Wayland) or kwin 6.6 (with X11) for ideal behavior. The root bug was fixed with those KDE versions, and so we were able to revert the hacks entirely for Proton 11 beta 🥳

It appears to work with The Binding of Isaac Repentence GOG Version (have a custom launcher setup for that that makes it super easy to swap out proton versions to test with). That was one of my major test cases and it appears to be working for me.

(KWin X11 6.6.4)

Got it added to steam in compatibility.d and have now also tested with the Steam version of The Binding of Isaac Rebirth.

Working there too.
(I'm hesitant to try it with World of Warcraft as it's still a beta version and I don't want to get my account flagged there)

Since it's working in Proton 11 I'm closing the issue.