Noticed this in SDL-1.2 in a gcc-13 build, which emitted the following
warning: (No such warnings in SDL2 and SDL3, due to macro differences)
./src/video/x11/SDL_x11sym.h:84:48: warning: argument 2 of type 'char *' declared as a pointer [-Warray-parameter=]
84 | SDL_X11_SYM(int,XQueryKeymap,(Display* a,char *b),(a,b),return)
| ~~~~~~^
./src/video/x11/SDL_x11dyn.c:95:15: note: in definition of macro 'SDL_X11_SYM'
95 | rc fn params { ret p##fn args ; }
| ^~~~~~
In file included from ./src/video/x11/SDL_x11dyn.h:27,
from ./src/video/x11/SDL_x11dyn.c:26:
/usr/include/X11/Xlib.h:2980:5: note: previously declared as an array 'char[32]'
2980 | char [32] /* keys_return */
| ^~~~~~~~~
The original actually was char[32] but was changed with
8ada1e8a6e
(https://bugzilla.libsdl.org/show_bug.cgi?id=170https://github.com/libsdl-org/SDL-1.2/issues/101)
(cherry picked from commit b2fca55e5c)
This changes the `SDL_EVENTS_DISABLED` path's return value from SDL_DISABLE
to SDL_IGNORE to match expectations, but doesn't actually change the ABI,
since these two symbols are both zero.
Fixes https://github.com/libsdl-org/sdlwiki/issues/460
Closing a device file takes 0.01 to 0.5s, which can add up to
significant startup delays. The udev classification does not
require opening the actual device files, so, use it if possible,
and only fall back to opening the device and probing otherwise.
LINUX_JoystickInit does a manual scan first so devices are sorted.
If SDL_UDEV_Init hasn't run by then, then the product info cannot
be looked up by SDL_UDEV_GetProductInfo and the initial-plugged-
in-device classification falls back to heuristic guessing.
XWayland seems to require that the pointer be hidden when it is warped, so hide and show the pointer when warping, if required.
Note that XWayland still only allows warping within the window, so attempts to warp to global coordinates outside the window won't work.
(cherry picked from commit a845c7027e)
The public headers saw lots of cleanups, backporting from SDL3 docs, and
merging with the wiki.
The markdown files in docs/README-*.md were converted to Unix endlines.
For whatever reason, `ExtractIconEx` returns icons whose sizes are
inappropriate for the current DPI, resulting in terribly-blurry
window icons at higher DPIs.
To solve this, the window icon is now set to the first icon group
that is present in the executable. This behaviour should match what
Explorer does. By selecting an icon group instead of a specific icon,
Windows is free to select the icon within the group that best suits
the current DPI.
This fixes an macOS bug that is only known to occur in fullscreen windows on the built-in displays of newer MacBooks with camera notches. When the mouse is moved near the top of such a window (within about 44 units) and then moved back down, the cursor rects aren't respected. This can cause the default cursor to be visible when it should not be.
