It's possible that an external component (probably a GL/VK context) committed, so we need to cover our bases and detach in both HideWindow and ShowWindow.
Fixes a crash in UE5 editor's pop-ups.
Partially fixes the mouse cursor in UE5 editor. Imperfect because UE5 uses window position and global mouse state to get position, but of course we don't have global mouse and this is just to get the right display index so this still fails overall. We really need to make global mouse support a feature query...
So if Gnome/KDE/etc have a keyboard shortcut or titlebar decoration to
make any window go fullscreen (with the _NET_WM_FULLSCREEN flag on the
_NET_WM_STATE property), we update the SDL window flag.
Fixes#5390.
This makes sure the window doesn't have outdated values if you try to access
them (or call something that does, like SDL_SetWindowMinimumSize).
Fixes#5233.
On Wine, when a window is programmatically minimized in response
to losing focus, we receive a WM_ACTIVATE for the deactivation,
but GetForegroundWindow still indicates that our window is focused.
This causes an incorrect SDL_WINDOWEVENT_FOCUS_GAINED.
This is probably a Wine bug, but it may take a while to fix and
then for the fix to make its way to users.
libGL.so may register callbacks that can be invoked upon XCloseDisplay().
If XCloseDisplay() is called after libGL.so is unloaded, the callback pointer
will point at freed memory and invoking it will crash.
The texture framebuffer check optimized out in f37e4a9 was causing libGL.so to
never be unloaded as a side-effect. Skipping it exposed this bug by allowing
libGL.so to actually unload.
We were returning the report size from HIDAPI_DriverPS5_RumbleJoystick() rather
than 0 upon success, causing SDL_JoystickRumble() (and callers) to think that
rumbling failed.
This didn't cause major problems until 1868c5b, when it started preventing
rumble state from being persisted in the joystick core, even though it was
successfully sent to the hardware.
This led to all sorts of strangeness, including broken rumble duration and
attempts to stop rumble being discarded.
The functions can go south if other operations are in progress, like
X11_SetWindowBordered, which might be doing something traumatic behind the
scenes of the window manager.
We can't make these tasks totally synchronous, which would fix the problem,
because not only can the window manager block however long it wants, it might
also decide to deny our requests without any notification, so we'd be waiting
forever for a window change that isn't coming. :(
Fixes#5274.
Use viewports for non-fullscreen windows when the desktop uses fractional scaling and the window is flagged as DPI-aware to provide a backbuffer mapped as close to 1:1 output as possible. In the cases of odd window sizes the backbuffer may be a pixel off of scaling perfectly into the window size due to its scaled size being rounded off, but a minute amount of scaling during output is likely preferable to the large amounts of overdraw needed with integer scaled buffers.
Expose as many emulated display modes as possible. They will currently display stretched to the display's native desktop aspect, but if an application requires a hardcoded resolution, it will work at minimum.
Aside from the change in the emulated display mode list, the Wayland event handling code had to be updated to support separate scaling for the x and y axes, as square pixels are no longer guaranteed.
Wayland doesn't support mode switching, however Wayland compositors can support the wp_viewporter protocol, which allows for the mapping of arbitrarily sized buffer regions to output surfaces. Use this functionality, when available, for fullscreen output when using non-native display modes and/or when dealing with scaled desktops, which can incur significant overdraw without this extension.
This also allows for the exposure of arbitrarily sized, emulated display modes, which can be useful for legacy compatability.
1. Mod index values are (mostly) constant, so can be done with xkb_state_new
2. Mods can change without the group changing, avoid remap events if possible
Lastly, as a bonus, I added braces to the locale check, because I was nearby.
When using shared linking (linking in the normal way with
-lwayland-client) rather than loading Wayland libraries dynamically at
runtime, listing symbols that don't exist in the current version results
in a build failure. We don't actually call wl_proxy_marshal_flags() or
wl_proxy_marshal_array_flags() directly; the reason we need them is
that they're called by the code generated by wayland-scanner >= 1.20.
If we're building against an older Wayland library, then we'll have its
corresponding version of wayland-scanner (mismatched versions are not
supported), so we won't need those two symbols, and can avoid generating
a dependency on them.
Conversely, if we're building against a newer Wayland library, the
generated code will call them unconditionally, so we cannot treat them as
optional and gracefully fall back: that would result in a crash. Instead,
treat them as a mandatory part of the Wayland library, so that if they
are not found at runtime, we can fall back to X11 without crashing.
libwayland 1.18 is in several LTS distributions (Ubuntu 20.04,
Debian 11, RHEL 8) so avoiding a hard dependency on 1.20 is quite
useful.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: https://github.com/libsdl-org/SDL/issues/5376
Using wl-output to get the desktop display dimensions and dividing by the integer scale factor will not return the correct result when using a desktop with fractional scaling (e.g. a 3840x2160 display at 150% will incorrectly report the scaled desktop area as 1920x1080 instead of 2560x1440). Use the xdg-output protocol, if available, to retrieve the correct desktop dimensions and offset.
Versions 1 through 3 of the protocol are supported.
- which also enable/disable the orientation lock status.
This is only provided when the window is not SDL_WINDOW_FULLSCREEN (see SDL_video.c).
Final orientation also depends on SDL_HINT_ORIENTATIONS.
The Java code needs the native functions to be implemented, even if
they're not surfaced via the C API, therefore, a stub version of
functions were made only to the purpose of "fill the gaps" when
SDL_HIDAPI_DISABLED set to 1.
if SDL_EnumUnixAudioDevices() fails to find any devices,
set an error message on the exit path. Without this,
SDL_Init() could fail without any message available
in SDL_GetError().
This isn't obvious, but makes sense when thinking about how games actually use it. This is also in line with how Windows mouse relative mode is implemented.
Fixes https://github.com/libsdl-org/SDL/issues/5340
Here's an IRC dump that hopefully explains the issue this fixes:
> I'm debugging something odd where, for a libre game,
unvanquished.net (a FPS), relative mouse input in fullscreen is
buggy
> it's like, working mostly ok, but it has a weird
performance/cleanup bug
> after some time in relative mouse input mode, some time as low
as 15s, usually more, the SDL sends A LOT of relative mouse
input per frame
> almost all of which have xrel==0 && yrel==0
> by A LOT, I mean that after ~1min, it's usually in the
thousands per frame
> each frame, a while ( SDL_PollEvent( &e)) loop reads the
inputs, but it seems SDL is not clearing the list.
> one way to clear the list is to open the in-game console or
menu, which switches the input mode to absolute, then close it
which gets a working relative input mode (for some time at least)
> I've shown the issue to be present with SDL2.0.20 but not with
2.0.14 on my system
> some other players on Arch Linux (SDL2.0.20) report a possibly
related issue, where some keys seem to be pressed at random
> I've did some bisection on SDL master, and I've found that
there are actually two commits involved, one breaking it
totally (no input at all), and one fixing it partially (with
the problem described above)
First related commit that breaks it totally:
commit 82793ac279
Author: Sam Lantinga <slouken@libsdl.org>
Date: Thu Oct 14 14:26:21 2021 -0700
Fixed mouse warping while in relative mode
We should get a mouse event with an absolute position and no relative motion and shouldn't change the OS cursor position at all
Second related commit, that halfway fixes it:
commit 31f8c3ef44
Author: Sam Lantinga <slouken@libsdl.org>
Date: Thu Jan 6 11:27:44 2022 -0800
Fixed event pump starvation if the application frequently pushes its own events
Reverting the first commit did fix the issue for me, but would
probably reintroduce the bug it was fixing(?). This patch should
fix it for everyone hopefully.
https://github.com/DaemonEngine/Daemon/issues/600 is the upstream
bug, and contains some early investigation.
According to MSDN, we can also get SIZE_MAXHIDE and SIZE_MAXSHOW,
based on state changes to other windows. It's not clear under
what circumstances this will happen (I saw some docs indicating
it may require multiple application windows), but it doesn't seem
right to treat them as RESTORED.
- no need to keep the error in a static variable
- always print the error code
- reduce the required stack-size
- reduce the number of snprintf calls (and code size)
* Fixes for IME Composition Truncation + Addition of SDL_ClearComposition, SDL_IsTextInputShown
* Fixed: Documentation and code style issues raised during code review.
The name that the Raw Input joystick driver pulls from the HID stack comes
from USB string descriptors contained on the device. For official wireless
receivers, this always contains "Xbox 360 Wireless Receiver for Windows"
which matches the friendly name that WGI provides.
3rd party Xbox 360 wireless receivers may have different strings in their
USB string descriptors (one uses "XBOX 360 For Windows" instead). This
fails to match WGI's name and causes Raw Input and WGI to both report the
same gamepad.
Since wireless Xbox 360 controllers seem to have a consistent VID/PID
regardless of the adapter enumerating them, we can also match on that to
catch these.
The duplicate case reported to me was:
Controller (XBOX 360 For Windows) - 030000005e040000a102000000007200
Xbox 360 Wireless Receiver for Windows - 030000005e0400000000000000007701
This adds support for all 3 of the gamecube controller's rumble modes
Rumble: 1
Stop: 0
StopHard: 2
This is useful for applications that need the full range of support
This also adds a hint to control rumble behavior, defaults 0 to maintain compatibility
If the app requested a specific renderer, even if it's not the optimal path,
let them have it, because they might want to render with a specific GPU API
on top of the framebuffer pixels.
This fixes DosBox-X crashing on startup, which forces the hint to "opengl".
Now we see if we can create an SDL_Renderer, and if that renderer reports
itself as "accelerated," and added some initial heuristics to the OpenGL
renderer to make better decisions about what qualifies as "accelerated."
This adds some FIXMEs that might be merely hypothetical, and removes the
old OpenGL checks from the video subsystem that probably weren't meaningful
in modern times. This will definitely need to improve the existing list
in the GL renderer, to catch things like llvmpipe, etc.
Reference issue #4624.
The io_list_check_add() and io_list_remove() functions are only ever called from within the Pipewire thread loop, so the locks are redundant. io_list_sort() is called from within a lock in the device detection function, so those additional locks are redundant as well.
Remove the hard upper limit of 8192 samples and instead use the buffer sizes provided by Pipewire to determine the size of the intermediate input buffer and whether double buffering is required for output streams. This allows for higher latency streams to potentially avoid double-buffering in the output case, and we can guarantee that the intermediate input buffer will always be large enough to handle whatever Pipewire may deliver.
As the buffer size calculations occur in a callback in the Pipewire processing thread itself, the stream readiness check has been modified to wait on two distinct flags set when the buffers have been configured and when the stream is ready and running.
- use the result of SDL_ConvertPixels to propagate error
- get rid of the verbose error message of D3D11_RenderReadPixels in case SDL_ConvertPixels failed
- always set error message in SDL_EGL_ChooseConfig / SDL_EGL_CreateContext
- assume SDL_EGL_DeleteContext does not alter the error message
- sync generic error message of SDL_EGL_MakeCurrent with SDL_EGL_Get/SetSwapInterval
- do not overwrite error message of SDL_EGL_ChooseConfig in WINRT_CreateWindow
- add missing error-message in SDL_LoadBMP_RW
- check return value of SDL_RWtell in SDL_LoadBMP_RW
- use standard SDL_EFREAD error instead of custom strings
+ adjust return type of readRlePixels
- allocate ime_candidates on demand
- allow write to the whole allocated memory of ime_candidates
- ensure ime_candcount is set to zero in case the candidates can not be queried for any reason
- move IME_ShowCandidateList, ImmGetContext and ImmReleaseContext to this function
- set ime_candpgsize to MAX_CANDLIST if dwPageSize is zero
- comment out deselection of ime_candsel in case of korean language for the moment (LANG_CHT does not work anyway)
The context and stream creation functions will destroy the passed properties object on failure, so no need to do it manually.
The pw_properties_free() function pointer is no longer needed, so it can be removed.
This reverts commit ca36cdb185f2f26241598068927821896f36b904.
The older Windows SDK's headers are wrong, and this change would crash if
you hotplug a device.
- drop unnecessary hascapture check
- call SDL_InvalidParamError and return -1 in case the index is out of range
- do not zfill SDL_AudioSpec
- adjust documentation to reflect the behavior
- reorganize the loop which checks for the right wave-format
- use the return value of UpdateAudioStream
- ensure SetError is called in SDL_NewAudioStream
- use assert instead of a check (it is a static function with constant parameter)
- assume it is called with 0 first (simplifies the logic)
- reuse dwLang value instead of a new 'call' to LANG()
- use SDL_bool if possible
- assume NULL/SDL_FALSE filled impl
- skip zfill of current_audio at the beginning of SDL_AudioInit (done before the init() calls)
If we get a SDL_SetWindowSize() call right after SDL_SetWindowFullscreen() but
before we've gotten a new configure event from the compositor, the attempt to
set our window size will silently fail (when libdecor is enabled).
Fix this by remembering that we need to commit a new size, so we can do that
in decoration_frame_configure().
This prevents SDL from making an OpenGL context and maybe throwing it away
immediately by default. It will now only do it when trying to request a
window framebuffer directly, or creating an SDL_Renderer with the "software"
backend, which makes that request itself.
The way SDL decides if it should use a "texture framebuffer" needs dramatic
updating, but this solves the immediate problem.
Reference Issue #4624.
First window is created and it triggers and 'EnterNotify' event
which calls SDL_SetMouseFocus() and X11_ShowCursor() while the second
windows hasn't finished to be created (eg window->driverdata isn't set)
Just check for a valid 'driverdata'
The issue is that MS Windows synthesizes a mouse-move event in response
to touch-move events, and those mouse-move events are NOT labeled as
coming from a touch (e.g. GetMouseMessageSource() will not return
SDL_MOUSE_EVENT_SOURCE_TOUCH for those synthesized mouse-move events).
In addition, there seems to be no way to prevent this from happening;
https://gist.github.com/vbfox/1339671 claims to demonstrate a technique
to prevent it, but in my experience, it doesn't work.
Because of this, the "fallthrough" case can't test that the synthesized
mouse-move came from a touch-move, and starts erroneously pressing down
the mouse-button, leading to massive confusion in the client
application.
If a touch-down event is received for an existing touch-ID, that
probably means the operating system lost it, and that the missing
touch-up should be synthesized, to keep the client state coherent.
This caused some weird stuff to happen in the libdecor path, probably because
the window hasn't actually been mapped yet. It ends up calling stuff that
should not yet apply, and so fullscreen in particular would have a really
messed up titlebar.
The good news is, libdecor is good about tracking fullscreen state, so we can
let the callback do this for us. Keep this for xdg_shell because we actually
map the window ourselves, so we know this call is valid for that path.
Pipewire, as of 0.3.22, uses client config files to load modules instead of explicitly specifying them (PW_KEY_CONTEXT_PROFILE_MODULES is deprecated). Use the new method to load the realtime module to boost the audio thread priority.
From e6cc4e7f4b8189be55dd3b0e13e54e59f73d7672 Mon Sep 17 00:00:00 2001
From: X512 <danger_mail@list.ru>
Date: Thu, 30 Jan 2020 04:01:58 +0900
Subject: libsdl2: Remove BDirectWindow, fix OpenGL handling.
* BDirectWindow changed to BWindow.
* Implemented fullscreen.
* Introduced view for non-OpenGL drawing.
* Drawing thread removed, window thread is used instead.
* Use BGLView as OpenGL context. Implement proper context switching and OpenGL
locking. Only one context per window is supported. BGLView should be not
deleted when window is closed, it deleted when deleting context.
Previous to this commit, key repeats events were typically generated when
pumping events, based on the time of when the events are pumped. However,
if an application doesn't call `SDL_PumpEvents` for some seconds, this time
can be multiple seconds in the future compared to the actual key up event time,
and generates key repeats even if a key was pressed only for an instant.
In practice, this can happen when the user presses a key which causes the
application to do something without pumping events (e.g. load a level).
In Crispy Doom & PrBoom+, when the user presses the key bound to "Restart
level/demo", the game doesn't pump events during the "screen melt" effect,
and the level is restarted multiple times due to spurious repeats.
To fix this, if the key up event is among the events to be pumped, we generate
the key repeats there, since in the Wayland callback we receive the time when
the key up event happened. Otherwise, we know no key up event happened and we
can generate as many repeats as necessary after pumping.
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
Refactorization with no functional changes.
Instead of `next_repeat_ms` containing a timestamp based on SDL ticks, we make
it zero-based relative to the key press time, and we store the key press time in
SDL ticks in a new field.
This refactorization is groundwork for future commits which need to use the
key press and release timestamps provided by the Wayland API, which are also
expressed in milliseconds, but whose base does not match the one for SDL ticks.
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
If `repeat_info->next_repeat_ms` overflows, many key presses will be generated.
In the worst case, `now = 0xFFFFFFFFU` and the loop will never terminate.
Rearrange the comparison in order to gracefully handle the overflow case.
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
src/render/psp/SDL_render_psp.c: In function 'PSP_RunCommandQueue':
src/render/psp/SDL_render_psp.c:1200: warning: passing argument 1 of 'PSP_SetBlendState' from incompatible pointer type
src/filesystem/psp/SDL_sysfilesystem.c: In function 'SDL_GetPrefPath':
src/filesystem/psp/SDL_sysfilesystem.c:71: warning: passing argument 1 of 'free' discards qualifiers from pointer target type
This reverts commit c477768e6f.
We want to add the sentinel anytime we pump inside SDL_WaitEventTimeout() to avoid pumping again the next time through, as a performance optimization.
We don't want to catch explicit SDL_PumpEvents() calls by the application with
our polling check to avoid stale data. If the call to SDL_PumpEvents() produced
no events, there will be a sentinel sitting in the queue that will cause
SDL_PollEvent() to immediately return 0 next time it is called.
Our SDL_WaitEventTimeout() implementation avoids this issue by always popping
an event after calling SDL_PumpEvents(). This will remove the new sentinel if
we didn't get any new events.
WGI calls SDL_DINPUT_JoystickPresent() so we need to be sure DInput remains
initialized for the lifetime of the WGI driver to avoid a crash or duplicated
joysticks between DInput and WGI.
If that condition was reachable, the return value should be negative to indicate that waiting for the timeout failed.
Otherwise, SDL_WaitEventTimeout would incorrectly return early.
SDL_Init(SDL_INIT_AUDIO) did not take into account that functions like
SDL_AddAudioDevice do register events, which will need final cleanup
and only gets fired when events were actually initialised.
Sample call stack of a malloc missing its free (Linux + PA):
SDL_malloc_REAL (SDL_malloc.c:5328)
SDL_AddEvent (SDL_events.c:445)
SDL_PeepEvents_REAL (SDL_events.c:531)
SDL_PushEvent_REAL (SDL_events.c:762)
SDL_AddAudioDevice (SDL_audio.c:443)
SourceInfoCallback (SDL_pulseaudio.c:681)
context_get_source_info_callback (introspect.c:534)
run_action (pdispatch.c:288)
pa_pdispatch_run (pdispatch.c:341)
pstream_packet_callback (context.c:349)
do_read (pstream.c:1012)
Fixes https://github.com/libsdl-org/SDL/issues/3005
When mouse buttons are swapped, right mouse button down is the same value as raw mouse button up, and conceptually the two systems use different button masks, so never cache state between the two.
Fixes https://github.com/libsdl-org/SDL/issues/5108
Program received signal SIGILL, Illegal instruction.
X11_InitKeyboard (_this=0x1001f8f0)
at /home/sdl/SDL_git/src/video/x11/SDL_x11keyboard.c:273
273 XKeyboardState values = { .global_auto_repeat = AutoRepeatModeOff };
If the X server's byte order is different from the client, things might
display in the wrong colour.
Apparently we can just set the byte_order field to the client's byte
order, and the X server will adjust everything automatically:
https://xorg.freedesktop.narkive.com/GbSD1aPq/ximage-s-byte-order-field
because:
- GeHint return a value pointer.
- SetHint free internally the pointer
- The -now invalid- pointer is re-read
==9363== Invalid read of size 1
==9363== at 0x4946860: SW_CreateRenderer (SDL_render_sw.c:1044)
==9363== by 0x48F0EC3: SDL_CreateRenderer_REAL (SDL_render.c:938)
==9363== by 0x48C5921: SDL_CreateRenderer (SDL_dynapi_procs.h:332)
==9363== by 0x401584: main (main.c:421)
==9363== Address 0x9c24040 is 0 bytes inside a block of size 1 free'd
==9363== at 0x484621F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==9363== by 0x494E403: SDL_free_REAL (SDL_malloc.c:5432)
==9363== by 0x48A6153: SDL_SetHintWithPriority_REAL (SDL_hints.c:76)
==9363== by 0x48A6254: SDL_SetHint_REAL (SDL_hints.c:101)
Rounding the scroll deltas from trackpads causes jerky scrolling behavior
by artificially amplifying the effects of very small scroll movements.
We should only round events from devices with discrete scroll wheels,
because we know the smallest unit of movement there is a single tick.
- Fix SDL2main on PSP
SDL2main was not working for PSP, because it wasn't being activated and
it wasn't unsetting the main. Besides that a debug screen being started
was causing issues with joystick input and the sceKernelExitGame calli
is no longer needed with the current PSPDEV SDK.
- Clean up imports in PSP main
- Set PSP GPU and user modes in main
- Fix exit callback in PSP main
The xdg_shell spec seems to state[1] that xdg_toplevel_configure events can
always provide a 0×0 width/height to signal that the compositor doesn't
care. SDL previously assumed the provided width/height was always valid
for fullscreen windows, and so applied it as-is.
This broke SDL applications on KDE/KWin 5.23, which now sends 0×0
configure events (and, in 5.23.3, 1×1 events for some reason), breaking
all SDL applications in fullscreen[2].
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/6
[2]: https://bugs.kde.org/show_bug.cgi?id=444962#c6
Otherwise, if one builds libSDL2_test using a new mingw but builds
the test programs using an older mingw, a link failure happens:
/opt/local/x86_64-w64-mingw32/lib/libSDL2_test.a(SDL_test_common.o): In function `printf':
/opt/local/x86_64-w64-mingw32/include/stdio.h:372: undefined reference to `__imp___acrt_iob_func'
collect2: ld returned 1 exit status
gbm_device_get_fd() in at least some libmali versions duplicates handle.
Other implementations do not do duplication. To prevent handle leak save
drm_fd in SDL_DisplayData.
When our keyboard grab hook is installed, GetKeyState() will return 0 for the
GUI keys even when they are pressed. This leads to spurious key up events when
holding down the GUI keys and the inability to use any key combos involving
those modifier keys.
This fixes a compile warning — and possible invalid memory read —
introduced in 9c03d255 ("Add back X11 legacy WM_NAME encodings"), which
was part of PR #5029, fixing Bug #4924.
The issue is with one of the added warnings in X11_GetWindowTitle().
Basically, the "title" variable passed to SDL_LogError() hasn't been
initialised yet: we could pass propdata in directly, but it's better to
move the SDL_LogError() call until after title is set, IMHO.
This fixes the following warning from gcc (SUSE Linux) 11.2.1:
In file included from /home/david/Development/SDL/src/video/x11/../../SDL_internal.h:45,
from /home/david/Development/SDL/src/video/x11/SDL_x11window.c:21:
/home/david/Development/SDL/src/video/x11/SDL_x11window.c: In function 'X11_GetWindowTitle':
/home/david/Development/SDL/src/video/x11/../../dynapi/SDL_dynapi_overrides.h:33:22: warning: '%s' directive argument is null [-Wformat-overflow=]
33 | #define SDL_LogDebug SDL_LogDebug_REAL
/home/david/Development/SDL/src/video/x11/SDL_x11window.c:720:13: note: in expansion of macro 'SDL_LogDebug'
720 | SDL_LogDebug(SDL_LOG_CATEGORY_VIDEO, "Failed to convert WM_NAME title expecting UTF8! Title: %s", title);
| ^~~~~~~~~~~~
Closes#4924.
Based on patches of the past, such as this work by James Cloos in July
2010:
d7d98751b7,
as well as code comments in the Perl module X11::Protocol::WM
(https://metacpan.org/pod/X11::Protocol::WM) and even the code to Xlib
itself, which taught me that we should never have been using
`XStoreName`, all it does is call `XChangeProperty`, hardcoded to
`XA_STRING`!
What can I say, when the task is old school, the sources are too 😂
On Win32 this list is empty and we always get controller added events. On UWP, this list is populated and we don't get controlle added events for currently connected controllers.
This is to workaround systems where we hang in playback because the buffer
does not report the space for whatever reason. The system will instead block
in PlayDevice, which always immediately follows WaitDevice in modern times
so this works out, and it seems to keep the device moving forward.
For a future revision, we are either going to clean this up more properly,
or attempt to move to PulseAudio's pa_stream_set_write_callback() API, but
this will do for SDL 2.0.18.
Reference #4387 for discussion and further information.
Touching HID devices with keyboard usages will trigger a keyboard capture
permission prompt on macOS 11+. See #4887
Like the IOKit joystick backend, we accept HID devices that have joystick,
gamepad, or multi-axis controller usages. We also allow the Valve VID for
the Steam Controller, just like the Windows HIDAPI implementation does.
We can also ditch the lock in RAWINPUT_JoystickQuit() now that the joystick
subsystem quits drivers in reverse order. There's no chance of a racing call
to RAWINPUT_WindowProc() anymore.
SDL_WINDOWS_JoystickDriver depends on callbacks in SDL_RAWINPUT_JoystickDriver
and SDL_HIDAPI_JoystickDriver being available. It also manages the common
WindowProc used for joystick detection in both WINDOWS and RAWINPUT drivers.
If we don't tear them down backwards, there's a window of time where we could
invoke RAWINPUT_WindowProc() after RAWINPUT_JoystickQuit() was called.
Since accessing Bluetooth prompts the user for permission on both Android and iOS, and we only need it for Steam Controller support, we'll leave it off by default. You can enable it by setting the hint SDL_HINT_JOYSTICK_HIDAPI_STEAM to "1" before calling SDL_Init()
Fixes https://github.com/libsdl-org/SDL/issues/4952
macOS 10.6 has some touch NSEvents which do not have a subtype
(Begin/EndGesture, Magnify, Rotate, Swipe) and cause an uncaught
exception which triggers SIGABRT and the program exits.
As it is, none of the macOS 10.6 touch events are detected as a
trackpad (including Gesture due to using different subtypes).
Case fallthrough warnings can be suppressed using the __fallthrough__
compiler attribute. Unfortunately, not all compilers have this
attribute, or even have __has_attribute to check if they have the
__fallthrough__ attribute. [[fallthrough]] is also available in C++17
and the next C2x, but not everyone uses C++17 or C2x.
So define the SDL_FALLTHROUGH macro to deal with those problems - if we
are using C++17 or C2x, it expands to [[fallthrough]]; else if the
compiler has __has_attribute and has the __fallthrough__ attribute, then
it expands to __attribute__((__fallthrough__)); else it expands to an
empty statement, with a /* fallthrough */ comment (it's a do {} while
(0) statement, because users of this macro need to use a semicolon,
because [[fallthrough]] and __attribute__((__fallthrough__)) require a
semicolon).
Clang before Clang 10 and GCC before GCC 7 have problems with using
__attribute__ as a sole statement and warn about a "declaration not
declaring anything", so fall back to using the /* fallthrough */ comment
if we are using those older compiler versions.
Applications using SDL are also free to use this macro (because it is
defined in begin_code.h).
All existing /* fallthrough */ comments have been replaced with this
macro. Some of them were unnecessary because they were the last case in
a switch; using SDL_FALLTHROUGH in those cases would result in a compile
error on compilers that support __fallthrough__, for having a
__attribute__((__fallthrough__)) statement that didn't immediately
precede a case label.
Case fallthrough warnings can be suppressed using the __fallthrough__
compiler attribute. Unfortunately, not all compilers have this
attribute, or even have __has_attribute to check if they have the
__fallthrough__ attribute. [[fallthrough]] is also available in C++17
and the next C2x, but not everyone uses C++17 or C2x.
So define the SDL_FALLTHROUGH macro to deal with those problems - if we
are using C++17 or C2x, it expands to [[fallthrough]]; else if the
compiler has __has_attribute and has the __fallthrough__ attribute, then
it expands to __attribute__((__fallthrough__)); else it expands to an
empty statement, with a /* fallthrough */ comment (it's a do {} while
(0) statement, because users of this macro need to use a semicolon,
because [[fallthrough]] and __attribute__((__fallthrough__)) require a
semicolon).
Applications using SDL are also free to use this macro (because it is
defined in begin_code.h).
All existing /* fallthrough */ comments have been replaced with this
macro. Some of them were unnecessary because they were the last case in
a switch; using SDL_FALLTHROUGH in those cases would result in a compile
error on compilers that support __fallthrough__, for having a
__attribute__((__fallthrough__)) statement that didn't immediately
precede a case label.
This causes lots of spam in test automation and it's not clear it's useful to developers. If we need this level of validation, we should add a log category for it.
Since the haptic subsystem is usually initialized after the joystick subsystem,
the initial calls to HapticMaybeAddDevice() from inside SDL_JoystickInit() will
arrive too early to be handled by the haptic subsystem. We need to add those
haptic devices for those already present joysticks ourselves.
* SDLTest_CommonDrawWindowInfo: log SDL_RenderGetScale, SDL_RenderGetLogicalSize
* testwm2: fix video modes menu hit detection in High DPI cases
- also when logical size is specified, e.g.
`--logical 640x480 --resizable --allow-highdpi`
* add function to determine logical coordinates of renderer point when given window point
* change since to the targeted milestone
* fix typo
* rename for consistency
* Change logical coordinate type to float, since we can render with floating point precision.
* add function to convert logical to window coordinates
* testwm2: use new SDL_RenderWindowToLogical
* SDL_render.c: alternate SDL_RenderWindowToLogical/SDL_RenderLogicalToWindow
Co-authored-by: John Blat <johnblat64@protonmail.com>
Co-authored-by: John Blat <47202511+johnblat64@users.noreply.github.com>
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)
Instead of taking a direct copy of the mouse cursor surface, and then
premultiplying on every BO upload (using the custom
legacy_alpha_premultiply_ARGB8888 function), use the new
SDL_PremultiplySurfaceAlphaToARGB8888() function, which converts a whole
surface at a time, once and save the result.
The already-premultiplied data is then copied from that to the BO on
each upload, adjusting for the stride (which the previous implementation
required to be equal to the width), thereby making the extra copy
slightly useful..
This also adds support for non-SDL_PIXELFORMAT_ARGB8888 surfaces.
It turns out that Wayland's WL_SHM_FORMAT_ARGB8888 format (and, indeed,
all wayland RGBA formats) should be treated as premultiplied. SDL
surfaces tend not to be premultiplied, and this is assumed by other
backends when dealing with cursors.
This change premultiplies the cursor surface in Wayland_CreateCursor()
using the new SDL_PremultiplySurfaceAlphaToARGB8888(). In so doing, it
also adds support for a wider range of input surfaces, including those
with non-ARGB8888 pixel formats, and those which don't have
pitch==width.
This should fix#4856
A number of video backends need to get ARGB8888 formatted surfaces with
premultiplied alpha, typically for mouse cursors. Add a new function to
do this, based loosely on legacy_alpha_premultiply_ARGB8888() from the
KMSDRM backend.
The new function, SDL_PremultiplySurfaceAlphaToARGB8888() takes two
arguments:
- src: an SDL_Surface to be converted.
- dst: a buffer which is filled with premultiplied ARGB8888 data of the
same size as the surface (assuming pitch = w).
This is not heavily optimised: it just repeatedly calls SDL_GetRGBA() to
do the conversion, but should do for now.