* Fix assumption that DRI_DEVNAME begins at 0
The existing logic of the code was to count every possible entry in
KMSDRM_DRI_PATH. After this a for loop would start trying to open
filename0, filename1, filename2, etc. In recent Linux kernels (say
5.18) with simpledrm, the lowest KMSDRM_DRI_DEVNAME is often
/dev/dri/card1, rather than /dev/dri/card0, causing the code to fail
once /dev/dri/card0 has failed to open. Running:
modprobe foodrm && modprobe bardrm && rmmod foodrm
before you try to run an application with SDL KMSDRM would have also
made this fail.
* Various changes from review
- Removed newline and period from SDL error
- Explicitely compare memcmp to zero (also changed to SDL_memcmp)
- Changed memcpy to strncpy
- Less aggressive line wrapping
* Various changes from review
- strncpy to SDL_strlcpy
- removed size hardcodings for KMSDRM_DRI_PATHSIZE and
KMSDRM_DRI_DEVNAMESIZE
- made all KMSDRM_DRI defines, run-time variables to reduce bugs caused
by these defines being more build-time on Linux and more run-rime on
OpenBSD
- renamed openbsd69orgreater variable to moderndri
- altered comment from "if on OpenBSD" to add difference in 6.9
* Various changes from review
- Use max size of destination, rather than max size of source
- Less hardcodings
When building on macOS without gcc (e.g. clang) where HAVE_GCC_ATOMICS
is not defined, `SDL_AtomicTryLock` will call
`OSAtomicCompareAndSwap32Barrier` which is not yet declared.
Including OSAtomic.h on OSX resolves this error/warning:
SDL_spinlock.c:125:12: error: implicit declaration of function
'OSAtomicCompareAndSwap32Barrier' is invalid in
C99 [-Werror,-Wimplicit-function-declaration]
return OSAtomicCompareAndSwap32Barrier(0, 1, lock);
This was reported in issue #3885 but marked Invalid and closed - possibly
because the default CMake build uses gcc instead of clang.
The documentation doesn't state that the argument is ever modified,
and no implementation does so currently.
This is a non-breaking change to guarantee as much to callers.
strchr and strrchr return a pointer to the first/last occurrence of a
character in a string, or NULL if the character is not found. According
to the C standard, the final null terminator is part of the string, and
it should thus be possible to get a pointer to the final null with
these functions. The fallback implementations of SDL_strchr and
SDL_strrchr would always return NULL if trying to find '\0', and this
commit fixes that.
* Xbox GDK support (14 squashed commits)
* Added basic keyboard testing
* Update readme
* Code review fixes
* Fixed issue where controller add/removal wasn't working (since the device notification events don't work on Xbox, have to use the joystick thread to poll XInput)
Also added test functions for multi-line debug text display
Currently this only supports ASCII, as the font doesn't have the correct Latin-1 characters
The HIDAPI joystick driver doesn't properly reset the change counter
it uses to track if re-enumeration is needed when the joystick
subsystem is quit and then reinitialized.
The first SDL_Init(SDL_INIT_JOYSTICK) will result in the expected
HIDAPI joysticks appearing, but subsequent calls will result in no
joysticks being enumerated until another HIDAPI joystick is added
or removed from the system.
Use SDL_lroundf() to round fractional backbuffer sizes halfway away from zero, as this is the rounding method recommended by the forthcoming Wayland fractional scaling protocol.
We might want to use ssize_t as @Guldoman suggested, but that's a larger internal API change, and still requires casting of the SDL_utf8strnlen() result.
Fixes https://github.com/libsdl-org/SDL/pull/5821
This allows us to handle controllers that use the Xbox protocol but look like Nintendo Switch or Playstation controllers, like the Qanba Dragon Arcade Stick in PC mode
This is done such that we can disable LTO for these 2 functions when
building with MSVC.
This is due to a limitation of Link Time Code Generation (LTCG).
Code generation might generate a new reference to memset after linking
has started. The LTCG must make assumptions about where memset is
defined which is normally the C runtime.
Some compositors will provide 'nicer' / 'human readable' output descriptions via the xdg-output protocol. Use these description strings, when available, instead of the model name provided by wl-output. On compositors such as GNOME where this is provided, the display names provided to applications by SDL will now match those in the desktop display settings panel. On compositors where this data isn't provided, the old behavior of using the model string provided by wl-output will remain unchanged.
Additionally, per the protocol spec, output data provided by xdg-output should supersede wl-output data, so this is the recommended behavior in general.
If the width is sufficiently ludicrous, then the calculated pitch or
the image size could conceivably be a signed integer overflow, which
is undefined behaviour. Calculate in the unsigned size_t domain, with
overflow checks.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Adds hint "SDL_WINDOWS_DPI_SCALING" which can be set to "1" to
change the SDL coordinate system units to be DPI-scaled points, rather
than pixels everywhere.
This means windows will be appropriately sized, even when created on
high-DPI displays with scaling.
e.g. requesting a 640x480 window from SDL, on a display with 125%
scaling in Windows display settings, will create a window with an
800x600 client area (in pixels).
Setting this to "1" implicitly requests process DPI awareness
(setting SDL_WINDOWS_DPI_AWARENESS is unnecessary),
and forces SDL_WINDOW_ALLOW_HIGHDPI on all windows.
If the move results in a DPI change, we need to allow the window to resize (e.g. AdjustWindowRectExForDpi frame sizes are different).
- WM_DPICHANGED: Don't assume WM_GETDPISCALEDSIZE is always called for PMv2 awareness - it's only called during interactive dragging.
- WIN_AdjustWindowRectWithStyle: always calculate final window size including frame based on the destination rect,
not based on the current window DPI.
- Update wmmsg.h to include WM_GETDPISCALEDSIZE (for WMMSG_DEBUG)
- WIN_AdjustWindowRectWithStyle: add optional logging
- WM_GETMINMAXINFO: add optional HIGHDPI_DEBUG logging
- WM_DPICHANGED: fix potentially clobbering data->expected_resize
Together these changes fix the following scenario:
- launch testwm2 with the SDL_WINDOWS_DPI_AWARENESS=permonitorv2 environment variable
- Windows 10 21H2 (OS Build 19044.1706)
- Left (primary) monitor: 3840x2160, 125% scaling
- Right (secondary) monitor: 2560x1440, 100% scaling
- Alt+Enter, Alt+Enter (to enter + leave desktop fullscreen), Alt+Right (to move window to right monitor). Ensure the window client area stays 640x480. Drag the window back to the 125% monitor, ensure client area stays 640x480.
The hint allows setting a specific DPI awareness ("unaware", "system", "permonitor", "permonitorv2").
This is the first part of High-DPI support on Windows ( https://github.com/libsdl-org/SDL/issues/2119 ).
It doesn't implement a virtualized SDL coordinate system, which will be
addressed in a later commit. (This hint could be useful for SDL apps
that want 1 SDL unit = 1 pixel, though.)
Detecting and behaving correctly under per-monitor V2
(calling AdjustWindowRectExForDpi where needed) should fix the
following issues:
https://github.com/libsdl-org/SDL/issues/3286https://github.com/libsdl-org/SDL/issues/4712
