The XKB_KEY_* and XK_* macros resolve to the same constant values, so use the raw values and note what keys they correspond to in the comments, as is done for the other keysym values in this file.
This completely eliminates the need for any X or XKB system headers along with the if/else defines.
Most of these are probably harmless, but the changes to SDL_immdevice.c and SDL_pixels.c appear to have fixed genuine bugs.
SDL_audiocvt.c: By separating the calculation of the divisor, I got rid of the suspicion that dividing a double by an integer led to loss of precision.
SDL_immdevice.c: Added a missing test, one that could have otherwise led to dereferencing a null pointer.
SDL_events.c, SDL_gamecontroller.c, SDL_joystick.c, SDL_malloc.c, SDL_video.c: Made it clear the return values weren't used.
SDL_hidapi_shield.c: The size is zero, so nothing bad would have happened, but the SDL_memset() was still being given an address outside of the array's range.
SDL_dinputjoystick.c: Initialize local data, just in case IDirectInputDevice8_GetProperty() isn't guaranteed to write to it.
SDL_render_sw.c: drawstate.viewport could be null (as seen on line 691).
SDL.c: SDL_MostSignificantBitIndex32() could return -1, though I don't know if you want to cope with that (what I did) or SDL_assert() that it can't happen.
SDL_hints.c: Replaced boolean tests on pointer values with comparisons to NULL.
SDL_pixels.c: Looks like the switch is genuinely missing a break!
SDL_rect_impl.h: The MacOS static checker pointed out issues with the X comparisons that were handled by assertions; I added assertions for the Y comparisons.
SDL_yuv.c, SDL_windowskeyboard.c, SDL_windowswindow.c: Checked error-result returns.
This reverts commit 04b50f6c6b.
It turns out OpenGL vsync has broken again in macOS 12, so
we're reintroducing our CVDisplayLink code to deal with it,
again.
Reference Issue #4918.
SDL is built around the concept of keyboards having a fixed layout with scancodes that correspond to physical keys no matter what linguistic layout is used. Virtual keyboards don't have this concept and can present an arbitrary layout of keys with arbitrary scancodes and names, which don't fit the SDL model. When one of these keyboards is encountered, it requires special handling: use the keysym of the pressed keys to derive their ANSI keyboard scancode equivalents for control keys and ASCII characters. All other characters are passed through as text events only.
Add a helper function to get the keycode for a scancode from the default lookup table. Unlike SDL_GetKeyFromScancode(), this is not affected by the set keymap.
It turns out that we can safely create a Metal view on an existing window, and that avoids issues with the window being recreated with the wrong orientation in iOS 16.
Fixes https://github.com/libsdl-org/SDL/issues/6289