Wayland gives no feedback to windows regarding whether a minimize request was successful, so we would universally send the minimize event and assume that the request succeeded.
Check the window manager capabilities, if available, for whether window minimization is supported, and don't send the minimized event in the case that it is unsupported.
Excessive resize events generated during interactive window resizing can cause applications to lag, severely in some cases. Throttle interactive resize events to once per frame callback interval.
- make all of function pointers static
- make EGLint context_attribs[] static
- comment out unused function pointer ov_wglGetCurrentContext
- remove unused SDL_DisplayMode openvr_dm_default
- move SDL_VideoDisplay openvr_vd_default to OPENVR_VideoInit()
context and eliminate its C99 initializers
- replace atoi() calls with SDL_atoi()
- replace atof() calls with SDL_atof()
This is already done on win32, however, other platforms were left in a state of limbo if a drop operation began, then never completed due to the drop leaving the window.
The window content scale may change independently of the display it is on if scaling or accessibility features are involved, so query it directly from the backend instead of inferring it.
This is an X11 error catcher that lived for the entire life of the program,
which causes problems in itself, but it also tries to make calls into Xlib,
which would cause further panics.
It's goal was to reset video modes if the app was going down, but it often
failed to do so, and caused potentially avoidable crashes instead.
Fixes#7975.
The text-scaling-factor setting is not useful, now that we watch the
Xft/DPI and Gdk/WindowScalingFactor XSETTINGS keys; on the contrary, it
is problematic in mixed environments with both the KDE and GNOME
portals, as they end up stepping on each other's toes, and we end up
with the wrong scaling factor value.
Fixes: https://github.com/libsdl-org/SDL/issues/11142
This fixes the following sequence:
* Press mouse button down
* Alt-tab away from the window
* Alt-tab back to the window
* Release mouse button
Fixes https://github.com/libsdl-org/SDL/issues/7747
SDL3: SDL_render_gl(render name: opengl) dose not support transparent on Linux/X11:
Create SDL window with SDL_WINDOW_TRANSPARENT flag;
Create "opengl" renderer for the window;
The window can't shown with errors:
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 130 (MIT-SHM)
Minor opcode of failed request: 3 (X_ShmPutImage)
Bug reason:
SDL_x11window.c:490 : bool X11_CreateWindow(SDL_VideoDevice *_this, SDL_Window *window, SDL_PropertiesID create_props)
SDL_x11window.c:566 : vinfo = X11_GL_GetVisual(_this, display, screen, transparent);[XVisualInfo *vinfo]
the X11_GL_GetVisual function returns a vinfo dose not support transparent.
Fix:
SDL_x11opengl.c:637 : XVisualInfo *X11_GL_GetVisual(SDL_VideoDevice *_this, Display *display, int screen, bool transparent)
X11_GL_GetVisual should returns a vinfo support transparent when transparent is true.
This protocol is unstable and not intended for clients, and SDL now sorts the display list into a stable order and selects a primary display suitable for games on its own, so it isn't necessary.
Reverts e71e16950a
This fixes having the incorrect location for mouse button presses on Steam Deck under gamescope. This works around a bug where the mouse motion appears to come at the next button press, and comes from the xwayland-pointer device instead of the xwayland-relative-pointer device which is delivering mouse button events.
Portrait displays are typically used as secondaries and almost certainly not what a user wants a game or movie initially becoming full screen on if a landscape display is available. Increase the priority of selecting a landscape display over a portrait display.
Wayland can expose displays in any arbitrary order, and doesn't have the native concept of a primary display. However, there are games that presume that the first listed display is the primary, which can lead to problems if that output isn't necessarily the ideal one, as they may use that display to build a resolution list or as the default fullscreen output. This sorts displays by position, then attempts to find the primary display, first by querying the explicit ordering hint, then the GNOME DBus property, then tries to determine the 'best' display according to the criteria that is generally ideal for games and media playback.
The makes the list of displays deterministic, as long as the desktop configuration remains static, with a reasonably appropriate one prioritized as primary, even if there is no explicit way to retrieve the primary display. In the case where a user has a particularly esoteric physical display configuration, the new hint enables explicitly overriding the sorting and selection logic, allowing the entire display order to be customized, if necessary.
