Commit Graph

99 Commits

Author SHA1 Message Date
Giovanni Campagna
aa15c09d54 Merge tag 'xrandr_branch_point' into wayland-kms-base
Conflicts:
	src/Makefile.am
	src/core/display.c
	src/core/screen-private.h
	src/core/screen.c
2013-08-27 10:07:39 +02:00
Giovanni Campagna
bd3d5df9ce Remove HAVE_WAYLAND ifdefs
Wayland support is always enabled now.

https://bugzilla.gnome.org/show_bug.cgi?id=705497
2013-08-26 15:00:29 +02:00
Giovanni Campagna
214f31257b Rework and consolidate monitor handling in MetaScreen
Consolidate all places that deal with output configuration in
MetaScreen, which gets it either from XRandR or from a dummy static configuration.
We still need to read the Xinerama config, even when running xwayland,
because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but
now we do it only when needed.

https://bugzilla.gnome.org/show_bug.cgi?id=705670
2013-08-18 00:22:54 +02:00
Jasper St. Pierre
0e098249b1 Merge remote-tracking branch 'origin/master' into wayland 2013-08-13 10:44:09 -04:00
Jasper St. Pierre
12d2e1f600 Support _GTK_FRAME_EXTENTS
https://bugzilla.gnome.org/show_bug.cgi?id=705766
2013-08-13 10:40:15 -04:00
Robert Bragg
40e820f551 Add support for stacking X and Wayland windows together
This breaks down the assumptions in stack-tracker.c and stack.c that
Mutter is only stacking X windows.

The stack tracker now tracks windows using a MetaStackWindow structure
which is a union with a type member so that X windows can be
distinguished from Wayland windows.

Some notable changes are:

Queued stack tracker operations that affect Wayland windows will not be
associated with an X serial number.

If an operation only affects a Wayland window and there are no queued
stack tracker operations ("unvalidated predictions") then the operation
is applied immediately since there is no server involved with changing
the stacking for Wayland windows.

The stack tracker can no longer respond to X events by turning them into
stack operations and discarding the predicted operations made prior to
that event because operations based on X events don't know anything
about the stacking of Wayland windows.

Instead of discarding old predictions the new approach is to trust the
predictions but whenever we receive an event from the server that
affects stacking we cross-reference with the predicted stack and check
for consistency. So e.g. if we have an event that says ADD window A then
we apply the predictions (up to the serial for that event) and verify
the predicted state includes a window A. Similarly if an event says
RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for
that event) and verify that window B is above C.

If we ever receive spurious stacking events (with a serial older than we
would expect) or find an inconsistency (some things aren't possible to
predict from the compositor) then we hit a re-synchronization code-path
that will query the X server for the full stacking order and then use
that stack to walk through our combined stack and force the X windows to
match the just queried stack but avoiding disrupting the relative
stacking of Wayland windows. This will be relatively expensive but
shouldn't be hit for compositor initiated restacking operations where
our predictions should be accurate.

The code in core/stack.c that deals with synchronizing the window stack
with the X server had to be updated quite heavily. In general the patch
avoids changing the fundamental approach being used but most of the code
did need some amount of re-factoring to consider what re-stacking
operations actually involve X or not and when we need to restack X
windows we sometimes need to search for a suitable X sibling to restack
relative too since the closest siblings may be Wayland windows.
2013-08-10 19:13:49 -04:00
Robert Bragg
f9a11b3b18 wayland: Adds basic hybrid X + Wayland support
This adds support for running mutter as a hybrid X and Wayland
compositor. It runs a headless XWayland server for X applications
that presents wayland surfaces back to mutter which mutter can then
composite.

This aims to not break Mutter's existing support for the traditional X
compositing model which means a single build of Mutter can be
distributed supporting the traditional model and the new Wayland based
compositing model.

TODO: although building with --disable-wayland has at least been tested,
I still haven't actually verified that running as a traditional
compositor isn't broken currently.

Note: At this point no input is supported

Note: multiple authors have contributed to this patch:
Authored-by: Robert Bragg <robert@linux.intel.com>
Authored-by: Neil Roberts <neil@linux.intel.com>
Authored-by: Rico Tzschichholz.
Authored-by: Giovanni Campagna <gcampagna@src.gnome.org>
2013-08-10 19:13:48 -04:00
Robert Bragg
531be6c413 Track the X Shape input region and use it for picking
We now track whether a window has an input shape specified via the X
Shape extension. Intersecting that with the bounding shape (as required
by the X Shape extension) we use the resulting rectangles to paint
window silhouettes when picking. As well as improving the correctness of
picking this should also be much more efficient because typically when
only picking solid rectangles then the need to actually render and issue
a read_pixels request can be optimized away and instead the picking is
done on the cpu.
2013-08-10 19:13:48 -04:00
Dan Winship
7a4c808e43 display: clean up focus_window vs expected_focus_window
Mutter previously defined display->focus_window as the window that the
server says is focused, but kept display->expected_focus_window to
indicate the window that we have requested to be focused. But it turns
out that "expected_focus_window" was almost always what we wanted.

