If testautomation is running with only a specific audio driver enabled, we shouldn't try to open other ones, as they might fail.
Fixes https://github.com/libsdl-org/SDL/issues/8797
(cherry picked from commit 4c11307a4e75fbfde0d8ace6b19d612d2973bf0b)
Allow for the creation of SDL windows with a roleless surface that applications can use for their own purposes, such as with a windowing protocol other than XDG toplevel.
The property `wayland.surface_role_custom` will create a window with a surface that SDL can render to and handles input for, but is not associated with a toplevel window, so applications can use it for their own, custom purposes (e.g. wlr_layer_shell).
A test/minimal example is included in tests/testwaylandcustom.c
A Wayland registry object can only have one listener attached at a time, so an application attempting to use the backend SDL registry object for its own purposes will just result in an error. Remove this property, as it is of no use to applications and will only result in errors.
If an application needs the registry, it needs to get the wl_display object via `SDL.window.wayland.display` and use wl_display_get_registry() to create a new registry object that it can attach its own listeners to.
If the xdg_wm_base protocol isn't present, the window won't be assigned a valid surface type at creation time, which makes these checks redundant.
The libdecor path was already cleaned up in this manner some time ago.
When a test has been disabled because it's known not to work reliably
or it's a test for unimplemented functionality, we probably don't want
to encourage developers and testers to run it and report its failures
as a bug.
Helps: #8798, #8800
Signed-off-by: Simon McVittie <smcv@collabora.com>
It would be easy to assume that all APIs that reference
SDL_JOYSTICK_AXIS_MAX work the same way, but they do not: triggers
generally use the full signed 16-bit range in the lower-level joystick
API, but are normalized to be non-negative by the higher-level gamepad
API.
We also never said explicitly which direction is positive here.
Experimentally, it's right (X), down (Y), and pressed (triggers).
Resolves: https://github.com/libsdl-org/SDL/issues/8793
Signed-off-by: Simon McVittie <smcv@collabora.com>
The ARM926EJ-S Technical Reference Manual states:
> You can only access CP15 registers with MRC and MCR instructions in a
> privileged mode. CDP, LDC, STC, MCRR, and MRRC instructions, and unprivileged
> MRC or MCR instructions to CP15 cause the Undefined instruction exception to
> be taken.
Furthermore, `MCR p15, 0, <Rd>, c7, c10, 5` (later called Data Memory Barrier)
is not specified for the ARM926. Thus, SDL should not use these cache
instructions on ARMv5.
- Child windows are added and removed dynamically from the window hierarchy when they're shown/hidden. Adding a hidden child window to a visible
parent is fine, but adding a hidden child window to a hidden parent will cause the child to show when the parent window is shown as it's still a part of
the window hierarchy.
- For some reason, not adding the child window to the parent entirely causes the child to not focus correctly the first time it's shown. Adding then immediately
calling orderOut to remove the child window from the hierarchy does work correctly so we do this to work around the weird issue.
Wayland will be increasingly encountered going forward and needs to be handled by applications requesting window handles to initialize the Vulkan WSI and such, so include it in the migration example to reflect current best practices.
For some reason, fullscreen space windows won't get any mouse button events unless the NSWindowStyleMaskTitled flag is set when entering fullscreen, even though they successfully become key and receive mouse motion events. Make sure the flag is always set when entering fullscreen space state.
It turns out that when you enable raw input and then process Windows messages, you'll get the currently pending input in GetRawInputBuffer(), and you'll get any new input that occurs while processing messages as WM_INPUT.
The fix for this is to create a dedicated thread to handle raw input and only use GetRawInputBuffer() in that thread. A nice side effect of this is that we'll get mouse input at the lowest latency possible, but raw mouse events will now occur on a separate thread, outside of the normal event loop processing.
Improved fix for https://github.com/libsdl-org/SDL/issues/8756
Frank Praznik
Sam Lantinga
SDL Wiki Bot
Ryan C. Gordon
Simon McVittie
Semphris
J. Neuschäfer
Anonymous Maarten
Ozkan Sezer
Nour Fouad
Vicki Pfau