Emulator Issues #11702
closedDolphin not reading Keyboard/Mouse inputs
0%
Description
Game Name?
N/A
Game ID? (right click the game in the game list, Properties, Info tab)
N/A
MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)
N/A
What's the problem? Describe what went wrong.
Dolphin is not recognizing inputs from Keyboard or Mouse. Gamepad reads correctly. Applies to menus, key config, and in-game.
What steps will reproduce the problem?
Attempt to use keyboard or Mouse input
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
yes, 100075
Is the issue present in the latest stable version?
no
If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)
First broken in 9876 [InputCommon: Fix Win32 init race. (PR #7951 from jordan-woyak)]
If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer
N/A
What are your PC specifications? (CPU, GPU, Operating System, more)
i7-8700k
NVIDIA 1080Ti
Win10 x64
Keyboard: Logitech G19s
Mouse: Logitech G502 (latest revision)
Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)
N/A
Files
Updated by JosJuice over 5 years ago
- Milestone set to Current
- Regression changed from No to Yes
- Regression start set to 5.0-9876
Updated by gamerk2 over 5 years ago
Update: I think it's a suspend issue; I did a cold boot of my PC and inputs read fine now. I'm guessing the keyboard/mouse aren't being detected properly post suspend; I've had issues in the past with this. Behavior has changed since previous builds however.
Updated by gamerk2 over 5 years ago
Update (again): Huh; it worked once; I restarted Dolphin and inputs aren't reading again.
Updated by Billiard26 over 5 years ago
Anything in Dolphin's log when input isn't working?
Does the "Refresh" button fix the problem?
Updated by gamerk2 over 5 years ago
I don't see anything going to the log; its like the emulator doesn't even recognize the devices in the first place.
Refresh doesn't fix the problem.
Updated by tossapon over 5 years ago
I also have this issue. Dolphin not even receive any input from both mouse and keyboard since 5.0-9876 version onward.
The controller configuration dialog does not even recognize the keyboard key press.
Updated by Billiard26 over 5 years ago
Can you please show a screenshot of your mapping dialog when input is not working.
Updated by tossapon over 5 years ago
- File Untitled.png Untitled.png added
There's the screenshot if you want to look.
Also in the 5.0-9874, the configuration dialog is working after the program started, the input itself is not actually working ingame. The latest version I confirmed to be working is 5.0-9865.
Updated by Billiard26 over 5 years ago
Input works before you start the game but not after you start the game?
So that screenshot is after you have started a game?
Updated by tossapon over 5 years ago
After more testing in 9874, the input seems to be working if I enter the game right away after open the emulator.
But there are cases where it stopped working...
- Start the emulator then open the configuration dialog work then closes the dialog then open again and it now stopped working.
- Start the emulator then run the game, the input is working but then closes the game and open the configuration dialog then it stopped working.
- Start the emulator then run the game, the input is working but after closes the game and run the game again, now it stopped working.
The cases above seems to point that the input only work once then broke after next time it used. This does not seems to be the case in 9865.
Updated by Billiard26 over 5 years ago
So the screenshot is after you have started a game or opened the dialog more than once?
Let me reiterate, I want to see the situation when input is currently broken, else the screenshot is counterproductive.
Updated by tossapon over 5 years ago
That screenshot is actually from 10086 and the previous comment is from 9874 where I tested the cases when it only working once per startup(I have to completely closes the emulator then reopen for the input to be working again).
I tested past revision from 9876-10086 and all of them seems to be broken and never working even once.
The one that is working once are 9869-9874 from the situation I stated in the previous comment.
For more information, revision 9869 change log is "Add hotplug support to DInput and XInput controller backends" which I suspect to be the problem. Then from 9876 onward(something about win32 racing), it seems to be completely broken for me.
Updated by gamerk2 over 5 years ago
- File Capture.PNG Capture.PNG added
Confirmed, last version that works reliably is 9865. Starting from 9869 you can sometimes map inputs but they don't seem to work once you open the config or quit a game. Starting from 9876 you can't map inputs period.
I have a suspicion what the problem is. I looked at all my keyboard and mouse devices and I have several duplicate entries for both listed in device manager and other utilities I have that check for directinput devices (ditool). I'm wondering if that's causing a problem as of release 9869. I've attached a screenshot for what devices I'm picking up; you can see the duplicate keyboard and mouse devices.
Updated by tossapon over 5 years ago
- File Untitled.png Untitled.png added
Yes, I have duplicate input devices too. See in the screenshot.
Updated by gamerk2 over 5 years ago
I tried removing all unused USB drivers, and reinstalled the drivers for my keyboard and mouse, and don't see any difference in performance. Not sure what else I can try on my end.
Updated by gamerk2 over 5 years ago
Suspicion confirmed. I think I've got a brute force workaround as well.
First off, I'm using 10132 as a base. In this version, input assignment works until the refresh button is clicked or a game is launched, in which case inputs stop working again.
What I'm seeing is this: My Keyboard/Mouse is definitely being picked up as multiple devices, and post PR7776 it looks like the code isn't accounting that multiple keyboard/mice as a possibility. Inputs work on Dolphin Init by accident; Dinput::PopulateDevices() is getting invoked twice and picks up the second device input the second time through. Once a game is started OR the refresh button is hit, Dinput::PopulateDevices() only gets invoked once and the second keyboard/mouse device never gets detected again.
I revoked some of the PR changes, and initial testing shows the problem is resolved, though likely breaking the intent of the PR for DirectInput devices in the process. I made the following changes:
ControllerInterface.ccp: Remove the entirety of PR7776.
DinputKeyboardMouse.ccp: Remove the check for duplicate devices (all instances of the use of bool s_keyboard_mouse_exists).
Note there is still a difference between an init and device refresh; on init two separate Dinput device entries are listed (Dinput/0/Keyboard Mouse and Dinput/1/Keyboard Mouse), but after a refresh only the first is listed. Inputs still work though, but I dislike an init and refresh are giving different results.
Someone smarter then me is going to have to come up with a proper solution. I can test whatever they come up with to confirm it works.
Updated by gamerk2 over 5 years ago
OBE. Far as I can tell even builds that were not working before are working properly now for me. I'm guessing MSFT did something on their end; only other update I've done recently is a JVE update and I can't imagine that would effect anything...
Updated by JosJuice over 5 years ago
- Has duplicate Emulator Issues #11766: Keybaord not responsive since build 9876 added
Updated by Geroyuni over 5 years ago
I'm still having that issue (Dolphin 5.0-10906, W10 1903 18362.295) with similar behavior (works only until I start a game or click refresh). The difference is versions before 9876 won't work at all, not even before the game starts (though it used to work).
Updated by Billiard26 about 5 years ago
- Related to Emulator Issues #11884: Keyboard hotkeys don't work, and weird behaviour in hotkey settings added
Updated by darkl3ad3r about 5 years ago
This is still happening for me on the latest builds as of 12/21/2019 5:00 AM. I have to refresh my hotkeys page or my keyboard does not work and I cannot use my ALT + ENTER combo to switch to fullscreen or press ESC to end emulation like I always have for the last 12 years. Is there anything being looked at to resolve this issue? I'm just glad I thought to search the Dolphin bug tracker because I was really starting to think it was my computer/keyboard that were failing and it turns out to be a hard bug in Dolphin instead. At least there's some relief there.
Updated by Billiard26 almost 5 years ago
- Operating system Windows added
- Operating system deleted (
N/A)
Updated by darkl3ad3r over 4 years ago
Still happening as of 2020-07-15. This is a pretty big regression devs, how come no one seems to care?
Updated by Billiard26 over 4 years ago
No developer can reproduce the issue.
Providing more information could help.
Show a screenshot of your mapping dialog WHILE input is not currently working.
Attach your Dolphin log file.
Updated by filoppi over 4 years ago
This PR seems to have improved the situation (at least on my machine) https://github.com/dolphin-emu/dolphin/pull/8795
but the issue is still present. I've been investigating with no success. The keyboard and mouse device is created correctly but calls like:
HRESULT mo_hr = m_mo_device->GetDeviceState(sizeof(tmp_mouse), &tmp_mouse);
return a blank input, so there is a small chance the problem is with DInput, though the person that opened the bug said it didn't happen before https://github.com/dolphin-emu/dolphin/pull/7951
Updated by gamerk2 over 4 years ago
Can't really comment since I haven't used Dolphin in a few months; I'll take a look sometime in the next few days and see if the issue is happening to me again.
It might also be worth noting what input devices you are using; in my case both devices at issue were Logitech devices; there might be some commonality there.
Updated by darkl3ad3r about 4 years ago
I've been keeping tabs on this problem and I can positively say I have not had to manually refresh the device list under the Hotkeys menu in at least a couple/few months. I wish I had something specific to point to as when it became resolved, but I can only state that it is 100% Dolphin that broke it and Dolphin that resolved it. There have been virtually no changes to my PC's hardware setup in nearly 4 years, and very limited software changes (a fresh OS install back in April with monthly patches from Microsoft, and driver updates to my graphics card exclusively) along the way.
I think it might be safe to close this one. Can anyone chime in if they're still getting this issue?
Updated by traviskaufman about 4 years ago
I can confirm this issue is still occurring for me. I am trying to add a new keyboard shortcut, and that's how I ran into this issue.
I'm compiling Dolphin from source and running from the Release version of the build.
I've experienced multiple issues. Namely:
-
Most hotkeys don't seem to work. Notable exceptions are open (CTRL+O), as well as the Save Register
-
Some hotkeys work the "Escape" hotkey works except it pauses the game, even though it's mapped to "Stop".
-
If I go to Options -> Controller Settings -> Gamecube Controllers and change "Port 1" to Keyboard, the Game window does not receive any input whatsoever. I have to leave it on "Standard Controller" for it to work.
-
I've tried cold-booting my PC and trying again, didn't do anything.
Specs:
CPU - AMD Ryzen 5 3600 6-Core
GPU - NVIDIA GeForce RTX 2070
OS - Windows 10 (x64) v1909 (OS Build 18363.1198)
Keyboard - Skytech K-1000 Gaming Keyboard
Mouse - Skytech M-1000 Gaming Mouse
Notes:
I'm happy to look into a fix for this, but I'd need someone with more experience in the codebase to point me in the right direction. I don't have the bandwidth to hunt through PRs to identify the issue and the Dolphin codebase seems very large and has undergone a lot of evolution so it's hard to pin down where one might make the change :)
Updated by traviskaufman about 4 years ago
Log from starting up Super Smash Bros. Melee, and trying to do a few keyboard shortcuts, all of which failed and/or behaved erratically:
15:33:829 Core\ConfigManager.cpp:694 N[CORE]: Active title: Super Smash Bros. Melee (GALE01)
15:33:832 Core\Core.cpp:998 N[COMMON]: Want determinism <- false
15:33:838 InputCommon\ControllerInterface\ControllerInterface.cpp:225 N[SI]: Added device: DInput/0/Keyboard Mouse
15:37:347 beb\src\cubeb_wasapi.cpp:1332 N[Audio]: default device period: 100000
15:37:347 beb\src\cubeb_wasapi.cpp:1340 N[Audio]: Minimum latency in frames: 480
15:37:347 beb\src\cubeb_wasapi.cpp:1679 N[Audio]: (000002916E76E740) Setup render: device=0000000000000000
15:37:349 beb\src\cubeb_wasapi.cpp:1587 N[Audio]: Setup requested=[f=0 r=48000 c=2 l=stereo] mix=[f=0 r=48000 c=2 l=stereo]
15:37:381 beb\src\cubeb_wasapi.cpp:1730 N[Audio]: Target sample rate: 48000
15:37:385 beb\src\cubeb_wasapi.cpp:151 N[Audio]: COM was already initialized in MTA
15:37:390 beb\src\cubeb_wasapi.cpp:1190 N[Audio]: Stop and join render thread.
15:37:390 beb\src\cubeb_wasapi.cpp:1233 N[Audio]: Closing thread.
15:37:390 Core\Boot\Boot.cpp:420 N[BOOT]: Booting from disc: C:/Users/Travis/true3d/Data/dolphin-games/Super Smash Bros. Melee (USA) (En,Ja) (v1.02).iso
15:37:398 Core\HLE\HLE_OS.cpp:85 N[OSREPORT]: 81200308->81300000|
15:37:398 Core\HLE\HLE_OS.cpp:85 N[OSREPORT]: 81200324->81300000| This Apploader built Nov 14 2001 02:04:39
15:37:521 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]:
15:37:522 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: Dolphin OS $Revision: 47 $.
15:37:523 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: Kernel built : Nov 12 2001 01:46:17
15:37:524 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: Console Type : Development HW3
15:37:524 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: Memory 24 MB
15:37:525 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: Arena : 0x804eec00 - 0x817f8ac0
15:37:547 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: app booted from bootrom
15:38:379 beb\src\cubeb_wasapi.cpp:377 N[Audio]: Audio device property value changed.
15:39:696 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: # ---------------------------------------------
15:39:696 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: # Super Smash Bros. Melee
15:39:696 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: #
15:39:697 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: # Distribution 1
15:39:697 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: # Language 1
15:39:697 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: # DbLevel 0
15:39:697 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: # Arena Size 19 MB
15:39:697 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: # ARAM Free Size 9 MB
15:39:698 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: # DATE Feb 13 2002 TIME 22:06:27
15:39:699 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: # GC Calendar Year 2020 Month 12 Day 1
15:39:699 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: # Hour 18 Min 15 Sec 34
15:39:699 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]: #
15:39:700 Core\HW\EXI\EXI_DeviceIPL.cpp:308 N[OSREPORT]:
15:53:882 beb\src\cubeb_wasapi.cpp:1190 N[Audio]: Stop and join render thread.
15:53:883 beb\src\cubeb_wasapi.cpp:1233 N[Audio]: Closing thread.
15:56:940 beb\src\cubeb_wasapi.cpp:1190 N[Audio]: Stop and join render thread.
15:56:941 beb\src\cubeb_wasapi.cpp:1233 N[Audio]: Closing thread.
15:58:063 beb\src\cubeb_wasapi.cpp:1190 N[Audio]: Stop and join render thread.
15:58:063 beb\src\cubeb_wasapi.cpp:1192 N[Audio]: No thread present.
15:58:063 beb\src\cubeb_wasapi.cpp:1190 N[Audio]: Stop and join render thread.
15:58:063 beb\src\cubeb_wasapi.cpp:1192 N[Audio]: No thread present.
15:58:091 VideoBackends\D3D\D3DBase.cpp:161 N[Video]: Successfully released all device references!
15:58:201 InputCommon\ControllerInterface\ControllerInterface.cpp:225 N[SI]: Added device: DInput/0/Keyboard Mouse
Updated by traviskaufman about 4 years ago
Ah so I did not realize that _trans(...) within HotkeyManager.cpp has to be in the same position as its corresponding enum in HotkeyManager.h (why would I lol), so that fixed my issue, and now hotkeys seem to be working. Sorry :sweat_smile:
Updated by filoppi almost 4 years ago
I originally commented that this already merged PR https://github.com/dolphin-emu/dolphin/pull/9326 didn't fix the problem (other issues made me think so) but it seems to have, at least I haven't had the bug in the last day but it always comes and goes.
Would be nice if others that had the bug tested it to.
Updated by gerp almost 4 years ago
still got the same thing happening over here, from 9869 onwards, not even the latest versions work
Updated by filoppi almost 4 years ago
filoppi wrote:
I originally commented that this already merged PR https://github.com/dolphin-emu/dolphin/pull/9326 didn't fix the problem (other issues made me think so) but it seems to have, at least I haven't had the bug in the last day but it always comes and goes.
Would be nice if others that had the bug tested it to.
Had the bug a few times again, though very very rarely, it's hard to reproduce at the moment. I have a few ideas so I will look into it some more. I'm not even sure that it's the same bug because some users have it all the times while others rarely? Hopefully it is.
Updated by a97 almost 4 years ago
Still a problem as of 5.0-13770. Every time I start emulation I have to alt-tab back to the main dolphin window, then click through Controllers > Configure > Refresh. I have to do it while the game is running and I have to do it again every time I stop and start emulation. How about you add a checkbox to the hack options to auto-run whatever code that Refresh button does on emulation start?
Updated by filoppi almost 4 years ago
a97 wrote:
Still a problem as of 5.0-13770. Every time I start emulation I have to alt-tab back to the main dolphin window, then click through Controllers > Configure > Refresh. I have to do it while the game is running and I have to do it again every time I stop and start emulation. How about you add a checkbox to the hack options to auto-run whatever code that Refresh button does on emulation start?
Do you know how to build from source?
Try out this branch, I'm fairly sure I fixed it but the problem rarely happens on my machine so I can't be sure:
https://github.com/dolphin-emu/dolphin/pull/9489/
Updated by a97 almost 4 years ago
Also want to note this only happens when my only input device is the keyboard. When I plug in a usb controller the problem goes away.
filoppi wrote:
Do you know how to build from source?
Try out this branch, I'm fairly sure I fixed it but the problem rarely happens on my machine so I can't be sure:
https://github.com/dolphin-emu/dolphin/pull/9489/
I've never tried to build dolphin before, but maybe I might give it shot here at some point. We'll see.
Updated by filoppi almost 4 years ago
I can send you a build if you give me a way to contact you.
Updated by filoppi almost 4 years ago
a97 wrote:
Also want to note this only happens when my only input device is the keyboard. When I plug in a usb controller the problem goes away.
filoppi wrote:
Do you know how to build from source?
Try out this branch, I'm fairly sure I fixed it but the problem rarely happens on my machine so I can't be sure:
https://github.com/dolphin-emu/dolphin/pull/9489/I've never tried to build dolphin before, but maybe I might give it shot here at some point. We'll see.
We do need someone that can reproduce the bug to test it after all.
Updated by a97 almost 4 years ago
Hmmm... I was just about to try building it myself. But I decided to make sure I could still reproduce the problem. I couldn't. I unplugged my usb gamepad and also tried renaming the config folder (Documents/Dolphin Emulator) to reset it but the bug is no longer reproduceable. It seems that plugging in a usb controller in just once and using it in dolphin fixes the issue. Maybe could try running a fresh install in a VM or something without any peripherals plugged in would be able to reproduce the issue.
Updated by filoppi almost 4 years ago
Pretty sure that deleting "Documents/Dolphin Emulator" is enough. Try with both a controller plugged in and without.
When is the last time you could reproduce it then?
Updated by a97 almost 4 years ago
I renamed that folder and it reset my config but the bug was not reproduceable idk why. I was able to reproduce it 100% before I plugged in my usb gamepad. After that 0%.
Updated by a97 almost 4 years ago
And yeah just to be clear I renamed the folder AND unplugged the usb gamepad.
Updated by a97 almost 4 years ago
Maybe Windows is keeping track of that usb info in a registry key or something?
Updated by filoppi almost 4 years ago
No. I can't see any relationship between the bug and anything outside of dolphin. Not even the config should have any influence. The only thing that can impact the bug is whether a DInput controller is plugged in.
Try to restart your PC maybe.
Updated by a97 almost 4 years ago
OK I was able to reproduce after unplugging+shutting down+starting my pc.
The pull request did NOT fix the problem.
Here are the steps I took:
git clone https://github.com/dolphin-emu/dolphin .
git fetch origin pull/9489/head:pr9489
git checkout pr9489
git submodule update --init
--build in visual studio
--install NSIS
--comment out line 143 in Installer.nsi
--run Installer.nsi
And yeah Dolphin [pr9489] still had the problem. I had to click "Controllers > Configure > Refresh" after starting the game to get the keyboard to work.
Updated by filoppi almost 4 years ago
a97 wrote:
OK I was able to reproduce after unplugging+shutting down+starting my pc.
The pull request did NOT fix the problem.
Here are the steps I took:git clone https://github.com/dolphin-emu/dolphin . git fetch origin pull/9489/head:pr9489 git checkout pr9489 git submodule update --init --build in visual studio --install NSIS --comment out line 143 in Installer.nsi --run Installer.nsi
And yeah Dolphin [pr9489] still had the problem. I had to click "Controllers > Configure > Refresh" after starting the game to get the keyboard to work.
Interesting. Thank you very much for testing. I'm out of idea. It doesn't seem to be a threading problem then, given that everything is thread safe now.
Not sure what the installer lines are for but I guess you were actually running my version.
So does the keyboard work in the controller config panels BEFORE starting a game for the first time? Then you need to refresh the inputs after starting a game? What about after stopping the game? Do you need to refresh once again to get it to work?
Did you also have a controller plugged in? Does it happen with and without?
Updated by filoppi almost 4 years ago
Ok you already said you also need to do it after the emulation stop. Which hints it's either related to the "Window handle" or to something broken inside "PopulateDevices()" though it's likely the first, as refreshing devices calls "PopulateDevices()" just like changing the window.
Can you see the "Keyboard Mouse" device in the list while input is broken?
Updated by filoppi almost 4 years ago
Also can you check the log? Enable "SerialInterface" and see if it prints out anything.
Updated by filoppi almost 4 years ago
I've added some more logs to my branch, if you want to try again, enable the log category: "ControllerInterface" (it has been renamed in my branch). That would be of great help. Thanks.
Updated by a97 almost 4 years ago
I did some more testing:
With the pr9489 build the workaround no longer works. Clicking "Controllers > Configure > Refresh" no longer actually does anything. While game is running I could press one hotkey before it failed. Then I had to stop emulation / start emulation / to get a single hotkey to work before it failed again.
So does the keyboard work in the controller config panels BEFORE starting a game for the first time? Yes.
Then you need to refresh the inputs after starting a game? Not anymore.
What about after stopping the game? I could then start emulation to get a single hotkey to work before it failed again.
Do you need to refresh once again to get it to work? Not anymore.
Did you also have a controller plugged in? No.
Does it happen with and without? When the controller is plugged in and I use a new config folder everything is fixed.
Can you see the "Keyboard Mouse" device in the list while input is broken? Yes.
SerialInterface prints this in the log on game load. Nothing is printed when hotkey is pressed.
31:46:430 Core\HW\SI\SI_DeviceGCController.cpp:81 I[SI]: PAD - Get Origin
31:46:432 Core\HW\SI\SI_DeviceGCController.cpp:322 I[SI]: PAD 0 set to mode 3
31:46:433 Core\HW\SI\SI_DeviceGCController.cpp:94 I[SI]: PAD - Recalibrate
31:46:433 Core\HW\SI\SI_DeviceGCController.cpp:322 I[SI]: PAD 0 set to mode 3
I will try the new branch now.
Updated by filoppi almost 4 years ago
Sorry, I've just updated my branch again.
If you have discord, your me your username at bhqrkomi@sharklasers.com, so we can communicate quicker.
Updated by a97 almost 4 years ago
I had to actually go do the Controllers/Config/Refresh button for some reason this time. It then failed to work after a single hotkey use and would not work again until after stop/restarting/refreshing again.
git fetch origin pull/9489/head:9489-2
git checkout 9489-2
git submodule update --init
Controller Interface log:
Notice/Error/Warning:
53:13:769 InputCommon\ControllerInterface\ControllerInterface.cpp:296 N[CI]: Added device: DInput/0/Keyboard Mouse
Info:
55:01:226 InputCommon\ControllerInterface\DualShockUDPClient\DualShockUDPClient.cpp:596 I[CI]: DualShockUDPClient PopulateDevices
Updated by a97 almost 4 years ago
Seems to be back to not needing to press the refresh button. But still fails after a single hotkey is pressed and needs to be restarted again.
git fetch origin pull/9489/head:9489-3
git checkout 9489-3
git submodule update --init
Controller Interface log:
Notice/Error/Warning:
07:24:405 InputCommon\ControllerInterface\ControllerInterface.cpp:296 N[CI]: Added device: DInput/0/Keyboard Mouse
Info:
07:43:931 InputCommon\ControllerInterface\DualShockUDPClient\DualShockUDPClient.cpp:596 I[CI]: DualShockUDPClient PopulateDevices
Updated by a97 almost 4 years ago
That test 3 was using 44ba7ca
https://github.com/dolphin-emu/dolphin/pull/9489/commits/44ba7ca
Updated by a97 almost 4 years ago
Let me know if there's anything else and I'll try again tomorrow.
Updated by a97 almost 4 years ago
Also want to note that the DualShock Info log is strange as the controller is not plugged in at the moment.
Updated by filoppi almost 4 years ago
- File Dolphin_teeWhnMe3l.png Dolphin_teeWhnMe3l.png added
Are you actually trying Hotkeys, like save states and stuff like that? Or do you just mean keyboard keys?
You should try controller inputs, go inside the view linked in the screenshot, and check whether they become red/1. Do both mouse and keyboard inputs not work?
I did have an idea which would avoid destroying and recreating the device upon changing the emulator main window, but it would be a hack and wouldn't really fix the actual problem, which I'm very intrigued in fixing.
From your information, and my research, it seems to be a timing problem, and maybe whether a controller is attached plays a role. I'm "100%" sure my changes fixed any thread timing dependency, so the only thing left that it could be, is whether DInput actually fails to release and re-aquire a device when not enough time passes between the two, but that would be insane. The fact that sometimes it works on your machine, suggests that it's not your version of Windows or a .dll that breaks it.
The fact that you don't even have an error in your log is pretty insane, because I have not idea what is not working.
I did manage to reproduce the bug some months back, and basically the "keyboard->GetState(state)" function was returning a blank/default state, same for the mouse. I'm quite sure the problem is still there.
What's even weirder is that input breaks after the first key is pressed? That makes even little sense, but I hope you have tested multiple times.
The dualshock UDP log just means you have the UDP Client on and doesn't really play a role here.
One thing you should try to do is connecting a DInput or XInput device, like a DS4 or xbox controller, while the KeyboardMouse has stopped working, and see if that also fixes the problem. Devices are refreshed every time Windows sends a message that a new device has been connected/disconnected.
If you want to keep helping with this, it would be very nice to chat somewhere quicker, you can either join the #dolphin-dev channel on irc or send me a contact at that generated email address.
Updated by a97 almost 4 years ago
git fetch origin pull/9489/head:9489-5dc8cf0
git checkout 9489-5dc8cf0
git submodule update --init
--I figured out why I had to comment out the line in Installer.nsi and fixed it. It now fully builds the installer without issue.
OK I have isolated my problem further. The issue is with the hotkey for fullscreen. All other hotkeys and controller buttons work. However if I use the fullscreen hotkey, it goes fullscreen but everything stops working (including trying to press the fullscreen hotkey again). If I use the "FullScr" button on the toolbar it comes out of fullscreen and all the hotkeys/controller buttons work again. So I guess the problem might be with the implementation of the fullscreen hotkey.
Updated by a97 almost 4 years ago
filoppi wrote:
One thing you should try to do is connecting a DInput or XInput device, like a DS4 or xbox controller, while the KeyboardMouse has stopped working, and see if that also fixes the problem. Devices are refreshed every time Windows sends a message that a new device has been connected/disconnected.
I tried this but it didn't fix the problem.
Updated by a97 almost 4 years ago
filoppi wrote:
One thing you should try to do is connecting a DInput or XInput device, like a DS4 or xbox controller, while the KeyboardMouse has stopped working, and see if that also fixes the problem. Devices are refreshed every time Windows sends a message that a new device has been connected/disconnected.
I tried this but it didn't fix the problem.
Updated by filoppi almost 4 years ago
a97 wrote:
git fetch origin pull/9489/head:9489-5dc8cf0
git checkout 9489-5dc8cf0
git submodule update --init
--I figured out why I had to comment out the line in Installer.nsi and fixed it. It now fully builds the installer without issue.OK I have isolated my problem further. The issue is with the hotkey for fullscreen. All other hotkeys and controller buttons work. However if I use the fullscreen hotkey, it goes fullscreen but everything stops working (including trying to press the fullscreen hotkey again). If I use the "FullScr" button on the toolbar it comes out of fullscreen and all the hotkeys/controller buttons work again. So I guess the problem might be with the implementation of the fullscreen hotkey.
Ok. Thanks. Ignore the fullscreen stuff and key because that doesn't really affect the problem and there are other changes in my branch.
So are you saying the problem is fixed on my branch after the last commit? Or were you just talking about the Fullscreen Hotkey not being a problem anymore? Have you tried after restarting your PC?
Updated by a97 almost 4 years ago
Yeah I think my problem was just that the fullscreen hotkey was messing things up. Everything else seems fine.
Updated by a97 almost 4 years ago
a97 wrote:
Yeah I think my problem was just that the fullscreen hotkey was messing things up. Everything else seems fine.
I just didn't realize this because I had been using that hotkey as my test subject.
Updated by filoppi almost 4 years ago
Just to confirm. The problem IS present in the main latest release of Dolphin, but not on my branch? Just wanna be sure you didn't mean that you always accidentally tested the wrong button.
Updated by a97 almost 4 years ago
Just retested the fullscreen hotkey using new config folders and your branch didn't work (it had the problem) and the latest dolphin-master-5.0-13792-x64 worked fine (did not have the problem).
Regardless, the lag introduced by dolphin-master-5.0-9869-x64 is unbearable to me and so the only playable version of dolphin for me is dolphin-master-5.0-9865-x64.
Had to scroll all the way back to https://dolphin-emu.org/download/list/master/70 to find it.
Updated by filoppi almost 4 years ago
Ok, the fullscreen hotkey problem in my branch is not really relevant here, I've made some changes to that stuff and the work is not finished.
But my attempts to fix the KeyboardMouse not working are finished and clean.
The lag introduced by build dolphin-master-5.0-9869-x64 is also not relevant.
I'm even more confused now. Did you actually this issue (number 11702) when you first commented a few days ago, or were your problems always exclusively with fullscreen hotkey?
I can't be 100% sure but the config file doesn't really play a role here, as the devices code isn't really linked to it, it's something that happens after.
As previously mentioned, you should check the controllers config panel that I linked in a screenshot above. If that always works, then you don't have this issue at all. If that only works in my branch, then the problem has been fixed in my branch.
Updated by gamerk2 almost 4 years ago
The original issue I wrote this against is still OBE for me. That being said, even when the issue went away I saw some weirdness within PopulateDevices(). I'll take a look at what the latest code is doing sometime today if I ever get some free time and see if that's still the case; if so maybe that's a hint to what's going on or at least where to look.
Updated by filoppi almost 4 years ago
gamerk2 wrote:
The original issue I wrote this against is still OBE for me. That being said, even when the issue went away I saw some weirdness within PopulateDevices(). I'll take a look at what the latest code is doing sometime today if I ever get some free time and see if that's still the case; if so maybe that's a hint to what's going on or at least where to look.
I've been investigating this on and off for months. I seems like the situation has improved, and it could even be fixed already, as it's easy to get confuse and attribute other problems to this.
That said, the issue is not exactly (directly) in PopulateDevices(), even if that code isn't very thread safe.
The exact issue has been described here: https://bugs.dolphin-emu.org/issues/11702#note-25
Updated by a97 almost 4 years ago
I mention dolphin-master-5.0-9869-x64 because the commit that introduced it was:
Add hotplug support to DInput and XInput controller backends
https://github.com/dolphin-emu/dolphin/pull/7776
I feel like that might be the root cause of all these problems people keep reporting.
Updated by a97 almost 4 years ago
Also want to mention that my original problem had to with a keyboard only setup and didn't have anything to do with the fullscreen hotkey.
Updated by a97 almost 4 years ago
At least I don't think it did. Lol, now I can't remember.
Updated by a97 almost 4 years ago
I'll do a cold boot with my usb controller to retest from scratch again just to verify for y'all.
Updated by a97 almost 4 years ago
a97 wrote:
I'll do a cold boot with my usb controller unplugged to retest from scratch again just to verify for y'all.
Updated by filoppi almost 4 years ago
a97 wrote:
At least I don't think it did. Lol, now I can't remember.
Ok. You are helping, but we need to come to a conclusion.
Let's forget about the fullscreen hotkey and entering fullscreen mode in Dolphin.
If you can still be bothered, I'd like you to try to restart your PC, try to reproduce the Keyboard issue (from this panel: https://bugs.dolphin-emu.org/attachments/8263/Dolphin_teeWhnMe3l.png) on the main latest release of dolphin, then, once you have reproduced it, try my branch, and see if it also happens there.
Don't go full screen when starting a game, and try the keyboard before starting a game, during it, and after stopping it. Also see if refreshing devices fixes it.
Thanks.
Updated by gamerk2 almost 4 years ago
filoppi wrote:
gamerk2 wrote:
The original issue I wrote this against is still OBE for me. That being said, even when the issue went away I saw some weirdness within PopulateDevices(). I'll take a look at what the latest code is doing sometime today if I ever get some free time and see if that's still the case; if so maybe that's a hint to what's going on or at least where to look.
I've been investigating this on and off for months. I seems like the situation has improved, and it could even be fixed already, as it's easy to get confuse and attribute other problems to this.
That said, the issue is not exactly (directly) in PopulateDevices(), even if that code isn't very thread safe.
The exact issue has been described here: https://bugs.dolphin-emu.org/issues/11702#note-25
I'll take a look; naturally my MSVC was horribly out of date so I've got to get my environment fixed before I can look at anything. It's a slow work day though, so I can take some time to poke and prod if nothing else.
filoppi wrote:
And what does OBE mean?
Overcome By Events. In my job, we generally use it when the problem has been fixed by some other means not related to the product. In my case, the issue magically went away after performing a Windows Update.
Updated by a97 almost 4 years ago
filoppi wrote:
If you can still be bothered, I'd like you to try to restart your PC, try to reproduce the Keyboard issue (from this panel: https://bugs.dolphin-emu.org/attachments/8263/Dolphin_teeWhnMe3l.png) on the main latest release of dolphin, then, once you have reproduced it, try my branch, and see if it also happens there.
Don't go full screen when starting a game, and try the keyboard before starting a game, during it, and after stopping it. Also see if refreshing devices fixes it.
Thanks.
OK. I was able to reproduce my original problem with both the latest dev build and your branch build. Click refresh was necessary at the start emulation every single time.
Updated by a97 almost 4 years ago
a97 wrote:
OK. I was able to reproduce my original problem with both the latest dev build and your branch build. Clicking refresh was necessary at the start of emulation every single time in order to enable keyboard controls.
Updated by filoppi almost 4 years ago
Ok. Good to finally have a clear explanation. Could you check again if there are any "ControllerInterface" logs in my branch?
Are you on the latest Windows 10 version?
Updated by a97 almost 4 years ago
Microsoft Windows
Version 2004 (OS Build 19041.804)
Updated by a97 almost 4 years ago
ControllerInterface:
42:10:769 InputCommon\ControllerInterface\DualShockUDPClient\DualShockUDPClient.cpp:596 I[CI]: DualShockUDPClient PopulateDevices
42:10:771 InputCommon\ControllerInterface\ControllerInterface.cpp:296 N[CI]: Added device: DInput/0/Keyboard Mouse
Updated by filoppi almost 4 years ago
Ok thanks. If you want to help further, please come on the dolphin-dev IRC chat. Otherwise we are gonna have to stop here because this is too complicated.
Updated by gamerk2 almost 4 years ago
Only thing I'll add is I just ran some quick tests, and from what I can see the general weirdness I saw last time I looked at this doesn't seem to be occurring; the input processing makes sense to me now. Since I'm not affected anymore I'm not sure I can be much use. My only additional comment is that this might be a device/driver dependent thing that's somehow floating up to Dolphin.
Updated by filoppi over 3 years ago
This PR has got a workaround for this issue:
https://github.com/dolphin-emu/dolphin/pull/9489
Merge ETA Unknown.
Updated by filoppi over 3 years ago
A more "focused" PR for this issue has been made:
https://github.com/dolphin-emu/dolphin/pull/9702
Updated by JosJuice over 3 years ago
- Status changed from New to Fixed
- Fixed in set to 5.0-14382