Make MetaDisplay do a better job of tracking focus-related requests
and events, and change display->focus_window to be our best guess of
the "currently" focused window (ie, the window that will be focused at
the time when the server processes the next request we send it).

https://bugzilla.gnome.org/show_bug.cgi?id=647706
2013-05-22 13:46:15 -04:00
Owen W. Taylor
97a4cc8c9b Make handling of windows that don't respond to _NET_WM_SYNC_REQUEST reliable
Previously, we were handling failure to respond to _NET_WM_SYNC_REQUEST
in the code path for throttling motion events. But this meant that
if a window didn't respond to _NET_WM_SYNC_REQUEST and there were no
motion events - for a keyboard resize, or after the end of the grab
operation - it would end up in a stuck state.

Use a separate per-window timeout to reliably catch the failure to respond
to _NET_WM_SYNC_REQUEST.

https://bugzilla.gnome.org/show_bug.cgi?id=694046
2013-03-14 08:01:28 -04:00
Owen W. Taylor
592374bc62 Fix freezing of windows with keyboard resizing
During resizing we froze window updates when configuring the
window, and unfroze the window updates when processing the
next resize. This wasn't absolutely reliable, because we might
not have a next resize. Instead tie window freezing more
directly to the current sync request value - a window is
frozen until it catches up with the last value we sent it
in _NET_WM_SYNC_REQUEST.

Testing with unresponsive clients showed that there was a bug
where window->disable_sync once set, would not actually disable
sync, but it *would* disable noticing that the client was
unresponsive for the next resize. Fix that by checking for
->disable_sync before sending _NET_WM_SYNC_REQUEST.

https://bugzilla.gnome.org/show_bug.cgi?id=694046
2013-03-14 07:59:57 -04:00
Ray Strode
2cafb8be2d window: fix meta_window_is_remote across hostname changes
meta_window_is_remote compares a cached copy of the system hostname
with the hostname of the client window
(as presented by the WM_CLIENT_MACHINE property).

Of course, the system hostname can change at any time, so caching
it is wrong. Also, the WM_CLIENT_MACHINE property won't necessarily
change when the system hostname changes, so comparing it with the
new system hostname is wrong, too.

This commit makes the code call gethostname() at the time
WM_CLIENT_MACHINE is set, check whether it's remote then, and cache
that value, rather than comparing potentially out of sync hostnames
later.

https://bugzilla.gnome.org/show_bug.cgi?id=688716
2013-02-20 16:02:10 -05:00
Owen W. Taylor
5876f2e3e5 Fix corner cases where _NET_WM_FRAME_DRAWN might be missed
The WM spec requires _NET_WM_FRAME_DRAWN to *always* be sent when
there is an appropriate update to the sync counter value. We were
potentially missing _NET_WM_FRAME_DRAWN when an application did a
spontaneous update during an interactive resize and during effects.
Refactor the code to always send _NET_WM_FRAME_DRAWN, even when
a window is frozen.

https://bugzilla.gnome.org/show_bug.cgi?id=693833
2013-02-14 16:21:26 -05:00
Owen W. Taylor
87fe9685b5 Distinguish "no delay" frames from spontaneous drawing
When a client is drawing as hard as possible (without sleeping
between frames) we need to draw as soon possible, since sleeping
will decrease the effective frame rate shown to the user, and
can also result in the system never kicking out of power-saving
mode because it doesn't look fully utilized.

