- hidapi already called CancelIo on hid_close but that only cancels pending IO for the current thread. Controller read/writes originate from multiple threads (serialized, but on a different thread nonetheless) but device destruction was always done on the main device thread which left any pending overlapped reads still running after hidapi's internal read buffer is deallocated leading to intermittent free list corruption.
Signed-off-by: Sam Lantinga <slouken@libsdl.org>
Touching HID devices with keyboard usages will trigger a keyboard capture
permission prompt on macOS 11+. See #4887
Like the IOKit joystick backend, we accept HID devices that have joystick,
gamepad, or multi-axis controller usages. We also allow the Valve VID for
the Steam Controller, just like the Windows HIDAPI implementation does.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Sam Lantinga <slouken@libsdl.org>
The get_usb_string call is rather expensive on some USB devices, so we
cache the vendor/product strings for future lookups (e.g. when
hid_enumerate is invoked again later).
This way, we only need to ask libusb for strings for devices we haven't
seen since before we started.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
Signed-off-by: Sam Lantinga <slouken@libsdl.org>
We weren't meant to have multiple contexts and mainloops, but we had one
for each opened device and the hotplug detection thread. Instead, use
pa_threaded_mainloop, which can be shared between threads and objects, and
a single context (which, according to the PulseAudio documentation, is
usually meant to be a singleton that represents a global server connection,
possibly with multiple streams hung on it).
Now instead of polling in a loop, threads will block until the
threaded_mainloop runs a callback, and the callback will fire a signal to
unblock the thread.
Prior to this, the code upset ThreadSanitizer, as Pulse has some unprotected
global resource that each mainloop/context would touch.
Reference Issue #7427.
SDL mutexes are always recursive in modern times, so no need to check this,
plus the test triggers a false-positive on ThreadSanitizer.
Reference Issue #7427.
There are many toolkit specific ways to set a font DPI in X11 desktop
environments. The primary approach of reading a Gnome specific setting
from the portal is ok, it will work on Gnome and on Plasma most the
time.
The current fallback GDK_SCALE is less great; it's an internal GTK
setting relating to the mapping of logical pixels to device pixels
within the toolkit, it's a developer setting for GTK devs. We were
instructed within Plasma to not set this as it caused issues.
Xft.dpi in xresources is a good universal fallback, it's very dated to
the point that it works in clients like xterm, Qt on X11 uses it in our
font DPI path.
Re-writes clipboard data handling in X11 to an on demand approach where
data can be produced on request instead of storing it in X11 properties
on the window.
Primary selection has been changed to mimic this behavior even though
it's only possible to use it for text as of now.
Ensure that incoming touch events originate from valid surfaces owned by SDL and have proper window data before forwarding them to the touch subsystem, or the window focus pointer that is sent with the event may not be a pointer to an SDL window.
Additionally, ensure that allocated touch events are always cleaned up on exit.
