If the wayland surface isn't available yet when we process the
WL_SURFACE_ID ClientMessage, we schedule a later function to try the
association again after we get a chance to process wayland requests.
This works fine except on cases where the MetaWindow already had a
previous surface attached (i.e. when the xwindow is reparented) since
we only break the existing association on the later function which
means that when processing the old surface's destruction we destroy
the MetaWindow and cancel the pending later function leaving us
without a MetaWindow and an invisible surface.
Fix this by detaching the old surface as soon as possible so that the
MetaWindow survives.
https://bugzilla.gnome.org/show_bug.cgi?id=743339
Make a surface roles into objects with vfuncs for things where there
before was a big switch statement. The declaration and definition
boilerplate is hidden behind C macros.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Being a "XWayland window" should be considered equivalent to a role,
even though it is not part of any protocol anywhere. The commit doesn't
have any functional difference, but just makes it clear that an
wl_surface managed by XWayland have the same type of special casing as
surface roles as defined by the Wayland protocol.
As the semantics are more explicit given the role is defined, a comment
explaining why the semantics need to be how they are was added.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
This piece of code hooks in both wl_data_device and the relevant X
selection events, an X11 Window is set up so it can act as the clipboard
owner when any wayland client owns the selection, reacting to
SelectionRequest events, and returning the data from the wayland client
FD to any X11 requestor through X properties.
In the opposite direction, SelectionNotify messages are received,
which results in the property contents being converted then written
into the wayland requestor's FD.
This code also takes care of the handling incremental transfers through
the INCR property type, reading/writing data chunk by chunk.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
The stop function currently manually constructs the lock
filename from the display number and also calls unlink
on the same, already known lock filename from the manager
struct.
This commit gets rid fo the manual construction in favor
of the saved lock filename.
https://bugzilla.gnome.org/show_bug.cgi?id=748380
The start function has a few exit paths that need to
perform clean up of the lock file.
This commit consolidates those exit paths at the end
using an out label and gotos.
https://bugzilla.gnome.org/show_bug.cgi?id=748380
since commit 8c16ac47c1, we started
creating the login screen on display 1024 instead of display 0.
This defeats this logic in try_display:
display++;
/* If display is above 50, then something's wrong. Just
* abort in this case. */
if (display > 50)
In practice it doesn't matter much since we only have one login
screen in most setups, but we should still fix the bug.
This commit introduces a separate counter to keep try of 50 tries,
rather than assuming "display number == number of tries".
https://bugzilla.gnome.org/show_bug.cgi?id=746545
The original code in Weston that this was ported from returned an errno,
not a boolean, so we were inadvertently returning TRUE here during an
error path. Fix that up.
In 3.16, GDM keeps a login screen running on vt1.
This login screen starts an Xwayland instance.
Since it's the first X server to start, it gets
the prized :0 display number.
This commit works around that problem, for now,
by having GDM's display number start at 1024.
https://bugzilla.gnome.org/show_bug.cgi?id=746295
Windows can be freed at some point after they are unmanaged - because
there is an effect in progress, because a language binding is holding
a reference. Therefore, we need to clean up the later to associate
the xwayland and wayland windows deterministically in an "unamanaged"
handler.
https://bugzilla.gnome.org/show_bug.cgi?id=736694
g_idle_add() makes no guarantee about when it will be run - if Mutter
is busy drawing and blocking glXSwapBuffers() it could happen only
minutes later. Use meta_later_add (META_LATER_BEFORE_REDRAW) instead -
this will deterministically be run after the Wayland socket is read
from but before the next frame is painted.
https://bugzilla.gnome.org/show_bug.cgi?id=736694
If we attach to a MetaWindow that disappears before the idle fires,
we'll notice that we can't associate the window properly again and
try to access data on the MetaWindow struct, which might crash.
Install a weak ref that ties the lifetime of the idle to the lifetime
of the MetaWindow.
It seems every GTK+ app does this for some reason at startup. This
is really unfortunate, since we'll have to create and destroy a new
MetaWindow really quickly.
The latest Xorg / Xwayland has support for -displayfd being used
in conjunction with an explicit display number. Use that to know
when the X server is ready, rather than UNIX signals, because
they're UNIX signals.
Since we get the ClientMessage after the surface is created, there's
no good way to synchronize the two streams. In this case, what we
need to do is delay the surface commit until after we get the
ClientMessage. Ideally, we'd be using a better surface system overall
where committing the surface didn't depend on what type it is, but
oh well, this is a good short-term hack for now.
This is effectively the same, but since we lose the xserver.xml protocol
in the new XWayland DDX, we have to use SIGUSR1 anyway, so might as well
switch over now.
The make_toplevel / window_unmanaging interface has never made
a lot of sense to me. Replace it with set_window, which does
effectively the same thing.
It's still not perfect in the case of XWayland, but I don't think
XWayland will ever make me happy.
We need a MetaWaylandSurface to build a MetaSurfaceActor, but
we don't have one until we get the set_window_xid() call from
XWayland. On the other hand, plugins expect to see the window
actor right from when the window is created, so we need this
empty state.
Based on a patch by Jasper St. Pierre.
This time, to make way for MetaSurfaceActorEmpty. This also fixes
destroy effects as a side effect. It still has issues if we try
to re-assign an actor that's already toplevel (e.g. somebody
re-popping up a menu that's already being destroyed), but this
will be fixed soon.
The idea here is that MetaWindowActor will do the unparenting of
the surface actor when it itself is destroyed. To prevent bad issues
with picking, we only make the surface actor reactive when it's
toplevel.
Use our new "surface_mapped" field to delay the showing of XWayland clients
until we have associated together the window's XID and the Wayland surface ID.
This ensures that when we show this window to the compositor, it will properly
use the Wayland surface for rendering, rather than trying to use COMPOSITE and
crash.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
To properly resize clients, we need to send them configure events
with the size we computed from the constraint system, and
then check if the new size they ask is compatible with
our expectation.
Note that this does not handle interactive resizing yet, it
merely makes the API calls work for wayland clients.
https://bugzilla.gnome.org/show_bug.cgi?id=707401
Add MIN(...) with the interface version actually implemented
to all resource constructor, so that we never risk seeing requests
we don't implement (and consequently segfault)
https://bugzilla.gnome.org/show_bug.cgi?id=707851
It is a very bad idea in a glib program (especially one heavily
using glib child watching facilities, like gnome-shell) to handle
SIGCHLD. While we're there, let's also use g_spawn_async, which
solves some malloc-after-fork problems and makes the code generally
cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=705816
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>