Use the amount the client increments the counter value by when
ending the frame to distinguish these cases:

 - Increment by 1: a no-delay frame
 - Increment by more than 1: a non-urgent frame, handle normally

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:27 -05:00
Owen W. Taylor
fbfab93c63 Send _NET_WM_FRAME_DRAWN messages
When the application provides the extended second counter for
_NET_WM_SYNC_REQUEST, send a client message with completion
information after the next redraw after each counter update
by the application.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
70c0d39fa7 Add support for an extended style of _NET_WM_SYNC_REQUEST_COUNTER
If an application provides two values in _NET_WM_SYNC_REQUEST_COUNTER,
use that as a signal that the applications wants an extended behavior
where it can update the counter as well as the window manager. If the
application updates the counter to an odd value, updates of the
window are frozen until the counter is updated again to an even value.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
7743c70d47 Move sync alarms to be per-window and permanent
Instead of creating a new alarm each time we resize a window
interactively, create an alarm the first time we resize a window
and keep it around permanently until we unmanage the window.
Doing it this way will be useful when we allow the application to
spontaneously generate sync request updates to indicate
frames it is drawing.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:25 -05:00
Owen W. Taylor
c9343e3ee3 Implement freezing of updates during resize
Replace the unused meta_compositor_set_updates() with
a reversed-meaning meta_compositor_set_updates_frozen(), and use
it to implement freezing application window updates during
interactive resizing. This avoids drawing new areas of the window
with blank content before the application has a chance to repaint.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:40:07 -05:00
Jasper St. Pierre
a613a55658 Support _NET_WM_OPAQUE_REGION
This new hint allows compositors to know what portions of a window
will be obscured, as a region above them is opaque. For an RGB window,
possible to glean this information from the bounding shape region of
a client window, but not for an ARGB32 window. This new hint allows
clients that use ARGB32 windows to say which part of the window is
opaque, allowing this sort of optimization.

https://bugzilla.gnome.org/show_bug.cgi?id=679901
2013-02-06 00:08:04 -05:00
Jasper St. Pierre
093e101252 Make work_area calculation funcs public and introspectible
https://bugzilla.gnome.org/show_bug.cgi?id=692679
2013-02-06 00:03:47 -05:00
Jasper St. Pierre
6f873be7fa Revert "Make work_area calculation funcs public and introspectible"
This reverts commit d8058138ab.
2013-02-06 00:03:10 -05:00
Jasper St. Pierre
d8058138ab Make work_area calculation funcs public and introspectible
https://bugzilla.gnome.org/show_bug.cgi?id=692679
2013-02-05 23:54:13 -05:00
Adel Gadllah
9a57626556 meta-window-actor: Change unredirection hints to match spec changes
Change the bypass / dont_bypass compositor code to match the latest
spec.

https://bugzilla.gnome.org/show_bug.cgi?id=693064
2013-02-03 14:29:45 +01:00
Florian Müllner
30bdadb519 window: Cache _NET_WM_ICON_GEOMETRY
Rather than doing a server round trip each time when retrieving the
icon geometry, use the existing property mechanism to cache it.

https://bugzilla.gnome.org/show_bug.cgi?id=692997
2013-02-01 15:08:38 +01:00
Jasper St. Pierre
d8eb47e2b7 window: Make meta_window_located_on_workspace() public
We have some code in gnome-shell that does the equivalent of:

    window.get_workspace() == workspace || window.is_on_all_workspaces();

which is a bit unwieldy. We already have a method in mutter,
so use that and document it.

https://bugzilla.gnome.org/show_bug.cgi?id=691744
2013-01-18 15:45:05 -05:00
Adel Gadllah
3876a1a192 Support bypass compositor hints
Add support for _NET_WM_BYPASS_COMPOSITOR and _NET_WM_DONT_BYPASS_COMPOSITOR
as proposed here: https://mail.gnome.org/archives/wm-spec-list/2012-February/msg00010.html

https://bugzilla.gnome.org/show_bug.cgi?id=683020
2012-12-18 19:02:34 +01:00
Jasper St. Pierre
1d827049d6 Port mutter to use XInput2 events instead of Core Events
Mechanically transform the event processing of mutter to care
about XI2 events instead of Core Events. Core Events will be left
in the dust soon, and removed entirely.

https://bugzilla.gnome.org/show_bug.cgi?id=688779
2012-12-13 14:56:25 -05:00
Jasper St. Pierre
881d256ce0 window: Move grab op sync handling code out
This removes some duplicate event type checks, and will make
the code cleaner in the future when we want to make the grab_op_event
handler take an XIDeviceEvent directly.

Based on a patch by Owen Taylor <otaylor@fishsoup.net>

https://bugzilla.gnome.org/show_bug.cgi?id=688779
2012-12-13 14:56:24 -05:00
Jasper St. Pierre
18b38320a6 window: Make some window methods public
There's no reason they aren't, right now. Extensions should be able
to use these.

https://bugzilla.gnome.org/show_bug.cgi?id=678126
2012-06-25 13:52:47 -04:00
Rui Matos
2926323a9a window: Introduce meta_window_get_tile_match()
Returns the matching tiled window. This is the topmost tiled window in a
complementary tile mode that is:

 - on the same monitor;
 - on the same workspace;
 - spanning the remaining monitor width;
 - there is no 3rd window stacked between both tiled windows that's
   partially visible in the common edge.

