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@winehq.org Reporter: timofeevsv1989@gmail.com Distribution: ---
Dragon Age Inquisition uses xinput9_1_0.dll which not implemented properly.
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #1 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Can you please provide a +xinput log?
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #2 from Timofeev Svyatoslav timofeevsv1989@gmail.com --- Maybe I can. Where its located?
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #3 from Timofeev Svyatoslav timofeevsv1989@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.
https://bugs.winehq.org/show_bug.cgi?id=47070
Timofeev Svyatoslav timofeevsv1989@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |ArchLinux
https://bugs.winehq.org/show_bug.cgi?id=47070
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair@hotmail.com
--- Comment #4 from Alistair Leslie-Hughes leslie_alistair@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
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #5 from Timofeev Svyatoslav timofeevsv1989@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
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #6 from Timofeev Svyatoslav timofeevsv1989@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
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #7 from Alistair Leslie-Hughes leslie_alistair@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
https://bugs.winehq.org/show_bug.cgi?id=47070
Timofeev Svyatoslav timofeevsv1989@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #64263|0 |1 is obsolete| |
--- Comment #8 from Timofeev Svyatoslav timofeevsv1989@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
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #9 from Alistair Leslie-Hughes leslie_alistair@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).
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #10 from Timofeev Svyatoslav timofeevsv1989@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
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #11 from Timofeev Svyatoslav timofeevsv1989@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?..
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #12 from Alistair Leslie-Hughes leslie_alistair@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?
https://bugs.winehq.org/show_bug.cgi?id=47070
Timofeev Svyatoslav timofeevsv1989@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #64264|0 |1 is obsolete| |
--- Comment #13 from Timofeev Svyatoslav timofeevsv1989@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
https://bugs.winehq.org/show_bug.cgi?id=47070
sorin.mikaelis255@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sorin.mikaelis255@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #14 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Can you please provide another log with the latest wine 5.5 version?
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #15 from sorin.mikaelis255@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.
https://bugs.winehq.org/show_bug.cgi?id=47070
Berillions berillions@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |berillions@gmail.com
--- Comment #16 from Berillions berillions@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
https://bugs.winehq.org/show_bug.cgi?id=47070
Berillions berillions@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=47070
temp82@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |temp82@luukku.com
https://bugs.winehq.org/show_bug.cgi?id=47070
Cameron Moore moore.cameron1111@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |moore.cameron1111@gmail.com
--- Comment #17 from Cameron Moore moore.cameron1111@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.
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #18 from Cameron Moore moore.cameron1111@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".
https://bugs.winehq.org/show_bug.cgi?id=47070
solidnoctis noctisbennington0@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |noctisbennington0@gmail.com
--- Comment #19 from solidnoctis noctisbennington0@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.
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #20 from Cameron Moore moore.cameron1111@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.
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #21 from Cameron Moore moore.cameron1111@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.
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #22 from Timofeev Svyatoslav timofeevsv1989@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.
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #23 from Cameron Moore moore.cameron1111@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.
https://bugs.winehq.org/show_bug.cgi?id=47070
--- Comment #24 from Cameron Moore moore.cameron1111@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
https://bugs.winehq.org/show_bug.cgi?id=47070
goremukin@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |goremukin@gmail.com
--- Comment #25 from goremukin@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
-
wine-bugs＠winehq.org -
WineHQ Bugzilla