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.