This reverts commit 6b4ae68460.
It turns out this deadlock is possible for any joystick event delivery combined with an event watcher that locks joysticks. I'm reverting this change for now, and will be working on a better global solution for this problem.
If a mode with a closer refresh was found, but it had the same color depth as the current best match, it was being dropped. Only ignore the new mode if the color depth is below the current best match.
* SVE2 was actually disabled in fdfbbce, this issue is fixed
- The macro __ARM_FEATURE_SVE is only defined when the compilation target is set as -march=armv8-m+sve2
* Improves 8888 alpha-blending performance
- Now, in In-Order AArch64 processors, e.g. A520, SVE2 is better than NEON with the 128bit vector width
- For Out-of-order processors, NEON is still better than SVE2 (We could improve this in the future), the performance is improved from 3.0 to 3.6.
* The 8888 -> RGB565 performance is also improved (from 7.4 to 9.3)
The core mouse code will unfocus the window when a capture ends outside the window boundaries, but the backend still needs to update the internal focus references.
Some compositors will send pointer enter/leave event while moving between surfaces that are part of the same window while mouse capture is active. Maintain window focus in this case, and adjust the coordinates relative to the content surface by the subsurface offset, if necessary.
XInput2 can send slave button presses before FocusIn events, which can confuse the click-through suppression logic. A window must have keyboard focus to grab the mouse anyway, so ignore slave presses when lacking keyboard focus.
This simply toggles a flag that rejects DnD offers if false. Events were previously dropped silently, but rejecting the offer makes some desktops display a proper icon when the drop will not work.
This fixes a UBSAN warning later in this function where it calculates
(1 << SDL_BITSPERPIXEL(surface->format)). The bpp might be >= 32 and
out of range for a bit shift.
SVE/SVE2 is a new SIMD extension for AArch64. Compared to NEON, SVE/SVE2 brings the following benefits that are good for SDL projects:
- Lane prediction: we don't have to treat the tail part of a stride separately when the width is n times the hardware vector size
- Although the performance is almost no difference from NEON when the hardware vector size is 128bits, when the hardware provides a longer vector size, e.g. 256, 512, ... 2048, we can enjoy the large performance gain without modifying the source code or recompiling a library.
The functional correctness is validated in a dedicated [qemu project](https://github.com/GorgonMeducer/aarch64_qemu_mac_template/tree/SDL-SVE2-Acceleration-Validation).
The performance is tested on [Radxa Orion 6 N](https://radxa.com/products/orion/o6n/), which provides 4x A720 and 4x A520 processors. Since the vector size is 128 bits, which is the same as NEON, the performance is almost the same (or no worse than) the NEON acceleration.
