This change corrects the mappings for the Atari gamecontroller and
adds support for the Atari Xbox 360 compatible gamecontroller. The Atari
game controller can switch between Atari and Xbox 360 mappings.
This might have changed at some point in the Pulse API, or this might have
always been wrong, but we didn't notice because the dynamic loading code
hides it by casting things to void *. The static path, where it
assigns the function pointer directly, puts out a clear compiler warning,
though.
With Dear ImGui + software renderer, it draws:
- by default at 250 fps
- drops to 70 fps if you show the color picker
- drops to 10 fps if put the color picker fullscreen
There were a few places throughout the SDL code where values were
clamped using SDL_min() and SDL_max(). Now that we have an SDL_clamp()
macro, use this instead.
This was the original intent (note SDL_UpdateWindowGrab() in SDL_OnWindowFocusGained() and SDL_OnWindowFocusLost()) and fixes a bug where relative motion unexpectedly stops if the task bar is covering the bottom of the game window and the mouse happens to move over it while relative mode is enabled.
Another alternative would be to confine the mouse when relative mode is enabled, but that generates mouse motion which would need to be ignored, and it's possible for the user moving the mouse to combine with the mouse moving into the confined area so you can't easily tell whether to ignore the mouse motion. See https://github.com/libsdl-org/SDL/issues/4165 for a case where this is problematic.
This is the mouse focus except in the case where relative motion is enabled and the mouse is over a window floating on top of the application window (e.g. the taskbar)
This fixes restoring the cursor clip rectangle after the mouse has moved off of the window.
Also try to better synchronize cursor visibility with mouse position changes when changing relative mode. This doesn't work perfectly, but it seems to improve things on Windows.
Don't rely on checking __clang_major__ since it is not comparable
between different vendors. Don't use "#pragma clang attribute" since it
is only available in relatively recent versions, there's no obvious way
to check if it's supported, and just using __attribute__ directly (for
gcc as well) results in simpler code anyway.
If we are already in the desired mode, changing it is a no-op at best,
and harmful at worst: on Xwayland, it sometimes happens that we disable
the crtc and cannot re-enable it.
Resolves: https://github.com/libsdl-org/SDL/issues/4630
Signed-off-by: Simon McVittie <smcv@collabora.com>
- cmake, configure (CheckDLOPEN): --enable-sdl-dlopen is now history..
detach the dl api discovery from SDL_LOADSO_DLOPEN functionality.
define HAVE_DLOPEN. also define DYNAPI_NEEDS_DLOPEN (CheckDLOPEN is
called only for relevant platforms.)
- update SDL_config.in and SDL_config.cmake accordingly.
- SDL_dynapi.h: set SDL_DYNAMIC_API to 0 if DYNAPI_NEEDS_DLOPEN is
defined, but HAVE_DLOPEN is not.
- pthread/SDL_systhread.c: conditionalize dl api use to HAVE_DLOPEN
- SDL_x11opengl.c, SDL_DirectFB_opengl.c, SDL_naclopengles.c: rely
on HAVE_DLOPEN, not SDL_LOADSO_DLOPEN.
- SDL_config_android.h, SDL_config_iphoneos.h, SDL_config_macosx.h,
SDL_config_pandora.h, and SDL_config_wiz.h: define HAVE_DLOPEN.
Closes: https://github.com/libsdl-org/SDL/pull/4351
Without this change, driver names don't get matched correctly;
for example "a" can get matched with "alsa" since it only checks
whether the string matches up to the length of the requested
driver name.
Without this change, driver names don't get matched correctly;
for example "x" can get matched with "x11" since it only checks
whether the string matches up to the length of the requested
driver name.
b08b1bde introduced a subtle bug. Despite not using D-Bus types directly,
the code used the SDL_USE_LIBDBUS definition set by SDL_dbus.h to conditionally
compile calls SDL_DBus_ScreensaverTickle() and SDL_DBus_ScreensaverInhibit().
As a result, it still compiled without SDL_dbus.h included, but screensaver
suspension silently failed to work.
The D-Bus stuff could probably use some tweaks to be harder to accidentally
break, but for now just restore the header includes.
Configure events from compositors have an extremely annoying habit of giving us
completely bogus sizes, from all sorts of places. Thankfully, the protocol
gives us the ability to completely ignore the width/height and just stick with
what we know, so for all windows that are not meant to be resized, pretend we
never even got the width/height at all, the compositor is required to respect
our dimensions whether they match configure's suggestion or not.
Otherwise only the display resolution is changed, but the SDL window size
(and for example the window-surface size) aren't adjusted accordingly
and thus don't fill the whole screen.
See #3313
.. and maybe other platforms as well (though X11 was not affected)?
The issue was that passing a higher resolution than the current desktop
resolution to SDL_CreateWindow() with SDL_WINDOW_FULLSCREEN didn't switch
to that resolution (even though it did switch to lower resolutions).
When creating a fullscreen window, window->fullscreen wasn't even set
at all (only zeroed out), setting it only happened if the user explicitly
called SDL_SetWindowDisplayMode(). So without that, SDL_CreateWindow()
-> SDL_UpdateFullscreenMode() -> SDL_GetWindowDisplayMode() used the
resolution from window->windowed.w/h which were limited to the desktop size
due to some weird combination of WIN_AdjustWindowRectWithStyle() and
WIN_WindowProc() being called after a call to SetWindowPos().
fixes#3313
This prevents a race if two threads that need d-bus try to init it at the
same time. Note that SDL_Init will likely handle this from a single thread
at startup, but there are places outside of init where one might trigger
D-Bus init, like setting thread priority (a common first thing for a new
thread to do) resulting in SDL trying to use RTKit.
Fixes#4587.
This reintroduces the fix from 0e16ee8330, but just marks
the viewport state as dirty after a clear that needs to expand the
viewport to fill the render target, as we'll need to also reset
the orthographic projection state elsewhere, and that won't
happen if we clear the dirty flag here.
Fixes#4210.
(again.)
(...sorry...!)
The Renderer logical scaling code scales mouse coordinates, and needs to
take the window DPI into account on HIGHDPI windows. However, the
variable which tracks this, renderer->dpi_scale, is set once when the
renderer is created, and then not updated. In the event that the window
is moved to another screen, or the screen DPI otherwise changes, this
will be outdates, and potentially the coordinates will be all wrong.
So let's update the dpi_scale on the SIZE_CHANGED event: it's at least a
possibility that this will be issued on some OSes when DPI changes, and
it's otherwise already handled by SDL_Renderer's event filter.
Otherwise you might have set the viewport to the full size of
the render target in SDL's API but this change hasn't been
transmitted to Direct3D yet by the time we attempt to clear.
Fixes#4210.
SDL_AddHintCallback() uses SDL_malloc(), which means this would
run before main(), so the app wouldn't be able to supply its own
replacement SDL_malloc() implementation in time.
This code was moved to under SDL_Init. Since the hint callback
already makes efforts to not override the app manifest's
orientation settings, this is safe to move until after pre-main()
startup.
Fixes#4449.
This removes the CM_Register_Notification code on WinRT. Note
that this API _is_ available to UWP apps as of Windows 10.0.17763
(version 1809, released October 2018), according to:
https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-devices-config-l1-1-1dll
So it might be worth readding with some sort of preprocessor check
for minimum targeted version, or whatever is appropriate for WinRT
development.
This was causing configure events to not inform SDL of window size
changes, even when they were based on resizes that we fully expected. The
result was fullscreen->windowed not working at all, because it would
retain the desktop resolution instead of reverting to the floating size
that it had before moving to fullscreen mode.
Fixes Super Hexagon fullscreen toggling.
The flush has been removed in e5f9fae034.
Unfortunately, even though ideally the flush shouldn't be necessary,
our resize sequence isn't... well, perfect, and removing that flush causes
tons of troubles.
We're also still flushing in other paths where the window size can be
changed by the compositor and where we may potentially have to obey that
change, like in Wayland_MaximizeWindow.
This also removes the hack introduced in 7f261d3b76,
which introduces problems with protocol violations and seems to not be
necessary when flushing.
We have issues with correct resize sequence and happen to commit old-sized
buffers even after configure event for the new size has been already
acknowledged. While the reason for that stays unknown, let's at least
workaround the problem by faking window geometry into expected size.
This does not fix visual glitch on e.g. fullscreen toggling, but having
a split-second glitch is still a much better outcome than being
terminated by the compositor for protocol violation.
This was causing window changes to completely break, resulting in broken
decorations and bizarre frame timing, I don't know what exactly it's doing
but it's not good. Kept the libdecor_frame_is_floating logic, at least.
Commit 871c11191b removed delayed
resize handling, but it left the whole structure untouched that
now became unnecessary. To help with code clarity, get rid
of the structure where pending resize state used to be stored
and pass all the data directly to Wayland_HandlePendingResize
(now renamed to Wayland_HandleResize, since it's not "pending"
anymore but applied immediately)
Otherwise our windows have no window decoration on compositors that
support xdg-decoration-unstable-v1, but default to client-side mode.
Contrary to what the comment was stating, there is nothing in the protocol
that would make redundant calls to zxdg_toplevel_decoration_v1::set_mode
problematic.
Some Wayland compositors send (0,0) as "suggested" configure event sizes to
indicate that the client has to decide on its own which sizes to used. This
is commonly done when restoring from maximised, fullscreen or tiles states
to fullscreen.
We now store the last known floating states in a new set of variables and
restore them when we receive such a (0,0) configure event.
From the vfork manpage:
> The vfork() function has the same effect as fork(2), except that
> the behavior is undefined if the process created by vfork() either
> modifies any data other than a variable of type pid_t used to store
> the return value from vfork(), or returns from the function in which
> vfork() was called, or calls any other function before successfully
> calling _exit(2) or one of the exec(3) family of functions.
unsetenv is still called inside a child process, so it does not
influence the rest of the application.
This fixes a crash on pressing keyboard button when compositor sends
zero as repeat rate, indicating that key repeat should be disabled.
From Wayland protocol spec:
> Negative values for either rate or delay are illegal. A rate of zero
> will disable any repeating (regardless of the value of delay).
This is a workaround and not a proper fix, but this is possibly complicated,
and possibly a corner case, so this will do for 2.0.16, if not the
foreseeable future.
Reference issue #4561
When we removed the OpenGL resize workaround it introduced a problem for
fullscreen windows in particular: When leaving fullscreen we tried to send a
resize event, but UpdateFullscreenMode would send a SIZE_CHANGED immediately
after, deleting our resize event and causing the following configure event's
resize to be ignored. This timing issue resulted in fullscreen windows not
being resized at all when becoming a floating window.
By always forcing resize events from configure events, we ensure that RESIZED
always makes it through. SetWindowSize-type changes should be unaffected as
they do not fire configure events.
The RenderDrawLinesWithRects and RenderDrawLinesWithRectsF functions can
sometimes call QueueCmdFillRects() with the data pointed to by frects
uninitialised. This can occur if none of the lines can be replaced with
rects, in which case the frects array is empty, and nrects is 0.
gcc 10.3.0 will detect this possibility, and print a warning like:
/home/david/Development/SDL/src/render/SDL_render.c: In function 'RenderDrawLinesWithRectsF':
/home/david/Development/SDL/src/render/SDL_render.c:2725:15: warning: '<unknown>' may be used uninitialized [-Wmaybe-uninitialized]
2725 | retval += QueueCmdFillRects(renderer, frects, nrects);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/david/Development/SDL/src/render/SDL_render.c:499:1: note: by argument 2 of type 'const SDL_FRect *' to 'QueueCmdFillRects' declared here
499 | QueueCmdFillRects(SDL_Renderer *renderer, const SDL_FRect * rects, const int count)
| ^~~~~~~~~~~~~~~~~
This is harmless, because when this is uninitialised, nrects is always
0, so QueueCmdFillRects() does nothing anyway. We therefore can work
around this by only calling QueueCmdFillRects() when nrects is nonzero.
Somewhat impressively, gcc recognises that this is now safe.
This is needed to support CHERI, and thus Arm's experimental Morello
prototype, where pointers are implemented using unforgeable capabilities
that include bounds and permissions metadata to provide fine-grained
spatial and referential memory safety, as well as revocation by sweeping
memory to provide heap temporal memory safety.
The C standard does not guarantee that if two pointers compare equal
they are the same pointer, as C pointers have a notion of provenance,
and compilers have been known to exploit this during optimisation. For
CHERI, this becomes even more important, as in-place expansion can
result in realloc returning a capability to the same address but with
increased capability bounds, and so reusing the old capability will trap
trying to access outside the bounds of the original allocation.
In the case that ptr == mem, memdiff and ptrdiff should still be equal,
so the only overhead is a small amount of pointer arithmetic and a store
of the new pointer (which is required per the C standard in order to not
be undefined behaviour when next loaded).
This also fixes the calculation of oldmem to use uintptr_t rather than
size_t as casting the pointer to size_t on CHERI will strip the
capability metadata, including the validity tag, with the subsequent
cast back to void * resulting in a null-derived capability whose
validity tag is clear and thus cannot be dereferenced without trapping.
This is needed to support CHERI, and thus Arm's experimental Morello
prototype, where pointers are implemented using unforgeable capabilities
that include bounds and permissions metadata to provide fine-grained
spatial and referential memory safety, as well as revocation by sweeping
memory to provide heap temporal memory safety.
On most systems (anything with a flat memory hierarchy rather than using
segment-based addressing), size_t and uintptr_t are the same type.
However, on CHERI, size_t is just an integer offset, whereas uintptr_t
is still a capability as described above. Casting a pointer to size_t
will strip the metadata and validity tag, and casting from size_t to a
pointer will result in a null-derived capability whose validity tag is
not set, and thus cannot be dereferenced without faulting.
The audio and cursor casts were harmless as they intend to stuff an
integer into a pointer, but using uintptr_t is the idiomatic way to do
that and silences our compiler warnings (which our build tool makes
fatal by default as they often indicate real problems). The iconv and
egl casts were true positives as SDL_iconv_t and iconv_t are pointer
types, as is NativeDisplayType on most OSes, so this would have trapped
at run time when using the round-tripped pointers. The gles2 casts were
also harmless; the OpenGL API defines this argument to be a pointer type
(and uses the argument name "pointer"), but it in fact represents an
integer offset, so like audio and cursor the additional idiomatic cast
is needed to silence the warning.
When choosing an X11 Visual for a window based on its GLX capabilities, first
try glXChooseFBConfig (if available) before falling back to glXChooseVisual.
This normally does not make a difference because most GLX drivers create a
Visual for every GLXFBConfig, exposing all of the same capabilities.
For GLX render offload configurations (also know as "PRIME") where one GPU is
providing GLX rendering support for windows on an X screen running on a
different GPU, the GPU doing the offloading needs to use the Visuals that were
created by the host GPU's driver rather than being able to add its own. This
means that there may be fewer Visuals available for all of the GLXFBConfigs the
guest driver wants to expose. In order to handle that situation, the NVIDIA GLX
driver creates many GLXFBConfigs that map to the same Visual when running in a
render offload configuration.
This can result in a glXChooseVisual request failing to find a supported Visual
when there is a GLXFBConfig for that configuration that would have worked. For
example, when the game "Unnamed SDVX Clone" [1] tries to create a configuration
with multisample, glXChooseVisual fails because the Visual assigned to the
multisample GLXFBConfigs is shared with the GLXFBConfigs without multisample.
Avoid this problem by using glXChooseFBConfig, when available, to find a
GLXFBConfig with the requested capabilities and then using
glXGetVisualFromFBConfig to find the corresponding X11 Visual. This allows the
game to run, although it doesn't make me any better at actually playing it...
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Fixes: https://forums.developer.nvidia.com/t/prime-run-cannot-create-window-x-glxcreatecontext/180214
[1] https://github.com/Drewol/unnamed-sdvx-clone
As of [1], SDL now compiles with a warning in SDL_waylandevents.c on
32-bit systems under gcc 10.3.0:
/tmp/SDL/src/video/wayland/SDL_waylandevents.c: In function 'seat_handle_capabilities':
/tmp/SDL/src/video/wayland/SDL_waylandevents.c:958:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
958 | SDL_AddTouch((SDL_TouchID)seat, SDL_TOUCH_DEVICE_DIRECT, "wayland_touch");
| ^
/tmp/SDL/src/video/wayland/SDL_waylandevents.c:964:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
964 | SDL_DelTouch((SDL_TouchID)seat);
| ^
This is due to SDL_TouchID always being 32-bit, but seat being a pointer
which is (obviously) only 32-bit on 32-bit systems. The conversion is
therefore harmless, so silence it with an extra cast via intptr_t.
This is what the cocoa backend does (and is similar to what the Win32
backend does, except with size_t).
Fixes: 03c19efbd1 ("Added support for multiple seats with touch input on Wayland")
[1]: 03c19efbd1
When wayland is not dynamically loaded (--enable-wayland-shared=no)
libdecor.h is not included unless SDL_VIDEO_DRIVER_WAYLAND_DYNAMIC
is set, so it fails to build. We can't simply move the libdecor.h
include above the #ifdef SDL_VIDEO_DRIVER_WAYLAND_DYNAMIC block, as
libdecor.h itself #includes wayland headers we need to replace with
#defines. Instead, duplicate the #include.
Fixes https://github.com/libsdl-org/SDL/issues/4543
Note that this doesn't fix any of the underlying issues of libdecor
being treated as part of wayland, it just fixes the build. A better
solution would probably be to decouple the wayland dynamic loading
from the libdecor dynamic loading completely, though that is a lot
more work...
Each window can have at most one zxdg toplevel decoration, but as of
[1], we accidentally create two. (If libdecor is not in use). This
causes wayland windows with server-side decorations (e.g. on KDE/KWin)
to crash with the message:
zxdg_decoration_manager_v1@7: error 1: decoration has been already constructed
This extra zxdg_decoration_manager_v1.get_toplevel_decoration() call was
introduced while deprecating wl-shell and xdg-shell-stable[1] support,
and possibly was a bad interaction with [2], which moved the decoration
creation around.
Fixes: 6aae5b44f8 ("Remove wl-shell and xdg-shell-unstable-v6 support (#4323)")
[1]: https://github.com/libsdl-org/SDL/pull/4323
[2]: https://github.com/libsdl-org/SDL/pull/4374
WASAPI_WaitDevice is used for audio playback and capture, but needs to
behave slighty different.
For playback `GetCurrentPadding` returns the padding which is already
queued, so WaitDevice should return when buffer length falls below the
buffer threshold (`maxpadding`).
For capture `GetCurrentPadding` returns the available data which can be
read, so WaitDevice can return as soon as any data is available.
In the old implementation WaitDevice could suddenly hang. This is
because on many capture devices the buffer (`padding`) wasn't filled
fast enough to surpass `maxpadding`. But if at one point (due to unlucky
timing) more than maxpadding frames were available, WaitDevice would not
return anymore.
Issue #3234 is probably related to this.
On modern CPUs, there's no penalty for using the unaligned instruction on
aligned memory, but now it can vectorize unaligned data too, which even if
it's not optimal, is still going to be faster than the scalar fallback.
Fixes#4532.
The Game Controller Kit doesn't show the controllers at startup, so the HIDAPI driver sees them first and therefore gets preference when a controller is supported by both drivers.
This fixes bug https://github.com/libsdl-org/SDL/issues/4209
This prevents an assertion whem LINUX_JoystickGetGamepadMapping tried to
open the stick temporarily and messed with global state by doing so. Now
the global state is only set in LINUX_JoystickOpen, but the common code
is shared by both interfaces.
Fixes#4198.
Wayland video subsystem uses a mix of libc and SDL function.
This patch switches libc functions to SDL ones and fixes a mismatch in memory
allocation/dealoccation of SDL_Cursor in SDL_waylandmouse.c (calloc on line 201
and SDL_free on line 313) which caused memory corruption if custom memory
allocator where provided to SDL.
As written, these contain undefined stack contents, which in practice
causes crashes/hangs and/or triggers the validation layers (they
complain about `pNext` and `flags` not being NULL).
When hint SDL_HINT_OPENGL_ES_DRIVER is set to "1" (e.g. for ANGLE support), assertion due to !_this->gl_config.driver_loaded can be causes while EGL is available.
When relative mode is enabled and not using warp mode, the cursor is
being clipped to the window. Therefore there is no reason to restore the
cursor position to the center.
Avoiding the warp to center simplifies mouse position event flow, as we
are no longer potentially receiving mouse events for the automated
movement of the cursor and can be (mostly) assured that an incoming
event from the windowing system is that of external means.
The implementation of clip logic for relative mode seemed to
unnecessarily limit the usable area to the middle of the window, in a
2x2 pixel region. This has the adverse side effect of moving the
operating system cursor to that location, even if it is in a valid
location in the window.
While in most scenarios this is handled correctly (by storing the
original position of the cursor in the window and restoring when leaving
relative mode), there are edge cases where this clip operation can cause
WM_MOUSEMOVE to fire at a point in time where it counts as a relative
delta from SDL's perspective.
X11_SetDisplayMode currently calls X11_XRRSetCrtcConfig alone. This results
in the monitor's viewport getting changed, but the underlying screen dimensions
stay the same.
The spec indicates that RRSetCrtcConfig only changes the crtc mode and has no effect
on the screen dimensions, only mentioning that the new crtc must fit entirely within the
screen size. For the size to change, RRSetScreenSize also needs to be called.
This affects Metro Exodus on Linux, when changing the resolution in the in-game settings
Metro gets stuck in a loop waiting for the size of its vulkan surface to change. Because
XRRSetScreenSize is not called the screen size is never changed, the vulkan surface dimensions
do not change, and Metro hangs forever watching for a surface size update that will
never come.
This change disables the CRTC, calls XRRSetScreenSize, and then updates the
CRTC configuration. This fixes changing the resolution from the Metro settings.
Tested with:
Metro Exodus, Portal 2
To enter Bluetooth pairing mode hold B and Action (button with circle) buttons for 3 seconds.
It works via usual HIDAPI if special filter driver is not installed:
https://www.amazon.com/gp/help/customer/display.html?nodeId=GZCT4CTFHXLHEB9T
With that driver installed it mimics Xbox One controller and works via XInput under Windows.
Under DInput this controller is not usable at all.
It is called from WGI before the normal joystick detection has been run, so it needs to actually enumerate currently connected devices.
We can skip the logic checking for other drivers also supporting this device, because that logic is duplicated from the call site.
Not only is it more efficient to batch process pending events, it is
necessary for correctness with the Win32 backend. WIN_PumpEvents() runs
periodic updates of the cursor clip region and disambiguation of
left and right shift keys in addition to standard event processing.
SDL_GetBasePath grows its path buffer for long paths, but GetModuleFileNameExW always truncates and succeeds,
so `len` was always equal to (buflen - 1) which is 127. This is easily fixed by checking for (buflen - 1) instead of buflen.
For paths longer than MAX_PATH, this problem sometimes got hidden by Windows path shortening ("C:\PROGRA~1\" etc.).
Tested on Windows 10 x64 19041 and 10586.
SDL_JoystickSetVirtualAxisInner() and SDL_JoystickSetVirtualHatInner()
did not properly sanitize the 'axis' and 'hat' parameters.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Based on a patch by Jochen Schäfer <josch1710@live.de> :
The problem is, that in the initialization code uses the same structure for
desktop_mode and current_mode. See SDL_os2video.c:OS2_VideoInit():
stSDLDisplay.desktop_mode = stSDLDisplayMode;
stSDLDisplay.current_mode = stSDLDisplayMode;
...
stSDLDisplayMode.driverdata = pDisplayData;
Then, if you call GetDisplayModes, current_mode will added to the modes
list, with the same driverdata pointer to desktop_mode.
SDL_AddDisplayMode( display, &display->current_mode );
When VideoQuit gets called, first the modes list gets freed including the
driverdata, the desktop_mode gets freed. See SDL_video.c:SDL_VideoQuit():
for (j = display->num_display_modes; j--;) {
SDL_free(display->display_modes[j].driverdata);
display->display_modes[j].driverdata = NULL;
}
SDL_free(display->display_modes);
display->display_modes = NULL;
SDL_free(display->desktop_mode.driverdata);
display->desktop_mode.driverdata = NULL;
So, the display_modes[j].driverdata gets freed, but desktop_mode->driverdata
points to the same memory, but is not NULL'ed. When desktop_mode->driverdata
gets freed the memory is already freed, and libcx crashes the application on
SDL_Quit.
Based on a patch by Jochen Schäfer <josch1710@live.de> :
On a T420 pressing the ACPI button for volume control, big scancodes
were emitted. This was causing an overflow, because missing guards.
- Do not call IDirectInputDevice8_QueryInterface(device, &IID_IDirectInputDevice8,...) on DIRECTINPUTDEVICE8 device
- Get joystick VendorID and ProductID via IDirectInputDevice8_GetProperty(.., DIPROP_VIDPID, ..) call instead of messing with DIDEVICEINSTANCE.guidProduct
- Normalize HID device interface path to upper case for stable operation of XInput check
- Remove useless RawInput calls in SDL_IsXInputDevice() - just check for "IG_" string in HID device interface path that we already have
There shouldn't be any observable behavior changes.
We can be in a situation where we receive a win32 hook callback on the same
thread that is currently waiting. In that case, we do still need to trigger
a wakeup when an event is pushed because the hook itself won't necessarily
do that (depending on what we return from the hook).
When possible use native os functions to make a blocking call waiting for
an incoming event. Previous behavior was to continuously poll the event
queue with a small delay between each poll.
The blocking call uses a new optional video driver event,
WaitEventTimeout, if available. It is called only if an window
already shown is available. If present the window is designated
using the variable wakeup_window to receive a wakeup event if
needed.
The WaitEventTimeout function accept a timeout parameter. If
positive the call will wait for an event or return if the timeout
expired without any event. If the timeout is zero it will
implement a polling behavior. If the timeout is negative the
function will block indefinetely waiting for an event.
To let the main thread sees events sent form a different thread
a "wake-up" signal is sent to the main thread if the main thread
is in a blocking state. The wake-up event is sent to the designated
wakeup_window if present.
The wake-up event is sent only if the PushEvent call is coming
from a different thread. Before sending the wake-up event
the ID of the thread making the blocking call is saved using the
variable blocking_thread_id and it is compared to the current
thread's id to decide if the wake-up event should be sent.
Two new optional video device methods are introduced:
WaitEventTimeout
SendWakeupEvent
in addition the mutex
wakeup_lock
which is defined and initialized but only for the drivers supporting the
methods above.
If the methods are not present the system behaves as previously
performing a periodic polling of the events queue.
The blocking call is disabled if a joystick or sensor is detected
and falls back to previous behavior.
This add controller mappings for the Atari vcs (modern) controller as
well as the classic controller, for both bluetooth and USB connectivity.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
At least on bluetooth the guid user the version reported by the
bluetooth device. Which for Atari vcs controllers is the firmware
version. However the mapping will stay the same regardless of firmware
version, so ignore the version entirely to avoid needing a new mapping
entry for each firmware version.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
this variable was added in commit 2067a7db8e and
ultimately tracks if this is a surface's first present. checking if the current
bo is NULL provides the same functionality and cuts down on a redundant piece
of state potentially getting out of sync in the future
SetDisplayMode needs to recreate the EGL surfaces, which then need to be
bound along with the correct context in each rendering thread
commit 3a1d7d9c9a removed this behavior which
has broken using SetDisplayMode when rendering with multiple contexts
the commit message was rather vague, but if the surfaces do need to be
created immediately, this process probably needs to be split such that
surface is created immediately, but the binding is deferred
and remove duplicate SDL_WINDOWEVENT_RESIZED event
commit 2067a7db8e made SDL_SetWindowSize and
SDL_SetWindowFullscreen modify the display mode previously set by a call to
SDL_SetWindowDisplayMode
as far as I understand the SDL API, calling SDL_SetWindowDisplayMode followed
by calling SDL_SetWindowFullscreen(..., SDL_WINDOW_FULLSCREEN) is the correct
way to mode set / switch to fullscreen
this change restores that functionaliy when switching to SDL_WINDOW_FULLSCREEN,
but other cases are still modifying the display mode set by the user. rather
than modifying the display mode set by the user, it seems this logic inside of
KMSDRM_ReconfigureWindow should be pushed further down into KMSDRM_CreateSurfaces
(as it was originally) to only modify the final mode that's set (based on the
fullscreen flags), but not override the mode requested by the user
commit 2067a7db8e introduced new surface_w and surface_h
variables which were passed to gbm_surface_create rather than the dimensions from the
drmModeModeInfo structure. commit 5105ecf8b1 further
refactored this code and no longer synchronized these variables inside
KMSDRM_SetDisplayMode, breaking it
this change removes the variables since they're seemingly redundant to begin with
When Xbox One/Series Controllers are connected via USB on Windows they all are using `XBOXGIP` driver and produce a special ProductID `0x02FF` (GIP software PID) for any connected controller.
On the other hand `Xbox 360 Wireless Controller Reciever` (PID 0x0719) is using `XUSB` driver and produces special ProductID `0x02A1` (XUSB software PID) for each connected Xbox 360 Wireless Controller.
Also fixed Xbox One Series X Controller comment.
Only adjust the biClrUsed field if it is set to zero in the bitmap, and make
some effort to make sure we don't overflow a buffer in any case.
This was triggering an issue with the sailboat bmp used for testpalette.c in
SDL 1.2, which is an 8-bit paletted image with 66 palette entries instead of
256. See discussion at https://github.com/libsdl-org/sdl12-compat/issues/63
This change might be a problem, but there's no indication this code, which
originally landed in SDL_image 17 years ago with a large rewrite, is actually
fixing a specific issue. I'm also not sure we should actually make an effort
to accept a bmp that has a biClrUsed field that is both non-zero and _also_
incorrect.
Details:
Currently doing 4 system calls per WM_INPUT message, which can cause the thread handling the message loop to be swapped out several times:
* GetProp - to get window data from the window handle
* GetRawInputData - to retrieve the raw input data
* 2 calls to GetMessageExtraInfo - to ignore synthetic mouse events generated for touchscreens
In this change:
* Replaced GetProp by iterating the list of windows maintained by SDL (with a fallback to GetProp). Note that this will affect all messages and not just WM_INPUT
* only calling GetMessageExtraInfo if a touchscreen has been detected
Fix for https://jira.valve.org/browse/CSGO-4855
@saml
- especially because we can be promoted to true color 888
make sure we don't select a potentially software implementation
- hopefully fix bug #1482 (EGL ChooseConfig selects software renderer on Android)
If you hide a window on Mutter, for example, the compositor never requests
new frames, which will cause Mesa to block forever in eglSwapBuffers to
satisfy the swap interval.
We now always set the swap interval to 0 and manage this ourselves, handing
the frame to Wayland when it requests a new one, and timing out at 10fps just
to keep apps moving if the compositor wants no frames at all.
My understanding is that other protocols are coming that might improve upon
this solution, but for now it solves the total hang.
Fixes#4335.
These would accidentally get a titlebar because the "borderless" style mask
is zero but the resizable attribute adds a bit. I assume this happens because
you used to need window decoration to resize a window in macOS, but this
changed in later releases.
This only caused problems when recreating a window (you had an
SDL_WINDOW_OPENGL window and tried to create a Metal SDL_Renderer on it, etc).
Fixes#4324.
It doesn't appear to work anymore, and was disabled by default anyhow, since
the needed APIs are forbidden on the Mac App Store.
A better solution to lock the mouse to the window on macOS would still be
welcome. CGAssociateMouseAndMouseCursorPosition() works fine for relative
mouse mode, this was just a question of SDL_SetWindowGrab(). As it stands
now, a grabbed mouse can briefly break out of the window, causing varying
degrees of chaos.
This can give some performance boost, and save some resources, as there's no
reason to keep a copy of an SDL window's contents on the server: most SDL
apps are redrawing completely every frame, and the API allows for expose
events to tell an app a redraw is needed anyhow.
(And compositors are free to ignore this setting if it makes sense to do so,
according to the Xlib docs.)
Reference Issue #3776.
If a developer uses SDL_SetMemoryFunctions, we can't rely on SDL_free()
working when SDL_main() returns.
Signed-off-by: Steven Noonan <steven@valvesoftware.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>
I have a buggy system which reports a udev "change" event for an empty
USB-C port every 0.14 seconds, which causes annoying frame hitches
because SDL decides that means it needs to do a libusb hid_enumerate,
which is slow (~25ms!) because of the get_usb_string() calls in there.
We only need to re-enumerate if we've seen a device added or removed, so
let's filter out the change event first.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
Signed-off-by: Sam Lantinga <slouken@libsdl.org>
It's already set with ANativeWindow_setGeometry, and eventually set/changed also by eglCreateWindowSurface.
- avoid issues with older device where SurfaceView cycle create/changed/destroy appears broken:
calling create/changed/changed, and leading to "deuqueBuffer failed at server side, error: -19", with black screen.
- re-read the format after egl window surface is created, to report the correct one (sometimes, changed from RGBA8888 to RGB24)
Previous version used 'popen' which required to sanitize user provided text. Not
sanitizing text could cause failure if user provided text included a " or command
injection with `cmd`.
There is an error "E libEGL : validate_display:91 error 3008 (EGL_BAD_DISPLAY)"
that occurs when calling "eglQueryString(display, EGL_VERSION)", with EGL_NO_DISPLAY.
Khronos says "EGL_BAD_DISPLAY is generated if display is not an EGL display connection, unless display is EGL_NO_DISPLAY and name is EGL_EXTENSIONS."
but this was added in SDL with "EGL 1.5 allows querying for client version"
( 56363ebf61 )
In fact:
- it actually doesn't work on Android that has 1.5 egl client
- it works on desktop X11 (using SDL_VIDEO_X11_FORCE_EGL=1)
The commit moves the version call where it's used, eg inside the "if (platform) {"
and checks that "eglGetPlatformDisplay" has been correctly loaded.
This unearthed an unspeakably large amount of bugs in the wl_output enumerator,
notably the fact that the wl_output user pointer was to temporary memory!
This was "fixed" in e862856, and was then pointed out as a leak in 4183211,
which was undone in d9ba204. The busted fix was correct that the malloc was an
issue, but wrong about _why_; SDL_AddVideoDisplay copies by value and does not
reuse the pointer, so generally you want your VideoDisplay to be on the stack,
but of course the callbacks don't allow that, so a malloc was a workaround. But
we can do better and just host our temporary display inside WaylandOutputData
because that will be persistent while also not leaking.
Wait, wasn't I talking about move events? Right, that: wl_surface_listener does
at least give us the ability to know what monitor we're on, even though we have
no idea where we are on the monitor. All we need to do is check the wl_output
against the display list and then push a move event that both indicates the
correct display while also not being _too_ much of a lie (but enough of a lie
to where our event doesn't get discarded as "undefined" or whatever). The index
check for the video display is what spawned the great nightmare you see before
you; aside from the bugfix this is actually a really basic patch.
The information whether a specific joystick can be used as a gamepad is
not going to change every frame, so we can cache the result into a
variable.
This dramatically reduces the performance impact of SDL2 on small
embedded devices, since the code path that is now avoided was quite
heavy.
Fixes#4229.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
- Only focus a new window when one closes if the window that was closed was an SDL window
- If the application already has a key window set that is not an SDL window, don't replace it when the application is activated
- Only register the URL event handler when SDLAppDelegate is going to be set as the applications app delegate. This is to
be consistent with previous behavior that would only register the handler in -[SDLAppDelegate applicationDidFinishLaunching:]
and allows the running app to opt out of the behavior by setting its own app delegate.
- The URL event handler is now removed if it was set on SDLAppDelegate dealloc
There is no guarantee on what order the Wayland interfaces will come in, but the
callbacks were assuming that wl_data_device_manager would could before wl_seat.
This would cause certain desktops to not have any data_device to work with,
meaning certain features like the clipboard would silently no-op.
On windows, when toggling the state of RelativeMode rapidly, there is a
high chance that SDL_WINDOWEVENT_ENTER / SDL_WINDOWEVENT_LEAVE events
will stop firing indefinitely.
This aims to resolve that shortcoming by ensuring mouse focus state is
correctly updated via WM_MOUSELEAVE events arriving via the windows
event hook.
KWin has supported the shared and formalised zxdg_decoration since
Plasma 5.16 which came out mid 2019.
Whilst it made sense to support them both for a while, it should not be
needed for future SDL releases.
Because Wayland only supports FULLSCREEN_DESKTOP, fullscreen_mode never gets
assigned at all, meaning driverdata is always NULL! Depending on what the
compositor does this can lead to dramatically different results. GNOME was fine
without this, but Plasma would trip an event that unintentionally unset the
fullscreen mode and caused the game to fire a configure event _every frame_,
and of course the configure would send the fullscreen_mode output which was
still empty. The fix is to just use the SDL_VideoDisplay directly, which will
always have a valid wl_output.
Rename locally-defined Interface ID symbols to avoid conflict with
locally linked dxgi library. Prefixed with `SDL_` to match with
other references in render_d3d11 or wasapi.
If app requested <= 16 color depth and there is a 24-bit config available,
favor that. This fixes things that quietly expect to get truecolor output
but don't request it (...like SDL's render api...) and things that are
probably requesting 16-bit color as a fallback but expecting reasonable
systems to give them full depth.
Specifically, this fixes Life is Strange on Wayland, which uses the latter
approach, and anything using SDL_Render on Wayland, which uses the former.
Fixes#4056.
Fixes#4132.
- Move an immutable condition out of a for loop.
- Add a break statement to that loop when we find what we're looking for.
- Add an assert to make sure we don't overflow a buffer.
- Wrap a single-statement if block in braces.
- Adjust some whitespace.
Note that this is purely to make it possible to enter text that requires
composition - for example, before this commit Kanji input didn't work at all.
The big problem this still has is that we need the window position, and this is
still not implemented. Once we have this information we can do the equivalent
of XTranslateCoordinates to put the rectangle where we want it.
While we should normally expect _something_ from the stream based on the
AudioStreamAvailable check, it's possible for a device change to flush the
stream at an inconvenient time, causing this function to return 0.
Thing is, this is harmless. Either data will be NULL and the result won't matter
anyway, or the data buffer will be zeroed out and the output will just be
silence for the brief moment that the device change is occurring. Both scenarios
work themselves out, and testing on Windows shows that this behavior is safe.
commit 6b8f933589aa3925978a23e77a305a7e89c6ae4a
Author: Xing Ji <jixingcn@gmail.com>
Date: Wed Mar 24 22:31:29 2021 +0800
update the dynapi by `gendynapi.pl`
commit ebd1790c19983b652713f40ab1e139e485e1a2b7
Author: Xing Ji <jixingcn@gmail.com>
Date: Wed Mar 24 22:17:48 2021 +0800
revert the change in src/dynapi
commit 734b5f85c1613070081e39238e84198128971b53
Merge: 5a56e5a8 5ac6bd54
Author: Xing Ji <jixingcn@gmail.com>
Date: Wed Mar 24 22:14:40 2021 +0800
Merge remote-tracking branch 'libsdl/main' into jixingcn
commit 5a56e5a8227d9cff6b497b681c618a76bec1cae1
Author: Xing Ji <jixingcn@gmail.com>
Date: Mon Mar 22 23:55:10 2021 +0800
Fix#3596, can call the `SDL_TLSCleanup` to cleanup the TLS data when closing the application
Some of the SDL_AudioDevice struct members aren't initialized until after returning from the OpenDevice function. Since Pipewire uses it's own processing threads, the callbacks can be entered before all members of SDL_AudioDevice are initialized, such as work_buffer, callbackspec and the processing stream, which creates a race condition. Don't use these members when in the paused state to avoid potentially using uninitialized values and memory.
There seems to be a bug where it can wrap the text based on the minimum possible
window size, which can be worked around with --no-wrap. This technically uncaps
the width entirely, but this isn't wildly different from what other backends do.
Drop include of SDL_platform.h as SDL_plaform.h is already included by
SDL_internal.h -> SDL_config.h -> SDL_platform.h
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
This prevents the dsp target from stealing the audio subsystem but not
being able to produce sound, so other audio targets further down the list
can make an attempt instead.
Thanks to Frank Praznik who did a lot of the research on this problem!
A user reported that the mpv video player hangs after attempting to
set an unsupported number of channels with the SDL audio output,
because it thinks it's successfully opened the device. This makes
the failure graceful.
Removes the node nickname from sink/source nodes as it doesn't provide any useful information and names now match those used in Pulseaudio, so any stored configuration data will be compatible between the two audio backends.
The clang-cl compiler defines `__llvm__` but not `__GNUC__`. The `__cpuid` intrinsic doesn't seem to exist with clang-cl, so the code won't link properly. The `__GNUC__` versions of these functions will work properly on Windows with clang-cl.
Constify the min/max period variables, use a #define for the base clock rate used in the calculations and note that changing the upper limit can have dire side effects as it's a hard limit in Pipewire.
Replace "magic numbers" with #defines, explain the requirements when using the userdata pointer in the node_object struct and a few other minor code and comment cleanups.
Use the 'R' (rear) prefixed designations for the rear audio channels instead of 'S' (surround). Surround designated channels are only used in the 8 channel configuration.
Further refactor the device enumeration code to retrieve the default sink/source node IDs from the metadata node. Use the retrieved IDs to sort the device list so that the default devices are at the beginning and thus are the first reported to SDL.
The latency of source nodes can change depending on the overall latency of the processing graph. Incoming audio must therefore always be buffered to ensure uninterrupted delivery.
The SDL_AudioStream path was removed in the input callback as the only thing it was used for was buffering audio outside of Pipewire's min/max period sizes, and that case is now handled by the omnipresent buffer.
Extend device enumeration to retrieve the channel count and default sample rate for sink and source nodes. This required a fairly significant rework of the enumeration procedure as multiple callbacks are involved now. Sink/source nodes are tracked in a separate list during the enumeration process so they can be cleaned up if a device is removed before completion. These changes also simplify any future efforts that may be needed to retrieve additional configuration information from the nodes.
In some cases, it can be useful to have the KMSDRM backend even if it cannot
be used for rendering. An app may want to use SDL for input processing while
using another rendering API (such as an MMAL overlay on Raspberry Pi) or
using its own code to render to DRM overlays that SDL doesn't support.
This also moves the check for DRM master to an earlier point where we can fail
initialization of the backend, rather than allowing the backend to initialize
then failing the creation of a window later.
Unlike Mutter and Sway, KWin actually checks the serial passed in
wl_pointer_set_cursor(). The serial provided is supposed to be the
serial of the pointer enter event, but We were always passing 0.
This caused KWin to drop our requests to hide the cursor.
Thanks to the KDE folks for spotting this in my debug logs.
Fixes#3576
In the extremely unlikely event that inotify is not available (and,
therefore, HAVE_INOTIFY is not #defined), SDL will no-longer build.
This is because <unistd.h> is only included when HAVE_INOTIFY is
defined, and PR #4098 adds a call to access(…, F_OK), which requires
<unistd.h>.
(Note that the F_OK symbol is the only one which actually prevented
SDL from compiling, but both access() and close() fell back to implicit
definitions, which is a bit concerning.)
Fixes: 8d43f45a7b ("Don't use udev for joystick enumeration if running in a container")
If we are running in a container, like Flatpak[1] or pressure-vessel[2],
it's likely that we are using user namespaces,
therefore udev event notification via netlink won't work reliably.
Use their filesystem API to detect them and automatically fallback to
the inotify-based enumeration.
[1] <https://flatpak.org/>
[2]
<https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/tree/master/pressure-vessel>
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
This improves SDL's ability to detect HIDAPI joystick hotplug in a
container environment because we cannot reliably receive events from
udev in a container.
For a more detailed explanation of why this issue happens with
containers, please check the previous commit
"joystick: Use inotify to detect joystick unplug if not using udev"
(b0eba1c5).
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
As already explained in the previous commit "joystick: Allow libudev to
be disabled at runtime" (13e7d1a9), libudev can fail in a container.
To make it easier to experiment with, we add a new environment variable
"SDL_HIDAPI_JOYSTICK_DISABLE_UDEV" that disables udev and let it
fallback to the device enumeration using polling.
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
This fixes problems with controllers not being re-detected when a computer goes to sleep and a controller is removed and plugged back in while it's asleep.
Fixes SDL_CreateWindowAndRenderer (and similar situations) not choosing a Metal backend. See #3991.
Passing an explicit backend into CreateWindow, eg SDL_WINDOW_OPENGL or SDL_WINDOW_METAL, will still prevent the window from being used with other backend types.
SDL_isxdigit() should only accept A-Fa-f, not A-Za-z (it shouldn't use
SDL_isalpha()).
SDL_ispunct() shouldn't accept spaces (it should use SDL_isgraph()
instead).
SDL has been missing a bunch of these 'isX' functions for some time,
where X is some characteristic of a given character.
This commit adds the rest of them to the SDL stdlib, so now we have:
- SDL_isalpha()
- SDL_isalnum()
- SDL_isblank()
- SDL_iscntrl()
- SDL_isxdigit()
- SDL_ispunct()
- SDL_isprint()
- SDL_isgraph()
This uses the mechanism added in emscripten-core/emscripten#10843
which was applied to SDL1 and OpenAL. This adds the same for SDL2.
This also reverts commit 865eaddffed50dbd13e6564c3f73902472cf74e8
which did something similar, but the new mechanism is more effective.
The DJGPP compiler emits many warnings for conflicts between print
format specifiers and argument types. To fix the warnings, I added
`SDL_PRIx32` macros for use with `Sint32` and `Uint32` types. The macros
alias those found in <inttypes.h> or fallback to a reasonable default.
As an alternative, print arguments could be cast to plain old integers.
I opted slightly for the current solution as it felt more technically correct,
despite making the format strings more verbose.
wahil1976
This patch fixes the warnings seen when compiling the Wayland backend. This will also be required in the future to avoid issues with compilation.
When SleepConditionVariableSRW() releases the SRW lock internally, it causes
our SDL_mutex_srw state to become inconsistent. The lock is unowned yet inside,
the owner is still the sleeping thread and more importantly the owner count is
still 1.
The next time someone acquires the lock, they will bump the owner count from 1
to 2. At that point, the lock is hosed. From the internal lock state, it looks
to us like that owner has acquired the lock recursively, even though they have
not. When they call SDL_UnlockMutex(), it will see the owner count > 0 and not
call ReleaseSRWLockExclusive().
Now when someone calls SDL_CondSignal(), SleepConditionVariableSRW() will start
the wakeup process by attempting to re-acquire the SRW lock. This will deadlock
because the lock was never released after the other thread had used it. The
thread waiting on the condition variable will never be able to wake up, even if
the SDL_CondWaitTimeout() function is used and the timeout expires.
There were two different implementations of IsBluetoothXboxOneController(), one
in SDL_hidapi_xbox360.c and one in SDL_hidapi_xboxone.c. The latter had been
updated to include USB_PRODUCT_XBOX_ONE_SERIES_X_BLUETOOTH while the former had
not.
This mismatch led to the Xbox Series X failing on macOS only. We have special
code for handling the 360Controller driver for macOS which requires us to use
the Xbox 360 driver for wired Xbox One controllers, and the SDL_hidapi_xbox360
version of IsBluetoothXboxOneController() was used to determine which devices
were wired.
In addition to adding the missing USB_PRODUCT_XBOX_ONE_SERIES_X_BLUETOOTH, this
change moves IsBluetoothXboxOneController() into a single shared function which
will ensure this bug won't happen again.
This is caused by the Metal renderer recreating the window because by default we create an OpenGL window on macOS.
It turns out that at least on macOS 10.15, a window that has been initialized for OpenGL can also be used with Metal. So we'll skip recreating the window in that case.
Hiroyuki Iwatsuki
If you pass the C string directly to NSLog(), it will be garbled with Japanese and probably other language strings, or no log will be output at all.
NSLog("Hello, World!"); // => "Hello, World!"
NSLog("こんにちは、世界！"); // => No output...
Therefore, you need to convert the string to an NSString before passing it to NSLog().
NSString *str = [NSString stringWithUTF8String:"こんにちは、世界！"];
NSLog(@"%@", str); // => "こんにちは、世界！"
Thank you.
By default, we will minimize the window when we receive Alt+Tab with a
full-screen keyboard grabbed window to allow the user to escape the
full-screen application.
Some applications like remote desktop clients may want to handle Alt+Tab
themselves, so provide an opt-out via SDL_HINT_ALLOW_ALT_TAB_WHILE_GRABBED=0.
For keys that are already down when we install the keyboard hook, we need to
allow the WM_KEYUP/WM_SYSKEYUP message to be processed normally. This ensures
that other applications see the key up, which prevents the key from being stuck
down from the perspective of other apps when our grab is released.
GNOME Mutter requires keyboard grab for certain important functionality like
window resizing, interaction with the application context menu, and opening the
Activites view. To allow Mutter to grab the keyboard as needed, we'll ungrab
when the mouse leaves our window.
To be safe, we'll do this for all WMs since forks of Mutter and Matacity (and
possibly others) may have the same behavior, and we don't want to have to keep
track of those.
Sylvain
I propose this new version for SDL_stretch.c that drops mprotect and asm
Code is similar to the StretchLinear, but the steps computation are kept similar to the nearest.
so that:
- it's pixel perfect with nearest
- as fast as asm I think
- no asm, nor mprotect
- benefit for all archicture
Ozkan Sezer
- adds MSVC __declspec(align(x)) support,
- disables asm if PAGE_ALIGNED no macro is defined,
- still disables asm for gcc < 4.6, need more info,
- drops Watcom support.
This adds SDL_SetWindowKeyboardGrab(), SDL_GetWindowKeyboardGrab(),
SDL_SetWindowMouseGrab(), SDL_GetWindowMouseGrab(), and new
SDL_WINDOW_KEYBOARD_GRABBED flag. It also updates the test harness to exercise
this functionality and makes a minor fix to X11 that I missed in
https://hg.libsdl.org/SDL/rev/02a2d609369b
To fit in with this new support, SDL_WINDOW_INPUT_CAPTURE has been renamed to
SDL_WINDOW_MOUSE_CAPTURE with the old name remaining as an alias for backwards
compatibility with older code.
The grabbed_window field is superfluous now since SDL added the
SDL_GetGrabbedWindow() function, so it can be removed.
DirectFB_SetWindowMouseGrab() is also simplified because SDL handles ungrabbing
any previously grabbed window prior to calling SetWindowMouseGrab() now.
Compile-tested only.
UMU
#define SDL_COMPOSE_ERROR(str) SDL_STRINGIFY_ARG(__FUNCTION__) ", " str
I think SDL_STRINGIFY_ARG should be removed.
#define SDL_COMPOSE_ERROR(str) __FUNCTION__ ", " str
(verified with Visual Studio 2019)
jibb
New hint to let the user opt out of having Switch controllers' Home button lit when opened.
This is more consistent with the Switch itself (which doesn't light the button normally) and may be preferred by users who may disconnect their controller without letting the application close it.
I think this warrants a Switch-specific hint because the default behaviour is unusual (inconsistent with using a Switch controller on a Switch itself or with some other programs on PC), and because of that it's distinct from other lights (the player number on Switch controllers and the player colour on PlayStation controllers).
SDL_SetKeyboardFocus(NULL) will lift any keys still pressed when keyboard focus
leaves the window, but then key repeat comes behind our backs and presses the
key down again. This results in an infinite stream of SDL_KEYDOWN events when
focus leaves the window with a key down (particularly noticeable with Alt+Tab).
This gives us flexibility to add others hints to control keyboard grab behavior
without having to touch all of the backends. It also allows us to possibly
expose keyboard grab separately from mouse grab for applications that want to
manage those independently.
These are explicitly written in C code rather than generated at build
time, so they weren't affected by changing how we invoke
wayland-scanner.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We support both the org.freedesktop.ScreenSaver D-Bus API (same as the X11
backend) and the Wayland idle_inhibit_unstable_v1 protocol.
Some Wayland compositors only support one or the other, so we need both to
for broad compatibility.
Wayland compositors seem to have standardized on 10 units per "wheel tick" for
continuous scroll events, so we need to convert these axis values to ticks by
dividing by 10 before reporting them in SDL_MOUSEWHEEL events.
This is implemented via a low-level keyboard hook. Unfortunately, this is
rather invasive, but it's how Microsoft recommends that it be done [0].
We want to do as little as possible in the hook, so we only intercept a few
crucial modifier keys there, while leaving other keys to the normal event
processing flow.
We will only install this hook if SDL_HINT_GRAB_KEYBOARD=1, which is not
the default. This will reduce any compatibility concerns to just the SDL
applications that explicitly ask for this behavior.
We also remove the hook when the grab is terminated to ensure that we're
not unnecessarily staying involved in key event processing when it's not
required anymore.
[0]: https://docs.microsoft.com/en-us/windows/win32/dxtecharts/disabling-shortcut-keys-in-games
Hiding the cursor doesn't appear to work reliably on GNOME when another window
steals mouse focus right as we call SDL_ShowCursor(SDL_DISABLE). This can happen
when the keyboard shortcut inhibition permission prompt appears in response to a
call to SDL_SetRelativeMouseMode() with SDL_HINT_GRAB_KEYBOARD=1. The result is
that the default cursor is stuck locked in position and visible on screen
indefinitely.
By redrawing the cursor on pointer focus enter, the cursor now disappears upon
the first mouse motion event. It's not perfect but it's way better than the
current behavior.
Use zwp_keyboard_shortcuts_inhibit_manager_v1 to allow SDL applications
to capture system keyboard shortcuts like Alt+Tab when keyboard grab is
enabled via SDL_HINT_GRAB_KEYBOARD.
Existing SDL applications may not know about the need to set a specific
hint to enable rumble on PS5 controllers, even though they may already
set the equivalent SDL_HINT_JOYSTICK_HIDAPI_PS4_RUMBLE hint for PS4
controller rumble support.
Rather than requiring those developers update their apps, let's use the
SDL_HINT_JOYSTICK_HIDAPI_PS4_RUMBLE value as an indication of the behavior
they are expected for all PlayStation controllers.
From hidapi mainstream git: https://github.com/libusb/hidapi/issues/142d2c3a9862e
Read callback may fire itself on its own even after its been requested
to stop and exactly before the calling code waits for its completion in
indefinite loop. Explicitly preventing re-fireing the submission loop
fixes the issue.
jibb
I'm testing with DualShock 4, DualSense, Switch Pro Controller, and PowerA Switch Controller.
I'm using the standard mapping file from here:
https://raw.github.com/gabomdq/SDL_GameControllerDB/master/gamecontrollerdb.txt
With SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS turned off (set to "0") I expect the button positions to be the same on all devices, based on Xbox controller button naming (eg SDL_GameControllerGetButton(g, SDL_CONTROLLER_BUTTON_Y) gives me whether the North face button is pressed).
However, the Switch Pro Controller layout is wrong (matching labels rather than positions, so X and Y are swapped and A and B are swapped). And with the PowerA controller the East and West buttons are correct, but the North and South buttons are swapped instead.
Mathias Kaerlev
Also seeing this on 2.0.14. This is most likely a regression, since we weren't seeing this on an earlier SDL version.
I suspect it might be caused by this commit:
a569b21188 (diff-da9344d94c66b8c702a45e7649f412039f08bba83bd82de33f5c80ea9c8c39d5)
It seems like both the HIDAPI driver and SDL_gamecontroller.c will try to swap the buttons if the hint is set to 0, causing the button remap to cancel out.
RustyM
This is related to Bug 5034, but crashes under a somewhat different condition.
In the latest tip (changeset 13914) or with the SDL 2.0.12 source + David?s 5034 patch, unplugging and then replugging in certain controller types on macOS will crash. A mix of new controllers like Switch Pro, PS4 and Xbox One all work without issue. But if a controller without a rumble function, like many SNES retro USB gamepads, is mixed with a PS4 or Switch Pro controller it will crash.
File: joystick/darwin/SDL_sysjoystick.c
Function: static recDevice *FreeDevice(recDevice *removeDevice)
On line 159: while (device->pNext != removeDevice) {
Causes: Thread 1: EXC_BAD_ACCESS (code=1, address=0x188)
This can be reproduced in testgamecontroller" by starting the test program with both a ?retro? controller plugged in and a ?modern rumble? controller (Switch Pro/PS4). This may crash on launch, but it depends on which controller ends up as device 0. If it doesn?t crash, unplug the ?modern rumble? controller and plug it back in.
Some of the "retro" controllers I?ve seen this crash with:
- iBuffalo SNES Controller
- 8Bitdo SN30 Gamepad (in MacOS mode)
- Retrolink NES Controller
- HuiJia SNES Controller Adaptor
The issue appears macOS specific. Seen on 10.12.6 and 10.14.6. Not seen on Windows 10.
The while loop in FreeDevice() assumes that every device is not NULL.
recDevice *device = gpDeviceList;
while (device->pNext != removeDevice) {
device = device->pNext;
}
device->pNext = pDeviceNext;
So maybe we should check for NULL here? Or instead prevent adding NULL devices to the list in the first place? Checking device for NULL before entering the loop appears to work.
recDevice *device = gpDeviceList;
if (!device) {
while (device->pNext != removeDevice) {
device = device->pNext;
}
}
device->pNext = pDeviceNext;
sashikknox
In some cases, need create EGLWindow with SDLWindow. In X11 i can get pointer to NativeWindow from **struct SDL_SysWMinfo wmInfo**
```C++
struct SDL_SysWMinfo wmInfo;
SDL_GetWindowWMInfo(ptSDLWindow, &wmInfo)
#if defined(__unix__) && defined(SDL_VIDEO_DRIVER_X11)
nativeWindow=(EGLNativeWindowType)wmInfo.info.x11.window;
nativeDisplay=(EGLNativeDisplayType)wmInfo.info.x11.display;
#endif
```
than i can create EGLSurface
```
eglCreateWindowSurface(nativeDisplay, EGL_CONFIG, nativeWindow, SURFACE_ATTRIBUTES);
```
in Wayland i can do it with same way, just need pointer to **EGLWindow**, we already have pointer to **wl_display** from **SDL_sysWMInfo**, need add to **wl** struct in SDL_SysWMInfo another pointer to **struct wl_egl_window *egl_window;**. And in wayland backend, in function **Wayland_GetWindowWMInfo** return pointer to **egl_window** from **SDL_WindowData**
Now i use patched statically built SDL2 in port of Quake 2 GLES2 for SailfishOS (it use QtWayland):
link to SDL2 commit and changed string for patch:
- 6858a618cd
- b1e29e87b9/SDL2/src/video/wayland/SDL_waylandwindow.c (L463)
link to use in Quake2 port:
1. here i get pointer to EGLNativeWindowType: 6d94fedb1b/Engine/Sources/Compatibility/OpenGLES/EGLWrapper.c (L319)
2. then use it for create EGLSurface: 6d94fedb1b/Engine/Sources/Compatibility/OpenGLES/EGLWrapper.c (L391)
wahil1976
This patch adds a written-from-scratch WSCONS driver for OpenBSD. It does not have hardcoded keymaps, and it features mouse support when wsmux is available.
For this to work, it needs access to the /dev/wskbd* devices which are not available to non-root users by default. Access to those can be granted by changing /etc/fbtab to give the logging user the ownership of those devices.
Note that axes are changed to match the axes we're using with PlayStation controllers, since users will appreciate consistent behaviour across devices.
Nia Alarie
The NetBSD kernel's audio resampling code is much simpler and lower quality than libsamplerate.
Presumably, if SDL always performs I/O on the audio device in its native frequency, we can avoid resampling audio in the kernel and let SDL do it with libsamplerate instead.
Dominik Reichardt
Exult (http://exult.info) has an editor app that uses GTK+2. Up to now we were using X's drag'n'drop to allow dropping of assets from the editor onto Exult.
There is now an experimental branch that makes use of SDL_DROPFILE. That works under X, dropping in Exult's SDL2 window puts the asset right at the spot you dropped at.
On macOS with native Exult and Quartz GTK+2 this doesn't work, the location of the drop is where the mouse was last tracked before you left the window (usually one of the edges, unless you tabbed out).
All we tried out pointed to the fact that the location update needs to be done by the dropfile event in SDL2, not by our own (which always only worked after the Exult window getting focus).
This patch adds this to SDL_cocoawindow.m and it works perfectly, passing the correct coordinates to our code (SDL_GetMouseState()).
- explicitly use UNICODE versions of DrawText, EnumDisplaySettings,
EnumDisplayDevices, and CreateDC: the underlying structures have
WCHAR strings.
- change WIN_UpdateDisplayMode and WIN_GetDisplayMode() to accept
LPCWSTR instead of LPCTSTR for the same reason.
- change WIN_StringToUTF8 and WIN_UTF8ToString to the explicit 'W'
versions where appropriate.
i.e. where the string is known guaranteed to be WCHAR*, in:
- SDL_dinputjoystick.c (WIN_IsXInputDevice): VARIANT->var is BSTR (WCHAR*)
- SDL_rawinputjoystick.c (RAWINPUT_AddDevice): string is WCHAR*
- SDL_windows_gaming_input.c (IEventHandler_CRawGameControllerVtbl_InvokeAdded):
string is WCHAR*
There should be more of these..
_InterlockedExchange_rel() is required for correctness on ARM because
the _ReadWriteBarrier() macro is only a compiler memory barrier, not a
hardware memory barrier. Due to ARM's relaxed memory model, this means
the '*lock = 0' write may be observed before the operations inside the
lock, causing possible corruption of data protected by the lock.
_InterlockedExchange_acq() is more efficient on ARM because it avoids an
expensive full memory barrier that _InterlockedExchange() does.
C.W. Betts
I tested building commit http://hg.libsdl.org/SDL/rev/7adf3fdc19f3 on Mac Catalyst and found some issues:
* MTLFeatureSet_iOS_* enums aren't available under Mac Catalyst.
* OpenGL ES is unavailable under Mac Catalyst.
* Some Metal features are available under Catalyst but not iOS, such as displaySyncEnabled.
* Set Metal as the default renderer on Mac Catalyst
Attaching a patch that will make SDL2 build for Mac Catalyst.
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.
Caleb Cornett
For a window created with SDL_WINDOW_ALLOW_HIGHDPI, SDL_GL_GetDrawableSize will return the high-dpi drawable size even before any GL context creation happens. But SDL_Metal_GetDrawableSize will return the size of the window if the Metal view has not been created. This is confusing and inconsistent behavior.
An easy way to test this is to build testgl2 and testvulkan on macOS with the SDL_WINDOW_ALLOW_HIGHDPI flag enabled during window creation. The GL2 program will report a drawable size of 2x window width and 2x window height, while the Vulkan program will report the window size.
This patch addresses the issue by falling back to using the content view dimensions if no Metal view exists in the window. (The code for this was taken directly from Cocoa_GL_GetDrawableSize.) With this change, the testvulkan behavior matches that of testgl2.
Note that I haven't tested for this issue on UIKit. It's possible a similar change will need to be made there too.
David Carlier
This form of 'or' provides a hint that performance
will probably be improved if shared resources dedicated
to the executing processor are released for use by other
processors
- 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.
Ivan Kuzmenko
MCST Elbrus 2000 (E2K, https://en.wikipedia.org/wiki/Elbrus_2000) is a russian processor architecture based on VLIW/EPIC instruction set (like Intel Itanium (IA-64) architecture). Architecture has half native / half software support of most Intel/AMD SIMD (e.g. MMX/SSE/SSE2/SSE3/SSSE3/SSE4.1/SSE4.2/AES/AVX/AVX2 & 3DNow!/SSE4a/XOP/FMA4).
It also has built-in x86/x86_64 <-> e2k binary translators (RTC, http://www.mcst.ru/rtc and Lintel, http://www.mcst.ru/lintel) that can run code for x86/x86_64 architecture (Transmeta did something similiar with their Crusoe series) with SIMD extensions support.
Attached patch allows SDL2 to detect extensions supported by E2K like MMX, 3dNOW!, AVX etc. (test/testplatform log: https://termbin.com/7qs3).
wahil1976
This patch adds support for OpenBSD to KMSDRM_LEGACY. Note that the patch won't be ported to the atomic KMSDRM backend because OpenBSD does not support atomic KMS properly yet.
Is automatically used when the SRW SDL_mutex implementation is active.
Otherwise falls back to the generic implementation.
v2: - Rebase onto master fa3ea1051a4b
https://bugzilla.libsdl.org/show_bug.cgi?id=5308
The udev code labels devices that are found by this code with
ID_INPUT_KEY which in turn gets used by SDL to label the devices as
SDL_UDEV_DEVICE_KEYBOARD.
This was missing for the code path when udev is not running and as such
devices such as the power button of a phone was not detected as keyboard
input and no devices were emitted.
Cameron Cawley
stdlib: Added SDL_round, SDL_roundf, SDL_lround and SDL_lroundf
The default implementation is based on the one used in the Windows RT video driver.
Keep Semaphore Kernel Object impl for Windows 7 and older - choose at runtime
v2: - Fix mixed int/LONG types
- Reorder definitions
- Add missing include
v3: - Use `GetModuleHandle()` to load the API Set
v2: - Add SRW definitions as suggested by Ozkan Sezer
Allows building against older platform headers.
- Rename "hidden" function parameter `mutex_` to `_mutex`
v3: - Use GetModuleHandle instead of LoadLibrary
- Fix typo in comment
