This allows creating the stage much earlier than it otherwise would have
been. Our initialization sequence has always been a bit haphazard, with
first the MetaBackend created, then the MetaDisplay, and inside of that,
the MetaScreen and MetaCompositor.
Refactor this out so that the MetaBackend creates the Clutter
stage. Besides the clarity of early initialization, we now have much
easier access to the stage, allowing us to use it for things such as
key focus and beyond.
The current GNOME Shell Alt-F2 restart looks very messy and also
provides no indication to the user what is going on. We need to
restart the compositor to switch in and out of stereo mode, so
add a framework for doing this more cleanly:
Additions:
meta_restart(): restarts the compositor with a message
MetaDisplay::show-restart-message: signal the embedding
shell to show a message
MetaDisplay::restart: signal the embedding shell to restart
itself.
meta_is_restart(): indicates whether the current instance is a
restart so we can suppress login animations.
A helper program meta-restart-helper holds the composite overlay
window up during the restart to avoid visual artifacts.
https://bugzilla.gnome.org/show_bug.cgi?id=733026
These just spam up our logs, and they aren't getting fixed any time
soon for a variety of reasons. Just disable them to ensure that really
important warnings get noticed and fixed.
This object tracks both touch sequences happening on the stage and
gestures attached to the stage actor. When a gesture emits
::gesture-begin, All triggering sequences and future ones will be
marked as "accepted" by the compositor, and events will be listened
for meanwhile there are active gestures.
If a sequence goes unclaimed for a short time, it will be
automatically "denied", and punted to the client or shell element
below.
Avoid populating *_VERSION constants through cflags in pkg-config-file
which could be overridden by the project using it. Properly prefix the
defines with META_ to make gi-scanner happy.
Clutter touch events are translated into events being sent down
the interface resource, with the exception of FRAME/CANCEL events,
which are handled directly via an evdev event filter.
The seat now announces invariably the WL_SEAT_CAPABILITY_TOUCH
capability, this should be eventually updated as devices come and
go.
The creation of MetaWaylandTouchSurface structs is dynamic, attached
to the lifetime of first/last touch on the client surface, and only
if the surface requests the wl_touch interface. MetaWaylandTouchInfo
structs are created to track individual touches, and are locked to
a single MetaWaylandTouchSurface (the implicit grab surface) determined
on CLUTTER_TOUCH_BEGIN.
https://bugzilla.gnome.org/show_bug.cgi?id=724442
This uses David Herrmann's new logind sessions interface to retrieve
fds for input devices, rather than using a custom setuid helper to do
the management. This vastly simplifies the interface.
This requires systemd v210, at least.
https://bugzilla.gnome.org/show_bug.cgi?id=724604
Right now this just has all of the files in one directory. We'll
be introducing more structure to this in the future, and build
a proper backend system.
I want the MetaCursorTracker to mostly be about retrieving cursor
information. Start moving the code that loads cursor images to a
new file, MetaCursor. Eventually, MetaCursorTracker's APIs will
all take MetaCursorReferences, and we can have a clean backend
split here.
display.c is getting a bit crowded. Move most of the handling
out to another file, events.c.
The long-term goal is to have generic event handling here, with
backend-specific handling for the types of windows and such.
This is specifically about managing X11 windows, not necessarily
running as an X11 compositor. By that I mean that this code is
still used for XWayland windows, and event handling is still and
modesetting / monitor management is still in core/.
This is also a fairly conservative move. We don't move anything
like screen.c or bell.c in here, even though those are really
only for X11 clients.
This is fairly simple and basic for now, with just skip_taskbar /
skip_pager, but eventually a lot of "WM policy" like this, including
move-resize, will be in subclasses for each individual surface.
The rendering logic before was somewhat complex. We had three independent
cases to take into account when doing rendering:
* X11 compositor. In this case, we're a traditional X11 compositor,
not a Wayland compositor. We use XCompositeNameWindowPixmap to get
the backing pixmap for the window, and deal with the COMPOSITE
extension messiness.
In this case, meta_is_wayland_compositor() is FALSE.
* Wayland clients. In this case, we're a Wayland compositor managing
Wayland surfaces. The rendering for this is fairly straightforward,
as Cogl handles most of the complexity with EGL and SHM buffers...
Wayland clients give us the input and opaque regions through
wl_surface.
In this case, meta_is_wayland_compositor() is TRUE and
priv->window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND.
* XWayland clients. In this case, we're a Wayland compositor, like
above, and XWayland hands us Wayland surfaces. XWayland handles
the COMPOSITE extension messiness for us, and hands us a buffer
like any other Wayland client. We have to fetch the input and
opaque regions from the X11 window ourselves.
In this case, meta_is_wayland_compositor() is TRUE and
priv->window->client_type == META_WINDOW_CLIENT_TYPE_X11.
We now split the rendering logic into two subclasses, which are:
* MetaSurfaceActorX11, which handles the X11 compositor case, in that
it uses XCompositeNameWindowPixmap to get the backing pixmap, and
deal with all the COMPOSITE extension messiness.
* MetaSurfaceActorWayland, which handles the Wayland compositor case
for both native Wayland clients and XWayland clients. XWayland handles
COMPOSITE for us, and handles pushing a surface over through the
xf86-video-wayland DDX.
Frame sync is still in MetaWindowActor, as it needs to work for both the
X11 compositor and XWayland client cases. When Wayland's video display
protocol lands, this will need to be significantly overhauled, as it would
have to work for any wl_surface, including subsurfaces, so we would need
surface-level discretion.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
The goal here is to make MetaWindow represent a toplevel, managed window,
regardless of if it's X11 or Wayland, and build an abstraction layer up.
Right now, most of the X11 code is in core/ and the wayland code in wayland/,
but in the future, I want to move a lot of the X11 code to a new toplevel, x11/.
Instead of hardcoded knowledge of certain classes in MetaWindowGroup,
create a generic interface that all actors can implement to get parts of
their regions culled out during redraw, without needing any special
knowledge of how to handle a specific actor.
The names now are a bit suspect. MetaBackgroundGroup is a simple
MetaCullable that knows how to cull children, and MetaWindowGroup is the
"toplevel" cullable that computes the initial two regions. A future
cleanup here could be to merge MetaWindowGroup / MetaBackgroundGroup so
that we only have a generic MetaSimpleCullable, and move the "toplevel"
cullability to be a MetaCullableToplevel.
https://bugzilla.gnome.org/show_bug.cgi?id=714706
Instead of having MetaWindowActor only have one single MetaShapedTexture
as actor drawing its content, introduce a new abstract MetaSurfaceActor
that takes care of drawing.
This is one step in the direction to decouple MetaWaylandSurface with a
MetaWindow and MetaWindowActor (except for shell/xdg surfaces) in order
to finally support subsurfaces like features, or any feature where
window is not drawn using a single texture.
The first step, implemented in this patch, is to not have
MetaWindowActor work directly with a shaped texture. There are still
some cases where it simply gets the texture and goes on as before, but
this should be changed by either removing the need of going via
MetaWindowActor or by adding some generic interface to MetaSurfaceActor
that doesn't limit its functionality to one shaped texture.
There should be no visible difference nor after this patch, but
meta_window_actor_get_texture() and meta_surface_actor_get_texture()
should be deprecated when equivalent functionality has been introduced.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=705502
Using the new Cogl API to actually modeset (because we can't
use the DRM API directly without controlling buffer swap), we
can finally have a KMS monitor backend, which means full display
configuration when running on bare metal.
https://bugzilla.gnome.org/show_bug.cgi?id=706308
Switching meta/util.h to gi18n.h was wrong, mutter is a library
and needs gi18n-lib.h, but that cannot be included from a public
header (since it depends on config.h or command line options),
so split util.h into a public and a private part.
https://bugzilla.gnome.org/show_bug.cgi?id=707897
Add a new interface, gtk_shell, than can be used by gtk to
retrieve a surface extension called gtk_surface, which will be
used to communicate with mutter all the GTK extensions to EWMH
https://bugzilla.gnome.org/show_bug.cgi?id=707128
Add support for GTK application menus
To do so, we need to be able to set surface state before creating
the MetaWindow, so we introduce MetaWaylandSurfaceInitialState as
a staging area.
The gtk-shell-surface implementation would either write to the
initial state, or directly to the window.
At the same, implement set_title and set_class too, because it's
easy enough.
https://bugzilla.gnome.org/show_bug.cgi?id=707128
Once mutter is started from weston-launch on its own VT, there is
no way to change VT again (for example to actually start an application),
because the keyboard is put in raw mode.
So introduce some keybindings mimicking the standard X ones (Ctrl+Alt+Fn)
that switch the VT manually when activated.
https://bugzilla.gnome.org/show_bug.cgi?id=705861
Now that we have a setuid launcher binary, we can make use of
using a private protocol through the socket we're passed at startup.
We also use the new hook in clutter-evdev to ask mutter-launch for
the FDs of the input devices we need, and we emulate the old X
DRM lock with a nested GMainContext without sources.
In the future, mutter-launch will be replaced with the new logind
API currently in development.
https://bugzilla.gnome.org/show_bug.cgi?id=705861
Being a setuid binary, our LD_LIBRARY_PATH is cleared by glibc at
startup, but we need the spawned binary to see it, otherwise
jhbuild doesn't work, so hardcode it using the configured libdir.
https://bugzilla.gnome.org/show_bug.cgi?id=705861
To run mutter as a display server, one needs to acquire and
release the DRM master, which is only possible for root, so
we take advantage of weston-launch, a small setuid helper binary
written for the weston project. We import our own slightly
modified copy of it, because weston-launch only launches weston,
for security reasons.
https://bugzilla.gnome.org/show_bug.cgi?id=705861
Modify all visible instances of mutter with mutter-wayland
(libraries, folders, pkgconfig, etc.), so that the wayland
branch can be installed alongside the usual X11 mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=705497
In the wayland branch of mutter, we want to build a wayland version
of the mutter libraries, and that's much easier if we just build
wayland support unconditionally.
The define is kept to avoid a huge diff, but should be removed
in a later patch.
Also, wayland support can still be disable at runtime, by
launching mutter without the --nested switch.
https://bugzilla.gnome.org/show_bug.cgi?id=705497
To allow other clients (gnome-session, gnome-settings-daemon)
to monitor user activity, introduce a DBus interface for the
idle monitor inside mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=706005
When running as a wayland compositor, we can't use the xserver's
IDLETIME, because that's updated only in response to X events.
But we have all the events ourselves, so we can just run the timer
in process.
https://bugzilla.gnome.org/show_bug.cgi?id=706005
Under X, we need to use XFixes to watch the cursor changing, while
on wayland, we're in charge of setting and painting the cursor.
MetaCursorTracker provides the abstraction layer for gnome-shell,
which can thus drop ShellXFixesCursor. In the future, it may grow
the ability to watch for pointer position too, especially if
CursorEvents are added to the next version of XInput2, and thus
it would also replace the PointerWatcher we use for gnome-shell's
magnifier.
https://bugzilla.gnome.org/show_bug.cgi?id=705911
Instead of keeping a forest of if backend else ..., use a subclass
and virtual functions to discriminate between XRandR and the
dummy backend (which lives in the parent class togheter with the
common code)
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Add a new object, MetaMonitorConfig, that takes care of converting
between the logical configurations stored in monitors.xml and
the HW resources exposed by MonitorManager.
This commit includes loading and saving of configurations, but
still missing is the actual CRTC assignments and a default
configuration when none is found in the file.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
