When a laptop's lid is closed we try to build and apply a temporary
configuration that disables the laptop's display if we have other
outputs.
This isn't enough though, we must also check if at least one of these
other outputs is enabled otherwise we'll try to resize the screen to
0x0 which (rightfully) hits an assertion.
https://bugzilla.gnome.org/show_bug.cgi?id=739450
The input region currently only gets scaled by the surface
scale while ignoring the output scale, which causes input events to not get
delivered correctly for clients on hidpi screens. So take the output scale
into account when doing so.
https://bugzilla.gnome.org/show_bug.cgi?id=739161
This commit is wrong, it assumes that the scale only applies to the one
set by the client but its not. meta_surface_actor_wayland_scale_texture
also handles the output scale. Revert the commit to fix hidpi for wayland
clients like weston-terminal.
This reverts commit 0364ea9140.
https://bugzilla.gnome.org/show_bug.cgi?id=739161
Since GTK+ commit 3a337156d11a86c7, save()/restore() may only be
used for subelements; in this particular case, the change broke
the backdrop state in decorations. Luckily we don't actually need
the save()/restore() pair anyway, as we only touch the context's
state and always set it explicitly.
The set/unset branches of meta_display_update_pointer_emulating_sequence()
have been split and put directly where it makes sense. The pointer emulated
sequence will be updated before processing the CLUTTER_TOUCH_BEGIN, and
after processing the CLUTTER_TOUCH_END, this way the checks on this hold
true during all the sequence lifetime.
https://bugzilla.gnome.org/show_bug.cgi?id=738411
If the actor surface has an input mask, custom picking is implemented
for the portions affected by the mask, although the child actors (most
usually subsurfaces) are left out.
https://bugzilla.gnome.org/show_bug.cgi?id=738890
Returning FALSE here gets the button release event propagated to the
client on wayland, which is unexpected after xdg_surface.move/resize()
have been called.
https://bugzilla.gnome.org/show_bug.cgi?id=738888
It turns out that this was wrong because MetaWindow->monitor points to
the old monitor infos and they are needed to position windows in the
new configuration which happens in a monitors-changed handler.
This reverts commit e1704acda4.
The code in MetaMonitorConfig was really complex and was trying to do
way too much, using multiple different variables to determine where
things were stored, and trying to do fancy tricks to transfer
ownership.
Add a refcounting system to help simplify this, and clean up the logic.
Simply along the way, this fixes multiple bugs in the monitor config
logic, most notably bug #734889, which was my original goal to fix.
The X server sends several RRScreenChangeNotify events in a burst when
something happens which, currently, causes us to rebuild our view of
the world as many times and notify the upper layers about it which
causes a lot of bogus repeated work like rebuilding background actors.
We can avoid this extra work by looking at the timestamp in the
XRRScreenResources struct which is updated when an X client (including
us!) last changed something and comparing it with the previous
timestamp.
https://bugzilla.gnome.org/show_bug.cgi?id=738630
meta_monitor_config_match_current() only matches the number of outputs
and if the output connector, vendor, product and serial match.
In the X backend, this means that we can't use it to bypass doing any
work because it won't detect cases where we actually want to update
ourselves like e.g. an output being turned off either by us or by
another X client (e.g. xrandr).
In the native backend, unlike the xrandr backend, we only get called
on real hotplug events and thus should always trigger the common
hotplug code to (possibly) apply a new mode so the check is pointless
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=738630
In randr events, configTimestamp can be considered the hotplug time,
i.e. whenever the server notices hardware changes, this value will be
updated.
Having that in mind, we can re-work the logic to make it clearer.
There are no semantic changes.
Whoops, I made the code work without it, but forgot to strip it from the
actual list of requires packages.
Spotted-by: Rico Tzschichholz <ricotz@ubuntu.com>
Commit 2f9c601 accidentally changed the logic here, changing the grab
behavior when not using raise-on-click. Fix this.
Spotted-by: Adam Goode <adam@spicenitz.org>
From a quick code search and grep of gnome-themes-standard, none of
the themes that I inspected used this feature. Since it's the last
thing that uses a lot of old legacy GdkPixbuf code, I'd rather just
consider the feature unsupported at this point and clean up everything
I need to.
https://bugzilla.gnome.org/show_bug.cgi?id=662962
Fullscreen windows look weird when they are overlapped by system chrome,
which currently happens when another window is stacked above. We used to
auto-minimize fullscreen windows in that case, which proved to be both
unreliable and unpopular. So instead, keep the system chrome hidden even
when the fullscreen window is not stacked at the top.
https://bugzilla.gnome.org/show_bug.cgi?id=693991
We clip the input region to the client rect, so the client rect should
be up to date before we fetch the input region.
This fixes popup windows not working in GTK+2 under Wayland.
We should also update the shape / input regions when the window is
reconfigured for a complete fix, so that making an O-R window bigger
doesn't confuse mutter, but let's leave that to a future commit.
The constructor would collect windows that are sticky before initializing its state
which would lead to a crash in the case of windows with struts which trigger a work
area recalculation where mutter would assume, due to uninitialized state, that an
existing work area has to be freed.
https://bugzilla.gnome.org/show_bug.cgi?id=738384
Damage coordinates are relative to the drawable not to the screen. So we
have to check whether x and y are 0 and not window_rect.x/y otherwise the
herustic will never trigger for windows on monitors whos x and y are not 0.
https://bugzilla.gnome.org/show_bug.cgi?id=738271
The key event should be interpreted by clients with the modifier state
as it was before the event itself just as in X11 input events.
Achieving this in wayland is a matter of sending the key event first
and the modifiers after (if needed).
This isn't really specified in the wayland protocol but it matches
weston's behavior and should avoid corner cases in clients.
https://bugzilla.gnome.org/show_bug.cgi?id=738238
