This will be used by our Wayland front-end to implement the wl_viewport
extension.

The important thing is whether this property exists or not, but the value
doesn't matter.

This helps make the Makefile look nicer and prevent merge conflicts.

We use Xfixes symbols in this file, but under some conditions, we don't
always include the Xfixes headers.

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

If the monitor reports a width/height that looks suspiciously like an
aspect ratio (16/9 or 16/10) don't check for hi-dpi. We can assume that
makers of devices that do support hi-dpi aren't so careless.

See http://cgit.freedesktop.org/~daniels/xserver/commit/?h=lodpi

https://bugzilla.gnome.org/show_bug.cgi?id=734839

Update NEWS.

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 0364ea91.

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.

It thinks remaining can be used uninitialized. It's wrong, but let's
help it out by initializing the variable.

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

Crossing events may also be gotten on subsurfaces.

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 e1704acd.

We were forgetting to unref in a few places.

We don't return this configuration, so don't name it ret.

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.

This also fixes the case where current_is_for_laptop_lid wasn't properly
set in the default case.

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

This is what the xrandr CLI tool does and will allow us to do less
work when we get RRScreenChangeNotify events.

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.

Nothing uses this. Signal handlers have access to the new monitor
infos built by make_logical_config() .

https://bugzilla.gnome.org/show_bug.cgi?id=738630

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>

Now it's only required by the native backend. The cursor code is getting
quite messy, but it was already considerable messy to start with.

Reverse the set of expressions so testing for gbm is at the top.

Commit 2f9c601a

 accidentally changed the logic here, changing the grab
behavior when not using raise-on-click. Fix this.

Spotted-by: Adam Goode <adam@spicenitz.org>

Cosimo Cecchi authored Sep 18, 2014 and Jasper St. Pierre committed Oct 14, 2014

We want to use GResources for system backgrounds, so move this to a
GFile.

https://bugzilla.gnome.org/show_bug.cgi?id=736936

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

https://bugzilla.gnome.org/show_bug.cgi?id=662962

https://bugzilla.gnome.org/show_bug.cgi?id=662962

Thanks to Benjamin Otte for helping me clean this up.

https://bugzilla.gnome.org/show_bug.cgi?id=662962