This is unsafe because the event is auto-reset, therefore the call to
WaitForSingleObject() resets the event which GetOverlappedResult() will
try to wait on.
Even though the overlapped operation is guaranteed to be completed at
the point we call GetOverlappedResult(), it will still wait on the event
handle for a short time to trigger the reset for auto-reset events. This
amounts to roughly a 100 ms sleep each time GetOverlappedResult() is called
for a completed I/O with a non-signalled event.
In the context of HIDAPI, this extra sleep means that callers that loop
on hid_read_timeout() with timeout=0 will loop forever, since the 100 ms
sleep each iteration ensures ReadFile() will always have new data.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Sam Lantinga <slouken@libsdl.org>
- 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.
Ideally we'd detect these as "joysticks" (or more generally, gaming
controllers), but in most cases their evdev flags are indistinguishable
from an accelerometer or gyro, so the only way to achieve this would be
a table of known devices that doesn't currently exist.
One exception is the one that reports a THROTTLE axis and TRIGGER, THUMB
buttons, which would be reasonable to detect via the joystick heuristic.
Signed-off-by: Simon McVittie <smcv@collabora.com>
There are some devices for which SDL's device classification heuristic
is known not to give the ideal result. Add a way to incorporate these
into our test data, so that when the heuristic is improved we can
detect them as their intended device type, without making the test fail
before that has been implemented.
Signed-off-by: Simon McVittie <smcv@collabora.com>
SDL Wiki Bot
Sam Lantinga
Ryan C. Gordon
David Edmundson
Simon McVittie