[Bug 47070] New: DA: Inquisition can't see gamepad
https://bugs.winehq.org/show_bug.cgi?id=47070 Bug ID: 47070 Summary: DA: Inquisition can't see gamepad Product: Wine Version: 4.6 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: xinput Assignee: wine-bugs(a)winehq.org Reporter: timofeevsv1989(a)gmail.com Distribution: --- Dragon Age Inquisition uses xinput9_1_0.dll which not implemented properly. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #1 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Can you please provide a +xinput log? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #2 from Timofeev Svyatoslav <timofeevsv1989(a)gmail.com> --- Maybe I can. Where its located? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #3 from Timofeev Svyatoslav <timofeevsv1989(a)gmail.com> --- Other games works fine with my generic gamepad. But implementation of gamepad detection in Inquisition is weird. And also... i cant use x360ce methods and many others - nothing works. I've tried to disable some gamepads in "wine control", but nothing happens. Everything works fine in other games, but nothing with Inquisition. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 Timofeev Svyatoslav <timofeevsv1989(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |ArchLinux -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair(a)hotmail.com --- Comment #4 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Follow these instruction on how to create a log file. https://wiki.winehq.org/FAQ#How_do_I_get_a_debug_trace.3F -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #5 from Timofeev Svyatoslav <timofeevsv1989(a)gmail.com> --- Created attachment 64263 --> https://bugs.winehq.org/attachment.cgi?id=64263 Xinput DAI Log It's in main menu, when I can't press START -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #6 from Timofeev Svyatoslav <timofeevsv1989(a)gmail.com> --- x360ce uses dinput8.dll hack for injecting xinput9_1_0.dll Also specific hooks required too [InputHook] HookMode=1 HookLL=0 HookCOM=1 HookSA=0 HookWT=0 HookDI=1 HookPIDVID=1 HookName=0 [DragonAgeInquisition.exe] Name = Dragon Age: Inquisition HookMask= 0x00000002 I dont know what it means, but maybe it will helpfull -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #7 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- (In reply to Timofeev Svyatoslav from comment #6)
x360ce uses dinput8.dll hack for injecting xinput9_1_0.dll
This means we need different log flags Please create a new log file +dinput,xinput -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 Timofeev Svyatoslav <timofeevsv1989(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #64263|0 |1 is obsolete| | --- Comment #8 from Timofeev Svyatoslav <timofeevsv1989(a)gmail.com> --- Created attachment 64264 --> https://bugs.winehq.org/attachment.cgi?id=64264 Dinput Xinput DAI log Warnings about fails open JoyDevs Still main menu, cant press START -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #9 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- There has been some work in this area which should fix this issue. Please retest when wine 4.8 is released. (Unless you build wine yourself). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #10 from Timofeev Svyatoslav <timofeevsv1989(a)gmail.com> --- (In reply to Alistair Leslie-Hughes from comment #9)
There has been some work in this area which should fix this issue.
Please retest when wine 4.8 is released. (Unless you build wine yourself).
Okay, i'll build my custom PKGBUILD (Tk-Glitch) today, and tell you is it fixed -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #11 from Timofeev Svyatoslav <timofeevsv1989(a)gmail.com> --- (In reply to Alistair Leslie-Hughes from comment #9)
There has been some work in this area which should fix this issue.
Please retest when wine 4.8 is released. (Unless you build wine yourself).
Today I tested it with fresh git PKGBUILD with no luck. Maybe patches not included to repo for now?.. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #12 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- (In reply to Timofeev Svyatoslav from comment #11)
(In reply to Alistair Leslie-Hughes from comment #9)
There has been some work in this area which should fix this issue.
Please retest when wine 4.8 is released. (Unless you build wine yourself).
Today I tested it with fresh git PKGBUILD with no luck.
Maybe patches not included to repo for now?..
Yes the patches where there, It was just an off change it was fixed. Could you provide a +dinput,xinput log please? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 Timofeev Svyatoslav <timofeevsv1989(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #64264|0 |1 is obsolete| | --- Comment #13 from Timofeev Svyatoslav <timofeevsv1989(a)gmail.com> --- Created attachment 64406 --> https://bugs.winehq.org/attachment.cgi?id=64406 New log. Pressed everything in all modes - game does not react. Cant press START -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 sorin.mikaelis255(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sorin.mikaelis255(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #14 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Can you please provide another log with the latest wine 5.5 version? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #15 from sorin.mikaelis255(a)gmail.com --- Created attachment 67308 --> https://bugs.winehq.org/attachment.cgi?id=67308 debug trace with +dinput,xinput ran a debug trace with +dinput,xinput with Wine 5.9 I believe I'm using a different controller from Timofeev, in his trace I'm seeing "generic usb controller" whereas I'm using an Xbox One controller via bluetooth In contrast to his traces there doesn't seem to be any output for xinput, just for dinput. I'm not sure if this is explained by the controller difference, something I did wrong, or something else entirely. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 Berillions <berillions(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |berillions(a)gmail.com --- Comment #16 from Berillions <berillions(a)gmail.com> --- Created attachment 71189 --> https://bugs.winehq.org/attachment.cgi?id=71189 +timestamp,+pid,+seh,+debugstr,+loaddll,+hid,+hidp,+xinput,+dinput,+plugplay The gamepad is still not recognized with wine-6.22. I attach a new log -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 Berillions <berillions(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon(a)codeweavers.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 temp82(a)luukku.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |temp82(a)luukku.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 Cameron Moore <moore.cameron1111(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |moore.cameron1111(a)gmail.com --- Comment #17 from Cameron Moore <moore.cameron1111(a)gmail.com> --- I've been messing around with it a bit. Not fixed, but I think I've found part of the problem.
From what I can tell, it is able to load xinput9_1_0.dll. Without the dll, the game crashes from the start. However, it also uses xinput1_4.dll, but this is not loaded in from what I can tell from +loaddll logs. This seems to be the cause as it is consistent with the behavior on Windows when xinput1_4.dll is not present (stuck on the "Press START" screen with soldiers marching). Possibly the thread that loads the xinput1_4.dll hangs somewhere before reaching the section of code that loads it.
From there, I'm stuck as I can't find a way to attach winedbg to its process without DragonAgeInquisition.exe crashing immediately.
-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #18 from Cameron Moore <moore.cameron1111(a)gmail.com> --- Did not fix it, but it seems to be related to something to do with a few possible things. First off, I was most likely wrong on the previous comment about xinput1_4.dll, it should probably only need xinput9_1_0.dll. The game uses XInputGetState for a certain number of frames at the start. Adding a sleep to the XInputGetState function somehow made it call it more times. On my computer it calls it 10 to 12 times regularly. With a 5 second sleep on the function, it is able to call it around 20 times. It seems that as soon as a thread called "AsyncOpManager" and something like "EAAudioCore Dac" are named / created, XInputGetState is never called again. RegisterRawInputDevices is also called around the time that it stops calling XInputGetState. However, when +relay is used, it never calls XInputGetState at all. This leads me to believe that maybe there is a bug with rawinput or something to do with AsyncOpManager. This is speculation though. Running gdb with it seems fairly unhelpful as when a SIGINT is sent to the application, every thread that is seemingly related to the issue is stopped in a seemingly unrelated place (possibly a signal handler function). Anyway, just putting this out there for anyone else who might look into the bug as I am mentally drained from looking into it at this point. One more helpful point, disable the Origin / EA App in-game-overlay. It injects hooks into the xinput dlls that are most likely unrelated to the problem, probably to get input to the overlay. Some helpful flags for debugging this might include "+seh,+loaddll,+hid,+hidp,+xinput,+dinput,+rawinput,+thread,+threadname". -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 solidnoctis <noctisbennington0(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |noctisbennington0(a)gmail.com --- Comment #19 from solidnoctis <noctisbennington0(a)gmail.com> --- I remember played in another game with Origin launcher, in previous versions of Wine, have a similar problem with my DS4 controller with this. What I did was disable overlay Origin. Maybe we have the same problem here? I can confirm from EA Launcher and Steam, DS4 controller and Steam Deck controller doesn't work, but as one of you said, it's detected by the game definitely. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #20 from Cameron Moore <moore.cameron1111(a)gmail.com> --- Pretty confident I found the actual problem this time. Not sure exactly why it is happening at the moment but I am continuing to look into it. Posting this in case any other people more experienced in Wine development can help pinpoint why this might be happening. Anyway, what seems to be happening is that GetFocus() is called every frame of the game before XInputGetState() can be called. GetFocus() returns the window handle of the that has keyboard focus. However, what happens is that GetFocus() returns NULL after about 10 calls where it correctly returns a window handle. XInputGetState() is called after checking for GetFocus() as long as it is not NULL + the one call after it returns NULL. Therefore, it seems to be assigning keyboard focus to a different thread than is needed. I'm guessing that it is assigning keyboard focus to one of the other threads created after such as the "AsyncOpManager" or "EAAudioCore DAC" but have not checked yet. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #21 from Cameron Moore <moore.cameron1111(a)gmail.com> --- Ok, so I've got a workaround / hack to make it work now. Most definitely not appropriate to integrate into Wine, but here is a link to a Github release if anyone would like to try it out: https://github.com/cammoore1/proton-wine/releases/tag/Workaround. NOTE: the build should only be used for Dragon Age Inquisition as it will probably cause bugs in other programs. I'm not completely sure on the specifics of why the bug happens, but there are two main threads involved. Thread A owns the window object for the game. Thread B makes all the calls to XInputGetState. However, Thread B checks if the window has focus to receive keyboard inputs every frame. Thread B calls AttachThreadInput to attach its message queue to the Thread A's window a few times before the bug starts occurring along with one separate time at the start where Thread A attaches Thread B's message queue to the window as well. The message queue is detached one last time and then Thread B no longer has access to the window. My workaround checks GetFocus for when it starts receiving Null for a response (meaning it does not have access to a window anymore). Prior to this, AttachThreadInput stores the IDs of the two threads which call the function the very first time (hopefully this works with the EA App as I've been debugging this with Origin which doesn't seem to call either of the two WINAPI functions as long as you load straight into the game from the Origin library menu). When GetFocus realizes it does not have a window for the thread, it calls AttachThreadInput with the two thread IDs. This allows Thread B to access the window, which let's GetFocus return the proper window handle, which then let's the program access XInputGetState meaning the controller finally works. Anyway, as far as the final cause of the bug: it might be because of thread prioritization causing Thread B to AttachThreadInput to be called by it last as the only time Thread A calls it, it does not detach the message queue afterwards. This leads me to believe that the bug might just be caused by incomplete wine functionality / stubs. Although, this part is speculation. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #22 from Timofeev Svyatoslav <timofeevsv1989(a)gmail.com> --- (In reply to Cameron Moore from comment #21)
Ok, so I've got a workaround / hack to make it work now. Most definitely not appropriate to integrate into Wine, but here is a link to a Github release if anyone would like to try it out: https://github.com/cammoore1/proton-wine/releases/tag/Workaround. NOTE: the build should only be used for Dragon Age Inquisition as it will probably cause bugs in other programs.
I'm not completely sure on the specifics of why the bug happens, but there are two main threads involved. Thread A owns the window object for the game. Thread B makes all the calls to XInputGetState. However, Thread B checks if the window has focus to receive keyboard inputs every frame. Thread B calls AttachThreadInput to attach its message queue to the Thread A's window a few times before the bug starts occurring along with one separate time at the start where Thread A attaches Thread B's message queue to the window as well. The message queue is detached one last time and then Thread B no longer has access to the window.
My workaround checks GetFocus for when it starts receiving Null for a response (meaning it does not have access to a window anymore). Prior to this, AttachThreadInput stores the IDs of the two threads which call the function the very first time (hopefully this works with the EA App as I've been debugging this with Origin which doesn't seem to call either of the two WINAPI functions as long as you load straight into the game from the Origin library menu). When GetFocus realizes it does not have a window for the thread, it calls AttachThreadInput with the two thread IDs. This allows Thread B to access the window, which let's GetFocus return the proper window handle, which then let's the program access XInputGetState meaning the controller finally works.
Anyway, as far as the final cause of the bug: it might be because of thread prioritization causing Thread B to AttachThreadInput to be called by it last as the only time Thread A calls it, it does not detach the message queue afterwards. This leads me to believe that the bug might just be caused by incomplete wine functionality / stubs. Although, this part is speculation.
Thank you!!! It works! Please push patches to your repo, because it is unclear for some people, which not trust suspicious binaries. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #23 from Cameron Moore <moore.cameron1111(a)gmail.com> --- (In reply to Timofeev Svyatoslav from comment #22)
(In reply to Cameron Moore from comment #21)
Ok, so I've got a workaround / hack to make it work now. Most definitely not appropriate to integrate into Wine, but here is a link to a Github release if anyone would like to try it out: https://github.com/cammoore1/proton-wine/releases/tag/Workaround. NOTE: the build should only be used for Dragon Age Inquisition as it will probably cause bugs in other programs.
I'm not completely sure on the specifics of why the bug happens, but there are two main threads involved. Thread A owns the window object for the game. Thread B makes all the calls to XInputGetState. However, Thread B checks if the window has focus to receive keyboard inputs every frame. Thread B calls AttachThreadInput to attach its message queue to the Thread A's window a few times before the bug starts occurring along with one separate time at the start where Thread A attaches Thread B's message queue to the window as well. The message queue is detached one last time and then Thread B no longer has access to the window.
My workaround checks GetFocus for when it starts receiving Null for a response (meaning it does not have access to a window anymore). Prior to this, AttachThreadInput stores the IDs of the two threads which call the function the very first time (hopefully this works with the EA App as I've been debugging this with Origin which doesn't seem to call either of the two WINAPI functions as long as you load straight into the game from the Origin library menu). When GetFocus realizes it does not have a window for the thread, it calls AttachThreadInput with the two thread IDs. This allows Thread B to access the window, which let's GetFocus return the proper window handle, which then let's the program access XInputGetState meaning the controller finally works.
Anyway, as far as the final cause of the bug: it might be because of thread prioritization causing Thread B to AttachThreadInput to be called by it last as the only time Thread A calls it, it does not detach the message queue afterwards. This leads me to believe that the bug might just be caused by incomplete wine functionality / stubs. Although, this part is speculation.
Thank you!!! It works!
Please push patches to your repo, because it is unclear for some people, which not trust suspicious binaries.
Sorry, just want to make sure what you mean by the patches. Do you mean like the git diff files for the fix or just any changes I did? The actual changes are on the Proton8-17-dai branch. I would like the change to be transparent as well. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 --- Comment #24 from Cameron Moore <moore.cameron1111(a)gmail.com> --- Ok, so I went ahead and just created a branch "fix-from-initial-fork" from the initial commit from GloriousEggroll's proton-wine on Proton8-17 branch that I pulled from and added only the fix to the it. This commit (https://github.com/cammoore1/proton-wine/commit/defdddcbc068f7b376181272603e...) shows the only changes that the fix requires in case anyone wants to see the patch differences. Other than that, if anyone needs to build it themselves to avoid using the binaries provided. Then you can clone the GloriousEggroll/wine-ge-custom repo and follow the build instructions listed there except with the following line: ./makebuild.sh <whatever-name-you-want> https://github.com/cammoore1/proton-wine fix-from-initial-fork Updated release URL without certain debug traces added from the previous link: https://github.com/cammoore1/proton-wine/releases/tag/Workaround-v1.0.1 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47070 goremukin(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |goremukin(a)gmail.com --- Comment #25 from goremukin(a)gmail.com --- (In reply to Cameron Moore from comment #24)
Ok, so I went ahead and just created a branch "fix-from-initial-fork" from the initial commit from GloriousEggroll's proton-wine on Proton8-17 branch that I pulled from and added only the fix to the it. This commit (https://github.com/cammoore1/proton-wine/commit/ defdddcbc068f7b376181272603ead5053bb0276) shows the only changes that the fix requires in case anyone wants to see the patch differences.
Other than that, if anyone needs to build it themselves to avoid using the binaries provided. Then you can clone the GloriousEggroll/wine-ge-custom repo and follow the build instructions listed there except with the following line:
./makebuild.sh <whatever-name-you-want> https://github.com/cammoore1/proton-wine fix-from-initial-fork
Updated release URL without certain debug traces added from the previous link: https://github.com/cammoore1/proton-wine/releases/tag/Workaround-v1.0.1
Hi! Your build works like a charm, thank you very much! When exiting the game, an exception is thrown, but in this case it is enough to suppress the crash dialogue using winetricks nocrashdialog -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla