| Age | Commit message (Collapse) | Author |
|---|
|
ControllerInterface/Android: Use InputEvent.getDeviceId
|
|
InputCommon: Remove OSX (IOKit) input backend
|
|
XInput2: Accept input from keyboards other than the first master
|
|
|
|
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.
|
|
|
|
Instead of InputEvent.getDevice followed by InputDevice.getId.
Should hopefully fix https://bugs.dolphin-emu.org/issues/13237,
while also being simpler.
|
|
XInput2 was created to support multiple pointer/keyboard pairs (often
called MPX for multi-pointer X). Dolphin's XInput2 implementation has
always supported MPX by creating a KeyboardMouse object per master
pointer. Since commit bbb12a7, Dolphin's keyboard state is filtered by
the output of XQueryKeymap. As a core X function, XQueryKeymap queries
"the" keyboard, which by default is the first master keyboard. As a
result, Dolphin will ignore keys pressed on other master keyboards
unless the first master is simultaneously pressing the same keys.
XInput2 doesn't provide a function to query the keyboard state. There
is no XIQueryKeymap and the current state is not a member of the
XIKeyClassInfo returned by XIQueryDevice. Instead, XInput2 allows a
master pointer to be nominated as "the" pointer on a per-client basis,
with "the" keyboard automatically becoming the associated master
keyboard. The "documentation" [1] says passing None for the window is
only for debugging purposes, but it is documented in the
XISetClientPointer man page and seems to be the only way to query
keyboards beyond the first.
With this commit, Dolphin correctly reads keys from keyboards other than
the first master keyboard. To test, use the xinput command-line utility
to create a master pointer and reattach a keyboard to the associated
master keyboard.
[1]: https://who-t.blogspot.com/2009/07/xi2-recipes-part-6.html
(the XInput2 developer's blog)
|
|
|
|
|
|
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.
|
|
It's missing a lot of features from the PC version for now, like
buttons for inserting functions and the ability to see what the
expression evaluates to. I mostly just wanted to get something in
place so you can set up rumble.
Co-authored-by: Charles Lombardo <clombardo169@gmail.com>
|
|
|
|
|
|
This is a battery-saving measure. Whether a sensor should be suspended
is determined in the same way as whether key events and motion events
should be handled by the OS rather than consumed by Dolphin.
|
|
This functionality was added in Android 12 to let apps get motion data
for gamepads.
|
|
|
|
|
|
When Android presents an input event to an app, it wants the app to
return true or false depending on whether the app handled the event or
not. If the event wasn't handled by the app, it will be passed on to
the system, which may decide to take an action depending on what kind
of input event it is. For instance, if a B button press is passed on to
the system, it will be turned into a Back press. But if an R1 press is
passed on to the system, nothing in particular happens.
It's important that we get this return value right in Dolphin. For
instance, the user generally wouldn't want a B button press to open
the EmulationActivity menu, so B button presses usually shouldn't be
passed on to the system - but volume button presses usually should be
passed on to the system, since it would be hard to adjust the volume
otherwise. What ButtonManager did was to pass on input events that are
for a button which the user has not mapped, which I think makes sense.
But exactly how to implement that is more complicated in the new input
backend than in ButtonManager, because now we have a separation between
the input backend and the code that keeps track of the user's mappings.
What I'm going with in this commit is to treat an input as mapped if
it has been polled recently. In part I chose this because it seemed
like a simple way of implementing it that wouldn't cause too many
layering violations, but it also has two useful side effects:
1. If a controller is not being polled (e.g. GameCube controllers in
Wii games that don't use them), its mappings will not be considered.
2. Once sensor input is implemented in the Android input backend,
we will be able to use this "polled recently" tracking to power down
the sensors at times when the game is using a Wii Remote reporting
mode that doesn't include motion data. (Assuming that the sensor
inputs only are mapped to Wii Remote motion controls, that is.)
|
|
Android doesn't let us poll inputs whenever we want. Instead, we
listen to input events (activities will have to forward them to the
input backend), and store the received values in atomic variables
in the Input classes. This is similar in concept to how ButtonManager
worked, but without its homegrown second input mapping system.
|
|
|
|
ButtonManager is very different from how a normal input backend works,
and is making it hard for us to improve controller support on Android.
The following commits will add a new input backend in its place.
|
|
Strangely, this case did not trigger a C26495 warning in Visual Studio's analyzer; instead, I spotted this when using Valgrind.
|
|
|
|
Obsoletes these functions in favor of the standard member functions
added in C++20.
|
|
InputCommon:QuartzKB&M: Fix mouse y coordinates
|
|
Cocoa uses a different coordinate system from Carbon (Carbon's origin is the top left while Cocoa's is the bottom left)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
InputCommon:QuartzKB&M: Use KVO to watch window position
|
|
This is the first step of getting rid of the controller indirection
on Android. (Needing a way for touch controls to provide input
to the emulator core is the reason why the controller indirection
exists to begin with as far as I understand it.)
|
|
|
|
WGInput: Work around crash with Steam overlay.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CGWindowListCreateDescriptionFromArray would block for up to ~1ms, which isn't a great thing to do on the main emulation thread
|
|
|
|
Add hotkey for centering mouse in render window.
|
|
StripWhitespace maintains old behavior
|
|
Co-authored-by: Dentomologist <dentomologist@gmail.com>
|
