There are many toolkit specific ways to set a font DPI in X11 desktop
environments. The primary approach of reading a Gnome specific setting
from the portal is ok, it will work on Gnome and on Plasma most the
time.
The current fallback GDK_SCALE is less great; it's an internal GTK
setting relating to the mapping of logical pixels to device pixels
within the toolkit, it's a developer setting for GTK devs. We were
instructed within Plasma to not set this as it caused issues.
Xft.dpi in xresources is a good universal fallback, it's very dated to
the point that it works in clients like xterm, Qt on X11 uses it in our
font DPI path.
Ideally we'd detect these as "joysticks" (or more generally, gaming
controllers), but in most cases their evdev flags are indistinguishable
from an accelerometer or gyro, so the only way to achieve this would be
a table of known devices that doesn't currently exist.
One exception is the one that reports a THROTTLE axis and TRIGGER, THUMB
buttons, which would be reasonable to detect via the joystick heuristic.
Signed-off-by: Simon McVittie <smcv@collabora.com>
There are some devices for which SDL's device classification heuristic
is known not to give the ideal result. Add a way to incorporate these
into our test data, so that when the heuristic is improved we can
detect them as their intended device type, without making the test fail
before that has been implemented.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Re-writes clipboard data handling in X11 to an on demand approach where
data can be produced on request instead of storing it in X11 properties
on the window.
Primary selection has been changed to mimic this behavior even though
it's only possible to use it for text as of now.
Ensure that incoming touch events originate from valid surfaces owned by SDL and have proper window data before forwarding them to the touch subsystem, or the window focus pointer that is sent with the event may not be a pointer to an SDL window.
Additionally, ensure that allocated touch events are always cleaned up on exit.
- SDL_MaximizeWindow, MinimizeWindow, SetFullScreenWindow, etc are not meant to show the window if it isn't currently visible, but on some platforms
(e.g. Windows) it isn't possible to set this state without also showing the window so cache the flags in a pending_flags field until SDL_ShowWindow is
called. Then replay the pending flags through ApplyPendingFlags (hoisted out from SDL_FinishWindowCreation).
If the text-scaling-factor setting is available via D-Bus, add a listener and update the content scale values for the displays if the value is changed during runtime.
Factors out the D-Bus message pump from the system theme detection code to the general D-Bus code, as it's now used for more purposes than just the system theme.
Expose the text scaling factor (aka the global scale factor on KDE) as the display content scale value so applications can scale themselves as necessary.
If D-Bus is unavailable or retrieving the setting fails, fall back to trying the legacy GDK_SCALE envvar before reverting to the default 1.0 value.
Change 8067023 by mikela:
Add SDL_HINT_WINDOW_ACTIVATE_WHEN_RAISED to SDL_RaiseWindow
- When set to false, this allows SDL_RaiseWindow to bring a chosen window to the top of the stack but not force input focus to it
Change 8067041 by mikela:
Rename SDL_HINT_WINDOW_NO_ACTIVATION_WHEN_SHOWN to SDL_HINT_WINDOW_ACTIVATE_WHEN_SHOWN
In theory this is illegal, but legit wavefiles in the field do it, and
it's easy to bump it to 1 for general purposes.
Formats with more specific alignment requirements already check for them
separately.
Fixes#7714.
First one to load and have the necessary symbol is the one we accept,
if any. Once we accept one, we won't try loading others.
Fixes#7613.
(cherry picked from commit 32999798e0232cdeda777a32ce2fe6b78ec2bb4e)
We have gotten feedback that abstracting the coordinate system based on the display scale is unexpected and it is difficult to adapt existing applications to the proposed API.
The new approach is to provide the coordinate systems that people expect, but provide additional information that will help applications properly handle high DPI situations.
The concepts needed for high DPI support are documented in README-highdpi.md. An example of automatically adapting the content to display scale changes can be found in SDL_test_common.c, where auto_scale_content is checked.
Also, the SDL_WINDOW_ALLOW_HIGHDPI window flag has been replaced by the SDL_HINT_VIDEO_ENABLE_HIGH_PIXEL_DENSITY hint.
Fixes https://github.com/libsdl-org/SDL/issues/7709
sdl12-compat can get into a state where a color-keyed surface is
marked for blending, but wants to blend with full alpha (which
is the same as _not_ blending), so rather than fail to find a
blitter in that case, it just selects the colorkey blitter.
Reference https://github.com/libsdl-org/sdl12-compat/issues/233
(cherry picked from commit 0eea92c8fcc4b5c572a0dd9848ca8886978ee0a2)
David Edmundson
Sam Lantinga
Simon McVittie
Linus Probert
Frank Praznik
Caleb Cornett
M. P. Halpin
Ozkan Sezer
SDL Wiki Bot
Ryan C. Gordon
valid-ptr