Applications might override WM_WINDOWPOSCHANGING which would prevent us from getting the correct window state.
This also fixes cases where the window doesn't get WM_SHOWWINDOW, as described in Raymond Chen's blog post:
https://devblogs.microsoft.com/oldnewthing/20080115-00/?p=23813
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.
Sylvain
Sam Lantinga
Ozkan Sezer
George Broughton
Caleb Cornett
Frank Praznik
SDL Wiki Bot
Ryan C. Gordon
Simon McVittie
Semphris
J. Neuschäfer