https://bugzilla.gnome.org/show_bug.cgi?id=643075
2012-03-16 19:12:05 +01:00
Ryan Lortie
1772a2a59c adjust to new Gtk properties for app menu
https://bugzilla.gnome.org/show_bug.cgi?id=668118
2012-01-18 17:26:12 -05:00
Florian Müllner
9729a99ec5 window: Support GTK+'s hide-titlebar-when-maximized hint
For maximized windows, titlebars cannot be used to reposition or
scale the window, so if an application does not use it to convey
useful information (other than the application name), the screen
space occupied by titlebars could be put to better use.
To account for this use case, a setting for requesting that windows'
titlebars should be hidden during maximization has been added to
GTK+, add support for this in the window manager.

https://bugzilla.gnome.org/show_bug.cgi?id=665617
2011-12-15 16:37:20 +01:00
Ryan Lortie
e4ed433e18 Add _DBUS_UNIQUE_NAME and _OBJECT_PATH properties
https://bugzilla.gnome.org/show_bug.cgi?id=664851
2011-12-15 10:21:22 -05:00
Colin Walters
8ab5cc8f19 Load _DBUS_APPLICATION_ID property, expose it via API
This is used to associate GtkApplication -> X window, and will
be consumed by gnome-shell.

https://bugzilla.gnome.org/show_bug.cgi?id=664851
2011-12-15 10:12:31 -05:00
Florian Müllner
baeb9fbc4b window: Make meta_window_can_tile_side_by_side() public
In order to support keybindings for window tiling, we need to
determine whether a window is tilable or not, so make this public.

https://bugzilla.gnome.org/show_bug.cgi?id=648700
2011-12-12 11:55:51 +01:00
Florian Müllner
bed9cb1648 window: Keep track of the last full-maximization state
In order to be able to toggle between tiled and normal/maximized
states, we need to keep track of the last full maximization state.

https://bugzilla.gnome.org/show_bug.cgi?id=648700
2011-12-12 11:55:50 +01:00
Rui Matos
138eb1e3b4 tiling: keep track of the monitor where a window was tiled
meta_window_get_current_tile_area() computes the area where the tiled window
should be based on the current pointer position but that's only meaningful
when the user is actually dragging the window.

When running the tiling constrain the pointer might be on other monitor and at
that point the window jumps to this other monitor.

https://bugzilla.gnome.org/show_bug.cgi?id=642580
2011-10-18 02:40:36 +01:00
Rui Matos
c39129b6e8 tiling: for tiled maximization use the tile area as target size/position
When using more than one monitor, tiled maximization can be triggered with the
pointer in one monitor while most of the window area remains in another. This
means that the maximization constraint would maximize the window into the wrong
monitor as it uses the work area size/position as target.

Fix this by using the current tile area as target size/position.

https://bugzilla.gnome.org/show_bug.cgi?id=657519
2011-10-18 02:33:41 +01:00
Alexander Larsson
19b6888ea5 When monitors change, keep windows on same output.
If XRANDR is availible, we track the first (or primary) output per
crtc (== xinerama monitor) so when the monitors change we can try
to find the same output and move windows there. If we can't find the
original monitor in the new set (or XRANDR is not supported) we move
the window to the primary monitor.

https://bugzilla.gnome.org/show_bug.cgi?id=645408
2011-09-14 15:38:55 +02:00
Dan Winship
7f8c59614e window: make determination of attached dialog windows more consistent
Different bits of code were using slightly different checks to test
whether a window was an attached dialog. Add a new
meta_window_is_attached_dialog(), and use that everywhere.

Also, freeze the is-attached status when the window is first shown,
rather than recomputing it each time the caller asks, since this could
cause problems if a window changes its type after it has already been
attached, etc. However, if an attached window's parent is destroyed,
or an attached window changes its transient-for, then fix things up by
destroying the old MetaWindow and creating a new one (causing
compositor unmap and map events to be fired off, allowing the display
of the window to be fixed up).

Remove some code in display.c that tried to fix existing windows if
the gconf setting changed, but which didn't actually do anything (at
least under gnome-shell). However, if 654643 was fixed then the new
behavior with this patch would be that changing the gconf setting
would affect new dialogs, but not existing ones.

