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.
