Emulator

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.

Update (again): Huh; it worked once; I restarted Dolphin and inputs aren't reading again.

Anything in Dolphin's log when input isn't working?
Does the "Refresh" button fix the problem?

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.

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.

Can you please show a screenshot of your mapping dialog when input is not working.

Input works before you start the game but not after you start the game?

So that screenshot is after you have started a game?

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.

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.

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.

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.

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.

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...

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).

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.

Still happening as of 2020-07-15. This is a pretty big regression devs, how come no one seems to care?

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.

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

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.

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?

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 :)

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

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:

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.

still got the same thing happening over here, from 9869 onwards, not even the latest versions work

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.

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?

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/

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.

I can send you a build if you give me a way to contact you.

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.

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.

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?

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%.

And yeah just to be clear I renamed the folder AND unplugged the usb gamepad.

Maybe Windows is keeping track of that usb info in a registry key or something?

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.

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.

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?

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?

Also can you check the log? Enable "SerialInterface" and see if it prints out anything.

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.

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.

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.

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

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

That test 3 was using 44ba7ca
https://github.com/dolphin-emu/dolphin/pull/9489/commits/44ba7ca

Let me know if there's anything else and I'll try again tomorrow.

Also want to note that the DualShock Info log is strange as the controller is not plugged in at the moment.

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.

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.

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.

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?

Yeah I think my problem was just that the fullscreen hotkey was messing things up. Everything else seems fine.

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.

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.

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.

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.

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.

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

And what does OBE mean?

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.

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.

At least I don't think it did. Lol, now I can't remember.

I'll do a cold boot with my usb controller to retest from scratch again just to verify for y'all.

a97 wrote:

I'll do a cold boot with my usb controller unplugged to retest from scratch again just to verify for y'all.

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.

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.

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.

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.

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?

Microsoft Windows
Version 2004 (OS Build 19041.804)

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

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.

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.

This PR has got a workaround for this issue:
https://github.com/dolphin-emu/dolphin/pull/9489
Merge ETA Unknown.

A more "focused" PR for this issue has been made:
https://github.com/dolphin-emu/dolphin/pull/9702

The fix is in