The joystick subsystem has complex precedence logic to deal multiple competing
backends like XInput, RawInput, and WGI. Let it fire the MaybeAdd callbacks
for joystick devices, since it knows which backend will end up managing them.
This resolves a situation where the RawInput joystick backend would take
control of an XInput device but the XInput haptic backend would still create
a haptic device. Since the XInput joystick backend didn't own the underlying
joystick device, we'd end up with an orphaned haptic device that didn't work
with SDL_HapticOpenFromJoystick() on the associated joystick device.
A racing reader could read from our fd between SDL_IOReady()/X11_Pending()
and our call to XNextEvent() which will cause XNextEvent() to block for
more data. Avoid this by using XCheckIfEvent() which will never block.
This also fixes a bug where we could poll() for data, even when events were
already read and pending in the queue. Unlike the Wayland implementation,
this isn't totally thread-safe because nothing prevents a racing reader
from reading events into the queue between our XCheckIfEvent() and
SDL_IOReady() calls, but I think this is the best we can do with Xlib.
This API and implementation comes from the Unreal Engine branch of SDL, which
originally called this "SDL_ConfineCursor".
Some minor cleanup and changes for consistency with the rest of SDL_video, but
there are two major changes:
1. The coordinate system has been changed so that `rect` is _window_ relative
and not _screen_ relative, making it easier to implement without having
global access to the display.
2. The UE version unset all rects when passing `NULL` as a parameter for
`window`, this has been removed as it was an unused feature anyhow.
Currently this is only implemented for X, but can be supported on Wayland and
Windows at minimum too.
This prevents conflicts with hidapi linked with applications, as well as allowing applications to make use of HIDAPI on Android and other platforms that might not normally have an implementation available.
Enabling the RawInput backend causes SDL_XINPUT_Enabled() to return false.
That causes WGI and DInput backends to take ownership of XInput-compatible
controllers, because they think there's no XInput-specific backend enabled.
In WGI's case, it will actually race with RawInput to open the device. By
properly excluding XInput devices from WGI, we can ensure that the sets of
devices managed by WGI and RawInput don't intersect. This makes the race
harmless, since they'll never both go after the same device.
The Xbox One driver stack doesn't propagate the VID/PID down to the
HID devices that end up in the GetRawInputDeviceList() output. This
means we end up matching against the wrong VID/PID and can't properly
exclude Xbox One controllers from WGI.
Fortunately, it is possible to walk back up the device tree to find
the parent with the matching VID/PID.
In this case we'll get WM_KILLFOCUS when the child window is focused, but we'll retain focus on the top level window, but when we Alt-Tab away, we won't get another WM_KILLFOCUS or WM_NCACTIVATE, we get WM_ACTIVATE instead, so we need to check for focus updates in response to that as well.
* SDL_OpenURL (macOS): try to open path if the url cannot be opened
* SDL_OpenURL (macOS): use CFURLCreateWithBytes & LSOpenCFURLRef to correctly escape input
* fix type casting + indentation
It's marked as being a public symbol internally, however, it was missing from the header files and not visible in the shared library. This adds it to the necessary headers and to the DynAPI list to expose it for use by applications.
Co-authored-by: Frank Praznik <frank.praznik@oh.rr.com>
Note that this removes the timeGetTime() fallback on Windows; it is a
32-bit counter and SDL2 should never choose to use it, as it only is needed
if QueryPerformanceCounter() isn't available, and QPC is _always_ available
on Windows XP and later.
OS/2 has a similar situation, but since it isn't clear to me that similar
promises can be made about DosTmrQueryTime() even in modern times, I decided
to leave the fallback in, with some heroic measures added to try to provide a
true 64-bit tick counter despite the 49-day wraparound. That approach can
migrate to Windows too, if we discover some truly broken install that doesn't
have QPC and still depends on timeGetTime().
Fixes#4870.
Add a new flag to avoid suppressing EINTR in SDL_IOReady(). Pass the
flag in WaitEventTimeout() to ensure that a SIGINT will wake up
SDL_WaitEvent() without another event coming in.
Even without the thread, it'll do an initial hardware detection at startup,
but there won't be any further hotplug events after that. But for many cases,
that is likely complete sufficient.
In either case, this cleaned up the code to no longer need a semaphore at
startup.
Fixes#4862.
We can have spurious wakeups in WaitEventTimeout() due to Wayland events
that don't end up causing us to generate an SDL event. Fortunately for us,
SDL_WaitEventTimeout_Device() handles this situation properly by calling
WaitEventTimeout() again with an adjusted timeout.
There are two issues which are stopping the SDL tests from building on
my machine:
- libunwind is not being linked
- Even if it is, it is missing several symbols.
The first is fixed by having the test programs link against libunwind if
available. Technically, SDL2_test should be linking against it, as it's
used in SDL_test_memory.c, but as SDL2_test is a static library, it
can't itself import libunwind. We just assume that if it's present on
the system, we should link it directly to the test programs. This should
strictly be an improvement, as the only case where this'd fail is if
SDL2 was compiled when libunwind was present, but the tests are being
compiled without it, and that'd fail anyway.
The second is fixed by #define-ing UNW_LOCAL_ONLY before including
libunwind.h: this is required to make libunwind link to predicatable
symbols, in what can only be described as a bit of a farce. There are a
few more details in the libunwind man page, but the gist of it is that
it disables support for "remote unwinding": unwinding stack frames in a
different process (and possibly from a different architecture?):
http://www.nongnu.org/libunwind/man/libunwind(3).html
Note that I haven't tried this with CMake: I suspect that it'll work,
though, as the CMakeLists.txt seems to have SDL2 link against libunwind if
it's present. This adds an ugly extra dependency to SDL2, but does mean
that issue 1 isn't present. The UNW_LOCAL_ONLY change shouldn't be
build-system-specific.
Wayland provides the prepare_read()/read_events() family of APIs for
reading from the display fd in a deadlock-free manner across multiple
threads in a multi-threaded application. Let's use those instead of
trying to roll our own solution using a mutex.
This fixes an issue where a call to SDL_GL_SwapWindow() doesn't swap
buffers if it happens to collide with SDL_PumpEvents() in the main
thread. It also allows coexistence with other code or toolkits in
our process that may want read and dispatch events themselves.
- Factorize PrepQueueCmdDraw{,DrawTexture,Solid) into one single function
- Change SDL_Texture/Renderer r,g,b,a Uint8 into an SDL_Color, so that it can be passed directly to RenderGeometry
- Don't automatically queue a SET_DRAW_COLOR cmd for RenderGeometry (and update GLES2 renderer)
Sam Lantinga
Susko3
Ryan C. Gordon
Sylvain
Cameron Gutman
Ethan Lee
Yufei Huang
Ozkan Sezer
Thomas Ballinger
Charlie Birks
Patrick Hogan
Eric Wasylishen
Kevin Colour
superzazu
Brick
Frank Praznik
Ivan Epifanov
Northfear
Cameron Cawley
David Gow