| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Make `s_is_adapter_wanted` and the elements of `s_config_rumble_enabled`
atomic.
The CPU thread reads `s_is_adapter_wanted` and `s_config_rumble_enabled`
in `Output`, while the host thread writes to them in `RefreshConfig`.
The simplest way to trigger this race is to close the `Settings` window
while playing a game with the adapter active.
|
|
GCAdapter: Automatically start and stop thread
|
|
This keeps the logic encapsulated inside GCAdapter.cpp so callers don't
have to think about it.
|
|
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.
|
|
GC adapter fixes (hotplugging, claim retries, Dolphin shutdown)
|
|
|
|
|
|
|
|
Core: Add SDL Hints settings
|
|
Signed-off-by: Andrew Strauss <astrauss11@gmail.com>
|
|
|
|
Previously, when an input device was connected or disconnected, we would
recreate all devices. This commit makes it so we only touch the relevant
device instead. This matters because recreating a device causes us to
drop all held buttons for that device. Due to Android only delivering
inputs as events, we're unable to poll for currently held buttons when
recreating a device.
This recently became a problem for users of Ayn devices due to a
firmware update. Every now and then, something about the display
viewports changes, triggering an update to an input device that I assume
is a touch input device. This input device isn't something users
normally map in Dolphin's controller settings, but it changing was
causing Dolphin to drop all held buttons for the device's built-in
gamepad as well as any other connected gamepads.
|
|
Remove unused vector `controller_names` from `LoadConfig` and
`SaveConfig`. The vector has names added to it but they're never used.
Prior to d03f9032c129e440e4f07d319be8b52500798e07 these vectors were
passed to `DynamicInputTextureManager::GenerateTextures`, but that
commit removed those calls.
|
|
Yellow squiggly lines begone!
Done automatically on .cpp files through `run-clang-tidy`, with manual corrections to the mistakes.
If an import is directly used, but is technically unnecessary since it's recursively imported by something else, it is *not* removed.
The tool doesn't touch .h files, so I did some of them by hand while fixing errors due to old recursive imports.
Not everything is removed, but the cleanup should be substantial enough.
Because this done on Linux, code that isn't used on it is mostly untouched.
(Hopefully no open PR is depending on these imports...)
|
|
|
|
|
|
|
|
Fix various typos and spelling mistakes
|
|
|
|
|
|
GCAdapter: Calculate poll rate for display in UI.
|
|
when Dolphin is configured to use the adapter.
|
|
Recently came across a strange issue where Dolphin would hard crash in most games with this error:
```sh
/usr/include/c++/15.2.1/optional:1165: constexpr const _Tp* std::optional<_Tp>::operator->() const [with _Tp = InputCommon::ImagePixelData]: Assertion 'this->_M_is_engaged()' failed.
```
The culprit turned out to be accessing `host_key_image` which is an `std::optional` thay may return `std::nullopt`. I'm not sure why this issue started occuring for me since I've had no issue with my Dynamic Input Textures in the past? But this fixes a crash if the image fails to load.
|
|
every 50 reads.
|
|
|
|
Common::HookableEvent.
|
|
WiimoteEmu: Require IRPassthrough has any bound inputs to operate.
|
|
confused and mistakenly enable it.
|
|
ControllerInterface/Xlib: Combine keycodes with the same name to fix non-working inputs.
|
|
Ultimate 2" controller.
|
|
|
|
Android: Detect GCAdapter hotplug using BroadcastReceiver
|
|
Add SDL Gamepad Profile
|
|
|
|
The mentioned SDL hotplug issue seems to have been fixed.
|
|
SDL3 enables it by default now and things seem to work properly even when it's off these days.
|
|
ControllerEmu: Remove nunchuk stick data hax.
|
|
Dentomologist/controllerinterface_fix_windows_deadlock
ControllerInterface: Fix Windows deadlock
|
|
This reverts commit 74ed5e55326b9d8e67dfbb8dd6f61d04bcae2445.
It solves a problem that no longer exists.
|
|
This lets us get rid of the Reset call in ProcessInputPayload, which was
causing us some threading headaches (see 74ed5e5532). Instead we handle
disconnection in the same way as the libusb implementation does.
|
|
We can register a BroadcastReceiver to have Android tell us when a GC
adapter gets connected instead of having a loop where we continuously
call SleepCurrentThread(1000) and poll the current status. When waiting
for a GC adapter to connect, this both reduces power usage and improves
responsiveness.
Note that I made openAdapter get the UsbDevice that's been stored by the
hotplug code instead of having openAdapter find the UsbDevice on its own
like before. This is only because I want to ensure that the UsbDevice
being tracked for disconnection is the same as the UsbDevice actually
being used, in case the user has multiple adapters connected.
|
|
This isn't how we name things in Java/Kotlin.
|
|
|
|
Android: Show input indicators in controller settings
|
|
InputCommon: Rename SDL input backend GameController to Gamepad.
|
|
|
|
Remove the redundant s_populate_mutex and only use
ControllerInterface::m_devices_population_mutex instead to prevent a
deadlock caused by locking them in opposite orders.
The device population functions in the win32 InputBackend previously
locked s_populate_mutex first before calling various functions that
locked m_devices_population_mutex. This normally worked but
ControllerInterface::RefreshDevices locks m_devices_population_mutex
first and then calls HandleWindowChange which then locked
s_populate_mutex, potentially causing the deadlock.
Fix this by using PlatformPopulateDevices to lock
m_devices_population_mutex before running the code that was previously
protected by s_populate_mutex. The functions in question lock
m_devices_population_mutex anyway, so this shouldn't meaningfully
increase contention on the lock.
Reproduction steps:
* Let Dolphin finish startup.
* In Win32.cpp::OnDevicesChanged set a breakpoint on the call to
PlatformPopulateDevices. When the breakpoint is triggered the function
will have locked s_populate_mutex, but since PlatformPopulateDevices
won't have run yet m_devices_population_mutex will still be unlocked.
* Unplug a device from your computer.
* Wait for the breakpoint to trigger. (At this point you can plug the
device back in).
* Freeze the ntdll.dll!TppWorkerThread() that triggered the breakpoint.
* Resume Dolphin and start a game.
* Core::EmuThread will call ControllerInterface::ChangeWindow which
calls RefreshDevices. It locks m_devices_population_mutex, then calls
InputBackend::HandleWindowChange, which tries to lock
s_populate_mutex.
* Unfreeze ntdll.dll!TppWorkerThread().
At this point EmuThread and TppWorkerThread are deadlocked. The UI is
still responsive since the Host thread is unaffected, but trying to stop
the game or close Dolphin normally will fail since EmuThread is unable
to stop.
|
|
|
|
Update to SDL3
|
