Using clutter API to transform coordinates is only accurate right
after a clutter layout pass but this function is used e.g. to deliver
pointer motion events which can happen at any time. This isn't a
problem for wayland clients since they don't control their position,
but X clients do and we'd be sending outdated coordinates if a client
is moving a window in response to motion events.
https://bugzilla.gnome.org/show_bug.cgi?id=768039
The call fetching the targets mistakenly used the timestamp meant
to back up the TIMESTAMP atom (hence, it's the timestamp at which
the selection is *owned* by the compositor, on behalf of a wayland
client).
This timestamp is actually only updated when the compositor gets
to own the selection, so it's a randomly late timestamp to retrieve
the TARGETS atom content, which certain clients might end up
ignoring.
https://bugzilla.gnome.org/show_bug.cgi?id=768007
The result flag needs to be marked as moved even for pending moves,
otherwise the window's unconstrained_rect doesn't get updated in
meta_window_move_resize_internal() and the anchor grab is wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=764180
The X11 backend uses EWMH's _NET_WM_PID to get the PID of an offending
client and kill its PID to force the client to terminate.
The Wayland backend is using a Wayland protocol error, but if the client
is hung, that will not be sufficient to kill the client.
Retrieve the client PID under Wayland using the Wayland client API
wl_client_get_credentials() and kill() the client the same way the X11
backend does.
https://bugzilla.gnome.org/show_bug.cgi?id=767464
xdg-shell allows desktop environments to extend the list of states
within a given range.
Use this possibility to add a new state for tiled so that gtk+ can
benefit from this.
https://bugzilla.gnome.org/show_bug.cgi?id=766860
This makes us behave the same both on bind and when an output
changes. In particular, we were not sending scale and done events on
output changes. We were also unconditionally sending mode events on
output changes even though these should only be sent if there is an
actual mode change.
https://bugzilla.gnome.org/show_bug.cgi?id=766528
If we try to send notify event (either from surface_state_changed()
or from meta_window_wayland_move_resize_internal()),
we will crash, because we don't have a sufrace anymore.
There's no reason why to resize the window that is being
unmanaged anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=751847
meta_wayland_tablet_manager_update()/handle_event() are called before
the MetaWaylandSeat counterparts. If the event comes from a device
managed by MetaWaylandTabletManager, the event will be exclusively handled
by it.
Each tool has its own MetaCursorRenderer instance, which is created/destroyed
upon proximity, and possibly updated through focus and set_cursor calls in
between.
This struct keeps the server side information for the wl_tablet_manager
global resource. It keeps the clients requesting this interface, and
does keep track of the plugged tablet devices, so
wl_tablet_manager.device_added is emitted on the expected clients.
Move into a standalone meta-wayland-surface-role-cursor.[ch], and
make generic enough to work for pointe and additional (eg. tablet)
cursors.
Most notably, the sprite is now kept completely internal to the
cursor role, and updates are routed through the given
MetaCursorRenderer (which may be the default one for the pointer,
or something else).
The way cursor updates after cursor surface destruction has also
been reworked, the pointer will just keep track of the last cursor
surface, so older surfaces being destroyed don't trigger pointer
rechecks/updates.
There's places where it would be convenient to add listeners to this,
so add the signal. The signal is only emitted once during destruction,
it is convenient for the places where we want notifications at a time
the object is still alive, as opposed to weak refs which notify after
the fact.
Separate "xdg_surface", "xdg_popup" and "xdg_shell" related functions
into three sections. Prior to this, the "xdg_shell" part was a bit all
over the place.
https://bugzilla.gnome.org/show_bug.cgi?id=763431
Dismiss the popup when the parent is destroyed, and do this in the
destructor of the parent object. This makes the parent destory listener
unnecessary, since we already handle the parent child unlinking
explicitly in the object destructor.
https://bugzilla.gnome.org/show_bug.cgi?id=763431
Instead of relying on destroy signals attached to the corresponding
role object, let the roles explicitly dismiss the popup when it should
be dismissed.
https://bugzilla.gnome.org/show_bug.cgi?id=763431
Add a bridge between the MetaWaylandPopup object and the corresponding
popup surface role. This bridge replaces communicating dismissed and
unmapped popup events.
https://bugzilla.gnome.org/show_bug.cgi?id=763431
Before this commit, on Wayland, the buffer rect would have the size of
the attached Wayland buffer, no matter the scale. The scale would then
be applied ad-hoc by callers when a sane rectangle was needed. This
commit changes buffer_rect to rather represent the surface rect (i.e.
what is drawn on the stage, including client side shadow). The users of
buffer_rect will no longer need to scale the buffer_rect themself to
get a usable rectangle.
https://bugzilla.gnome.org/show_bug.cgi?id=763431
A large part of meta_wayland_surface_apply_window_state() was only
relevant for xdg_surface. Make this more obvious by splitting it up,
moving the relevant parts to the relevant roles.
https://bugzilla.gnome.org/show_bug.cgi?id=763431
Move xdg_shell related functionality to a new meta-wayland-xdg-shell.c
and wl_shell related functionality to a new meta-wayland-wl-shell.c,
and adapt role object tree.
Common functionality related to the surface being drawn as a
MetaSurfaceActor was moved to a MetaWaylandSurfaceRoleActorSurface role.
The subsurface role GObject is made to inherit the actor surface GObject.
Shell surface hooks (configure, ping, close, popup done) were added to
a MetaWaylandSurfaceRoleShellSurface GObject which inherits the
surface actor role GObject.
The shell surface roles (xdg_surface, xdg_popup, wl_shell_surface) are
made to inherit the shell surface GObject and implement the relevant
API.
https://bugzilla.gnome.org/show_bug.cgi?id=757623https://bugzilla.gnome.org/show_bug.cgi?id=763431
Leave these checks up to the callers, the only uses of this function
(indirect, through meta_wayland_seat_get_grab_info) are
[wl_shell|xdg]_surface.move/resize/show_window_menu.
In move/resize it makes sense to check for a button being pressed, because
we must expect a button release event. However for xdg_surface.show_window_menu
we 1) don't strictly need further events and 2) we must account for press+release
event pairs being processed at once in the compositor before the client sees
the former.
That is eg. the case of touchpad 2nd/3rd button tap emulation, multifinger
taps will emit the event pair at once, so when the client manages to request
xdg_surface.show_window_menu, it'll be too late in the compositor side, so the
request is ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=764519
A wl_data_device object may be created while it is being focused,
either because the client destroyed it or because the client was
destroyed. Handle this by early out in focus handler vfuncs the case
where it was destroyed, so that we don't corrupt memory and/or cause
segmentation fault.
https://bugzilla.gnome.org/show_bug.cgi?id=765062
If we get a key event but still have pending modifier state changes we
need to send a modifiers event right away so that the key event can be
interpreted by clients correctly modified.
This case could happen when mutter/gnome-shell itself consumes the
modifier key press event such as with the overview key which by
default is triggered on super press.
https://bugzilla.gnome.org/show_bug.cgi?id=748526
The wayland protocol has enough space to send both virtual and real
modifiers on modifiers events which saves clients the work of
resolving virtual modifiers themselves.
https://bugzilla.gnome.org/show_bug.cgi?id=748526
While CoglError is a define to GError, it doesn't follow the convention
of ignoring errors when NULL is passed, but rather treats the error as
fatal :-(
That's clearly unwanted for a compositor, so make sure to always pass
an error parameter where a runtime error is possible (i.e. any CoglError
that is not a malformed blend string).
https://bugzilla.gnome.org/show_bug.cgi?id=765058
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
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
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
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
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
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
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.
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
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
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
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
The wp_pointer_constraints protocol is a protocol which enables clients
to manipulate the behavior of the pointer cursor associated with a seat.
Currently available constraints are locking the pointer to a static
position, and confining the pointer to a given region.
Currently locking is fully implemented, and confining is implemented for
rectangular confinement regions.
What else is lacking is less troublesome semantics for enabling the lock
or confinement; currently the only requirement implemented is that the
window that appears focused is the one that may aquire the lock.
This means that a pointer could be 'stolen' by creating a new window that
receives active focus, or when using focus-follows-mouse, a pointer
passes a window that has requested a lock. This semantics can be changed
and the protocol itself allows any semantics as seems fit.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
