As per the spec:
- wl_pointer.axis_source determines the current source of
scroll events.
- wl_pointer.axis_stop determines when there's no further
scroll events on the given axis.
- wl_pointer.axis_discrete is emitted on "wheel"
scroll sources, measured in ticks.
- wl_pointer.frame is meant to coalesce events that logically belong
together, e.g. axis events in this case.
Co-Authored-By: Peter Hutterer <peter.hutterer@who-t.net>
https://bugzilla.gnome.org/show_bug.cgi?id=760637
During xwayland initialization we run main loop and dispatch wayland
events, so that xwayland can initialize. If some client during this
phase connects and creates surface, mutter crashes because
it is not initialized yet. If we bind wayland socket after xwayland
is initialized and main loop is not running anymore, no client can
connect to mutter during initialization and that is what we want.
https://bugzilla.gnome.org/show_bug.cgi?id=751845
Use the xdg_shell XML file installed by wayland-protocols instead of
our own copy. This protocol has yet to go through any unstable naming,
but since we had an outdated (though wire compatible) version, some
minor changes were needed.
https://bugzilla.gnome.org/show_bug.cgi?id=758633
Remove our own copy of the pointer gestures protocol, and us the one
installed by wayland-protocols. This also means the new fixed unstable
naming conventions are used for the new version of the protocol, which
is reflected in the change. No functional changes were made, it is only
a rename.
https://bugzilla.gnome.org/show_bug.cgi?id=758633
When running as a native compositor, we can just do that. However, the
previous code must stay for whenever it's run as a X11 client.
Additionally, the fallback switch{} that transforms clutter 1-indexed
buttons into input.h event codes had to be adapted to the change introduced
in clutter commit 83b738c0e, where the 4-7 button range is kept clear for
compatibility with the X11 backend.
https://bugzilla.gnome.org/show_bug.cgi?id=758239
On the wire, Wayland specifies the refresh rate in milliHz. Mutter sends
the refresh rate in Hz, which confuses clients, e.g. weston-info:
interface: 'wl_output', version: 2, name: 4
mode:
width: 2560 px, height: 1440 px, refresh: 0 Hz,
flags: current preferred
interface: 'wl_output', version: 2, name: 5
mode:
width: 3200 px, height: 1800 px, refresh: 0 Hz,
flags: current preferred
and xrandr:
XWAYLAND0 connected 2560x1440+3200+0 600mm x 340mm
2560x1440@0.1Hz 0.05*+
XWAYLAND1 connected 3200x1800+0+0 290mm x 170mm
3200x1800@0.1Hz 0.03*+
Export the refresh rate in the correct units. For improved precision,
perform the KMS intermediate calculations in milliHz as well, and
account for interlaced/doublescan modes.
This is also consistent with what GTK+ expects:
timings->refresh_interval = 16667; /* default to 1/60th of a second */
/* We pick a random output out of the outputs that the window touches
* The rate here is in milli-hertz */
int refresh_rate = _gdk_wayland_screen_get_output_refresh_rate (wayland_display->screen,
impl->outputs->data);
if (refresh_rate != 0)
timings->refresh_interval = G_GINT64_CONSTANT(1000000000) / refresh_rate;
Where the 'refresh_rate' given is exactly what's come off the wire.
1000000000/60000 comes out as 16667, whereas divided by 60 is ...
substantially less.
https://bugzilla.gnome.org/show_bug.cgi?id=758653
Right now we just check the pointer serial, so the popup will be
immediately dismissed if the client passes a serial corresponding to
another input device.
Abstract this a bit further and add a meta_wayland_seat_can_popup() call
that will check the serial all input devices. This makes it possible to
trigger menus through touch or keyboard devices.
https://bugzilla.gnome.org/show_bug.cgi?id=756296
If we immediately dismiss the popup, we still need to set the
surface->xdg_popup pointer field in order for the destructor to
properly clean up the state. Not doing this may cause a crash if the
xdg_popup resource that was immediately dismissed is destoryed after
wl_surface during client destruction.
https://bugzilla.gnome.org/show_bug.cgi?id=756675
We don't have any way of knowing what the intended size of a XWayland
cursor is supposed to be, so lets do what we do with regular XWayland
surfaces and don't scale them. The result is that cursor sprites of
HiDPI aware X11 clients will show correctly, but non-aware clients may
have tiny cursor sprites.
https://bugzilla.gnome.org/show_bug.cgi?id=755099
Each keyboard focus change ends up calling the MetaWaylandDataDevice
counterpart, we don't need though to notify the current selection
again. In order to fix this, keep track of the current client, and
only emit the relevant signals when the focus switches to another
client.
The situations where wl_data_device.selection were emitted during
focus changes between surfaces of the same client was inocuous most
of the times, although it's prone to inducing confusing behavior
on context menu clipboard actions, as the closing menu triggers a
focus change, which triggers a whole new wl_data_offer being created
and given on wl_data_device.selection, at a time where there's already
ongoing requests on the previous data offer.
https://bugzilla.gnome.org/show_bug.cgi?id=754357
If the transfer is cancelled, the X11SelectionData will be cleared from
the MetaSelectionBridge, although x11_data_write_cb() was invariably
expecting it to be non-NULL.
If the write was cancelled, all the actions done in x11_data_write_cb()
are moot, so just return early. If there's other errors happening
(eg. "connection closed" if the target client happens to crash), we
should still attempt at clearing the data anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=754357
When committing a toplevel surface we might no longer have a MetaWindow
associated with it. The reason may vary but some are: a popup was
dismissed, the client attached and committed a NULL buffer to a
wl_surface with the wl_shell_surface role, the client committed a
buffer to a wl_surface which previously had an toplevel window role
which extension object was destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=755490
If the drag dest surface suddenly disappears, we may find ourselves
processing an XdndPosition message that was sent before the X11 drag
source had an opportunity to find out.
In that case mutter does know, so double check before processing the
messages.
We try to translate the atom with its corresponding mimetype both back
and forth, which actually breaks if the X11 client chose to announce the
mimetype atom. To do the translation properly, keep track on whether the
source announced the UTF8_STRING atom, and reply back with this only if
that happened.
If the wayland surface isn't available yet when we process the
WL_SURFACE_ID ClientMessage, we schedule a later function to try the
association again after we get a chance to process wayland requests.
This works fine except on cases where the MetaWindow already had a
previous surface attached (i.e. when the xwindow is reparented) since
we only break the existing association on the later function which
means that when processing the old surface's destruction we destroy
the MetaWindow and cancel the pending later function leaving us
without a MetaWindow and an invisible surface.
Fix this by detaching the old surface as soon as possible so that the
MetaWindow survives.
https://bugzilla.gnome.org/show_bug.cgi?id=743339
The saved rect is used to restore a saved window size. We need to
update this when the window is moved to a monitor with different scale,
so that if we unmaximize a window which was moved to a different
monitor while maximized (for example when unplugged) will restore to
the correct size.
https://bugzilla.gnome.org/show_bug.cgi?id=755097
When a window is moved across monitors with different scales, its
rectangle is scaled accordingly. We also need to scale the
unconstrained_rect rectangle, so that moving a window via
meta_window_move_resize() which uses the unconstrained_rect.
https://bugzilla.gnome.org/show_bug.cgi?id=755097
This commits refactors cursor handling code and plugs in logic so that
cursor sprites changes appearance as it moves across the screen.
Renderers are adapted to handle the necessary functionality.
The logic for changing the cursor sprite appearance is done outside of
MetaCursorSprite, and actually where depends on what type of cursor it
is. In mutter we now have two types of cursors that may have their
appearance changed:
- Themed cursors (aka root cursors)
- wl_surface cursors
Themed cursors are created by MetaScreen and when created, when
applicable(*), it will extend the cursor via connecting to a signal
which is emitted everytime the cursor is moved. The signal handler will
calculate the expected scale given the monitor it is on and reload the
theme in a correct size when needed.
wl_surface cursors are created when a wl_surface is assigned the
"cursor" role, i.e. when a client calls wl_pointer.set_cursor. A
cursor role object is created which is connected to the cursor object
by the position signal, and will set a correct texture scale given what
monitor the cursor is on and what scale the wl_surface's active buffer
is in. It will also push new buffers to the same to the cursor object
when new ones are committed to the surface.
This commit also makes texture loading lazy, since the renderer doesn't
calculate a rectangle when the cursor position changes.
The native backend is refactored to be triple-buffered; see the comment
in meta-cursor-renderer-native.c for further explanations.
* when we are running as a Wayland compositor
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Make a surface roles into objects with vfuncs for things where there
before was a big switch statement. The declaration and definition
boilerplate is hidden behind C macros.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
If a surface doesn't have a role, the compositor will not know how, if
or when it will be painted. By adding it to the compositor frame
callback list, the compositor will respond to the client that the
surface has been drawn already which might not be true.
Instead, queue the frame callback in a list that is then processed when
the surface gets a role assigned. The compositor may then, given the
role the surface got, queue the frame callback accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Being a "XWayland window" should be considered equivalent to a role,
even though it is not part of any protocol anywhere. The commit doesn't
have any functional difference, but just makes it clear that an
wl_surface managed by XWayland have the same type of special casing as
surface roles as defined by the Wayland protocol.
As the semantics are more explicit given the role is defined, a comment
explaining why the semantics need to be how they are was added.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Use a better name, use GNOME conventions for error handling, open code the
client error reporting and send the error to the correct resource.
wl_subcompositor doesn't have a role error yet, so continue use some
other error. The only effect of this is error received in the client will
be a bit confusing, it will still be disconnected.
https://bugzilla.gnome.org/show_bug.cgi?id=754215
Older GCC only allows "for (int i" in explicit c99 mode - there's probably
no reason that we can't enable that, but avoiding the construct for
a fast fix.
If the user Alt-Tabs out of the window, we will be left thinking
the Alt key is still pressed since we don't see a release for it.
Solve this and other related issues for the nested X11 compositor
by selecting for KeymapStateMask which causes a KeymapNotify event
to be sent after each FocusIn, and when we get these events, update
the internal XKB state and send any necessary modifiers events to
clients.
https://bugzilla.gnome.org/show_bug.cgi?id=753948
When a client binds an incompatible version, we should terminate it.
This check should only be there for the unstable version, as once it is
declared stable and renamed, future versions will be backward compatible.
https://bugzilla.gnome.org/show_bug.cgi?id=753855
meta_wayland_pointer_get_client_pointer() may be called when the
MetaWaylandPointer as been already shut down, so the hash table will be
NULL at that moment.
The global wl_pointer_gestures object is now created, effectively
bridging pinch/swipe gestures with clients, so they're now
accessible to clients implementing the protocol.
Instead of moving around all the bound pointer resources for a client
when changing focus, keep all the resources bound by a client in a per
client struct, and track the focus by having a pointer to the current
active pointer client struct instance.
This will simplify having wl_pointer extensinos sharing the pointer
focus of the wl_pointer by only having to add them to the pointer
client.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
The spec says:
"A server should avoid signalling the frame callbacks if the surface is not
visible in any way, e.g. the surface is off-screen, or completely obscured
by other opaque surfaces."
We actually do have the information to do that but we are always calling
the frame callbacks in after_stage_paint. So fix that to only call when
when the surface gets drawn on screen.
https://bugzilla.gnome.org/show_bug.cgi?id=739163
If we can't put up a popup because grabbing the pointer fails we
immediately dismiss the popup but the client might have made requests
already, in particular it might have commited the surface and in that
case we should ignore it.
https://bugzilla.gnome.org/show_bug.cgi?id=753237
When a client sets an input region or a opaque region to NULL, it
should still be considered a change to the corresponding region on the
actor. This patch makes sure this state is properly forwarded.
https://bugzilla.gnome.org/show_bug.cgi?id=753222
When placing a popup and the legacy transient wl_shell_surface surfaces,
take the current scale of the window into account. This commit doesn't
fix relative positioning in case a window scale would change, but since
the use case for relative positioning is mostly popups, which would be
dismissed before the parent window would be moved, it should not be that
much of a problem.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
Make meta_wayland_surface_get_toplevel_window return the top most window
in case its a chain of popups. This is to make all popups in a chain
including the top most surface have the same scale.
The reason for this is that popups are mostly integrated part of the
user interface of its parent (such as menus). Having them in a different
scale would look awkward.
Note that this doesn't affect non-popup windows with parent-child
relationship, because such windows are typically not an integral part of
the user interface (settings window, dialogs, ..) and can typically be
moved independently. It would probably make sense to make attached modal
dialogs have the same scale as their parent windows, but modal dialogs
are currently not supported for Wayland clients.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
Since we scale surface actors given what main output their toplevel
window is on, also scale the window geometry coordinates and sizes
(window->rect size and window->custom_frame_extents.top/left) in order
to make the window geometry represent what is being rendered on the
stage.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
Tracking back from the monitor to the output every time we need to
figure out the scale of a window on a monitor is inconvenient, so
propagate the scale from the output to the monitor it is associated
with.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
A MetaWaylandSurface was casted into a ClutterActor, but it should have
been the MetaSurfaceActor.
Move out parent_actor and surface_actor out of the loop while at it
since they won't change when iterating.
https://bugzilla.gnome.org/show_bug.cgi?id=745655
Keep the active position state in its original coordinate space, and
synchronize the surface actor with it when it changes and when
synchronizing the rest of the surface state, in case the surface scale
had changed.
https://bugzilla.gnome.org/show_bug.cgi?id=745655
Previously a MetaWaylandOutput could be removed from the current outputs
table (by being unplugged for example). This would result in the global
object being removed and the MetaWaylandOutput instance freed, but the
wl_resource destructor would still try to remove itself from the list of
resources. Trying to do this, it'd try to access its user data pointer
which would point to the freed MetaWaylandOutput instance, and as a
result crash when trying to manipulate the freed data.
https://bugzilla.gnome.org/show_bug.cgi?id=744453
Whenever a MetaSurfaceActor is painted, update the list of what outputs
the surface is being drawed upon. Since we do this on paint, we
effectively avoids this whenever the surface is not drawn, for example
being minimized, on a non-active workspace, or simply outside of the
damage region of a frame.
DND icons and cursors are not affected by this patch, since they are not
drawn as MetaSurfaceActors. If a MetaSurfaceActor or a parent is cloned,
then we'll check the position of the original actor again when the clone is
drawn, which is slightly expensive, but harmless. If the MetaShapedTexture
instead is cloned, as GNOME Shell does in many cases, then these clones
will not cause duplicate position checks.
https://bugzilla.gnome.org/show_bug.cgi?id=744453
We may access it during painting even if it has been freed. For now,
manually unset it during the MetaWaylandSurface cleanup; in the future
make MetaWaylandSurface a GObject and make the surface pointer a weak
reference.
https://bugzilla.gnome.org/show_bug.cgi?id=744453
Lets use the role when doing role specific commit actions. The
conditions effectively do that anyway, and this way we will get a
compiler warning here whenever we add a new role, as well as we avoid
having different variants of role-determination checks in different
places.
https://bugzilla.gnome.org/show_bug.cgi?id=744453
Firstly, this patch makes MetawaylandDataSource a GObject. This is in
order to easier track its lifetime without adding destroy signals etc. It
also makes the vfunc table GObject class functions instead while at it,
as well as moves protocol specific part of the source into their own
implementations.
An important part of this patch is the change of ownership. Prior to this
patch, MetaWaylandDataDevice would kind of own the source, but for
Wayland sources it would remove it if the corresponding wl_resource was
destroyed. For XWayland clients it would own it completely, and only
remove it if the source was replaced.
This patch changes so that the protocol implementation owns the source.
For Wayland sources, the wl_resource owns the source, and the
MetaWaylandDataDevice sets a weak reference (so in other words, no
semantical changes really). For XWayland sources, the source is owned by
the selection bridge, and not removed until replaced or if the client
goes away.
Given the changes in ownership, data offers may now properly track the
lifetime of a source it represents. Prior to this patch, if an offer with
an XWayland source would loose its source, it wouldn't get notified and
have an invalid pointer it would potentally crash on. For Wayland
sources, an offer would have a weak reference and clean itself up if the
source went away. This patch changes so the behavior is consistent,
meaning a weak reference is added to the source GObject so that the offer
can behave correctly both for Wayland sources and XWayland sources.
https://bugzilla.gnome.org/show_bug.cgi?id=750680
When a possible drag dest client crashes during DnD, it may happen
we receive first the destroy notification for the data_device, and
later the notification for the focus surface. When this happens we
unset the drag_focus_data_device first, and later on
meta_wayland_drag_grab_set_focus(grab, NULL) we assume it still
exists when sending the leave event, leading to mutter crashing
right after.
So, as we don't receive any ordering guarantees about resource
destruction, just prepare the meta_wayland_drag_grab_set_focus()
paths for this.
If a client unsets a selection (calls set_selection with the offer
NULL), this should cause the compositor not to continue sending the
previously set offer.
https://bugzilla.gnome.org/show_bug.cgi?id=750007
Mutter generates a motion event for every button and scroll events,
which confuses Xwayland apps that rely on XMotionEvents for various
purposes, e.g. it fools rxvt jumpy mouse detection code.
Remove the call to notify_motion() from the button and scroll event
handlers to avoid these spurious motion events.
https://bugzilla.gnome.org/show_bug.cgi?id=748705
According to the xdg-shell protocol specification the (x, y) coordinates
passed when creating a popup surface is relative to top left corner of
the parent surface, but prior to this patch, if the parent surface was
a xdg_surface, it'd position it relative to top left corner of the
window geometry of that xdg_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=749716
When DnD is started from an X11 client, mutter now sets up an special
grab that 1) Ensures the drag source keeps receiving events, and 2)
Moves an internal X Window over wayland clients as soon as the pointer
enters over these.
That window will act as the X-side peer for the currently focused
wayland client, and will transform XdndEnter/Position/Leave/Drop
messages into wayland actions. If DnD happens between X11 clients,
the window will be moved away and unmapped, to let these operate as
usual.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
X11 client windows now hook a X11-specific MetaWaylandDragDestFuncs
that converts these into Xdnd* messages, and an additional selection
bridge has been added to take care of XdndSelection, and the data
transfers done through it.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
This will be useful in order to interact with drag dest surfaces in
its windowing-specific ways, although everything defaults to the
wayland vfuncs.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
This piece of code hooks in both wl_data_device and the relevant X
selection events, an X11 Window is set up so it can act as the clipboard
owner when any wayland client owns the selection, reacting to
SelectionRequest events, and returning the data from the wayland client
FD to any X11 requestor through X properties.
In the opposite direction, SelectionNotify messages are received,
which results in the property contents being converted then written
into the wayland requestor's FD.
This code also takes care of the handling incremental transfers through
the INCR property type, reading/writing data chunk by chunk.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
Expose it partly (in internal headers anyway), and pass a vtable for the
data source functions, the wayland vfuncs just delegate operations on the
wl_data_source resource. The resource has been also made optional, although
it'll be present on all data sources from wayland clients.
The ownership/lifetime of the DnD data source has also changed a bit,
belonging now to the MetaWaylandDataDevice like the selection one does, as
we can't guarantee how long it will be needed after the grab is finished,
it will be left inert and replaced the next time DnD is started at worst.
This allows the creation of custom/proxy data sources, which will turn out
useful for X11 selection interoperation.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
The corresponding wl_notify field for destroy_data_device_icon()
is drag_grab->drag_icon_listener, otherwise we're fetching a pointer
that's slightly off where we want.
The stop function currently manually constructs the lock
filename from the display number and also calls unlink
on the same, already known lock filename from the manager
struct.
This commit gets rid fo the manual construction in favor
of the saved lock filename.
https://bugzilla.gnome.org/show_bug.cgi?id=748380
The start function has a few exit paths that need to
perform clean up of the lock file.
This commit consolidates those exit paths at the end
using an out label and gotos.
https://bugzilla.gnome.org/show_bug.cgi?id=748380
Add set_modal ond unset_modal to the gtk_surface interface. When a
surface is modal, the compositor can treat it differently from non-modal
dialogs, for example attach it to the parent window if any. There is
currently no changes to input device focus; it is up to the client to
ignore events to the parent surface that is wanted.
This bumps the gtk_shell version to 2.
https://bugzilla.gnome.org/show_bug.cgi?id=745720
