| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Accomplished using `run-clang-tidy` with `performance-move-const-arg,performance-unnecessary-value-param,modernize-pass-by-value`.
Changed arguments to const references, removed them where inappropriate (e.g. sink parameters). Same with std::move.
Manually reviewed each change to make sure that it makes sense, and do something more appropriate if possible.
|
|
|
|
Common::HookableEvent.
|
|
|
|
In WiimoteReal.cpp, JitRegCache.cpp, lambda predicates were replaced by pointers to member functions because ranges algorithms are able invoke those.
In ConvertDialog.cpp, the `std::mem_fn` helper was removed because ranges algorithms are able to handle pointers to member functions as predicates.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This specific issue was already addressed by https://github.com/dolphin-emu/dolphin/pull/11635
though I felt like there was something more we could do, and wasn't too happy with the
likelihood of devices update calls being skipped (due to `m_devices_population_mutex` being locked).
|
|
InputCommon: Remove OSX (IOKit) input backend
|
|
This reads Steam Deck controls bypassing Steam Input. This allows for access to
motion controls as well as independent access to thumb sticks, trackpads, and
back grip buttons.
|
|
|
|
ControllerInterface: Fix deadlock when Wii Remote disconnects
|
|
In UpdateInput, lock m_devices_population_mutex before m_devices_mutex
to be consistent with other ControllerInterface functions. Normally the
former lock isn't needed in UpdateInput, but when a Wii Remote
disconnects it calls RemoveDevice which results in the mutexes being
locked in the wrong order.
|
|
|
|
|
|
|
|
|
|
|
|
Fixes bug: https://bugs.dolphin-emu.org/issues/12744
Before https://github.com/dolphin-emu/dolphin/commit/e1e3db13baabefa89991388d37db0bb260c4f535
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)
|
|
Removed useless locks to DeviceContainer::m_devices_mutex, as they were all already protected by m_devices_population_mutex.
We have no interest in blocking other threads that were potentially reading devices at the same time so this seems fine.
This simplifies the code, and I've adjusted a few comments which mentioned possible deadlock that should now be totally gone.
The deadlock could have happen if a thread directly called EmulatedController::UpdateReferences(), while another another thread also reached EmulatedController::UpdateReferences() within a call to ControllerInterface::UpdateDevices(), as the mentioned function locked both the DeviceContainer::m_devices_mutex and s_get_state_mutex at the same time.
The deadlock was frequent on game emulation startup on Android, due to the UpdateReferences() call in InputConfig::LoadConfig() and the UI thread triggering calls to ControllerInterface::UpdateDevices().
It could also have happened on Desktop if a user pressed "Refresh Devices" manually in the UI while the input config was loading.
Also brought some UpdateReferences() comments and thread safety fixes from https://github.com/dolphin-emu/dolphin/pull/9489
|
|
SPDX standardizes how source code conveys its copyright and licensing
information. See https://spdx.github.io/spdx-spec/1-rationale/ . SPDX
tags are adopted in many large projects, including things like the Linux
kernel.
|
|
devices
Also polished DInput code in general to try and mitigate issue 11702.
Added a lot of logging and comments.
|
|
sorting priority
This helps us keeping the most important devices (e.g. Mouse and Keyboard) on the top
of the list of devices (they still are on all OSes supported by dolphin
and to make hotplug devices like DSU appear at the bottom.
|
|
|
|
also make it more thread safe (avoid rare deadlock)
and fix it trying to add devices before the CI has init
|
|
-Fix Add/Remove/Refresh device safety, devices could be added and removed at the same time, causing missing or duplicated devices (rare but possible)
-Fix other devices population race conditions in ControllerInterface
-Avoid re-creating all devices when dolphin is being shut down
-Avoid re-creating devices when the render window handle has changed (just the relevantr ones now)
-Avoid sending Devices Changed events if devices haven't actually changed
-Made most devices populations will be made async, to increase performance and avoid hanging the host or CPU thread on manual devices refresh
|
|
|
|
A "devices changed" callback could have ended up waiting on another thread that was also populating devices
and waiting on the previous thread to release the callbacks mutex.
|
|
where appropriate. SerialInterface was a leftover from the past,
and makes no sense to be used on actual/real controllers.
|
|
the raw delta mouse input
Co-authored-by: Jordan Woyak <jordan.woyak@gmail.com>
|
|
Make sure m_is_populating_devices is true when a WM_INPUT_DEVICE_CHANGE
event is received directly on the ciface thread, so that callbacks do
not occur while removing devices. This breaks a hold-and-wait deadlock
between the ciface thread and the CPU thread when using emulated
Wiimotes.
Co-authored-by: brainleq <brainleq@users.noreply.github.com>
Co-authored-by: oldmud0 <oldmud0@users.noreply.github.com>
|
|
Continues the migration of the logging calls over to the fmt capable
ones.
|
|
|
|
|
|
We need this because we need to pass the layer to MoltenVK, not
the view handle. But the input subsystem still needs the window.
|
|
to connect additional Wii Remotes.
|
|
RemoveDevice can be used within UpdateInput.
|
|
|
|
"DualShockUDPClient"/"DSUClient".
|
|
This is done by:
1) Implementing said protocol in a new controller input class CemuHookUDPServer.
2) Adding functionality in the WiimoteEmu class for pushing that motion input to the emulated Wiimote and MotionPlus.
3) Suitably modifying the UI for configuring an Emulated Wii Remote.
|
|
hotplug event.
|
|
|