https://bugzilla.gnome.org/show_bug.cgi?id=646761
2011-08-27 13:12:25 -04:00
Florian Müllner
4f3b03e13b window: Parse _GTK_THEME_VARIANT property
Since version 3.0, GTK+ has support for style variants. At the moment,
themes may provide a dark variant, which can be requested by
applications via GtkSettings. The requested variant is exported to
X11 via the _GTK_THEME_VARIANT property - support this property, in
order to pick up the correct style variant in the future.

https://bugzilla.gnome.org/show_bug.cgi?id=645355
2011-05-18 23:07:23 +02:00
Owen W. Taylor
67c3c93b8f Only shadow ARGB windows with a frame outside the frame
An ARGB window with a frame is likely something like a transparent
terminal. It looks awful (and breaks transparency) to draw a big
opaque black shadow under the window, so clip out the region under
the terminal from the shadow we draw.

Add meta_window_get_frame_bounds() to get a cairo region for the
outer bounds of the frame of a window, and modify the frame handling
code to notice changes to the frame shape and discard a cached
region. meta_frames_apply_shapes() is refactored so we can extract
meta_frames_get_frame_bounds() from it.

https://bugzilla.gnome.org/show_bug.cgi?id=635268
2011-04-26 15:10:02 -04:00
Dan Winship
f464b85ffc window: add an appears-focused property, redraw shadows when it changes
We need to redraw a window's shadow any time the value of
meta_window_appears_focused() changes. So make that into a property so
we can get notifications on it.

https://bugzilla.gnome.org/show_bug.cgi?id=636904
2011-03-28 12:09:10 -04:00
Alexander Larsson
9d62d13f88 Split out on_all_workspaces and on_all_workspaces_requested
Sometimes on_all_workspaces is requested by the client/user, and sometimes
its calculated implicitly due to internal state. We split this up so that
we know when the user has explicitly asked for sticky window, when e.g.
setting wmspec properties or storing session info.

on_all_workspaces means this window is visible on all workspaces.

on_all_workspaces_requested, means the user explicitly made the window
sticky somehow (via imported session, _NET_WM_STATE from another wm,
toggled in the window menu, etc). It always implies on_all_workspaces is
TRUE.

Right now the only time we set on_all_workspaces is for override-redirect
windows, but later we can add a "windows on non-primary monitor are not
part of the workspace switching" feature.

https://bugzilla.gnome.org/show_bug.cgi?id=609258
2011-03-17 13:48:54 +01:00
Alexander Larsson
44cfceba00 Track the monitor for each window
https://bugzilla.gnome.org/show_bug.cgi?id=609258
2011-03-17 13:48:54 +01:00
Dan Winship
c84da3ce1b Move the installed includes to a subdir
If mutter is going to be a "real" library, then it should install its
includes so that users can do

    #include <meta/display.h>

rather than

    #include <display.h>

So rename the includedir accordingly, move src/include to src/meta,
and fix up all internal references.

There were a handful of header files in src/include that were not
installed; this appears to have been part of a plan to keep core/,
ui/, and compositor/ from looking at each others' private includes,
but that wasn't really working anyway. So move all non-installed
headers back into core/ or ui/.

https://bugzilla.gnome.org/show_bug.cgi?id=643959
2011-03-07 18:19:53 -05:00
Florian Müllner
286160646b display: Keep track of the original tile state during drag
Drag operations may be cancelled, in which case the dragged window
should be restored to the position/state it had when the drag was
initialized. In order to do this for tiled states, the original
state has to be saved during the operation.

https://bugzilla.gnome.org/show_bug.cgi?id=639988
2011-01-20 18:49:48 +01:00
Florian Müllner
58068260a5 window: Make meta_window_tile() semi-public
The previous tiling state of a grabbed window should be restored
if the drag operation is cancelled (by hitting the Escape key).
This might involve to meta_window_tile(), so export the function
in window-private.h.

https://bugzilla.gnome.org/show_bug.cgi?id=639988
2011-01-20 18:49:48 +01:00
Florian Müllner
ed99d12e8b theme: Add tiled_left/tiled_right frame states
It may be desirable for theme authors to treat side-by-side tiled
windows differently, for instance to give the edge-touching border
a width of 0, so add additional frame states for tiled windows.

https://bugzilla.gnome.org/show_bug.cgi?id=637330
2011-01-05 01:49:58 +01:00
Ray Strode
07c0471902 tiling: Add new "maximized" tile
In addition to the existing side-by-side tiling modes, this commit
adds a new "maximize" tiling mode.  It allows the user to maximize
their windows (in other words, tile with the edge panels) by dragging
their window to the top edge of the monitor.

https://bugzilla.gnome.org/show_bug.cgi?id=630548
2010-12-02 17:11:11 -05:00