Just like we do for _NET_WM_MOVERESIZE messages on X11, consider
wayland client move/resizes as "frame actions" so that the same
constraints are applied to them, in particular the titlebar visibility
constraint.
https://bugzilla.gnome.org/show_bug.cgi?id=748819
In order for the native cursor renderer to be able to create a hw
cursor in response to wl_pointer.set_cursor(), keep a private use-count
and reference to the active buffer, stopping it from being released
until it is consumed, replaced, or the surface is destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=762828
Whether a surface needs to keep the committed wl_buffer un-released
depends on what role the surface gets assigned to. For example a cursor
role may need an unreleased shm buffer in order to create a hw cursor from
it.
In order to support this, keep a separate reference and use count to
the buffer on behalf of the in the future assigned role, and release
those references after the surface was assigned a role. A role that
needs its own references and use counts, must in its assign function
make sure to add those.
https://bugzilla.gnome.org/show_bug.cgi?id=762828
Each wl_surface.commit with a newly attached buffer should result in
one wl_buffer.release for the attached buffer. For example attaching
the same buffer to two different surfaces must always result in two
wl_buffer.release events being emitted by the server. The client is
responsible for counting the wl_buffer.release events and be sure to
have received as many release events as it has attached and committed
the buffer, before reusing it.
https://bugzilla.gnome.org/show_bug.cgi?id=762828
We can detect that these windows are already fully opaque, so allow them
to unredirect. Allows unredirecting Totem during video playback, giving
a significant speed boost.
This target is set whenever DnD moves towards an area between surfaces.
Although no offer is set and data is actually not read, drag sources
offering this mimetype will be able to behave just like they used to
do in X11.
https://bugzilla.gnome.org/show_bug.cgi?id=762104
We want some initial processing, even if the current focus didn't change.
This could be for example the case of starting DnD too close to the window
edge and out of it. At the point start_drag() is called, the current
pointer focus is already NULL, so set_focus() would simply bail out here.
https://bugzilla.gnome.org/show_bug.cgi?id=762104
On the X11 backend we don't track the pointer position in
priv->current_x/y which remain set to zero. That means we never set
the clutter stage cursor if point 0,0 isn't covered by any monitor
since we return early.
Commit 4bebc5e5fa introduced this to
avoid crashing on the prepare-at handlers when the cursor position
doesn't fall inside any monitor area but we can handle that higher up
in the stack. In that case, the sprite's scale doesn't matter since
the cursor won't be shown anyway so we can skip setting it.
https://bugzilla.gnome.org/show_bug.cgi?id=763159
We currently rely only on MetaWindowActor to update the mask
texture. This isn't good enough since we might get asked to use the
mask (e.g. via meta_shaped_texture_get_image() ) after having a new
texture size but before MetaWindowActor decides to update the mask in
which case we might crash since cogl_texture_new_from_sub_texture()
might fail with an early return such as
Cogl-CRITICAL **: cogl_sub_texture_new: assertion 'sub_x + sub_width
<= next_width' failed
https://bugzilla.gnome.org/show_bug.cgi?id=762639
This commits adds a gtk_surface.present request and its implementation.
The timestamp is assumed to be from some input event that the client
responded to. The timestamps we deal with when managing windows will
usually come from two different clocks: CLOCK_MONOTONIC if they come
from libinput/evdev, or CLOCK_MONOTONIC_COARSE if they come from the
X server.
Luckily these are quite similar, the difference beeing that the X server
timestamps having lower resolution, so we can just pass the timestamps
no matter where they came from and it'll most likely work fine, except
for the race condition described in bug 756272 which might happen here
too until it is properly fixed.
https://bugzilla.gnome.org/show_bug.cgi?id=763295
CSD X11 clients and Wayland clients don't have a window frame drawn by
the compositor to flash. So instead of flashing the whole screen when
configured to just flash the window, flash just the window region.
https://bugzilla.gnome.org/show_bug.cgi?id=763284
Add a system_bell request to gtk_shell. A client can use this to invoke
the system bell, be it aural, visual or none at all. Currently per
window visual bell support is not implemented.
https://bugzilla.gnome.org/show_bug.cgi?id=763284
To support invoking the system bell on Wayland we shouldn't have paths
that fallback to X11. Let the X11 caller deal with the absence of
libcanberra, and change API to not take any X events.
https://bugzilla.gnome.org/show_bug.cgi?id=763284
The gtk_shell protocol used some half baked unstable protocol semantics
that worked by only allowing binding the exact version of the
interface. This hack is a bit too confusing and it makes it impossible
to do any compatible changes without breaking things.
So, instead rename it to include a number in the interface names. This
way we can add requests and events without causing compatibility issues,
and we can later remove requests and events by bumping the number in
the interface names.
https://bugzilla.gnome.org/show_bug.cgi?id=763284
Using the current position to set the origin x/y of the DnD icon
is wrong, it should still be used in order to move the icon besides
the current pointer position though.
Fixes possible drag-start-x/y property constraint warnings when
starting a drag too close to the window edge, and towards outside
of it.
If a MetaWindow's 'appears-focused' state changed to true, but the
window did not have pointer focus, the constraint did not enable. Thus,
make it possible for the user to also click the window to enable it.
https://bugzilla.gnome.org/show_bug.cgi?id=762661
Instead of relying on the keyboard focus surface, use the
'appears-focused' state of the corresponding MetaWindow to determine if
a constraint should enable or not.
https://bugzilla.gnome.org/show_bug.cgi?id=762661
Instead of having MetaWindowWayland having hooks into pointer
constraints subsystem, have the pointer constraints subsystem listen
for the signal itself and enable/disable itself.
https://bugzilla.gnome.org/show_bug.cgi?id=762661
Instead of having a very large region represent an infinitely large
region, use NULL, and use the calculated input region from the
MetaWaylandSurface if the constraint region was not set.
https://bugzilla.gnome.org/show_bug.cgi?id=762661
The when surface->input_region is NULL, it should be interpreted as the
whole surface region. If not, the effective input region is the
intersection of the buffer region and the input region set by
wl_surface.set_input_region. Add
meta_wayland_surface_calculate_input_region() that does this
calculation.
https://bugzilla.gnome.org/show_bug.cgi?id=762661
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.
