For devices connected via HDMI (supposedly TVs) we want have a
scale factor of 1 if we are *below* the smallest 4k resolution
width (not equal or above) and do the scaling factor computation
if we are above the limit. This check was apparently wrongly
ported from gnome-settings-daemon.
Based of a patch by Caolan McNamara <caolanm@redhat.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=777347
Previously, the function only returned `TRUE` if the given surface was
equal to the given pointer's focused surface. This changes the behaviour
to also return `TRUE` if any of the given surface's subsurfaces are
equal to the pointer's focused surface.
https://bugzilla.gnome.org/show_bug.cgi?id=781811.
For size change animations, plugins rely on the size change effect being
followed by size changed signal (or effects being kill altogether).
However unless the move_resize operation included the STATE_CHANGED flag,
the size changed event emitted when the compositor syncs the window
geometry only happens when the operation resulted in an actual change.
To avoid animations getting stuck in that case, make sure to include the
flag when tiling a window.
https://bugzilla.gnome.org/show_bug.cgi?id=783293
Use the "destroy" MetaWaylandSurface signal instead of the wl_resource
destroy signal for tracking the lifetime of the surface with pointer
focus.
As unsetting the focus may have side effects due to handlers of the
"focus-surface-changed" signal, connect the signal after the default
handler to make sure other clean up facilities have the chance deal with
the surface destruction before we try to unset the focus.
https://bugzilla.gnome.org/show_bug.cgi?id=783113
A single keysym can resolve to multiple keycodes. Instead of only using
the first one and ignoring the others, we store all codes in
MetaResolvedKeyCombo and then handle all of them in keybinding
resolution. If we already have bound a keycode for a keybinding with a
specific keysym then this can get overwritten by a new keybinding with a
different keysym that resolves to the same keycode. Now that we resolve
and bind all keycodes for a keysym this might happen more often; in that
case warn but still overwrite, but only for the first keycode for each
keysym. If a secondary (i.e. all non-first keycodes) is already indexed
we just ignore that; this should resemble the old behavior where we
only took the first keycode for any keysym as close as possible.
https://bugzilla.gnome.org/show_bug.cgi?id=781223
We will both create and destroy monitors during initialization (when
using the X11 backend), so don't try to access the monitor manager from
the backend, but store a pointer to it instead.
It's stored in MetaMonitor even though only MetaMonitorTiled uses it,
mostly because it makes more sense to store such a pointer there.
https://bugzilla.gnome.org/show_bug.cgi?id=781723
In some circumstances, the origin tile (0, 0) is not the one that
should be used to drive the monitor when using a non-tiled mode. Update
MetaMonitorTiled to support this case. It also seems to be so that the
preferred mode might be some low resolution or bogus mode on these
monitors, so also adapt MetaMonitorTiled to manage to ignore the
preferred mode of a tiled monitor if the preferred mode doesn't use
both tiles.
https://bugzilla.gnome.org/show_bug.cgi?id=781723
Only support suggested monitor positioning if the monitor is non-tiled.
Normally this functionality is used by virtual machines to provide a
hint of how to place the virtual monitors, and they don't tend to use
tiled monitors anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=781723
This commit makes it possible to configure logical monitor scale also
when running on top of an X11 server using Xrandr. An extra property
'requires-globla-scale' is added to the D-Bus API is added to instruct
a configuration application to only allow setting a global logical
monitor scale.
This is needed to let gsd-xsettings use the configured state to set a
XSettings state that respects the explicit monitor configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The scale calculation doesn't really have anything to do with KMS, and
eventually we'll want to have mutter calculate the monitor scale for
non-KMS backends too, so move the scale calculation to MetaMonitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Introduce MetaSettings and add the settings managed by MetaBackend into
the new object. These settings include: experimental-features and UI
scaling factor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
hotplug_mode_update is used (mostly by VMs nowadays, and
VMware has implemented it) to inform that modes list (including
the preferred one) might change after an uevent.
However, when using MetaMonitorConfigManager we should
ignore this value at initialization level, or mutter
won't restore the configured values at startup.
https://bugzilla.gnome.org/show_bug.cgi?id=783073
Since commit 5cb5baa7d4, we skip transitions when updating an
actor's scale/position to the existing value. As a result, we
don't get change notification on those properties either - given
that the properties did not actually change, that behavior seems
fine, so just modify the test to not expect a notify signal for
unchanged properties.
Call meta_compositor_size_change_window while tiling in order
to emit the size-change signal. Since the untiling action is
considered a unmaximize size change, treat tiling as a maximize
size change for consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=782968
Disable-while-typing disables the touchpad while the user is typing.
This patch introduces the necessary backend code to implement the
org.gnome.desktop.peripherals.touchpad.disable-while-typing setting of
gsettings-desktop-schemas which was implemented in commit
4c5b1c1df399d6afaaccb237e299ccd1d5d29ddd and released as part of 3.24.
This is known as dwt in libinput.
This patch has been tested on X11 and Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=764852
Let the backend implementations create their own input settings
backend, as is done with other backend specific special purpose
backends. Also use the macro for declaring the GType.
https://bugzilla.gnome.org/show_bug.cgi?id=782152
meta_backend_real_post_init() had some open coded initialization with
some unexpected interdependencies. Split these up and move them to their
own functions in order to make meta_backend_real_post_init() a bit more
readable.
https://bugzilla.gnome.org/show_bug.cgi?id=782152
Relayouts in clutter may trigger synthesized crossing events if the
actor below the pointer changes. In that situation we do need to
repick() the MetaWaylandPointer to end up with the right current
wayland surface.
https://bugzilla.gnome.org/show_bug.cgi?id=755164
Those are cached and reused across runs, which doesn't qualify to mesa
as "static" indeed. Properly marking those as dynamic is more true, and
brings in slight performance benefits just by avoiding the resulting
(and later silenced) mesa warning.
https://bugzilla.gnome.org/show_bug.cgi?id=782344
When terminating mutter running as a display server, don't try to resize
maximized windows when unmanaging, as at this point, they will have no
MetaWaylandSurface. Originally this was done instead of setting the
net_wm_state to not mess with future window managers, but when we're a
Wayland compositor, this does not matter.
https://bugzilla.gnome.org/show_bug.cgi?id=782156
If a client changes the state of a surface to issue a set_maximize, this
causes apply_pending_state() to be called before mutter has placed the
window.
If the monitor on which the window is to be shown initially is different
from the one where the pointer is placed, this causes the effect to be
played at the wrong location before the window eventually reaches its
location on another monitor.
Force the window to be placed prior to change its state to maximized in
xdg-shell so that mutter won't relocate the window afterwards.
This also avoids sending an xdg_toplevel.configure with a size of 0x0
which would cause the client to initially draw its surface with some
arbitrary size.
https://bugzilla.gnome.org/show_bug.cgi?id=782183https://bugzilla.gnome.org/show_bug.cgi?id=781353
Some distros such as Ubuntu and Debian set it to 'no',
while others might keep it to 'unknown' (which defaults to
'yes'). And this causes troubles when linking with mutter-clutter
in some tests.
https://bugzilla.gnome.org/show_bug.cgi?id=782821
