http://bugs.winehq.org/show_bug.cgi?id=31899
Bug #: 31899 Summary: No keyboard input in La-Mulana remake Product: Wine Version: 1.5.14 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: twwinwood@gmail.com Classification: Unclassified
Created attachment 41993 --> http://bugs.winehq.org/attachment.cgi?id=41993 Output of "env WINEDEBUG=-all,+keyboard,+key,+dinput,+message wine LaMulanaWin.exe"
Per the AppDB entry for version 1.1.1.1, the game works as far as the menu screen but cannot be played due to the lack of response to keyboard input.
http://bugs.winehq.org/show_bug.cgi?id=31899
Thomas Winwood twwinwood@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |twwinwood@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=31899
Tim timothy.m.hagberg@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |timothy.m.hagberg@gmail.com
--- Comment #1 from Tim timothy.m.hagberg@gmail.com 2012-10-08 05:13:21 CDT --- The same issue is happening for me. I want to add that while no keyboard input seems to be recognized, the directional pad buttons on my Logitech F310 gamepad are recognized, but no other buttons. Thus I'm able to navigate the main menu but cannot make any selections.
http://bugs.winehq.org/show_bug.cgi?id=31899
ssss2 zolbster@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zolbster@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=31899
Spummy mrmcspummbucket@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrmcspummbucket@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=31899
--- Comment #2 from Spummy mrmcspummbucket@gmail.com 2012-10-16 17:00:48 CDT --- Even though I already said my description for my AppDB report, I might as well comment here saying I also get this bug. And just like Tim, I also can am capable of using a gamepad to scroll the main menu, but apparently the game doesn't set any other gamepad buttons by default, and you can only do so from within the options menu (which can't be selected).
http://bugs.winehq.org/show_bug.cgi?id=31899
Stephan Sokolow from_wine_bugzilla@ssokolow.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |from_wine_bugzilla@ssokolow | |.com
http://bugs.winehq.org/show_bug.cgi?id=31899
Lucas Fialho Zawacki lfzawacki@yahoo.com.br changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lfzawacki@yahoo.com.br
https://bugs.winehq.org/show_bug.cgi?id=31899
--- Comment #3 from Bruno Jesus 00cpxxx@gmail.com --- Is this still na issue in wine 1.7.34 or later?
https://bugs.winehq.org/show_bug.cgi?id=31899
--- Comment #4 from Stephan Sokolow from_wine_bugzilla@ssokolow.com --- (In reply to Bruno Jesus from comment #3)
Is this still na issue in wine 1.7.34 or later?
Yes. I'm on 1.7.34 via the Ubuntu PPA and it's still ignoring keyboard input.
https://bugs.winehq.org/show_bug.cgi?id=31899
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=31899
--- Comment #5 from Sebastian Lackner sebastian@fds-team.de --- Is the problem still present with the latest wine version 1.7.37? I am currently taking a look at various bug reports related to keyboard input issues.
If the problem still exists, please attach a log with:
WINEDEBUG=+keyboard,+key,+dinput,+message,+win,+tid wine LaMulanaWin.exe
https://bugs.winehq.org/show_bug.cgi?id=31899
--- Comment #6 from Stephan Sokolow from_wine_bugzilla@ssokolow.com --- I haven't received 1.7.37 through the PPA yet and I'm a bit short on time.
Would a log from 1.7.34 do or should I wait?
https://bugs.winehq.org/show_bug.cgi?id=31899
--- Comment #7 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Stephan Sokolow from comment #6)
I haven't received 1.7.37 through the PPA yet and I'm a bit short on time.
Would a log from 1.7.34 do or should I wait?
A log using 1.7.34 should probably also be fine, and definitely better than the initial log from 2012. ;)
https://bugs.winehq.org/show_bug.cgi?id=31899
--- Comment #8 from Stephan Sokolow from_wine_bugzilla@ssokolow.com --- Created attachment 50938 --> https://bugs.winehq.org/attachment.cgi?id=50938 WINEDEBUG=+keyboard,+key,+dinput,+message,+win,+tid wine LaMulanaWin.exe in pristine Wine 1.7.34 prefix
Sorry for taking so long. GOG.com sprung their Double Insomnia Promo on me and it's been a mess jugging that and existing obligations with the need to dig up my La-Mulana installer and put together a clean wineprefix with just enough winetricks to make the game run under 1.7.34 rather than the one I set up back in the mists of antiquity.
Here's how I generated the attached log:
cd ~ lgogdownloader --download --game '^la_mulana$' mv .wine .wine.old winecfg # (Remove all drives but C: and disable Desktop Integration so La Mulana won't put a NIGORO folder in my homedir) cp -r la_mulana .wine/drive_c/ cd .wine/drive_c/ wine la_mulana/setup_la-mulana_2.0.0.7.exe wine la_mulana/patches/patch_la-mulana_2.0.2.9.exe cd GOG\ Games/La-Mulana WINEDEBUG=+keyboard,+key,+dinput,+message,+win,+tid wine LaMulanaWin.exe 2>&1 | tee LaMulanaWin.xact.log # Wait through the logo and the intro until the title screen menu appears, confirm it's non-responsive, and then click the window manager close button
https://bugs.winehq.org/show_bug.cgi?id=31899
--- Comment #9 from Stephan Sokolow from_wine_bugzilla@ssokolow.com --- Created attachment 50939 --> https://bugs.winehq.org/attachment.cgi?id=50939 WINEDEBUG=+keyboard,+key,+dinput,+message,+win,+tid wine LaMulanaWin.exe in Wine 1.7.34 prefix with xact_jun2010 installed
# Start with the prefix left over from generating the previous log winetricks xact_jun2010 # Without this, La-Mulana is silent WINEDEBUG=+keyboard,+key,+dinput,+message,+win,+tid wine LaMulanaWin.exe 2>&1 | tee LaMulanaWin.xact.log # Wait through the logo (intro is auto-skipped after the first time) until the title screen menu appears, confirm non-responsiveness (and that PulseAudio causes audio to stutter when bare ALSA didn't), close window
https://bugs.winehq.org/show_bug.cgi?id=31899
--- Comment #10 from Stephan Sokolow from_wine_bugzilla@ssokolow.com --- Oh, and I just realized that I forgot to correct the typo in that first set of instructions. (I was sloppy when logging what I did)
"tee LaMulanaWin.log", not "tee LaMulanaWin.xact.log"
https://bugs.winehq.org/show_bug.cgi?id=31899
--- Comment #11 from Sebastian Lackner sebastian@fds-team.de --- The logs unfortunately didn't help much, but I decided to buy the game for debugging purposes. Issue is still present with 1.7.38 and is actually similar to bug 27238 (but most likely not identical). The following hack is sufficient to fix the issue and to get into the game. I also played a little bit, and everything seemed to work well.
diff --git a/dlls/user32/input.c b/dlls/user32/input.c index 1f05f34..03d0a90 100644 --- a/dlls/user32/input.c +++ b/dlls/user32/input.c @@ -750,7 +750,7 @@ SHORT WINAPI DECLSPEC_HOTPATCH GetKeyState(INT vkey)
SERVER_START_REQ( get_key_state ) { - req->tid = GetCurrentThreadId(); + req->tid = 0; // GetCurrentThreadId(); req->key = vkey; if (!wine_server_call( req )) retval = (signed char)reply->state; }
Will investigate this issue a bit further and hopefully come up with a better patch. ;)
https://bugs.winehq.org/show_bug.cgi?id=31899
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |wineserver Depends on| |27238 Summary|No keyboard input in |No keyboard input in |La-Mulana remake |La-Mulana remake | |(GetKeyState should behave | |similar to GetAsyncKeyState | |for specific window | |messages / queue states)
--- Comment #12 from Sebastian Lackner sebastian@fds-team.de --- As already suspected this issue is really very similar to bug 27238. I prefer to keep the separate anyway because they can probably be fixed independently.
The problem is that the GetKeyState(...) implementation of Wine is completely wrong (well, and the MSDN description also). Some testing on Windows 7 turns out that it is not true, that the returned key state is a saved state when the message was originally added. This is only true for specific keyboard-related window messages, but for the rest GetKeyState behaves identical to GetAsyncKeyState, and even recognizes keyboard events typed in into other applications. We'll have to write some additional tests to figure out more exactly how Windows decides what to use.
The reason why the fix for bug 27238 doesn't work in this case: An OLE apartment is initialized on the same thread, and this implicitly creates a window, so the thread has already a message queue. Nevertheless, even when explicitly creating a window it still works on Windows, so the Wine bug must be in GetKeyState itself. Component is most likely the server (in combination with user32).
https://bugs.winehq.org/show_bug.cgi?id=31899
--- Comment #13 from Ken Thomases ken@codeweavers.com --- This is also related to bug 35907, in that the synchronous key state reflected by GetKeyState() changes spontaneously across all processes and threads, whether or not they get the corresponding WM_KEYDOWN.
https://bugs.winehq.org/show_bug.cgi?id=31899
--- Comment #14 from Sebastian Lackner sebastian@fds-team.de --- A fix was added to Wine-Staging: https://github.com/wine-compholio/wine-staging/tree/master/patches/server-Ke...
I ran a lot of manual tests with various self-written test applications and games, and came to the conclusion that my theory is right. Windows internally uses a locking mechanism of the thread input keystate, and under specific circumstances synchronizes it with the global keystate. Some things in the patch might look weird (for example that GetKeyboardState() does _NOT_ synchronize the keystate), but this matches very exactly what Windows does. Will try to clean up the tests during the next time, and integrate them somehow in the wine test suite.
https://bugs.winehq.org/show_bug.cgi?id=31899
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=31899 Bug 31899 depends on bug 27238, which changed state.
Bug 27238 Summary: Tesla: The Weather Man demo: movement keys not working (GetKeyState should fallback to GetAsyncKeyState for threads without message queue) https://bugs.winehq.org/show_bug.cgi?id=27238
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
https://bugs.winehq.org/show_bug.cgi?id=31899
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |STAGED CC| |michael@fds-team.de Ever confirmed|0 |1 Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/server-Key_Sta | |te
https://bugs.winehq.org/show_bug.cgi?id=31899
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/server-Key_Sta |er/patches/server-Key_State |te |
https://bugs.winehq.org/show_bug.cgi?id=31899
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
-
wine-bugs＠winehq.org -
WineHQ Bugzilla