[Bug 33427] New: Tomb Raider (2013): Desktop does not get mouse focus after closing game
http://bugs.winehq.org/show_bug.cgi?id=33427
Bug #: 33427 Summary: Tomb Raider (2013): Desktop does not get mouse focus after closing game Product: Wine Version: 1.5.28 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv AssignedTo: wine-bugs@winehq.org ReportedBy: felixhaedicke@web.de Classification: Unclassified
After closing Tomb Raider (2013), the game window disappears and the TombRaider.exe process is not running any more, but the desktop and running applications do not react to mouse move / click. But the mouse cursor is visible and the keyboard seems to work. After pressing a key to switch to another application (for example the super key to open the Unity starter), or executing "wineserver -k", everything is fine again.
The game is bound to Steam, so the steam process is still running after closing Tomb Raider.
The bug seems to be independent of the desktop environment, it happens at least with Unity and KDE on Ubuntu 12.10.
This does not happen if the game is run in windowed mode. In fullscreen mode, it is always reproducible.
As this did not happen with Wine 1.5.13 (but with 1.5.14), I ran a regression test and identified the following commit as the guilty one:
commit 73d68c5a31b972a24dab39b036a5d3197edb3565 Author: Henri Verbeet hverbeet@codeweavers.com Date: Fri Sep 28 01:06:53 2012 +0200
winex11: Handle a NULL cursor clipping rect the same as a fullscreen rect.
We want to avoid ungrabbing the clipping window if "fullscreen clipping" is enabled.
Reverting this commit fixes the problem in current wine git master version.
http://bugs.winehq.org/show_bug.cgi?id=33427
Felix Hädicke felixhaedicke@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |73d68c5a31b972a24dab39b036a | |5d3197edb3565
http://bugs.winehq.org/show_bug.cgi?id=33427
Felix Hädicke felixhaedicke@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hverbeet@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=33427
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=33427
--- Comment #1 from Henri Verbeet hverbeet@gmail.com 2013-04-23 05:25:05 CDT --- It sounds a bit like the clipping window (from clip_fullscreen_window()) never gets ungrabbed, although the entire clipping window should just go away on process exit either way. Are you sure the process has exited? I don't suppose this has a demo or some other way to easily reproduce this, right? A "+tid,+x11drv,+event,+cursor,+win" may be useful.
http://bugs.winehq.org/show_bug.cgi?id=33427
--- Comment #2 from Felix Hädicke felixhaedicke@web.de 2013-04-23 16:48:08 CDT --- Created attachment 44275 --> http://bugs.winehq.org/attachment.cgi?id=44275 Output with WINEDEBUG=+tid,+x11drv,+event,+cursor,+win
stderr output with WINEDEBUG=+tid,+x11drv,+event,+cursor,+win
After closing the game (and the bug occured), according to winedbg info process, the following processes were running: explorer.exe services.exe plugplay.exe winedevice.exe Steam.exe but not TombRaider.exe Killed the processes with wineserver -k
http://bugs.winehq.org/show_bug.cgi?id=33427
--- Comment #3 from Felix Hädicke felixhaedicke@web.de 2013-04-23 16:49:36 CDT --- As far as I know there is no demo, and I don't know another way to reproduce the bug. Other (fullscreen) games started with Steam seem to work fine.
http://bugs.winehq.org/show_bug.cgi?id=33427
--- Comment #4 from Felix Hädicke felixhaedicke@web.de 2013-04-23 16:55:19 CDT --- Created attachment 44276 --> http://bugs.winehq.org/attachment.cgi?id=44276 Revert to the old behaviour in explorer.exe only
I experimented a bit to find out if the code change affects Steam or TombRaider. But I found out that for these two processes the change does not make a difference. But for explorer.exe, it does.
This patch restores the old beahviour for explorer.exe only and the problem does not occur then.
http://bugs.winehq.org/show_bug.cgi?id=33427
--- Comment #5 from Henri Verbeet hverbeet@gmail.com 2013-04-24 11:37:23 CDT --- Created attachment 44285 --> http://bugs.winehq.org/attachment.cgi?id=44285 patch
I think that makes sense, actually. Does the attached patch make it any better?
http://bugs.winehq.org/show_bug.cgi?id=33427
--- Comment #6 from Felix Hädicke felixhaedicke@web.de 2013-04-24 12:15:41 CDT --- Your patch fixes the bug, thanks!
http://bugs.winehq.org/show_bug.cgi?id=33427
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |76bbf106a28c4caa82873e8450b | |de7d4adc765bf Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #7 from Henri Verbeet hverbeet@gmail.com 2013-04-25 14:33:29 CDT --- Should be fixed by commit 76bbf106a28c4caa82873e8450bde7d4adc765bf.
http://bugs.winehq.org/show_bug.cgi?id=33427
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2013-04-26 13:16:27 CDT --- Closing bugs fixed in 1.5.29.
-
wine-bugs＠winehq.org