c1b9d2ad98
Properly handle the close of run loop on macOS
(https://github.com/libusb/hidapi/pull/522)
- as per documentation `kCFRunLoopRunStopped` should be handled once the runloop is closed via `CFRunLoopStop`;
- if it is not handled - a race condition/crash may happen on the latest macOS when a device gets disconnected while being open;
Insert new displays at the end of the list instead of the front so that the initial ordering, as exposed by the compositor, is preserved. This is particularly important when the compositor exposes the xdg-output instance after the wl_output instance, as xdg-output must be attached to the outputs in the same order that wl_output exposed them, or they can be added to the SDL output list in reverse order.
Destroy any proxy wrappers and callbacks before the associated event queues to silence libwayland warnings about destroying the queues while proxies are still attached.
Otherwise they'll try to run with no arguments, and fail, when run by
ginsttest-runner.
Fixes: 81ca9d61 "cmake+test: add more automated tests + use properties"
Signed-off-by: Simon McVittie <smcv@collabora.com>
wl_compositor v6 introduces the preferred buffer scale event, which serves a similar function to the fractional scale protocol, but deals in integer scale factors. Listen to this event when the wl_compositor version is >= 6 and the fractional scale protocol is not present to set the scale factor for surfaces.
- Composited windows seem to need to actually paint (or appear to paint) through calls to Begin/EndPaint to properly validate
their update region. If not done they will continue to receive WM_PAINT messages for the same region.
When X11_UpdateWindowPosition() was called and the position didn't update
we would fire an SDL_EVENT_WINDOW_MOVED event with the global x,y for
the pop-up instead of the relative position for the pop-up.
This change ensures we always have a relative position for pop-ups before sending
the SDL_EVENT_WINDOW_MOVED event.
xdg-output names and descriptions are deprecated in favor of those provided by the core wl_output protocol as of v4. Bump wl_output support to v4 and ignore the xdg-output description in favor of the wl_output description when appropriate.
This allows clients to be aware of "natural scrolling" settings in the
compostior and adjust accordingly to optionally keep the same wheel and
trackpad behaviour accross platforms.
Testing using the "testmouse" example, behaviour in the demo is now the
same regardless of the compositor setting for scrolling.
./src/video/SDL_video.c:1734:13: warning: no previous prototype for function 'SDL_CreateWindowInternal' [-Wmissing-prototypes]
SDL_Window *SDL_CreateWindowInternal(const char *title, int x, int y, int w, int h, SDL_Window *parent, Uint32 flags)
^
./src/video/SDL_video.c:1734:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
SDL_Window *SDL_CreateWindowInternal(const char *title, int x, int y, int w, int h, SDL_Window *parent, Uint32 flags)
^
static
Track the serial numbers of key events, mouse button presses, touch down events, tablet tool down events, and tablet button presses, and pass the serial, along with the seat, to the xdg-activation protocol when raising windows to increase the chances of it succeeding.
Don't perform a round trip when setting the minimized and maximized window states during initial window creation, as it will be done later in the window creation process.
When changing the fullscreen state and performing a roundtrip, more than one configure event can be sent before getting the event that changes the fullscreen state. Don't change the higher-level window state and avoid recursive calls back into the video system during these events.
According to the xdg-shell spec, xdg-toplevel min/max values are just hints, which compositors are free to ignore, and they often do so in several cases (usually when tiling, maximizing, or entering fullscreen). Even with the hints set, manually constraining the surface dimensions for non-maximized, non-fullscreen surfaces is required for consistent behavior.
In the case of maximized windows, the dimensions as specified in the configure event are non-negotiable and must be respected by the client, as not doing so is a protocol violation.
This also eliminates some redundant calls to set the libdecor resizable state, which can cause unnecessary commits internally.
It turns out there's a race condition on X11 where the window could be placed by the window manager while being placed by the application, so we need to have the initial position available at window creation.
Sam Lantinga