- Removed GTK signal handler in x11settings. XSettings events are now properly dispatched to X11_XsettingsNotify.
Previously events were not being passed to xsettings-client as no SDL xsettings_window was created. Now all events
are filtered through xsettings_client_process_event allowing it to process the external window events that are selected.
Global content scale is updated for changes to any recognized dpi settings.
- X11_GetGlobalContent now reads the current RESOURCE_MANAGER prop off of the root window to ensure it sees the
current value. XResourceManagerString is now only used if getting the current prop fails as it caches the current resource
manager value per-display connection.
- Clean up some warnings in SDL_gtk.
In addition to hiding the border on bordered windows that will immediately become fullscreen, The combination of flags used in STYLE_BORDERLESS_WINDOWED will still show the borders on borderless windows if the initial window size exactly matches the desktop, so STYLE_BORDERLESS must be used instead.
If attempting to switch to an exclusive mode while a fullscreen spaces transition is active, wait until the transition is complete before trying to apply the changes, or the window can wind up in a weird, broken state if a mode switch occurs while in a fullscreen space.
This reverts commit ee8f2861e7.
It turns out that the problem is elsewhere, related to needing to block mode changes until spaces transitions are complete.
- Removed gtk-xft-dpi read from GetGlobalContentScale. Xrm either returns either the same value as gtk-xft-dpi or the integer
scale value in cases where gtk-xft-dpi is 1.
- Refactor SDL_x11settings handlers to defer to GetGlobalContentScale
- GetGlobalContentScale is now exported and the XSettings and Gtk signal handlers now use it for consistency. This involves
a bit of extra work reading from Xrm rather than the setting notification but ensures consistent handling based on signal
origin and hints enabled.
- Hook both gtk-xft-dpi in SDL_x11settings. This should generally result in only one being called based on which is updated.
Since both signal handlers defer to X11_GetGlobalContentScale this will cause the same content scale to be applied multiple
times. The gtk-xft-dpi signal is now only used to trigger content scale updates when the XSettings notification does not occur.
There may have been a reason for not attaching a null buffer when destroying a popup at some point in the past, but that is unnecessary now, as is the comment about ShowWindow crashing, as ShowWindow assures that a null buffer is attached before (re)creating the window.
The previous calculation could result in a window whose original position was positioned exactly corner-to-corner with the parent not being adjusted to be adjoining, and thus subject to spurious closure.
- This is to support dynamic updates of content scale when running in XWayland. The GTK signal is
preferred over the XSettings watcher and Xrm database if supported as it will trigger and update
for both native X11 and XWayland on changes to Xft.dpi.
Keymap construction is an expensive process, so keymaps are cached to facilitate fast switching, as they are static after initial construction, and do not need to be rebuilt every time.
This still logs backend choices, but we might use it for other things. For
example, what Android device is being used, or all the devices we enumerated,
etc.
Ideally this eventually logs all the stuff we often have to ask followup
questions about.
Only use the specified output if an exclusive mode is being used, or a position was explicitly requested before entering fullscreen desktop. Otherwise, let the compositor handle placement, as it has more information about where the window is and where it should go, especially if fullscreen was requested before the window was fully mapped, or the window spans multiple outputs.
When changing the text input mode on a window, only update the seats that currently hold keyboard focus on that window, otherwise, text input might be inadvertently enabled or disabled on a seat focused on another window.
Build all the available keyboard layouts at once; this adds a negligible bit of overhead when initially handling the keymap (which was already significantly lowered by previous commits), but reduces the later cost of changing layouts to just swapping a pointer.
Additionally, handling of unknown keysyms, particularly when dealing with virtual keyboards, is improved, as keys generating valid Unicode values with no corresponding scancode will be dynamically added to the keymap with reserved scancodes, allowing for proper round-trip lookup behavior.
Initializing the compose table is a very expensive operation, and only necessary if the locale envvar changed, which is often not the case when just changing the keymap, so don't destroy and recreate it whenever the keymap changes. The state only needs to be reset in this case.
This allows us to avoid browser mouse emulation for touches, since we provide
our own anyhow.
The other option is to "prevent default" in the legacy touch event handlers we
historically used, to tell the browser not to supply emulation, but we can't
currently tell Emscripten to mark those handlers as not "passive," so as it
stands they are unable to prevent default. Using Pointer Events bypasses this
problem entirely.
Fixes#13161.
macOS sends a focus loss event when the dialog is created, which causes SDL
to try to minimize the window, which confuses the entire system. So in this
special case, don't do the minimization.
Fixes#13168.
It apparently works better (or can work better?) on multimonitor setups
than SwapBuffers.
This should be available back to Windows 95, but just in case, it falls
back to standard SwapBuffers if not available.
Fixes#13269.
Wayland previously didn't specify that the seat name preceded the capabilities, but it is now specified that the name event must always come first. Remove the 'SDL_Set<device>Name()' functions that were only added to accommodate the case of compositors sending the name after the seat capabilities, as this clarification means that they are no longer needed.
The internal key repeat mechanism already disables itself if the key repeat interval is 0, and SDL tracks and handles the flagging of repeated keys itself, so just map the 'repeated' event to 'pressed'.
The spec states that xdg_surface must have seen an initial configure event before attaching a buffer, however, this was only being done when initially showing the window, and not after show->hide->show cycle.
Always wait for the initial configure event when (re)creating an xdg_surface as part of the show window sequence.
If the pointer should be confined, keep trying until a confine/lock signal is received. This considerably improves locking/confinement reliability on compositors where confining can be a racy operation, or may not take effect until the pointer is actually in the confinement region.
A pointer lock is used to special-case 1x1 confinement regions, as otherwise, the pointer can still exhibit jitter at the subpixel level, particularly on scaled desktops.
Pointer events in seat version 5 and higher should be grouped and sent together when a pointer frame event occurs. Store pending pointer motion events and dispatch them together when a frame event is received.
This helps avoid spurious pointer motion events that some compositors generate with no associated frame (e.g. from some tablet events).
On newer systems, the trick isn't necessary, and if you do it, if the user is
moving the mouse when launching the app, it'll show a hidden Dock.
Fixes#10340.
