If the client doesn't set a geometry using xdg_shell, we'll compute its
geometry based on its surface and subsurfaces.
Yet, we translate that as a window (re)size only when there is a pending
geometry, that we don't have when we computed the geometry by ourself.
Make sure we set the pending new geometry flag when computing the
geometry when it actually changed.
https://bugzilla.gnome.org/show_bug.cgi?id=782213
A client can still commit state to a destroyed subsurface. It wont
update anything on the screen, since the subsurface will not be
visible, but mutter should still handle it and not crash.
https://bugzilla.gnome.org/show_bug.cgi?id=781391
This commit adds support for rendering onto enlarged per logical
monitor framebuffers, using the scaled clutter stage views, for HiDPI
enabled logical monitors.
This works by scaling the mode of the monitors in a logical monitors by
the scale, no longer relying on scaling the window actors and window
geometry for making windows have the correct size on HiDPI monitors.
It is disabled by default, as in automatically created configurations
will still use the old mode. This is partly because Xwayland clients
will not yet work good enough to make it feasible.
To enable, add the 'scale-monitor-framebuffer' keyword to the
org.gnome.mutter.experimental-features gsettings array.
It is still possible to specify the mode via the new D-Bus API, which
has been adapted.
The adaptations to the D-Bus API means the caller need to be aware of
how to position logical monitors on the stage grid. This depends on the
'layout-mode' property that is used (see the DisplayConfig D-Bus
documentation).
https://bugzilla.gnome.org/show_bug.cgi?id=777732
If the dnd window ends up lower in the overall stack than the window
it's supposed to fence, the drop might end up in some other window
underneath the expected target window.
Maps and raises the dnd window each time it's shown so that it's always
placed above.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=779800
QT apps reject DnD if the timestamp received in the SelectionRequest
event isn't the same it gave in XdndPosition/Drop client messages.
Bookkeeping and using it in XConvertSelection makes it happy again.
https://bugzilla.gnome.org/show_bug.cgi?id=779757
We are keeping accounting of the focus window as seen by the DnD bridge
right here, so use it instead of the MetaWaylandDragGrab focus as it may
lag behind the real focus (i.e. till the drag source notices the window
and sends XdndEnter to it).
This leads to the window trying to be repositioned more often than
necessary when the drag source takes long to send the XdndEnter client
message, and maybe not repositioned at all if the pointer leaves the
surface while no XdndEnter message was received.
https://bugzilla.gnome.org/show_bug.cgi?id=763246
We currently wait for the selection being cleared by the drag source,
which might not happen on not quite educated clients. This may leave
a stuck XDND grab in the compositor side.
We can actually do a bit better, and clear the grab if:
1) The drag source sent XdndDrop to the wayland drag destination.
2) There's no accepting drag destination and all pointer buttons are
released.
3) As usual, whenever the drag source clears the selection data
https://bugzilla.gnome.org/show_bug.cgi?id=763246
No XDnD events which notify DnD status change comes in Wayland. To emulate XDnD
behavior, MetaDnd checks whether there is a grab or not when the modal window
starts showing. When there is a grab, it processes the raw events from
compositor, and emits DnD signals for plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=765003
Operate on MetaMonitor's instead of MetaOutput's, as the latter may be
only a subset of an actual "monitor" when referring to the physical
computer equipment.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
When a logical monitor constains monitors with different subpixel
ordering, make the wl_output have the subpixel order 'unknown' so that
clients don't make assumptions given only a subset of the monitors of
the given region.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Don't try to mirror the physical dimension, since that's a property of
one of the monitors, not of the logical monitor. Callers are changed to
deal with choosing the monitor to represent the logical monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Instead of storing the logical monitors in an array and having users
either look up them in the array given an index or iterate using
indices, put it in a GList, and use GList iterators when iterating and
alternative API where array indices were previously used.
This allows for more liberty regarding the type of the logical monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Move the last piece of monitor grid getter API to the monitor manager
away from MetaScreen. The public facing API are still there, but are
thin wrappers around the MetaMonitorManager API.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Turning a rectangle into a logical monitor also has nothing to do with
the screen (MetaScreen) so move it to MetaMonitorManager which has that
information.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Let the backend initialize the cursor tracker, and change all call
sites to get the cursor tracker from the backend instead of from the
screen. It wasn't associated with the screen anyway, so the API was
missleading.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
It checks whether a surface is on a given "logical monitor", not
output. Output here is the Wayland name for the same thing, but should
not be confused with MetaOutput.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In preparation for further refactorizations, rename the MetaMonitorInfo
struct to MetaLogicalMonitor. Eventually, part of MetaLogicalMonitor
will be split into a MetaMonitor type.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Use the proposed EGL_WL_wayland_eglstream EGL extension instead of the
file descriptor hack that was used as a temporary solution.
Note that this results in EGL clients will no longer work if they are
running on a Nvidia driver with a version older than 370.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Instead of having a way to determine the type of a buffer, add a
realization step that implicitly detects the buffer type. This makes it
possible to both realize (i.e. creating needed objects from the buffer)
and determine the type at the same time, which may be the only possible
way (for example, the only way to know whether a buffer is a EGLStream
is to create the EGLStream from it).
https://bugzilla.gnome.org/show_bug.cgi?id=773629
When the monitor the surface is on has a scale other than 1, the
coordinate of the window menu popup position needs to be scaled, as it
is reported in logical pixels, while the stage is still in physical
pixels.
https://bugzilla.gnome.org/show_bug.cgi?id=776055
A window manager must select the SubstructureRedirect mask on the root
window to receive the MapRequest from the X11 clients and manage the
windows. Without this event mask set, a window manager won't be able to
map any new window.
The Wayland selection code in mutter can change/clear the event mask on
the requestor window from a XSelectionRequest event when the window is
not managed by mutter/gnome-shell.
A rogue or simply buggy X11 client may send a XConvertSelection() on the
root window and mutter will happily change/clear its own event mask on
the root window, effectively turning itself into a regular X11 client
unable to map any new X11 window from the other X11 clients.
To avoid this, simply check that the requestor window is not the root
window prior to change/clear the event mask on that window.
https://bugzilla.gnome.org/show_bug.cgi?id=776128
Commit 5eb5f72 - wayland: Check surface outputs after mapped state
changes connected the ::mapped signal handler, we need to disconnect it
on destroy to avoid a possible assertion failure in
update_surface_output_state()
https://bugzilla.gnome.org/show_bug.cgi?id=776036
Commit 4295fdb892 made us skip focusing
all xdg_popups instead of just non-grabbing ones as intended. This
means that when unmanaging a window we might select a xdg_popup window
to focus (in meta_stack_get_default_focus_window() ) but then since we
don't actually focus it we go on unmanaging the focused window which
triggers an assertion, as it should.
To avoid this and still fixing bug 771694 we can make use of the
MetaWindow->input property for non-grabbing xdg_popup windows since
their semantics, in this regard, are the same as no input X11 windows.
This way, when unmanaging a focused window while a xdg_popup is up,
we'll either give focus to the xdg_popup or not select the popup at
all to be focused if it's non-grabbing.
https://bugzilla.gnome.org/show_bug.cgi?id=775986
This reverts commit 989ec7fc60.
We now rely on accurately knowing if a window moved and/or resized in
meta_window_move_resize_internal() so the wayland implementation can't
lie any longer.
https://bugzilla.gnome.org/show_bug.cgi?id=770345
This commit adds for a new type of buffer being attached to a Wayland
surface: buffers from an EGLStream. These buffers behave very
differently from regular Wayland buffers; instead of each buffer
reperesenting an actual frame, the same buffer is attached over and
over again, and EGL API is used to switch the content of the OpenGL
texture associated with the buffer attached. It more or less
side-tracks the Wayland buffer handling.
It is implemented by creating a MetaWaylandEglStream object, dealing
with the EGLStream state. The lifetime of the MetaWaylandEglStream is
tied to the texture object (CoglTexture), which is referenced-counted
and owned by both the actors and the MetaWaylandBuffer.
When the buffer is reattached and committed, the EGLStream is triggered
to switch the content of the associated texture to the new content.
This means that one cannot keep old texture content around without
copying, so any feature relying on that will effectively be broken.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Add support for inverted Y Wayland buffers. OpenGL textures are by
default inverted, so adding support for EGL_WAYLAND_Y_INVERTED_WL
effectively means adding support for non-inverted, which makes the
MetaShapedTexture apply a transformation when drawing only when querying
EGL_WAYLAND_Y_INVERTED_WL resulted in the response "EGL_FALSE".
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Don't rely on the Cogl layer having Wayland specific paths by
determining the buffer type and creating the EGLImage ourself, while
using the newly exposed CoglTexture from EGLImage API. This changes the
API used by MetaWaylandSurface to make the MetaWaylandBuffer API be
aware when the buffer is being attached. For SHM and EGL buffers, only
the first time it is attached will result in a new texture being
allocated, but later for EGLStream's, more logic on every attach is
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Similarly to Weston (where this code originated), there were two errors
in the X11 lockfile handling.
Firstly, after reading 11 characters from the lock file (which could
have been placed by any process), there was no guarantee of
NUL-termination, meaning strtol could've theoretically run off the end
of the string.
Secondly, whilst writing the new lock, the trailing NUL byte was not
correctly accounted for. The size passed as an input to snprintf takes
the maximum size of the string including the trailing NUL, whilst the
return (and the input to write) gives the actual size of the string
without the trailing NUL.
The code did attempt to check the return value, however snprintf returns
the size of the _potential_ string written, before snprintf culls it, so
this was off by one, and the LF was not being written.
Signed-off-by: Daniel Stone <daniels@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=774613
Stylus configuration (stylus buttons, pressure) was handled
at the very high level, doing the button and pressure translations
right before sending these to wayland clients.
However, it makes more sense to store these settings into the
ClutterInputDeviceTool itself, and have clutter apply the config
at the lower level so 1) the settings actually apply desktop-wide,
not just in clients and 2) X11 and wayland may share similar
configuration paths. The settings are now just applied whenever
the tool enters proximity, in reaction to
ClutterDeviceManager::tool-changed.
This commit moves all handling of these two settings to
the clutter level, and removes the wayland-specific paths
https://bugzilla.gnome.org/show_bug.cgi?id=773779
And remove the wayland-specific handling. This works for both Wayland and
X11 (provided the compositor receives pad events through a passive grab
there).
https://bugzilla.gnome.org/show_bug.cgi?id=773779
The keyboard focus semantics for non-grabbing xdg_shell v6 popups is
pretty undefined.
Same applies for subsurfaces, but in practice, subsurfaces never receive
keyboard focus, so it makes sense to do the same for non-grabbing
popups.
https://bugzilla.gnome.org/show_bug.cgi?id=773210
We shouldn't cancel the pointer grab when there is a compositor grab,
since that'd break things like drag-n-drop via the overview and
alt-tabs.
The original reason for cancelling the pointer grab on compositor grabs
was to avoid a re-entry when a compositor grab was activated while
there was an active pointer constraint grab. The re-entry would happen
when the compositor grab cleared the pointer focus. Clearing the focus
would trigger the pointer constraint to be deactivated, which would end
its grab. Ending the grab would reset the grab to the default one, which
could focus the same surface again, triggering the constraint to
re-enable before it finished disabling.
This is now avoided because the default grab handler is now aware of
compositor grabs, and won't override the cleared pointer focus until
the compositor grab ends.
https://bugzilla.gnome.org/show_bug.cgi?id=772914
Teach the default grab about compositor grabs (i.e.
display->event_route) so that it can avoid setting a pointer focus when
after the compositor grab actively unset the pointer focus.
https://bugzilla.gnome.org/show_bug.cgi?id=772914
When disabling the device/capability, we can't rely on cancelled events
being emitted timely, because the capability will be already disabled by
then, all touches must be cancelled immediately then.
https://bugzilla.gnome.org/show_bug.cgi?id=772929
When the monitor is scaled (i.e. HiDPI scaling) the placement coordinates
ere still in unscaled xdg_surface window geometry coordinate space when
used to place the window. Fix this by scaling the coordinates by the
monitor scale of the parent toplevel window before using them.
https://bugzilla.gnome.org/show_bug.cgi?id=771841
As meta_window_place_with_placement_rule will trigger a configure event
being sent ensure that the popup is placed on the correct monitor first
to ensure the right scale factor is applied.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=771841
Directly set the monitor of the toplevel window for the popup to avoid
the change not being applied due to later constraints calculation.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=771841
Always use the monitor of the toplevel surface's window, so that the
popup menu and the parent will always have the same scale. This fixes
the dimensions sent in the xdg_popup configure event.
https://bugzilla.gnome.org/show_bug.cgi?id=771841
When Xwayland confines, the surface dimensions will include the server
side window manager decorations. We don't want the decorations to be
included in the constraint region so intersect the calculated input
region with the parts of the buffer rect that is not part of the window
frame.
https://bugzilla.gnome.org/show_bug.cgi?id=771859
Put the conditions for enabling a pointer constraint in a helper
function, and use that in both maybe_enable() and maybe_remove(). The
constraint region checking is still only done in maybe_enable()
however.
This changes the conditions for maybe disabling the constraint on focus
change and other trigger points, namely it makes constraints by Xwayland
not disable when they shouldn't due to the constraining window being an
override-redirect window.
https://bugzilla.gnome.org/show_bug.cgi?id=771859
When the grab is cancelled, for example because of an Alt-tab, VT
switch etc, disable or remove (depending on the constraint type) the
constraint. This avoids a re-entry issue when the focus is returned and
the focus listener tries to re-enable a disabled constraint.
https://bugzilla.gnome.org/show_bug.cgi?id=771859
Dismiss the popup when the grab is cancelled, so that if the grab is
ended for whatever reason (such as VT switching or the last pointer
being disconnected), it doesn't try to end the grab when it isn't
active.
This fixes a crash when VT switching back and forth while a popup grab
is active.
https://bugzilla.gnome.org/show_bug.cgi?id=771858
Previously a grab could suddenly end without the grabber knowing
anything about it. Some grabs assume they won't suddenly end without
notice, and can use then new 'cancel' vfunc to be notified.
Currently a grab is cancelled when a new one is started (i.e. in
meta_wayland_pointer_grab_start()), when a non-popup compositor wide
event route is initiated, and when the seat looses the pointer
capability.
https://bugzilla.gnome.org/show_bug.cgi?id=771858
Instead of using meta_wayland_pointer_end_grab() which focuses the new
grab, add a new helper mean to be used to reset the grab state without
changing the pointer focus. When using this function, the call site is
supposed to explicitly manage focus.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
Make the caller of focus setting check whether there is a pointer to
update the focus state of. It makes it more obvious what to expect, as
the call would be a no-op in when no pointer is present.
Grabbing is still allowed without the presence of a pointer because it
is used by popups even on touch-only systems.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
Make the caller of focus setting and grab starting check whether there
is a keyboard to update the focus state or start grabbing. It makes it
more obvious what to expect, as the call would be a no-op in when no
keyboard is present.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
The variable name 'l' usually refers to a GList iterator, but here it's
just a short hand for a specific list. Stop using this shorthand, since
it just makes it harder to read what list is used.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
In order to kill a window, on both X11 and wayland we first try to
kill(3) the corresponding process, so we can add the newly added
get_client_pid() method to share that code.
https://bugzilla.gnome.org/show_bug.cgi?id=772613
It is often useful to identify the client process that created
a particular window, however the existing meta_window_get_pid()
method relies on _NET_WM_PID, which is only available on X11 and
depends on applications to set it correctly (which may not even
be possible when the app runs in its own PID namespace as Flatpak
apps do). So add a get_client_pid() method that uses windowing
system facilities to resolve the PID associated with a particular
window.
https://bugzilla.gnome.org/show_bug.cgi?id=772613
Previously the focus was reset implicitly by a memset() on the whole
MetaWaylandPointer struct. When MetaWaylandPointer was turned into a
GObject, this was not possible any more, and the focus was not updated
properly.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
There may be other windows managing selection whose events are seen in
our GDK event filter, like st-clipboard in gnome-shell, we should in
that case not interfere on Selection/SelectionRequest events that are
not meant for us.
This fixes an odd feedback loop where requesting clipboard contents from
wayland results in a XConvertRequest call and a SelectionRequest event
that is interpreted by mutter as a request from another X11 client, so
the current data source is poked for content, which happens to be the
X11 bridge, which does a XConvertRequest to get contents... This is only
broken after the many nested async operations create enough pipes and
cancellables to run out of fds.
Adding checks to ensure only events meant to our "selection owner"
window are managed prevent this unintended loop to happen in the first
place.
https://bugzilla.gnome.org/show_bug.cgi?id=760745
A xdg_popup, when active, always has a parent surface. However, a popup
created may immediately become invalid, for example when it is not
granted a grab, in which case it won't be assigned a parent since it
will never be mapped.
This case needs to be handled elsewhere, as one cannot assume a
MetaWaylandXdgPoup that is processed (via wl_surface commit handling
etc) will have a parent_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=771495
If a X11 client would initiate a Xdnd session after it had lost pointer
focus (for example when the Xdnd event starting the drag happens after
the implicit pointer grab is already broken due to the button being
released), just end the drag operation instead of dereferencing the
non-existing focus surface.
Also avoid using a native Wayland surface as a drag origin, as that can
never happen, but allow any arbitrary Xwayland client, since there is
no way to find out the actual drag origin.
https://bugzilla.gnome.org/show_bug.cgi?id=770940
We cannot check 'has-target' or 'has-seat' when verifying a
wl_data_offer.finish request is valid or not, since the source may have
effected 'has-target' or whether theh source has a seat or not when the
finish request was already on the wire.
Instead of checking against the source state, keep track whether the
required operations has been done on the offer in question (i.e.
whether an action has been sent, or a mime type been accepted).
This fixes incorrectly raised error when dragging from gtk+'s testdnd
via Xwayland onto gtk+'s testdnd using Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=770937
Since wl_surface.set_buffer_transform() is not supported, until it is
added, pretend outputs are never transformed, so that clients are less
likely to attach pre-transformed buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=770672
Also maybe remove a constraint when the pointer focus changes. This is
needed because when Xwayland has a constraint focus may change, the
constraint object will not receive a 'appears-focused' event on its
window since it never changed.
This happens for example when an override-redirect window (which never
appears focused) holds the constraint, and alt-tab happens. In this case
focus changes, but from the constraint's point of view, none of the
windows it knows about changed its focus appearance.
https://bugzilla.gnome.org/show_bug.cgi?id=771345
Instead of initializing the default grab when the device class is
enabled, initialize it on object initialization. This way other device
classes can still grab the pointer, as if there was one. This may be
useful for example if a touch grab is active and a mouse is connected.
This also makes it possible for popup grabs, which currently use a
pointer grab for controlling, to be triggered by touch devices, while
still holding an active pointer grab.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
Make the device <-> seat association permanent, and move it into
MetaWaylandInputDevice. A device will never be disassociated with a
seat, so there is no point in unsetting it.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
Add a new object class, MetaWaylandInputDevice, and make all device
classes (pointer, keyboard, touch) inherit it. In the future common
functionality may be placed there.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
Meant to replace explicitly checking whether a
MetaWaylandPointer/MetaWaylandKeyboard/MetaWaylandTouch has a seat or
not to determine whether they are supposed to be active or not.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
Since Xwayland surface constraints might need to enable not only
because the constrained window appears focused, add a pointer focus
listener and try constrain whenever the pointer focus changes. It's
still required that a Xwayland window is focused to activate.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
Xwayland surfaces are special, because there is no reliable way to
associate a window with its corresponding "application window" (the one
which was given focus). Many games that require pointer warping and
confining pointer grabs may for example create override redirect windows
and make that window receive input even though it will never be the
focus window.
Therefore, the requirements for enabling a constraint for a wl_surface
from Xwayland needs to be relaxed in order. This commit changes
Xwayland wl_surfaces to not require being focused to be enabled; it'll
be enabled as long as any X11 window is the one with focus.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
Require pointer focus to enable, otherwise we can't guarantee it has
entered the surface, as the focus may have been given to a subsurface,
override-redirect or other sub window covering the surface that was
requested to have o pointer constraint.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
Add a signal that is emitted when the pointer focus surface of the
pointer device changes. This will later be used by the pointer
constraints to maybe enable pointer constraints when a surface receives
pointer focus.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
For Xwayland, a newly created wl_surface and X11 Window pair may not be
immediately associated, but Xwayland may still request a pointer
constraint on some of its wl_surface's. Handle the situation by
postponing maybe enabling the constraint until the window and surface
has been associated.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
Move the MetaWaylandSurface::destroy signal before starting the actual
destruction, in wl_surface_destructor, so that all fields (e.g. surface
role) are intact when the listeners are invoked.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
When the Xwayland wl_surface is created, it may not yet be possible to
associate it with the corresponding X11 Window. Add a signal to the
Xwayland role to communicate with any interested parties.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
If a client would attach a buffer to a surface, commit, destroy the
buffer and then later set the surface as a cursor, there will be no
wl_buffer available to be used by the cursor role. Instead of
dereferencing the non-existing wl_buffer resource, handle this situation
by logging a warning and treating a prematurely destroyd wl_buffer as if
no buffer had been attached.
https://bugzilla.gnome.org/show_bug.cgi?id=770992
Implement min/max size request from xdg-shell-v6 and plug it into the
existing code so that windows with fixed size cannot be tiled/maximized
in Wayland just like in X11.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=770226
The seat capability updating is synchronous, but input events are
asynchronous (first queued then emitted). This means we may end up in a
situation where we from libinput first may receive a key event,
immediately followed by a device-removed event. Clutter will first
queue the key event, then remove the device, immediately triggering the
seat capability removal.
Later, when the clutter stage processes the queued events, the
previously queued key event will be processed, eventually making it
into MetaWaylandSeat. Before this patch, MetaWaylandSeat would still
forward the key event to MetaWaylandKeyboard, even though it had
'released' it. Doing this would cause referencing potentially freed
memory, such as the xkb state that was unreferenced when the seat
removed the capability.
In order to avoid processing these lingering events, for now, just drop
them on the floor if the capability has been removed.
Eventually, the event queuing etc needs to be redesigned to work better
when used in a Wayland compositor, but for now at least don't access
freed memory.
https://bugzilla.gnome.org/show_bug.cgi?id=770727
We may be assigned multiple times, if the surface is assigned to be a
cursor surface multiple times. Each time e.g. wl_pointer.set_cursor is
called, we'll be assigned.
While the role object exists, we'll handle buffer use count even when
we are not actively assigned, thus we should only handle the initial
assignment use count bump when constructing, so that we don't increase
it when reassigned, where the wl_resource may already have been
released.
https://bugzilla.gnome.org/show_bug.cgi?id=770402
For backend handled cursors, if nothing else changes on the clutter
stage, we end up not sending out frame callbacks since clutter doesn't
draw a new frame.
To fix this, we'll keep cursor surfaces' frame callbacks separate from
other surfaces' and trigger them from the new
MetaCursorRenderer::cursor-painted signal which handles both software
and hardware cursors.
https://bugzilla.gnome.org/show_bug.cgi?id=749913
If cogl fails to create a texture from the client's given buffer,
mutter would raise a fatal error and terminate.
As a result, a broken client might kill gnome-shell/mutter and take the
entire Wayland session with it.
Instead of raising a fatal error in this case, log the cogl error
message and send the client an OOM error, so mutter/gnome-shell can
survive an unsupported buffer size.
https://bugzilla.gnome.org/show_bug.cgi?id=770387
Windows from Xwayland still needs to use the Wayland path, but is
represented an MetaWindowX11, thus the abstraction introduced in
"window: Make meta_window_has_pointer() per protocol implemented"
is wrong. Lets turn back time, and reconsider how this can be
abstracted more correctly in the future.
This reverts commit 9fb891d216.
Rely on the actor surface role's commit function for queuing frame
callbacks. This also makes the surface actor state synchronization work
again, which was broken by 'wayland: Sync surface actor state in actor
role commit handler'.
https://bugzilla.gnome.org/show_bug.cgi?id=770131
Don't check whether the surface of the role has a window, but whether
the corresponding toplevel surface has a window. This is necessary to
make subsurfaces not always early out.
https://bugzilla.gnome.org/show_bug.cgi?id=770131
There is nothing stopping a subsurface from commiting its state before
its parents role has been assigned. Thus, we need to handle
meta_wayland_surface_get_toplevel() returning NULL for subsurfaces even
on commit.
Make sure to always call the parent role commit vfunc, so that they can
handle updating their state properly.
This means other places need to handle the situation where
surface->window is NULL on commit. This may for example happen when the
parent of a modal dialog is unmapped or NULL is attached to a
wl_shell_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=769936
Port the xdg_shell implementation to use the unstable v6 protocol. This
includes:
- making xdg_surface a generic base interface for xdg_shell surface
roles
- create a xdg_toplevel role replacing the old xdg_surface
- change the xdg_opup role to be based on xdg_surface
- make xdg_popup not grab by default
- add support for xdg_positioner
https://bugzilla.gnome.org/show_bug.cgi?id=769936
Emit a 'configure' signal before configuring the role. This will enable
extensions to send its own configure events before the role is
configured.
https://bugzilla.gnome.org/show_bug.cgi?id=769936
Add support for assigning a window a custom window placement rule used
for calculating the initial window position as well as defining how a
window is constrained.
The custom rule is a declarative rule which defines a set of parameters
which the placing algorithm and constrain algorithm uses for
calculating the position of a window. It is meant to be used to
implement positioning of menus and other popup windows created via
Wayland.
A custom placement rule replaces any other placement or constraint
rule.
https://bugzilla.gnome.org/show_bug.cgi?id=769936
Allow passing parameters (only GObject parameters supported for now) so
that role assignment can affect the paremeters set during construction.
If a role was already assigned when assigning, the passed parameters
are set using g_object_set_valist().
https://bugzilla.gnome.org/show_bug.cgi?id=769936
This commits adds support for exporting xdg_surface handles via
xdg_exporter and importing them via xdg_importer.
This bumps the required wayland-protocols version to 1.6.
https://bugzilla.gnome.org/show_bug.cgi?id=769786
Meant to be used by users of MetaWaylandSurface's that need to know
when the surface was unmapped. So far only emitted by shell surfaces
(surfaces with MetaWindow's).
https://bugzilla.gnome.org/show_bug.cgi?id=769786
We do some things when binding to a socket fails (closing the fd,
logging, unlinking files, ...) those might affect errno in some
or other way, so it might no longer be EADDRINUSE even if we later
try to make those non fatal.
It seems better to check errno soon after the failure, and don't
rely on it in any way at a later point. All error paths in
bind_to_abstract_socket() also have early logging, which also might
help figure out better the point of failure when the socket fails
to be created.
https://bugzilla.gnome.org/show_bug.cgi?id=769578
We only use a handful of the attributes set, so lets stop pretending
that things are initialized for a reason. Eventually we should stop
using XWindowAttributes in the generic MetaWindow creation path.
https://bugzilla.gnome.org/show_bug.cgi?id=769070
If the compiler cannot figure out that the condition for setting
the dev variable is the same as the condition for accessing it,
it will complain about potential uninitialized use.
We must lookup the mode switch serial for the group where the button
belongs to. Also, avoid the changes if the client requests setting
the feedback for buttons owned by the compositor.
We assumed that each group could only have 1 strip and/or ring, because
accounting is performed per group, so we could not assume the real
index for anything above 1. Get rid of this restriction, now that
MetaWaylandTabletPad does its own accounting of rings/strips, alongside
groups.
This is best for 2 reasons:
- It's feels cleaner doing first creation of rings/strips and then
the group assignment. The other option is making groups iterate
other all rings/strips and selectively skip those not meant for
it, which sounds somewhat redundant.
- Some minimal accounting of rings/strips without group restrictions
is needed for meta_wayland_tablet_pad_get_label().
The rings/strips memory is now owned by MetaWaylandTabletPad instead
of groups, which is sort of meaningless since all are meant to go
at the same time.
All pads will share the same focus than the keyboard, so this means that:
- The focus changes in-sync for keyboard and all pad devices, and
- Newly plugged pads will be immediately focused on that same surface
This object represents the collection of buttons, strips and rings
in a tablet pad. All the objects created (pad, strips and rings)
share a common focus surface and have the same lifetime.
This is now separated from the generic cursor one. This means that wl_surfaces
can't be shared across wl_pointer and wp_tablet_tool. This is a change in
tablet protocol v2.
This is a simple subclass of MetaWaylandSurfaceRoleCursor, mostly
so we can distinguish by GType, the methods in the parent class
still apply and are useful.
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
