| Age | Commit message (Collapse) | Author |
|---|
|
No need to check write access if we call open() right after which checks
that anyway. Also only get the device name once.
|
|
This currently only supports using the internal vibrate on a phone for rumble.
|
|
Xlib supports many mouse buttons, though there are 9 standard buttons, and they aren't arranged like other mouse APIs. Using only 5 buttons was preventing the use of buttons besides left/right/middle click and the scroll wheel. Here's what all the standard buttons are:
1. left button
2. middle button (pressing the scroll wheel)
3. right button
4. turn scroll wheel up
5. turn scroll wheel down
6. push scroll wheel left
7. push scroll wheel right
8. 4th button (aka browser backward button)
9. 5th button (aka browser forward button)
The remaining button indices are non-standard and device-specific, and technically far more than 32 are supported, but this seems like a reasonable limit to avoid cluttering the list with tons of useless mouse buttons. What mouse has more than 32 buttons anyways?
|
|
|
|
Otherwise, Dolphin will crash when the joystick is removed.
|
|
|
|
|
|
Macros should be all upper-cased. This is also kind of a wart that's
been sticking out for quite a while now (we avoid prefixing
underscores).
|
|
Add -Wno-register to calm down clang 6.0.0 (C++17 mode)
|
|
The 'register' keyword is used by a header included from Xlib (X11/XKBlib.h).
|
|
Whenever udev_monitor_receive_device() returns a non-null pointer,
the device must be unref'd after use with udev_device_unref().
We previously missed some unref calls for non-evdev devices.
|
|
|
|
It's not guaranteed that the eventfd is smaller than the monitor fd,
because fds are not always monotonically allocated. To select()
correctly in all cases, use the max between the monitor fd and eventfd.
|
|
ControllerInterface: cleanup callbacks API and logic
|
|
|
|
This lets Dolphin know if a configured GameCube Controller should actually
be treated as connected or not.
Talked to @JMC47 a bit about this last night. My use-case is that all of
my controllers are the same hardware (Xbox One controllers) so share the
same configuration (modulo device number). Treating them all as always
connected isn't a problem for most games, but in some (Smash Bros.) it
forces me to go find a keyboard/mouse and unconfigure any controllers
that I don't actually have connected. Hotplugging devices (works on macOS,
at least) + this patch remove my need to ever touch the Controller Config
dialog while in a game.
This patch makes the following changes:
- A new `BooleanSetting` in `GCPadEmu` called "Always Connected", which
defaults to false.
- `ControllerEmu` tracks whether the default device is connected on every
call to `UpdateReferences()`.
- `GCPadEmu.GetStatus()` now sets err bit to `PAD_ERR_NO_CONTROLLER` if
the default device isn't connected.
- `SIDevice_GCController` handles `PAD_ERR_NO_CONTROLLER` by imitating the
behaviour of `SIDevice_Null` (as far as I can tell, this is the only use
of the error bit from `GCPadStatus`).
I wanted to add an OSD message akin to the ones when Wiimotes get
connected/disconnected, but I haven't yet found where to put the logic.
|
|
Axis range was previously calculated as max + abs(min), which relies on the assumption that
min will not exceed 0. For (min, max) values like (0, 255) or (-128, 127), which I assume to
be the most common cases, the range is correctly calculated as 255. However, given (20,
235), the range is erroneously calculated as 255, leading to axis values being normalized
incorrectly.
SDL already handles this case correctly. After changing the range calculation to max - min,
the axis values received from the evdev backend are practically identical to the values
received from the SDL backend.
|
|
when refreshing
|
|
|
|
|
|
Some backends already cause this to happen, so make it consistent across
systems.
|
|
On OSX, iterate the HID device's elements and only store the last of
each type to accommodate for flaky hardware
|
|
Ideally Common.h wouldn't be a header in the Common library, and instead be renamed to something else, like PlatformCompatibility.h or something, but even then, there's still some things in the header that don't really fall under that label
This moves the version strings out to their own version header that doesn't dump a bunch of other unrelated things into scope, like what Common.h was doing.
This also places them into the Common namespace, as opposed to letting them sit in the global namespace.
|
|
|
|
|
|
|
|
|
|
Ignore capabilities reported by an XInput device
|
|
|
|
Each axis would appear as multiple elements with 0 min/max.
Filter the list of elements using the correct usage page like
done for buttons.
|
|
Simpler usage.
|
|
Add headless support on macOS
|
|
These were not caught by the lint script while it was broken.
|
|
Makes comparison logic symmetric
|
|
|
|
Building fails on GCC7 without an explicit
|
|
Better separation of concerns. Relegates `ControllerInterface` to
enumerating input controls, and the new `ControlReference` deals with
combining inputs and configuration expression parsing.
|
|
|
|
|
|
|
|
GetName() creates a new evdev device which calls tons of ioctls. But the
main culprit is close() which for input devices appears to be a slow
path in the kernel.
This commit reduces PopulateDevices() by 50% on my laptop, but ~730 ms
is still ridiculously slow for something that isn't needed right away.
|
|
|
|
Note: This probably means our approach of populating from udev isn't
safe to be called multiple times.
|
|
ControllerInterface: enable hotplugging on macOS
|
|
|
|
The SDL backend crashes when you close a joystick after SDL_Quit has
been called. Some backends don't need to be shutdown and
re-initialized everytime, we can just ask to enumerate devices again.
|
|
The SDL backend faults if it tries to close a joystick after SDL_Quit
has been called.
|
|
Make analog triggers on PS3 controllers accessible on Mac
|
|
Warning fixes
|
|
Previously the 'usage' value was used to identify the axis by name, but this is not unique. For example on a PS3 controller *all* axis other than the well known ones return a usage of '1' so there are 30 or more axis all named "1". This stops things such as analog triggers being usable.
Using the element cookie uniquely identifies each axis and allows them to be assigned successfully as controls
|
