This allows the application to tell when a joystick polling cycle is complete and can process state changes as a single atomic update. It is disabled by default, at least for now.
It is possible for retrieving the machine ID to fail, either because
dbus was installed incorrectly (machine ID absent or corrupt), or in
32-bit builds, because stat() on the machine ID fails with EOVERFLOW
if it has an out-of-range timestamp or inode number.
dbus has historically treated this as a faulty installation, raising
a warning which by default causes the process to crash. Unfortunately,
dbus_get_local_machine_id() never had a way to report errors, so it has
no alternative for that (bad) error handling.
In dbus >= 1.12.0, we can use dbus_try_get_local_machine_id() to get
the same information, but with the ability to cope gracefully with
errors. ibus won't work in this situation, but that's better than
crashing.
Mitigates: https://github.com/ValveSoftware/steam-for-linux/issues/9605
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it so you can interact with sensors on multiple threads, as long as only one thread initializes and cleans up the sensor subsystem.
This also has the benefit that sensor data is available as soon as possible.
The hidraw device may take additional time to get the correct permissions for us to open it. In my tests on Steam Deck hardware, this ranges between 5-8ms.
To match the focus stealing prevention logic from windows/osx.
I didn't implement SDL_HINT_WINDOW_ACTIVATE_WHEN_SHOWN as there is no
standard mechanism for us to do so. In most cases marking a window as OverrideRedirect
will cause to not acquire focus when mapped. And in steam we are doing that when
appropriate.
I still left a note in X11_ShowWindow() regarding this behaviour.
- Cocoa_ShowWindow will order a window that is not being activated below the key window (if one exists) then set visible
- Cocoa_RaiseWindow calls -[NSWindow orderFront:] without changing the key window
Also renamed SDL_GetDisplayOrientation() SDL_GetDisplayCurrentOrientation()
The natural orientation of the primary display is the frame of reference for accelerometer and gyro sensor readings.
If a device is positively identified as an accelerometer, pointing stick
or clickpad, then we don't need to second-guess it.
In practice this does not change the result for any device in our
test data, so add some artificial records that exercise this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In newer kernels, devices that can be positively identified as a
particular device type (for example accelerometers) get a property
bit set. Plumb this information through into the function, but don't
use it for anything just yet.
Signed-off-by: Simon McVittie <smcv@collabora.com>
udev distinguishes between ID_INPUT_KEY, a device with any keyboard keys
at all (including for example USB numeric keypads, Bluetooth headsets
with volume control buttons, and some game controllers; and
ID_INPUT_KEYBOARD, a reasonably fully-featured keyboard that you could
use for general-purpose text entry. If we do the same here, then it's
useful input to our heuristics for identifying devices: for example,
a device with ID_INPUT_KEY could reasonably be a gamepad, but a device
with ID_INPUT_KEYBOARD certainly isn't.
Resolves: https://github.com/libsdl-org/SDL/issues/7827
Signed-off-by: Simon McVittie <smcv@collabora.com>
We can't actually tell yet whether a controller has paddles, so this code isn't effective, but I'll file an upstream issue and see if we can get that resolved.
This heuristic for gamepads without a more specific mapping already
tried two incompatible conventions for handling triggers: the Linux
Gamepad Specification uses hat switch 2 for the triggers (for whatever
reason), but the de facto standard set by the drivers for older Xbox
and Playstation controllers represents each trigger as the Z-axis of
the nearest analog stick.
Android documentation encourages Bluetooth gamepad manufacturers to use
a third incompatible convention where the left and right triggers are
represented as the brake and gas pedals of a driving simulator
controller. The Android convention also changes the representation of
the right stick: instead of using X and Y rotation as a second pair
of axes, Android uses Z position as a second horizontal axis, and
Z rotation as a second vertical axis.
Try to cope gracefully with all of these. This will hopefully resolve
the issue described in #5406 (when using unpatched kernels).
Signed-off-by: Simon McVittie <smcv@collabora.com>
The bitfield `mapped` has two different sets of meanings, depending
whether we're setting up the triggers or the d-pad. Represent them
as symbolic constants rather than opaque integers.
Signed-off-by: Simon McVittie <smcv@collabora.com>
