Ensure that incoming touch events originate from valid surfaces owned by SDL and have proper window data before forwarding them to the touch subsystem, or the window focus pointer that is sent with the event may not be a pointer to an SDL window.
sdl12-compat can get into a state where a color-keyed surface is
marked for blending, but wants to blend with full alpha (which
is the same as _not_ blending), so rather than fail to find a
blitter in that case, it just selects the colorkey blitter.
Reference https://github.com/libsdl-org/sdl12-compat/issues/233
An in-place swizzle mutation was erroneously inside of a loop, which
caused each consecutive 4-pixel vector to alternate between correct and
incorrect endianness.
The bug was introduced in 715e070d29.
Thanks to RobbieAB for reporting the bug.
Fixes https://github.com/libsdl-org/SDL/issues/3428
(cherry picked from commit 9142292f4ad6d9bc8a2bc7c874e2fde54befeb9b)
Destroy any proxy wrappers and callbacks before the associated event queues to silence libwayland warnings about destroying the queues while proxies are still attached.
The X11 driver uses scancodes derived from keysyms to map the scancodes for extended keys to the physical keyboard, however, this can be incorrect when using certain XKB options (e.g. caps:swapescape), which changes the keysyms emitted by certain keys, but does not imply that their scancodes or positions should be altered. Mark selected scancodes as being non-remappable so that their scancodes aren't changed by toggling XKB mapping options.
4b1378f
X11: fix size/position (test video_setWindowCenteredOnDisplay)
this fix x11 backend to correctly pass video_setWindowCenteredOnDisplay()
get border values early (eg status bar)
wait for size/position change to get valid values
d4d26e0
testautomation_video: if SDL_SetWindowSize/Position isn't honored, we should check there is an event
x11: send the events if various occasions
This happens on Windows 11 with fullscreen desktop windows when the desktop is brought up with the Windows+D shortcut.
Fixes https://github.com/libsdl-org/SDL/issues/7419
(cherry picked from commit 2ca727aec6f5f264620f80999beb5ef77eefec4a)
If we don't do this, the view will be blanked even if another context is current and rendering from that context won't be visible.
Fixes https://github.com/libsdl-org/SDL/issues/4986
Passing True for owner_events in the XGrabPointer call makes all
XI_RawMotion events appear in the queue twice, with the only difference
between them being the value of XGenericEventCookie::cookie. These have
always been filtered out by a check in the XI_RawMotion handler,
however with a mouse that polls at more than 1 kHz frequency, there
also exist legitimate events that appear indistinguishable from these
duplicated events. These must not be filtered out, otherwise the
pointer may move at an inconsistent speed, appearing like a bad pointer
acceleration implementation.
Change owner_events to False in the XGrabPointer and remove the
duplicate event detection code to fix this.
Signed-off-by: Torge Matthies <openglfreak@googlemail.com>
(cherry picked from commit f18b5656f6f859e4d4e096d290afd9fae884a5b8)
Setting the cursor clip area to a single pixel prevents the relative mouse motion remote desktop warping from working, so the mouse is never recentered.
(cherry picked from commit daffe02b117ccd484763eadc716e4d4453c89868)
