[Bug 38087] New: Settlers III: mouse not working on start screen and menu (after fixing raw input bug 33479)
https://bugs.winehq.org/show_bug.cgi?id=38087
Bug ID: 38087 Summary: Settlers III: mouse not working on start screen and menu (after fixing raw input bug 33479) Product: Wine Version: 1.7.32 Hardware: x86 URL: http://www.fileplanet.com/27965/20000/fileinfo/The-Set tlers-III:-Quest-of-the-Amazons-Demo OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: sebastian@fds-team.de CC: gyebro69@gmail.com, stefan@codeweavers.com Depends on: 33479 Regression SHA1: f6dde7062413a1dfdd71acc92c5178ac66f3ade0 Distribution: ArchLinux
Originally reported here: https://bugs.wine-staging.com/show_bug.cgi?id=95
The problem doesn't occur with plain Wine, because the incorrect commit from bug 33479 somehow magically "works around" this regression. I am opening this bug anyway because sooner or later a proper fix will get upstream.
To reproduce this issue, you have to revert 76bbf106a28c4caa82873e8450bde7d4adc765bf, or alternatively apply the staging fix for bug 33479. See here for more details https://bugs.winehq.org/show_bug.cgi?id=33479#c45 .
When starting Settlers 3 as fullscreen, before the bad commit was introduced the mouse cursor appears and works properly on the start screen and in the menu. After the bad commit the mouse cursor doesn't show up anymore. This makes it impossible to enter the game.
Patch http://source.winehq.org/patches/data/108577 does not help in this case, and the issue is still present in latest upstream Wine (wine-1.7.36-83-gf75d1b0).
Desktop environment: XFCE 4.1 md5sum(S3_A_Demo.exe): f8f8214bed453cde3c7b2a1fe80f947a
The regression test was performed by reverting 76bbf106a28c4caa82873e8450bde7d4adc765bf at each step.
$ git bisect good f6dde7062413a1dfdd71acc92c5178ac66f3ade0 is the first bad commit commit f6dde7062413a1dfdd71acc92c5178ac66f3ade0 Author: Stefan Dösinger stefan@codeweavers.com Date: Tue Nov 18 21:26:57 2014 +0100
wined3d: Restore the display mode on focus change.
:040000 040000 aa87fc202d416bf38b92925b0040cbdbcc9e3a84 23850dec1d6e575a9050437206d54d48db834005 M dlls :040000 040000 0e90d026408ce1c052257f931536dd23c1e53a6f 5e45b170033d4faab106d4de13292c70ce3cbed4 M include
https://bugs.winehq.org/show_bug.cgi?id=38087
--- Comment #1 from Stefan Dösinger stefan@codeweavers.com --- The game supports two mouse pointer types: A GDI-Based one ("Monochrome Pointer") and a ddraw overlay based one ("Colored Pointer"). Which one do you have set in the setup program?
https://bugs.winehq.org/show_bug.cgi?id=38087
--- Comment #2 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Stefan Dösinger from comment #1)
The game supports two mouse pointer types: A GDI-Based one ("Monochrome Pointer") and a ddraw overlay based one ("Colored Pointer"). Which one do you have set in the setup program?
So far I was using the default settings (which is monochrome mousepointer), but changing these settings doesn't help. No matter what is selected, the result is the same.
https://bugs.winehq.org/show_bug.cgi?id=38087
--- Comment #3 from Stefan Dösinger stefan@codeweavers.com --- Yeah, because we don't overlays the game will always fall back to the monochrome cursor. I suspected a temporary mode change might cause the game to re-try the overlay cursor and not check the caps.
It took me a few tries to reproduce this. The pointer is always fine in a virtual desktop, and I got it broken twice in 10 runs without a VD, running in KDE.
https://bugs.winehq.org/show_bug.cgi?id=38087
--- Comment #4 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Stefan Dösinger from comment #3)
Yeah, because we don't overlays the game will always fall back to the monochrome cursor. I suspected a temporary mode change might cause the game to re-try the overlay cursor and not check the caps.
It took me a few tries to reproduce this. The pointer is always fine in a virtual desktop, and I got it broken twice in 10 runs without a VD, running in KDE.
With XFCE (and a workaround/fix for bug 33479) I can reliably reproduce it here every time - but I also noticed that its somehow timing related, enabling additional debug channels (like +cursor) prevent the application from starting at all. Very weird ^^
https://bugs.winehq.org/show_bug.cgi?id=38087
--- Comment #5 from Stefan Dösinger stefan@codeweavers.com --- Yes, the game has plenty of race conditions. Start it with taskset -c 1.
Meanwhile, my problem was actually that I forgot to recompile my 64 bit explorer.exe. Now it is reliable.
The actual change this patch was supposed to introduce (the one in swapchain_activate) is never run. The problem happens because the changed redundant mode setting check now directly calls EnumDisplaySettingsExW(ENUM_CURRENT_SETTINGS) instead of wined3d_get_adapter_display_mode, so it misses the bpp override in the latter function. Therefore it thinks the mode is changed and re-applies the mouse clip whereas it previously did not.
(The previous code had similar problems with D3DFMT_A8R8G8B8 vs D3DFMT_X8R8G8B8).
The proper thing to do would be to move the redundant mode application check to user32 and the bpp faking to winex11.drv (or maybe user32, if winemac.drv needs it in the same way). But I also recommend to check if the fix for bug 33479 should really be susceptible to a redundant ClipCursor call. Perhaps this is a bug on its own.
https://bugs.winehq.org/show_bug.cgi?id=38087
--- Comment #6 from Stefan Dösinger stefan@codeweavers.com --- Also, the ClipCursor call is wrong from a technical point of view, but it is a really nice feature we should keep. Windows does not clip the cursor in fullscreen mode. This can be observed when running a fullscreen game on a dual head setup. If you don't have two monitors you can observe it by reading forum posts by Windows users complaining about their mouse pointer leaving the game if they have two monitors.
https://bugs.winehq.org/show_bug.cgi?id=38087
Adrian Kalla adrian.kalla@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adrian.kalla@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=38087
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED CC| |michael@fds-team.de, | |sebastian@fds-team.de Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/server-ClipCur | |sor
https://bugs.winehq.org/show_bug.cgi?id=38087 Bug 38087 depends on bug 33479, which changed state.
Bug 33479 Summary: Multiple games (Guild Wars 2, Risen 2, Tomb Raider 2013): Raw input is broken https://bugs.winehq.org/show_bug.cgi?id=33479
What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED Resolution|--- |FIXED
https://bugs.winehq.org/show_bug.cgi?id=38087
--- Comment #7 from Adrian Kalla adrian.kalla@gmail.com --- Oh boy - the patch for bug 33479 did land: https://bugs.winehq.org/show_bug.cgi?id=33479#c57
Does this mean, that starting with Wine 1.7.55 Settlers 3 becomes unplayable...?
https://bugs.winehq.org/show_bug.cgi?id=38087
--- Comment #8 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Adrian Kalla from comment #7)
Oh boy - the patch for bug 33479 did land: https://bugs.winehq.org/show_bug.cgi?id=33479#c57
Does this mean, that starting with Wine 1.7.55 Settlers 3 becomes unplayable...?
Hopefully not. There is already a staged patchset for this bug, and I'm hoping to get it also upstream before the next release.
https://bugs.winehq.org/show_bug.cgi?id=38087
--- Comment #9 from Adrian Kalla adrian.kalla@gmail.com --- (In reply to Sebastian Lackner from comment #8)
(In reply to Adrian Kalla from comment #7)
Oh boy - the patch for bug 33479 did land: https://bugs.winehq.org/show_bug.cgi?id=33479#c57
Does this mean, that starting with Wine 1.7.55 Settlers 3 becomes unplayable...?
Hopefully not. There is already a staged patchset for this bug, and I'm hoping to get it also upstream before the next release.
As I suspected: 1.7.55 did bust S3 support... There is a workaround, though, but not for everyone: disable the "Capture the mouse in full-screen windows" - then the mouse works again. But for the people who play S3 with the S3-option "Bump Scrolling", this is not an option, as it requires the mouse to stay inside the window...
https://bugs.winehq.org/show_bug.cgi?id=38087
--- Comment #10 from Adrian Kalla adrian.kalla@gmail.com --- BTW. Is the status "STAGED" still correct after the bug already affects the released not-staged version of Wine?
https://bugs.winehq.org/show_bug.cgi?id=38087
--- Comment #11 from Adrian Kalla adrian.kalla@gmail.com --- Any progress on this? Or will the next stable Wine really have this bug?
https://bugs.winehq.org/show_bug.cgi?id=38087
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=38087
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=38087
Maik Wagner maiktapwagner@aol.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maiktapwagner@aol.com
--- Comment #12 from Maik Wagner maiktapwagner@aol.com --- Hello everyone,
wine 1.9.15-staging on openSUSE Tumbleweed here.
I have good news: Installation in a new prefix of the demo just works fine and moving the mouse on title screen and in-game both work fine.
https://bugs.winehq.org/show_bug.cgi?id=38087
--- Comment #13 from Adrian Kalla adrian.kalla@gmail.com --- @Maik Wagner: this is no news - it was working on the STAGING-releases for a long, long time...
https://bugs.winehq.org/show_bug.cgi?id=38087
--- Comment #14 from Adrian Kalla adrian.kalla@gmail.com --- (In reply to Sebastian Lackner from comment #8)
Does this mean, that starting with Wine 1.7.55 Settlers 3 becomes unplayable...?
Hopefully not. There is already a staged patchset for this bug, and I'm hoping to get it also upstream before the next release.
Did you mange to find some to get this patchset upstream after now 1.5 years? If not: what is blocking this?
https://bugs.winehq.org/show_bug.cgi?id=38087
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset|https://github.com/wine-com |https://github.com/wine-com |pholio/wine-staging/tree/ma |pholio/wine-staging/tree/ma |ster/patches/server-ClipCur |ster/patches/winex11-ClipCu |sor |rsor CC| |dmitry@baikal.ru, | |erich.e.hoover@wine-staging | |.com
https://bugs.winehq.org/show_bug.cgi?id=38087
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/tree/mast |ster/patches/winex11-ClipCu |er/patches/winex11-ClipCurs |rsor |or
https://bugs.winehq.org/show_bug.cgi?id=38087
tt_1 herrtimson@yahoo.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |herrtimson@yahoo.de
--- Comment #15 from tt_1 herrtimson@yahoo.de --- with the linked staging patchset (winex11-ClipCursor) applied it'll work for stable wine-3.0.3 - wine-staging-3.15 should work as well.
https://bugs.winehq.org/show_bug.cgi?id=38087
Józef Kucia joseph.kucia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED Fixed by SHA1| |e2389c015c69a036aab183eaf16 | |a2dd1e7341330 CC| |joseph.kucia@gmail.com Resolution|--- |FIXED
--- Comment #16 from Józef Kucia joseph.kucia@gmail.com --- The patch was accepted upstream. Thanks Sebastian.
https://bugs.winehq.org/show_bug.cgi?id=38087
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #17 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.5.
https://bugs.winehq.org/show_bug.cgi?id=38087
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |4.0.x
https://bugs.winehq.org/show_bug.cgi?id=38087
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.0.x |---
--- Comment #18 from Michael Stefaniuc mstefani@winehq.org --- Removing the 4.0.x milestone from bug fixes included in 4.0.2.
https://bugs.winehq.org/show_bug.cgi?id=38087
--- Comment #19 from Adrian Kalla adrian.kalla@gmail.com --- The bug reappeared in Wine (Staging) 5.9 and 5.10.
This was working at least until Wine 5.5.
https://bugs.winehq.org/show_bug.cgi?id=38087
Adrian Kalla adrian.kalla@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |49347
-
wine-bugs＠winehq.org -
WineHQ Bugzilla