Alex S
...which allows SDL to talk to webcamd/iichid. (Webcamd actually bundles quite a few gamepad drivers.) Note that this does _not_ disable usbhid, both joystick backends will be compiled.
This uses pre-recorded evdev capabilities, so that we can check for
regressions without the devices having to be physically present.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This improves SDL's ability to detect joystick hotplug in a container
environment.
We cannot reliably receive events from udev in a container, because they
are delivered as netlink events, which are authenticated by their uid
being 0. However, in a user namespace created by an unprivileged user
(for example bubblewrap, as used by Flatpak and Steam's
pressure-vessel-wrap), the kernel does not allow us to map uid 0, and
the netlink events appear to be from the kernel's overflowuid (typically
65534/nobody), meaning libudev cannot distinguish between genuine uevents
from udevd and an attack by a malicious local user.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Anything with X, Y and Z axes but no buttons is probably an
accelerometer (this is the assumption made in udev).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we only checked for at least one button or key and at least
the X and Y absolute axes, but this has both false positives and false
negatives.
Graphics tablets, trackpads and touchscreens all have buttons and
absolute X and Y axes, but we don't want to detect those as joysticks.
On normal Linux systems ordinary users do not have access to these
device nodes, but members of the 'input' group do.
Conversely, some game controllers only have digital buttons and no
analogue axes (the Nintendo Wiimote is an example), and some have axes
and no buttons (steering wheels or flight simulator rudders might not
have buttons).
Use the more elaborate heuristic factored out from SDL's udev code path
to handle these cases.
In an ideal world we could use exactly the same heuristic as udev's
input_id builtin, but that isn't under a suitable license for inclusion
in SDL, so we have to use a parallel implementation of something
vaguely similar.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This works on capability bitfields that can either come from udev or
from ioctls, so it is equally applicable to both udev and non-udev
input device detection.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Device enumeration via libudev can fail in a container for two reasons:
* the netlink protocol between udevd and libudev is considered private,
so there is no API guarantee that the version of libudev in a container
will understand netlink messages from a dissimilar version of udevd
on the host system;
* the netlink protocol between udevd and libudev relies for security on
being able to check the uid of each message, but in a container with
a user namespace where host uid 0 is not mapped, the libudev client
cannot distinguish between messages from host uid 0 and messages from
a different, malicious user on the host
To make this easier to experiment with, always compile the fallback
code path even if libudev is disabled. libudev remains the default if
enabled at compile time, but the fallback code path can be forced.
Signed-off-by: Simon McVittie <smcv@collabora.com>
GetAsyncKeyState() and GetRawInputData() report the state of the physical
buttons without applying the user's primary/secondary mouse button swap
preference. Swap the buttons returned from these functions, so we expose a
consistent view of the buttons to SDL callers. This new behavior also matches
the behavior of macOS and X11 backends.
See the Remarks section of the GetAsyncKeyState() function on MSDN.
We should only perform the VK_LEFT, VK_UP, etc. mapping if none of the other
special mappings apply. This allows the scancode normalization for the number
pad to take place as intended.
When we request realtime priority from rtkit, we have a rttime limit. If we exceed
that limit, the kernel will send SIGKILL to the process to terminate it.
This isn't something that most high priority processes will want, only processes
that selectively opt into SCHED_RR/FIFO through SDL_HINT_THREAD_PRIORITY_POLICY
should be subject to this level of scrutiny.
This change:
* Switches non-apple posix OSs to use SCHED_OTHER instead of SCHED_RR
for SDL_THREAD_PRIORITY_HIGH/SDL_THREAD_PRIORITY_TIME_CRITICAL.
* Fixes using a hardcoded RLIMIT_RTTIME, instead queries it from rtkit
* Only sets RLIMIT_RTTIME for MakeRealtime rtkit requests
* Adds a note regarding the possible SIGKILL with SDL_HINT_THREAD_PRIORITY_POLICY
* Introduces SDL_HINT_THREAD_FORCE_REALTIME_TIME_CRITICAL to allow apps to acquire realtime scheduling policies on Linux
CPU Vendor ID "Shanghai" and "CentaurHauls" belongs to Zhaoxin.
Background:
Shanghai Zhaoxin Semiconductor Co., Ltd ("Zhaoxin") , established in 2013,
headquartered in Zhangjiang, Shanghai, China. Zhaoxin aims at providing
general-purpose x86 processors.
Related Zhaoxin Linux Kernel patch can be found at
https://lore.kernel.org/lkml/01042674b2f741b2aed1f797359bdffb@zhaoxin.com
Best regards.
Debugging inside rtkit showed we were failing the RLIMIT_RTTIME check, now that we're asking for realtime and not just high-priority due to a change in SDL.
Between that and the DBus code in SDL being wrong in previous changelist I'm not sure how this could have ever worked.
Nov 02 20:34:15 redcore rtkit-daemon[2825]: Failed to parse MakeThreadRealtime() method call: Argument 1 is specified to be of type "uint32", but is actually of type "int32"
Nov 02 20:34:15 redcore rtkit-daemon[2825]: Failed to parse MakeThreadRealtime() method call: Argument 1 is specified to be of type "uint32", but is actually of type "int32"
Docs:
http://git.0pointer.net/rtkit.git/tree/README
CLIENTS:
To be able to make use of realtime scheduling clients may
request so with a small D-Bus interface that is accessible on
the interface org.freedesktop.RealtimeKit1 as object
/org/freedesktop/RealtimeKit1 on the service
org.freedesktop.RealtimeKit1:
void MakeThreadRealtime(u64 thread_id, u32 priority);
void MakeThreadHighPriority(u64 thread_id, s32 priority);
wcodelyokoyt
The atom name that X11_GetAtomName() returns never gets freed, which result in a minor memory leak (14 bytes?) every time the user drops a file on a window.
You can see the line in question here:
6b6170caf6/src/video/x11/SDL_x11events.c (L1350)
Fix: call XFree on name after the while loop.
Joel Linn
This patch fixes a MSVC warning, which is dependent on the regional settings of the build system. Although the character is inside a comment and harmless, it is undesirable to disable the warning for this.
OpenGL leaves the final line segment open, SDL's software renderer does not,
so we need a tiny bit of trigonometry here to move one more pixel in the right
direction.
Sam Lantinga
Simon McVittie
Cameron Gutman
John "Nielk1" Klein
Ozkan Sezer
Ryan C. Gordon
Dylan Fan
Bart van der Werf
Sylvain Becker