This commit adds support for rendering onto enlarged per logical
monitor framebuffers, using the scaled clutter stage views, for HiDPI
enabled logical monitors.
This works by scaling the mode of the monitors in a logical monitors by
the scale, no longer relying on scaling the window actors and window
geometry for making windows have the correct size on HiDPI monitors.
It is disabled by default, as in automatically created configurations
will still use the old mode. This is partly because Xwayland clients
will not yet work good enough to make it feasible.
To enable, add the 'scale-monitor-framebuffer' keyword to the
org.gnome.mutter.experimental-features gsettings array.
It is still possible to specify the mode via the new D-Bus API, which
has been adapted.
The adaptations to the D-Bus API means the caller need to be aware of
how to position logical monitors on the stage grid. This depends on the
'layout-mode' property that is used (see the DisplayConfig D-Bus
documentation).
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This gsetting will allow the adding of keywords to a array, where each
keyword may enable an experimental feauter, if the given mutter version
supports that particular experimental feature. Emphasis is put on the
lack of guarantee that any such keyword has any effect. Currently no
keywords are defined.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This commit adds the ability to set a scale on a scale view. This will
cause the content in the stage view to be painted with the given scale,
while still keeping the configured layout on the stage. In effect, for
a stage view with scale 'n', this means the framebuffer of a given stage
will 'n' times larger, keeping the same size on the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Make the concept of maximum screen size optional, as it is not
necessarily a thing on all systems (e.g. when using the native backend
and stage views).
The meta_monitor_monitor_get_limits() function is replaced by a
meta_monitor_manager_get_max_screen_size() which fails when no screen
limit is available. Callers and other users of the previous max screen
size fields are updated to deal with the fact that the limit is
optional.
The new D-Bus API is changed to move it to the properties bag, where
its absence means there is no applicable limit.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a new D-Bus API that uses the state from GetCurrentState to
configure high level monitors, instead of low level CRTCs and
connectors. So far persistent configuration is not implemented, as
writing to the configuration store is still not supported.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Logical monitors in a configuration must be adjecent to each other,
meaning there will be at least one pixel long side touching some other
logical monitor.
The exception to this is when there is only one logical monitor, which
cannot be adjecent to any other.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
We don't want to limit ourself to whole integers for configuration, as
that'd mean it wouldn't be able to provide configurations for
fractional scalings. Thus, change scales to be referred to as floats
instead of ints.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a 'is_underscanning' entry to the properties map, if the monitor
supports underscanning. The client should assume a monitor does not
support underscanning if no property was added.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a D-Bus method for getting the current monitor and logical monitor
state. Currently does not contain information about transforms or any
limitations (such as limited CRTCs and cloning).
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Let the backends decide whether to just rebuild a derived state, or use
the NULL config to rebuild an empty logical state.
This also changes the expected screen size values of the no-outputs
test; as this case is actually handled now.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add support to configure the logical monitor scale. With this, it
becomes possible to override the automatically calculated scaling
number per logical monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Replace the 'scale' of an output with a vfunc on the MetaMonitorManager
class that takes a monitor and a monitor mode which calculates the
scale. On X11 this always returns 1, on KMS, the old formula is used.
On the dummy and test backends, the already configured values are
returned.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The default (calculated) scale is derived from the output, but
ultimately set via the monitor scale. This will enable config files to
override the scale. Yet to be done is handling when a scale is not
supported by a backend (i.e. the X11 backend).
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In some cases the hardware cursor is invisible when Mutter is launched from the
TTY, due to drmModeSetCursor2 failing without a fallback being set.
This patch captures the return value of drmModeSetCursor2 and in case of an
error, enables the texture based fallback. It adds a `broken` state, that is
checked in should_have_hw_cursor() and
meta_cursor_renderer_native_realize_cursor_from_*() to avoid copying every
cursor into a gbm buffer when we know it will fail every single time.
https://bugzilla.gnome.org/show_bug.cgi?id=770020
Quick motions can come across as too fast (or slow) if it crosses outputs
with different scales. If this happens, rebuild the motion delta applying
the scale that applies to each logical monitor the pointer is crossing.
https://bugzilla.gnome.org/show_bug.cgi?id=778119
To allow for more natural pointer movements from relative pointer
devices (e.g. mouse, touchpad, tablet tool in relative mode, etc), scale
the relative motion from libinput with the scale of the monitor. In
effect, this means that the pointer movement is twice as fast (physical
movement vs numbers of pixels passed) as before, but it also means that
the same physical movement crosses the distance in a GUI no matter if
it is on a HiDPI monitor or not.
https://bugzilla.gnome.org/show_bug.cgi?id=778119
Clutter's evdev input backend has no support for setting double
click timeout set by gnome-settings-daemon. This results in
touchpad click events timing out on wayland, because the
default timeout value wasn't enough.
This patch moves timeout setting to mutter and removes X11
backend specific setting from clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=771576
The code calculating the output scale involves calculations around pixel
and mm sizes, however we do compare post-transformation pixel sizes to
untransformed mm sizes, which breaks the DPI calculations. Fix this by
transforming back pixel sizes back to untransformed.
While we're at it, actually compare the output height to HIDPI_MIN_HEIGHT
instead of its width, it seems right according to the #define name and
comment.
https://bugzilla.gnome.org/show_bug.cgi?id=777687
When a state changed, e.g. a window went from unfullscreen to
fullscreen, always sync the window geometry, otherwise a compositor
application (e.g. gnome-shell) might end up with an unfinished window
state transition effect.
Without always syncing, the compositor plugin will see a 'size-change'
event, as a result of the state change, but if the size didn't change,
it would never see the 'size-changed' event. If an effect, for example
gnome-shell's fullscreen effect, is triggered on 'size-change' it might
rely on the actual size change to not get stuck. This commit allows it
to have this dependency.
This fixes a bug where a fullscreen effect gets "stuck" when a window
goes fullscreen without changing the window geometry.
https://bugzilla.gnome.org/show_bug.cgi?id=780292
