The libsn API provides its timestamps in the "Time" X11 type, which is
usually is a typedef for "unsigned long". The type of the "timestamp"
parameter of StartupNotificationSequence is a signed 64 bit integer.
When building on an architecture where a "unsigned long" is not 64 bit,
we'd then pass a 32 bit unsigned integer via a va_list where a signed 64
bit integer is expected causing va_arg to read past the passed 32 bit
unsigned integer.
Fix this by ensuring that we always pass the expected type via the
va_list. Also change the internal timestamp type from time_t (which
size is undefined) to gint64, to avoid any potential overflow issues.
https://bugzilla.gnome.org/show_bug.cgi?id=762763
Since mutter was changed to be D-Bus activatable, the test cases has not
been working when running from inside a GNOME Wayland session. This
commit makes the test work again by ensuring the tests run in a nested
mutter instance.
https://bugzilla.gnome.org/show_bug.cgi?id=763125
If we receive multiple SelectionRequest events, we'll end up replacing the
former WaylandSelectionData at a time when an async read has been issued.
This will cause the cancellation of the previous operation.
But the wayland_data_read() callback will attempt to just remove the
current wayland data again on error, which will not be the one we're
cancelling, so the new operation will just be cancelled too.
Also, cancellation is no longer warned about. As the wayland selection
has been replaced at this time, we can just return here.
https://bugzilla.gnome.org/show_bug.cgi?id=760745
This is necessary for the X11 side to catch up, and unset the primary
selection ownership on our window that represents the wayland side in
X11 selection.
https://bugzilla.gnome.org/show_bug.cgi?id=760745
This is necessary for the X11 side to catch up, and unset the selection
ownership on our window that represents the wayland side in X11 selection.
https://bugzilla.gnome.org/show_bug.cgi?id=760745
We may have released the wl_buffer already when doing this, which means
we should not try to access the wl_buffer content.
Regarding the cursor texture this is not an issue since we can just use
the texture created in apply_pending_state().
The hw cursor however will only be realized if the surface is already
using the the buffer (surface->using_buffer == true). This will, at the
moment, effectively disable hardware cursors for SHM buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=762828
Don't unset the surface->buffer if the associated wl_buffer object is
destroyed. The MetaWaylandBuffer doesn't really only represent a
wl_buffer object, but also the data (texture) created from the given
wl_buffer. Thus, for example destroying a released SHM wl_buffer should
not destroy the MetaWaylandBuffer instance, because the texture may
still be used.
This commit also fixes a race where calc_showing would hide a window
because, at the time of calculation whether it should be showing, the
surface's buffer had been destroyed as described above.
https://bugzilla.gnome.org/show_bug.cgi?id=762716
In destroy_data_offer() there is code to ensure compatibility when
dragging from a v3 wl_data_device to a v2 one, it's however not checking
correctly that this is the DnD drag source. The other path should be
used otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=762878
Add an additional MetaWaylandDataSource implementation for primary selection
sources, and methods to set primary selection offers. Primary selection
sets altogether a different channel than the clipboard selection, those don't
cross in any way.
Also, the bridge for the X11 PRIMARY selection atom has been added, which
adds all the necessary handling to translate primary selection both ways
with wayland and X11 applications.
https://bugzilla.gnome.org/show_bug.cgi?id=762560
This protocol is an internal mirror of the primary selection drafts
being proposed for wayland-protocols. No changes besides prefix/suffix
changes.
https://bugzilla.gnome.org/show_bug.cgi?id=762560
It indirectly triggers expensive operations in gnome-shell
(js/ui/keyboard.js), which turns out too expensive if we happen to operate
the shell simultaneously with 2 devices that will trigger the operations
there.
So just rate limit the signal emission, defer to an idle and just emit
the last device gotten. Worst that will happen is that we may possibly
emit the signal on the same device consecutively.
https://bugzilla.gnome.org/show_bug.cgi?id=753527
If a MetaLater callback queued another MetaLater with a scheduling
later than the one currently being invoked, make it so that the newly
scheduled callback will actually be invoked.
The fact that it doesn't already do this is a regression from
cd7a968093.
https://bugzilla.gnome.org/show_bug.cgi?id=755605
Separate from meta-test-runner which runs metatests testing window
manager operations, a new test program (mutter-unit-tests) is
introduced. This is meant to run unit test like tests on various units
in mutter.
An initial test testing the order of MetaLater callback invokation was
added.
https://bugzilla.gnome.org/show_bug.cgi?id=755605
The constraint may be destroyed before the client destroyes the
protocol object, for example if a oneshot constraint was disabled by
alt-tab. Therefore we need to NULL check the constraint in request
handlers and ignore any requests to defunct objects.
As of "core: start as wayland display server when
XDG_SESSION_TYPE=wayland" it is no longer possible to run a nested
mutter Wayland session on top of another Wayland session. This patch
adds a command line argument to make it possible to force mutter to
start as a nested compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=758658
Add a gtk_shell.set_startup_id request, so the application can communicate
to the compositor the startup id that it received through the
DESKTOP_STARTUP_ID envvar, or other means.
https://bugzilla.gnome.org/show_bug.cgi?id=762268
This is kind of in a middle ground at the moment. Even though it
handles sequences not coming from libsn, they're added nowhere at
the moment, we'll rely on the app launch context being in the x11
side at the moment.
Also, even though we do create internal sequence objects, we keep
exposing SnStartupSequences to make gnome-shell happy, we could
consider making this object "public" (and the sequence objects with
it), things stay private at the moment.
https://bugzilla.gnome.org/show_bug.cgi?id=762268
Since a buffer can be used by multiple surfaces at once,
we need to release the buffer only after all surfaces
are finished with it. Currently we track whether or
not to release the buffer based on the accessible boolean.
This commit changes it to a counter to accomodate multiple
users.
Also, each surface needs to know whether not it is done with
the buffer, so this commit adds a buffer_used boolean to the
surface state.
https://bugzilla.gnome.org/show_bug.cgi?id=761613
We currently track whether or not a buffer can be released early
by looking at the copied_data boolean on the buffer. This boolean
is, practically speaking, always set to TRUE for shm buffers and is
always false otherwise.
We can just as easily check if the buffer is a shm buffer to decide
whether or not to do an early release. That's better from a
theoretical point of view since copied_data assumes a 1-to-1
relationship between surface and buffer, which may not actually hold.
This commit drops copied_data and changes the check to instead see
if the buffer is shm.
https://bugzilla.gnome.org/show_bug.cgi?id=761613
If a broken or naughty application tries set up its windows to create
a loop in the transient relationship, mutter will hang, looping forever
in meta_window_foreach_ancestor()
To avoid looping infinitely at various point in the code, check for a
possible loop when setting the transient relationship and deny the
request to set a window transient for another if that would create a
loop.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759299
meta_wayland_surface_toplevel_commit has a lot of logic to handle
a new buffer getting attached as part of the commit. None of
that code needs to run if there is no new buffer attached.
This commit short-circuits that case.
https://bugzilla.gnome.org/show_bug.cgi?id=761613
If we rely on getting back an input event with the warped pointer
coordinates, we might draw a frame with the old coordinates if we warp
during the paint phase. Avoid that by moving the cursor immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
This patch adds support for confinement regions that are more complex
than a single rectangle. It relies on details about cairo regions not
explicitly in the API in order to generate the outer border of the
region.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
The x/y coordinates of the ClutterInputDevice were not the ones which was
the result of this event but whatever event was queued the last. The
correct coordinates can, however, be found in the event itself, so lets
use those.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
