Well, here's a new one: Dolphin is refusing to recognize any inputs for my keyboard or mouse. This applies to both the Hotkeys menu and Controller configuration. I've confirmed that "DInput/0/Keyboard Mouse" and "All Devices" have the same problem. My gamepad "XInput/0/Gamepad" reads fine.
Was confirmed working somewhere around version 8500 or so. Want me to isolate to a specific build?
Currently using 10071.
EDIT
Isolated problem to build 9876; created new bug report in tracker:
https://bugs.dolphin-emu.org/issues/11702
Odd problem; I can't believe I'm the first to run into this. Might be related to my PC going to sleep periodically; I've had issues with logitech peripherals and sleep before. I'll toy around some more and report back.
EDIT2
I restarted my PC and started up Dolphin. Inputs read fine. Updated bug tracker and started Dolphin up again. Inputs no longer read properly. Anyone have any thoughts?
EDIT3
Unplugged the USB devices, shut down Logitech Gaming Software, replugged, still nothing. It's almost as if Dolphin isn't seeing the Keyboard or mouse for some strange reason.
For anyone tracking this, it appears the last version that reliably works is 9865; after that keyboard/mouse input starts becoming unreliable. It *looks* like everything works off a cold PC boot, up until I either enter a controller configuration menu or exit Dolphin. From that point on, Keyboard/Mouse inputs won't recognize, even on the key configuration screens.
Its worth noting I'm using a Logitech Keyboard/Mouse (G19s/G502), and I know from past experience Logitech does some *weird* stuff in driver land. It's also worth noting that a few of my diagnostic devices show multiple entries for these devices (see attachment; captured using ditool), and I'm wondering if that's confusing Dolphin.
The code for the PR in question doesn't look too bad; I even have a suspicion what the problem is (the added check for multiple devices, or the skip over devices in use). If I get some free time this weekend I might screw around and try and fix the problem (or at minimum identify the root cause). Are there any recommended compilers for compiling the source and any dependencies not packaged (aside from MSVC, of course)?
(05-03-2019, 07:33 AM)gamerk2 Wrote: [ -> ]Are there any recommended compilers for compiling the source and any dependencies not packaged (aside from MSVC, of course)?
If you want to build on Windows, you need MSVC, git (must be on the PATH) and Windows 10 SDK 10.0.17134.0. Also make sure that you pull the Qt submodule in the Dolphin repo.
(05-03-2019, 07:40 AM)JosJuice Wrote: [ -> ]If you want to build on Windows, you need MSVC, git (must be on the PATH) and Windows 10 SDK 10.0.17134.0. Also make sure that you pull the Qt submodule in the Dolphin repo.
Got it to compile. Naturally have to go away for a few hours before I can toy with it :/. Hoping to at least identify a cause sometime tonight/tomorrow.
Suspicion confirmed. I think I've got a brute force workaround as well. Note this took a lot longer then I was expecting because I ended up chasing another unrelated issue (which I'll write up shortly).
First off, I'm using 10132 as a base. In this version, input assignment works until the refresh button is clicked 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:
opulateDevices() 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:
opulateDevices() 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.
That seems like a fairly serious bug that could be be breaking things...
(05-04-2019, 09:31 PM)Billiard26 Wrote: [ -> ]@ gamerk2 Can you try this change, please?
https://github.com/jordan-woyak/dolphin/...f41ba2ec91
Behaving the same as current baseline; inputs work until refresh or game start.
I've gone an removed *every* unused driver from my system, and the behavior I'm seeing is the same. It's possible Logitech is still picking up one of my old devices (I used a G700 mouse until recently moving to a G502) and that's causing the problem, but it may just be something Logitech is doing under the hood within their drivers. As far as I can tell I don't have any device drivers hanging around that could be causing this problem.
I think the problem is usb driver but I don't figure the way to access windows without keyboard and mouse+_+
(05-09-2019, 02:19 PM)Julie7487 Wrote: [ -> ]I think the problem is usb driver but I don't figure the way to access windows without keyboard and mouse+_+
OBE. Far as I can tell even non-working builds work 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...
*shrug*