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.
These are faster and more precise.
This did not change the Uint16 versions (as SDL3 dropped them, and honestly
no one should be using them in SDL2), nor the NEON converters (as this was
not changed in SDL3, so far).
Fixes#8786.
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 d747daf03d3210a794d609b8cc662f28beaedaf6)
like SDL_triangle.c:305:30: runtime error: left shift of negative value -672
(even if the value was correctly computed)
(cherry picked from commit 4033a0a83b3a675c6b7803e36fb13114579d0b5b)
The previous code was working incorrectly on viewports not having the
top left corner on the origin: even in those cases we only need to look
at the width and height of the viewport, because the drawing coordinates
are translated.
Fixes#8828
Unlike the test images in the previous commit, this one is
4-bytes-per-pixel RGBA32, so the masks used here appear to be correct
for both endiannesses. Converting it to SDL_PIXELFORMAT_RGBA32 just
makes it more concise.
Signed-off-by: Simon McVittie <smcv@collabora.com>
All of these test images are provided as an octal dump of
3-bytes-per-pixel data with red, green and blue bytes in that order,
referred to as RGB24 in SDL's taxonomy. However, the call to
SDL_CreateRGBSurfaceFrom() used masks that would have been appropriate
for RGBA32 data.
On little-endian platforms, the test images loaded as intended anyway,
because SDL does not actually check all four masks before deciding to
use RGB24 (it only looks at the red mask), and the red channel happens to
be in the 0x000000FF position for both RGB24 and RGBA32 on little-endian.
Unfortunately, on big-endian platforms, the required masks are not the
same and the call failed with "Unknown pixel format". As far as I can
tell, this means testautomation_surface has never succeeded on big-endian
platforms, but presumably nobody has tried to run it on such platforms
until now.
In the SDL 3 branch, this was fixed as a side-effect of commit
932f6134 "Remove mask versions of SDL_CreateRGBSurface* #6701 (#6711)",
which I have used as a reference to confirm that RGB24 is correct.
Resolves: https://github.com/libsdl-org/SDL/issues/8817
Signed-off-by: Simon McVittie <smcv@collabora.com>
When a test has been disabled because it's known not to work reliably
or it's a test for unimplemented functionality, we probably don't want
to encourage developers and testers to run it and report its failures
as a bug.
Helps: #8798, #8800
Signed-off-by: Simon McVittie <smcv@collabora.com>
This better reflects the actual implementation and makes SDL_HINT_ENABLE_SCREEN_KEYBOARD work on Android.
Fixes https://github.com/libsdl-org/SDL/issues/8652
(cherry picked from commit 014a63b4b5b94ce50f329eddb345f5434654305b)
(cherry picked from commit 46de6241d79c6f4531dbb729b2ed5992ec61b4a2)
(cherry picked from commit 0bd77a5b93494ca88bfd1a86fe106e7bb1d90133)
(cherry picked from commit f341c06552c8618c1178287880fcb8775decfbd3)
(cherry picked from commit 4d2f9f3a324884add7245e8cd13ee06af907c306)
(cherry picked from commit 06f8f9a891194d86ff93a5856f80510d39b75272)
(cherry picked from commit 0c4cb3d1539fefa66c05d131385e35fb2a205fa3)
(cherry picked from commit 0dad56354ceb4222be569e6969475adeec5a1ca1)
The udev container issue is mostly to do with device notifications
and netlink. The device classification stuff just pokes file in /sys
and /run/udev. Doesn't hurt to try it first for classifying joysticks
and then fall to the guess heuristics if it fails.
