http://bugs.winehq.org/show_bug.cgi?id=23745
Summary: warcraft 3 freeze when desktop switching/minimize Product: Wine Version: 1.2-rc7 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P1 Component: winex11.drv AssignedTo: wine-bugs@winehq.org ReportedBy: gufide_g@yahoo.ca
Warcraft 3 starting to freeze when you move to another workspace. It crash when you move, not when you return. I try to minimize the game and that happen again. I see that it doesn't make this when you are in window mode.
http://bugs.winehq.org/show_bug.cgi?id=23745
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P2 Component|winex11.drv |-unknown Severity|major |normal
--- Comment #1 from Jeff Zaroyko jeffz@jeffz.name 2010-07-21 20:39:54 --- not major: http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity
is this a regression, did it work properly in earlier versions of Wine?
It could be bug 23711, you can try reverting that commit.
http://bugs.winehq.org/show_bug.cgi?id=23745
Guillaume gufide_g@yahoo.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.2-rc7 |1.2
--- Comment #2 from Guillaume gufide_g@yahoo.ca 2010-07-24 11:24:14 --- I think that is a regression, because before I was able to change to another workspace or minimize.
http://bugs.winehq.org/show_bug.cgi?id=23745
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.2 |1.2-rc7
--- Comment #3 from Dmitry Timoshkov dmitry@codeweavers.com 2010-07-25 01:05:49 --- Please don't change an originally reported version.
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #4 from Guillaume gufide_g@yahoo.ca 2010-08-23 17:15:01 --- Update: now we can minimize warcraft 3 window and it doesn't freeze. When it minimized, we can switch workspace, return and maximize. It only crash when you switch to another workspace and warcraft is full screen. If warcraft 3 is in window mode, it don't happen (no crash)
http://bugs.winehq.org/show_bug.cgi?id=23745
clm@martindroessler.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |clm@martindroessler.de
--- Comment #5 from clm@martindroessler.de 2010-09-11 05:24:34 CDT --- I have a similar problem with World of Warcraft, when running in fullscreen mode and I switch to another desktop. When I try to open WoW again, its frozen. Nothing is rendered, but its transparent and like a layer over the desktop, and the only option is, to switch back to another desktop again and kill WoW.
I'm using KDE 4 - if this matters.
This behavior appears since wine 1.2rc3 (maybe since rc2, but have not tried this). Wine 1.2rc1 works fine.
I've also tried version 1.3.2 but its still the same.
http://bugs.winehq.org/show_bug.cgi?id=23745
Roman m01brv@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |m01brv@mail.ru
--- Comment #6 from Roman m01brv@mail.ru 2010-09-13 04:32:58 CDT --- (In reply to comment #5)
This is probably bug 23123 ?
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #7 from Roman m01brv@mail.ru 2010-09-13 04:38:22 CDT --- And I suspect this bug itself may be a duplicate of the bug 23123. The patch from there changes things in warcraft 3 to better too.
http://bugs.winehq.org/show_bug.cgi?id=23745
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz
--- Comment #8 from Wylda wylda@volny.cz 2010-09-19 03:23:29 CDT ---
Can't confirm. Works perfectly here. To be sure we are talking about the same thing. 1. run warcraft 3 in fullscreen mode on "Desktop 1" 2. press Ctrl+F2, Ctrl+F3, Ctrl+F4 to switch desktop and i still can hear sounds(fight), i.e. game is active 3. when i press Ctrl+F1 and i can continue with playing
These steps were tested under wine-1.2-rc6, wine-1.3.3.
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #9 from Roman m01brv@mail.ru 2010-09-22 04:40:19 CDT --- (In reply to comment #8) In my system (KDE 4.4.2) switching to another desktop causes warcraft window to be minimized (from fullscreen), and when it is minimized it gets suspended. I do not think this itself is a wrong behaviour, but the wrong thing is that after minimizing the game cannot be resumed by any means, I can only kill it. So the basic problem is probably triggered by minimizing the game (rather than desktop or alt+tab switching). But if so, then it is bug 23123, since the reverse patch from there makes it resumable at least when kwin effects are disabled.
http://bugs.winehq.org/show_bug.cgi?id=23745
NickNill dmbohdan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #10 from NickNill dmbohdan@gmail.com 2010-10-02 12:31:21 CDT --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=23745
NickNill dmbohdan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dmbohdan@gmail.com
--- Comment #11 from NickNill dmbohdan@gmail.com 2010-10-02 12:32:49 CDT --- This bug present in my system too, I use KDE 4.5,1
http://bugs.winehq.org/show_bug.cgi?id=23745
Maxym Kit kitmaxter@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kitmaxter@gmail.com
--- Comment #12 from Maxym Kit kitmaxter@gmail.com 2010-10-09 16:52:28 CDT --- Confirming with wine-1.3.4, kde-4.4.5
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #13 from Roman m01brv@mail.ru 2010-10-13 05:52:05 CDT --- I found a way to reanimate the warcraft window when it gets frozen in minimized state. It works with my KDE 4.4.2.
Run winecfg, then just close it (press "cancel"). After that, the focus is unexpectedly transferred to the warcraft window, which is restored automatically. Sometimes it gets restored and active behind other windows, in such a case you need also to alt+tab to it. I have no idea why it happens, maybe due to another bug in wine. It may not work if you have other applications running under wine at the same time (the focus may be tranferred to a wrong app). It works not only with the winecfg/warcraft pair, seemingly closing any other wine window may transfer focus to some other wine app.
http://bugs.winehq.org/show_bug.cgi?id=23745
Jean-Noel Rivasseau elvanor2007@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |elvanor2007@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #14 from Guillaume gufide_g@yahoo.ca 2010-11-14 12:37:26 CST --- I discovered something, when it freeze, I just minimize it and restore to unfreeze it just if I already minimize it and restore one time
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #15 from Roman m01brv@mail.ru 2010-11-17 03:16:28 CST --- (In reply to comment #14) Hmm, sorry, cannot reproduce. What graphical environment you use? KDE or something else?
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #16 from Guillaume gufide_g@yahoo.ca 2010-11-20 23:03:15 CST --- I use gnome, with the Nvidia driver 260. It unfreez, but the window dont get fullscreen
http://bugs.winehq.org/show_bug.cgi?id=23745
Francisco Pina Martins f.pinamartins@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |f.pinamartins@gmail.com
--- Comment #17 from Francisco Pina Martins f.pinamartins@gmail.com 2010-11-24 17:48:29 CST --- Confirming under Gnome 2.32, nVidia 260.19.21, wine 1.3.7. Desktop switching causes the game to freeze. There is nothing I can do to restore "action" to the game. Only "xkill" (or equivalent) will kill the game. I don't remember it ever working right.
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #18 from Guillaume gufide_g@yahoo.ca 2010-11-25 18:03:57 CST --- I forget something, I have force fullscreen with compiz and remove shadow and decoration in the compiz setting manager
http://bugs.winehq.org/show_bug.cgi?id=23745
Guillaume gufide_g@yahoo.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |winex11.drv
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #19 from Francisco Pina Martins f.pinamartins@gmail.com 2010-11-26 02:46:15 CST --- I have the freeze regardless of using compiz or metacity as my WM. However, switching to IceWM does solve the problem. I can switch between workspaces with no problem at all. Could this be simply a WM bug?
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #20 from Roman m01brv@mail.ru 2010-11-26 07:38:28 CST --- I think the problem is in how wine interacts with a particular WM
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #21 from Guillaume gufide_g@yahoo.ca 2010-11-30 20:12:23 CST --- After upgrade to wine 1.3.8, I can now switch to another workspace without freezes only if I don't put -opengl at the end of my link. It work very well without forcing fullscreen with compiz and I can minimize without problem. With -opengl, when I minimize, the window don't get in fullscreen again, and when I switch to another workspace, it freeze again and I have to miminize and maximize to continue the game.
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #22 from Roman m01brv@mail.ru 2011-01-26 03:48:57 CST --- I've done some investigation tracing the "event" debug channel and some others (with WINEDEBUG). I found that this bug emerges due to the following piece of code in handle_wm_state_notify of /dlls/winex11drv/event.c:
if (is_net_wm_state_maximized( event->display, data )) { if ((style & WS_MAXIMIZEBOX) && !(style & WS_DISABLED)) { TRACE( "restoring to max %p/%lx\n", data->hwnd, data->whole_window ); SendMessageW( data->hwnd, WM_SYSCOMMAND, SC_MAXIMIZE, 0 ); } else TRACE( "not restoring to max win %p/%lx style %08x\n", data->hwnd, data->whole_window, style ); } else if (style & (WS_MINIMIZE | WS_MAXIMIZE)) { TRACE( "restoring win %p/%lx\n", data->hwnd, data->whole_window ); SendMessageW( data->hwnd, WM_SYSCOMMAND, SC_RESTORE, 0 ); } else TRACE( "not restoring win %p/%lx style %08x\n", data->hwnd, data->whole_window, style );
The minimized game window is marked as "maximized" by KWin. This can be checked by right-clicking on the game icon in the taskbar: both "minimize" and "maximize" checkboxes are ticked. So is_net_wm_state_maximized returns true, but the wine's WS_MAXIMIZEBOX flag is unset, so the execution goes to the first "else" branch ("not restoring to max win"). I am not a windows programmer, but I found in the web that WS_MAXIMIZEBOX should mean only that the window does not have the maximize button. I do not see a reason why such windows should not be restored, although this window style could apparently contradict to the fact that WM thinks the window is maximized. Maybe wine mistakenly registered the window (in the WM) as maximized one somewhen earlier. Note that when the game window is in the normal fullscreen state, the "maximized" box from the taskbar right-click menu is grayed out and unchecked.
Note: the minimized game window possesses the following style flags: WS_POPUP, WS_MINIMIZE, WS_VISIBLE, WS_CLIPSIBLINGS, WS_CLIPCHILDREN (as it follows from the debug log when I try to restore the window)
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #23 from Roman m01brv@mail.ru 2011-01-26 03:58:52 CST --- Given the results from the above post, I found an easy workaround for this bug, which works for me pretty well. It is possible (in KDE at least) to set some specific window behaviour for a given application. I set for war3.exe the properties "maximized horizontally" and "maximized vertically" to be forced off, and the "fullscreen" property to be forced on. After that, KWin is always forced to treat this window as non-maximized one, and the execution in the above piece of code goes to the "else if" branch with the message "restoring win ...". In practice, the game window just becomes restorable as it normally should be. The forced fullscreen was necessary because otherwise my desktop panels overlapped the window.
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #24 from Alexandre Julliard julliard@winehq.org 2011-01-26 04:04:30 CST --- It would be interesting to find out how the window got the maximized state in the first place, that isn't supposed to happen for fullscreen windows.
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #25 from Jean-Noel Rivasseau elvanor2007@gmail.com 2011-01-26 06:58:39 CST --- Thanks a lot for your work, Roman! I implemented your workaround in KDE 4.4 and now it works perfectly. Before that I had to click many times on the Fullscreen button in KDE to restore it...
And as Alexandre says, it would be nice to find the root cause of the bug so this can be fixed in Wine (eg without the KDE workaround).
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #26 from Roman m01brv@mail.ru 2011-01-27 03:35:57 CST --- I could not find where the window gets the maximized state except during its creation - WIN_CreateWindowEx is called with WS_MAXIMIZE flag. However, a bit later (still during the initialization) I see the log message "window is no longer maximized" from X11DRV_ConfigureNotify. No further messages, which could indicate that it is being re-maximized. I noted that when the window is being minimized to the taskbar, it is no longer marked as fullscreen by the WM (as shown in the right-click taskbar menu). The "maximized" box is ticked only in this minimized state. When the window is in fullscreen, the "maximized" box is unticked and even disabled. Since I could not find anything in the debug log that could indicate that the window gets "maximized" during the minimization, my only guess is that KWin or Xorg may have somehow remembered this maximized state from the very window creation (wine did not notify them to remove this flag at some point?). This is probably ignored when the window is in fullscreen, but is recalled each time the window looses the fullscreen state.
By the way, I found that it is sufficient to force only the "fullscreen" property in the KWin configuration for war3.exe. In that case, the window just never attains the "maximized" state - the respective menu checkbox remains always disabled.
http://bugs.winehq.org/show_bug.cgi?id=23745
Lance lancerdot@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lancerdot@gmail.com
--- Comment #27 from Lance lancerdot@gmail.com 2011-02-01 21:46:59 CST --- Set the in-game resolution to your native/full-screen resolution and close WAR3. Then, use CompizConfig Window Rules to make the window full-screen. Warcraft III will work as it does windowed mode, so minimizing and maximizing should not be a problem, but Compiz will make it full screen without stretching.
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #28 from Lance lancerdot@gmail.com 2011-02-01 21:48:17 CST --- (In reply to comment #27)
Oh, and I should add WAR3 needs to be run with (-window) for this to work.
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #29 from Roman m01brv@mail.ru 2011-05-13 04:54:15 CDT --- I have found some time to return to this issue, and the more detailed sequence looks like the following:
After all loading stuff, the window has only a single property _NET_WM_STATE_FULLSCREEN in the _NET_WM_STATE list. When the user presses alt+tab and the game looses focus, it asks to minimize itself and awaits until it is restored. The wine layer basically calls XIconifyWindow() and then asks to remove the _NET_WM_STATE_FULLSCREEN atom (in the update_net_wm_states() function). Short after that, the window receives a few PropertyNotify events concerning _NET_WM_STATE, and by that time the content of the _NET_WM_STATE appears now: _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_HIDDEN. I think these new atoms are added by KWin when it is iconifining the window - no other source looks possible. Wine does not request this, and by the time when it completes its request in update_net_wm_states(), the window still has only _NET_WM_STATE_FULLSCREEN. When the user attempts to restore the window from the taskbar, KWin removes the _NET_WM_STATE_HIDDEN property, but _NET_WM_STATE_MAXIMIZED_VERT and _NET_WM_STATE_MAXIMIZED_HORZ are not altered. _NET_WM_STATE_FULLSCREEN is not restored. Wine interpretes the window as a maximized one, and does not restore it, as I described in comment 22.
Summarizing, iconifining the window leads to loosing the fullscreen flag, which is not recovered by KWin automatically after restoring the window. Forcing the window to be always fullscreen in the KDE settings fixes the problem.
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #30 from Alexandre Julliard julliard@winehq.org 2011-05-13 05:39:12 CDT --- Could you please get a +event,+win,+x11drv trace?
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #31 from Roman m01brv@mail.ru 2011-05-13 06:48:42 CDT --- Actually, I completely forgot about the +win channel. Then I obtain the full log you ask and upload it here in a couple of days.
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #32 from Roman m01brv@mail.ru 2011-05-14 03:44:20 CDT --- Created an attachment (id=34692) --> (http://bugs.winehq.org/attachment.cgi?id=34692) +event,+x11drv,+win trace of the issue
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #33 from Roman m01brv@mail.ru 2011-05-14 03:46:18 CDT --- Created an attachment (id=34693) --> (http://bugs.winehq.org/attachment.cgi?id=34693) same log, but forcing the window to be always fullscreen in KWin settings
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #34 from Roman m01brv@mail.ru 2011-05-14 03:54:26 CDT --- Created an attachment (id=34694) --> (http://bugs.winehq.org/attachment.cgi?id=34694) patch adding some extra trace logging
When obtaining these logs I added some extra tracing in the wine source, because the original trace output was not informative enough. This patch explains what extra tracing is added (mainly dumping the content of all PropertyNotify events, and dumping the full content of the _NET_WM_STATE property when it might be useful).
The logs also contain a few my comments (started from !!!), marking what I was doing with the game.
http://bugs.winehq.org/show_bug.cgi?id=23745
Lylat9@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Lylat9@gmail.com
--- Comment #35 from Lylat9@gmail.com 2011-09-10 02:38:54 CDT --- Any fixes for fullscreen in Gnome yet WITHOUT Compiz? (I prefer not to use compiz)
http://bugs.winehq.org/show_bug.cgi?id=23745
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |atalanttore@googlemail.com
--- Comment #36 from Alexandre Julliard julliard@winehq.org 2012-05-18 16:30:39 CDT --- *** Bug 21861 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=23745
Florentino floritaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |floritaka@gmail.com
--- Comment #37 from Florentino floritaka@gmail.com 2012-06-04 04:01:11 CDT --- (In reply to comment #35)
Any fixes for fullscreen in Gnome yet WITHOUT Compiz? (I prefer not to use compiz)
I use "wmctrl -k on" on a terminal in the same desktop where warcreaft III is running (in fullscreen mode). Then select the wine windows in the Unity bar and the game is restored, however with the desktop top menu visible but not available. Some times the keyboard is not focused on warcraft's window and have to call Unity's fast command text input (with alt key) to force focus on Unity then close it with alt again, to gain focus on WC3 window.
Ugly but works if you don't want to play in windowed mode and use compiz.
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #38 from Henri Verbeet hverbeet@gmail.com 2012-09-28 12:07:33 CDT --- Does commit 47c54c4ae7f235780a55ddf670503db4afc11055 make any difference here?
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #39 from Roman m01brv@mail.ru 2012-10-02 08:37:22 CDT --- Yes, it does, but I would say the difference is to the bad. The window does not minimize normally: the sound does not stop after that, and I suspect the game is not paused gracefully enough (this is the difference). But I cannot restore the graphical window anyway, I only see the KWin snapshot of the last picture (this is like before). No reaction on keyboard or mouse input. However,it seems that somewhere between versions 1.4 and 1.5.13 something else was broken, so my workaround no longer works (after upgrade from 1.4). Unfortunately now I am too busy to dig this deep, sorry.
http://bugs.winehq.org/show_bug.cgi?id=23745
Bjoern Bidar theodorstormgrade@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |theodorstormgrade@googlemai | |l.com
--- Comment #40 from Bjoern Bidar theodorstormgrade@googlemail.com 2013-01-10 16:36:17 CST --- World of Warcraft is affected too when using no virtual desktop, but I don't if its the same bug.
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #41 from Roman m01brv@mail.ru 2013-09-20 09:54:59 CDT --- I recently checked this bug with the latest updates of my KUbuntu 12.10 (KDE 4.9.5, wine 1.6 as well as 1.7.1). Surprisingly, I found that the bug is *almost* gone now. "Almost" means that the freezes are now rare - they occur approximately once per each ~10 minimize attempts.
I feel that the behaviour significantly depends on the KDE or X versions, not just on wine itself.
http://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #42 from Ken Sharp imwellcushtymelike@gmail.com --- Does this still occur in Wine 1.7.11 or later?
https://bugs.winehq.org/show_bug.cgi?id=23745
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #43 from Stefan Dösinger stefan@codeweavers.com --- Please retest this with a current Wine. Since 1.7.32 we minimize the window on focus loss. For me the game now resumes operation correctly on restore.
https://bugs.winehq.org/show_bug.cgi?id=23745
dennis.vaerum@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dennis.vaerum@gmail.com
--- Comment #44 from dennis.vaerum@gmail.com --- (In reply to Stefan Dösinger from comment #43)
Please retest this with a current Wine. Since 1.7.32 we minimize the window on focus loss. For me the game now resumes operation correctly on restore.
I am running ArchLinux with Plasma 5 on my desktop, KDE 4 on laptop and wine 1.7.55 and this is still a problem.
https://bugs.winehq.org/show_bug.cgi?id=23745
--- Comment #45 from dennis.vaerum@gmail.com --- (In reply to dennis.vaerum from comment #44)
Okay, know it works for me. I am on wine version 1.8-rc3. What I had to do was. 1. Go to System Settings -> Display and Monitor -> Compositor 2. Change the setting "Keep window thumbnails" from "Always" to "Only for Shown Windows".
Hope this helps others
https://bugs.winehq.org/show_bug.cgi?id=23745
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |stefandoesinger@gmx.at
https://bugs.winehq.org/show_bug.cgi?id=23745
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=23745
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #46 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-5.11?
-
wine-bugs＠winehq.org -
WineHQ Bugzilla