Fixes a crash if no seat was available at initialization, but still allows for one to still be created later if an input device is added.
Manual backport of 84e47b4
(cherry picked from commit a8eeb181b6)
The dummy driver can be in use on these platforms, so check the actual driver name string.
Fixes the automated video tests with the dummy driver on Win32.
Otherwise we'll miss it when XWarpPointer() is used. x11vnc may do this to
manage mouse input in some circumstances, so it can be possible for _all_
mouse motion to go through this path, breaking SDL_GetGlobalMouseState().
Thanks to @chrismile for all the detective work to figure this out!
Fixes#8827.
Matches the one in `GetMouseMessageSource()`.
From my testing on Windows 11, the lower 8 bits in touch events cycle
trough the values 0x8c-0x95 in order.
(cherry picked from commit d747daf03d)
Compositors may switch from mouse to touch mode when a touch event is received, causing a pointer leave event and subsequent loss of mouse focus.
Don't relinquish mouse focus on surfaces with active touch events. If there are active touch events when pointer focus is lost, the keyboard focus is used as a fallback for relinquishing mouse focus: if, in this case, the keyboard focus is then lost and there are no active touches, mouse focus is lost, and if all touches are raised and there is no keyboard or pointer focus, then the window loses mouse focus.
(cherry picked from commit 21879faf48)
Mesa and Nvidia handle it differently, and one or the other may fix their
implementation in the future, so test which way it works at runtime.
Reference Issue #8004.
(cherry picked from commit 74a2542564)
I handle command+C and command+V shortcuts for copy/paste from clipboard using
SDL_GetClipboardText/SDL_SetClipboardText. But on iOS command+V shortcut is
also handled by system, so that I also get textinput event with that clipboard
text. And thus the application gets this clipboard text twice (from
SDL_GetClipboardText and from textinput event).
I assume that intended behavior is that command+V shouldn't generate textinput
events. At least as far as I know ctrl+V on other platforms does nothing. This
commit disables paste action for UITextField, so that textinput event isn't
generated anymore.
(cherry picked from commit eddaf870f5)
`driverdata->width` and `driverdata->height` represent the width and height in logical pixels on scaled outputs with xdg_output. However, to correctly calculate the display's DPI value, we need to use its native resolution.
For example, on a 27" 4K screen with 175% scaling, we have `width` == 2192 and `height` == 1233, resulting in a bogus value of 92dpi, whereas 162dpi are correct for 3840x2160 pixels at 27 inches.
Tested on GNOME mutter 45.1.
