xpad has a series of questionable design choices when it comes to button
mapping. Notably, BTN_TRIGGER_HAPPY1-4 are used for the D-pad on dance mats
instead of the typical BTN_DPAD_*, and maps the paddles to
BTN_TRIGGER_HAPPY5-8. This commit plumbs through driver detection for a udev
device and adds special exceptions for xpad's quirks.
Newer kernels (6.17+) add the BTN_GRIP* mappings for paddles on controllers. We
should prefer that if available, as its meaning and mapping is unambiguous.
However, since it's only in new kernels, we need to maintain the older mappings
where we know they exist.
It also exposes KEY_RECORD as the share button regardless of vendor, which had
previously been gated behind being a Microsoft controller. All Xbox Series
controllers can include this button, and many third party ones do.
- Implements 'handheld' flag to indicate whether the SInput device is a gamepad or handheld (ROG Ally etc)
- Implements generic mapping fallback along with face style setting ability
Building SDL for armeabi-v7a gives this warning:
```
SDL/src/audio/SDL_audiotypecvt.c:541:14: warning: '#pragma FENV_ACCESS' is not supported on this target - ignored [-Wignored-pragmas]
541 | #pragma STDC FENV_ACCESS ON
```
This reverts commit 608f706a95.
Didn't end up using this in SDL3_mixer, and it's a super-awkward API if we
don't need it.
I _might_ bite the bullet and let people lock a physical audio device, though,
as I could see that being useful but less awkward for the same reasons I
originally wanted it.
Keymap construction is an expensive process, so keymaps are cached to facilitate fast switching, as they are static after initial construction, and do not need to be rebuilt every time.
This still logs backend choices, but we might use it for other things. For
example, what Android device is being used, or all the devices we enumerated,
etc.
Ideally this eventually logs all the stuff we often have to ask followup
questions about.
...so the backends don't have to do it.
Also added a stern warning about `org` being omitted, but leaving it as
allowed so as not to break existing apps (more than they are already broken,
at least).
Fixes#13322.
Only use the specified output if an exclusive mode is being used, or a position was explicitly requested before entering fullscreen desktop. Otherwise, let the compositor handle placement, as it has more information about where the window is and where it should go, especially if fullscreen was requested before the window was fully mapped, or the window spans multiple outputs.
