Fix default input config default device not being loaded/found #10248
+35
−14
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
JosJuice
reviewed
Nov 27, 2021
Source/Core/InputCommon/ControllerInterface/ControllerInterface.cpp
Outdated
Show resolved
Hide resolved
Filoppi
force-pushed
the
fix_input_config_default_device_load
branch
from
dc1c6cd
to
a0e77be
Compare
JosJuice
approved these changes
Nov 27, 2021
Filoppi
force-pushed
the
fix_input_config_default_device_load
branch
from
a0e77be
to
5af35cc
Compare
|
I had to build myself since the buildbot seems to be having trouble with building for Windows, It works to resolve the issue. |
Filoppi
force-pushed
the
fix_input_config_default_device_load
branch
4 times, most recently
from
7220993
to
925c3de
Compare
|
Hello! I've downloaded Dolphin 5.0-15611 (most recent version for Windows) from build-bot and the issue is still there. Is there a build already available with this fix or should I wait? |
|
Once this pull request says "Merged" instead of "Open", the change will be available in a build at https://dolphin-emu.org/. For now, either download a test build from this page, or wait. |
JosJuice
reviewed
Dec 5, 2021
Source/Core/InputCommon/ControllerInterface/ControllerInterface.cpp
Outdated
Show resolved
Hide resolved
…/found Fixes bug: https://bugs.dolphin-emu.org/issues/12744 Before dolphin-emu@e1e3db1 the ControllerInterface m_devices_mutex was "wrongfully" locked for the whole Initialize() call, which included the first device population refresh, this has the unwanted (accidental) consequence of often preventing the different pads (GC Pad, Wii Contollers, ...) input configs from loading until that mutex was released (the input config defaults loading was blocked in EmulatedController::LoadDefaults()), which meant that the devices population would often have the time to finish adding its first device, which would then be selected as default device (by design, the first device added to the CI is the default default device, usually the "Keyboard and Mouse" device). After the commit mentioned above removed the unnecessary m_devices_mutex calls, the default default device would fail to load (be found) causing the default input mappings, which are specifically written for the default default device on every platform, to not be bound to any physical device input, breaking input on new dolphin installations (until a user tried to customize the default device manually). Default devices are now always added synchronously to avoid the problem, and so they should in the future (I added comments and warnings to help with that)
Filoppi
force-pushed
the
fix_input_config_default_device_load
branch
from
925c3de
to
125971d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Fixes bug: https://bugs.dolphin-emu.org/issues/12744
Before e1e3db1 the ControllerInterface m_devices_mutex was "wrongfully" locked for the whole Initialize() call, which included the first device population refresh, this has the unwanted (accidental) consequence of often preventing the different pads (GC Pad, Wii Contollers, ...) input configs from loading until that mutex was released (the input config defaults loading was blocked in EmulatedController::LoadDefaults()), which meant that the devices population would often have the time to finish adding its first device, which would then be selected as default device (by design, the first device added to the CI is the default default device, usually the "Keyboard and Mouse" device).
After the commit mentioned above removed the unnecessary m_devices_mutex calls, the default default device would fail to load (be found) causing the default input mappings, which are specifically written for the default default device on every platform, to not be bound to any physical device input, breaking input on new dolphin installations (until a user tried to customize the default device manually).
Default devices are now always added synchronously to avoid the problem, and so they should in the future (I added comments and warnings to help with that).
The only one which was async was the Windows "Keyboard and Mouse" device, and I took care of that. I also changed devices sorting order to be clearer (and avoid other devices accidental ending up as default) (the sorting order only affect the Qt devices list order and nothing else).