The actor is already in surface coordinate space, so we should not scale
with the buffer scale to transform surface coordinates to stage
coordinates.
This bug causes input method using wayland text-input protocol to
receive wrong cursor location. Reproduced in ibus (when candidate
window is open) with scaling factor other than 1.
This commit also fixes pointer confinement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/915
Java applications might use override-redirect windows as parent windows for
top-level windows, although this is not following the standard [1].
In such case, the first non-override-redirect child window that is created
was marked as being on_all_workspaces since the call to
should_be_on_all_workspaces() returns TRUE for its parent, and this even
though the on_all_workspaces_requested bit is unset.
When a further child of this window was added, it was set as not having a
workspace and not being on_all_workspaces, since the call to
should_be_on_all_workspaces() for its parent would return FALSE (unless if
it is in a different monitor, and the multiple-monitors workspaces are
disabled).
Since per commit 09bab98b we don't recompute the workspace if the
on_all_workspaces bit is unset, we could end up in a case where a window can
be nor in all the workspaces or in a specific workspace.
So let's just ignore the transient_for bit for a window if that points to an
override-redirect, using the x11 root window instead.
Add a stacking test to verify this scenario (was failing before of this
commit).
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/885https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
[1] https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472512128
Once we set the transient_for, we look for parent MetaWindow, so instead
of overwriting this value for loops check, just use another function
and avoid to look for the xwindow again when setting the MetaWindow parent.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
Override-redirect windows have no workspace by default, and can't be parent
of a top-level window, so we must check that the parent window is not an
O-R one when setting the workspace state.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
We're expected by MetaWaylandSurface to always pick the frame callbacks
out from the pending state when committing (applying) so that no frame
callbacks are unaccounted for. We failed to do this if our actor for
some reason (e.g. associated window was unmanaged) was destroyed. To
handle this situation better, store away the frame callbacks until we
some later point in time need to pass them on forward.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/893
We ask XLib the next request serial number before performing other actions
triggered by meta_x11_display_set_input_focus_internal() that doesn't use
the request serial anyways. So, just request it before updating the focus
window as that's the operation that needs it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/909
When using DesktopIcons extension and clicking in an icon, gnome-shell
starts an infinite loop caused by the first focus change that may trigger
on X11 a focus in/out event that leads to stage activation/deactivation
which never ends.
This happens because as part of meta_x11_display_set_input_focus_xwindow()
to focus the X11 stage window, we unset the display focus, but this also
causes to request the X11 display to unset the focus since we convolute by
calling meta_x11_display_set_input_focus() with no window, that leads to
focusing the no_focus_window and then a focus-in / focus-out dance that the
shell amplifies in order to give back the focus to the stage.
In order to fix this, mimic what meta_display_set_input_focus() does, but
without updating the X11 display, and so without implicitly calling
meta_x11_display_set_input_focus(), stopping the said convolution and
properly focusing the requested xwindow.
Also ensure that we're not doing this when using an older timestamp, since
this check isn't performed anymore.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/896
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/899https://gitlab.gnome.org/GNOME/mutter/merge_requests/909
This function is already checking for the focus surface client
matching the requestor. The type check was slightly bogus though
as it'd be an screwup in our code, make it an assert instead.
Also, move the check for the client having the focus into the
upper call, so this and wl_data_device.set_selection code can
get more in line.
https://gitlab.gnome.org/GNOME/mutter/issues/878
We have an abstract MetaWaylandDataSource and 2 subclasses for
clipboard/primary data sources. Since the abstraction provided
by the additional sublevel is arguable, push the wl_resource
field up, and leave us with just 2 objects to think about, all
of them containing a wl_resource.
https://gitlab.gnome.org/GNOME/mutter/issues/878
Otherwise we'll end up trying to access the out of date state later.
Fixes the following test failure backtrace:
#0 _g_log_abort ()
#1 g_logv ()
#2 g_log ()
#3 meta_monitor_manager_get_logical_monitor_from_number ()
#4 meta_window_get_work_area_for_monitor ()
#5 meta_window_get_tile_area ()
#6 constrain_maximization ()
#7 do_all_constraints ()
#8 meta_window_constrain ()
#9 meta_window_move_resize_internal ()
#10 meta_window_tile ()
https://gitlab.gnome.org/GNOME/mutter/merge_requests/912
`meta_surface_actor_is_obscured` implies that the actor got successfully culled
out and nothing of it will get painted. This includes that there are no clones,
no effects etc. In this cases we don't want to send frame callbacks, thus avoiding
unnecessary client work.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/918
Create the intermediate shadow framebuffer for use exclusively when a
shadowfb is required.
Keep the previous offscreen framebuffer is as an intermediate
framebuffer for transformations only.
This way, we can apply transformations between in-memory framebuffers
prior to blit the result to screen, and achieve acceptable performance
even with software rendering on discrete GPU.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/877
This is a workaround for X11 games which use randr to change the resolution
in combination with NET_WM_STATE_FULLSCREEN when going fullscreen.
Newer versions of Xwayland support the randr part of this by supporting randr
resolution change emulation in combination with using WPviewport to scale the
app's window (at the emulated resolution) to fill the entire monitor.
Apps using randr in combination with NET_WM_STATE_FULLSCREEN expect the
fullscreen window to have the size of the emulated randr resolution since
when running on regular Xorg the resolution will actually be changed and
after that going fullscreen through NET_WM_STATE_FULLSCREEN will size
the window to be equal to the new resolution.
We need to emulate this behavior for these games to work correctly.
Xwayland's emulated resolution is a per X11 client setting and Xwayland
will set a special _XWAYLAND_RANDR_EMU_MONITOR_RECTS property on the
toplevel windows of a client (and only those of that client), which has
changed the (emulated) resolution through a randr call.
This commit checks for that property and if it is set adjusts the fullscreen
monitor rect for this window to match the emulated resolution.
Here is a step-by-step of such an app going fullscreen:
1. App changes monitor resolution with randr.
2. Xwayland sets the _XWAYLAND_RANDR_EMU_MONITOR_RECTS property on all the
apps current and future windows. This property contains the origin of the
monitor for which the emulated resolution is set and the emulated
resolution.
3. App sets _NET_WM_FULLSCREEN.
4. We check the property and adjust the app's fullscreen size to match
the emulated resolution.
5. Xwayland sees a Window at monitor origin fully covering the emulated
monitor resolution. Xwayland sets a viewport making the emulated
resolution sized window cover the full actual monitor resolution.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/739
Add an adjust_fullscreen_monitor_rect virtual method to MetaWindowClass
and call this from setup_constraint_info() if the window is fullscreen.
This allows MetaWindowClass to adjust the monitor-rectangle used to size
the window when going fullscreen, which will be used in further commits
for a workaround related to fullscreen games under Xwayland.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/739
This allows xdg_popup.grab() to work with styli. Without this check
we would bail out and emit xdg_popup.popup_done, leaving stylus users
unable to interact with popup menus, comboboxes, etc...
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/886
When a touch sequence was rejected, the emulated pointer events would be
replayed with old timestamps. This caused issues with grabs as they
would be ignored due to being too old. This was mitigated by making sure
device event timestamps never travelled back in time by tampering with
any event that had a timestamp seemingly in the past.
This failed when the most recent timestamp that had been received were
much older than the timestamp of the new event. This could for example
happen when a session was left not interacted with for 40+ days or so;
when interacted with again, as any new timestamp would according to
XSERVER_TIME_IS_BEFORE() still be in the past compared to the "most
recent" one. The effect is that we'd always use the `latest_evtime` for
all new device events without ever updating it.
The end result of this was that passive grabs would become active when
interacted with, but would then newer be released, as the timestamps to
XIAllowEvents() would out of date, resulting in the desktop effectively
freezing, as the Shell would have an active pointer grab.
To avoid the situation where we get stuck with an old `latest_evtime`
timestamp, limit the tampering with device event timestamp to 1) only
pointer events, and 2) only during the replay sequence. The second part
is implemented by sending an asynchronous message via the X server after
rejecting a touch sequence, only potentially tampering with the device
event timestamps until the reply. This should avoid the stuck timestamp
as in those situations, we'll always have a relatively up to date
`latest_evtime` meaning XSERVER_TIME_IS_BEFORE() will not get confused.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/886
This way, we can simply pop up the Looking Glass and run:
>>> Meta.add_clutter_debug_flags(Clutter.DebugFlag.PICK, 0, 0)
And measure specific actions or events on GNOME Shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/862
In a similar vein to commit 8fd55fef85. This notably failed when setting
the focus on the stage (eg. to redirect key events to Clutter actors).
Deeper in MetaDisplay focus updating machinery, it would check
meta_stage_is_focused() which would still return FALSE at the time it's
called.
This would not typically have side effects, but our "App does not respond"
dialogs see the focus change under their feet, so they try to bring
themselves to focus again. This results in a feedback loop.
Changing the order results in later checks on the X11 POV of the focus
being correct, so focus is not mistakenly stolen from the close dialog,
and it actually succeeds in keeping the key focus.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1607https://gitlab.gnome.org/GNOME/mutter/merge_requests/876
Syncronized subsurfaces that call into `merge_pending_state` might
otherwise not create new destroy handlers, ending up with a invalid
handler ids, throwing errors and leaking.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/868
It might be the case that handling an event induces the stream to
trigger completion, hence removing itself from the list. In that
case we would operate on the no longer valid list element to fetch
the next one.
Keep a pointer to the next element beforehand, so we can tiptoe
over streams that did remove themselves.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/869
The streams were only detached from MetaX11Display (and its event handling)
on completion. This is too much to expect, and those might be in some
circumstances replaced while operating.
Make those streams detach themselves on dispose(), so we don't trip into
freed memory later on when trying to dispatch unrelated X11 selection events.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/869
Instead of doing a roundtrip to the X server before setting it, rely on
the previous value fetched before the configuration was sent over DBus.
This matches the argument check we already do elsewhere, and will allow
us to more easily add an additional condition to determine if underscan
is supported.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/673
As the first step into removing Cogl types that are covered by
Graphene, remove CoglEuler and replace it by graphene_euler_t.
This is a mostly straightforward replacement, except that the
naming conventions changed a bit. Cogl uses "heading" for the
Y axis, "pitch" for the X axis, and "roll" for the Z axis, and
graphene uses the axis themselves. That means the 1st and 2nd
arguments need to be swapped.
Also adapt the matrix stack to store a graphene_euler_t in the
rotation node -- that simplifies the code a bit as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Graphene uses C99 and includes stdbool.h, which adds a
new 'bool' type. Clutter has an a11y test that names a
variable as 'bool' too, and they do not play well together.
Rename this variable to boolean.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Fog is explicitly deprecated in favour of CoglSnippet API,
and in nowhere we are using this deprecated feature, which
means we can simply drop it without any sort of replacement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Move out updating of various shapes (input, opaque, shape) indirectly
from X11 to the corresponding X11 sub types of MetaWindowActor and
MetaSurfaceActor.
Also move fullscreen window unredirection code with it. We want to
effectively do something similar for MetaCompositorServer, but it will
work differently enough not to share too much logic.
While it would have been nice to move things piece by piece, things were
too intertwined to make it feasible.
This has the side effect fixing accidentally and arbitrarily adding
server side shadow to Wayland surfaces.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/727https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
It is opaque if the texture has no alpha channel, or if the opaque
region covers the whole content.
Internally uses a function that checks whether there is an alpha
channel. This API will be exposed at a later time as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
As we will start adding support for more pixel formats, we will need to
define a notion of planes. This commit doesn't make any functional
change, but starts adding the idea of pixel formats and how they (at
this point only theoretically) can have multple planes.
Since a lot of code in Mutter assumes we only get to deal with single
plane pixel formats, this commit also adds assertions and if-checks to
make sure we don't accidentally try something that doesn't make sense.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/858
Clutter had support for internal children in its early revisions, but they
were deprecated for long time (commit f41061b8df, more than 7 years ago) and
no one is using them in both clutter and in gnome-shell.
So remove any alternative code path that uses internal children.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/816
Instead of passing around an X11 Display pointer that is retrieved from
the default Gdk backend, then finding the MetaX11Display from said X11
Display, pass the MetaX11Display directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/854
The functionality core/core.c and core/core.h provides are helpers for
the window decorations. This was not possible to derive from the name
itself, thus rename it and put it in the right place.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/854
This is for all intents and purposes the same as
`cogl_object_ref/unref`, but still refers to handles rather than
objects (while we're trying to get rid of the former) so it's a bit of
unnecessary redundant API.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/451
We were just looking at DnD actions which might still be unset at that
point. Instead of doing these heuristics, store the selection type on
the data offer.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/845
Requesting a selection with a NULL data source means "unset the clipboard",
but internally we use an unset clipboard as the indication that the
clipboard manager should take over.
Moreover, this unset request may go unheard if the current owner is someone
else than the MetaWaylandDataDevice.
Instead, set a dummy data source with no mimetypes nor data, this both
prevents the clipboard manager from taking over and ensures the selection
is replaced with it.
The MetaSelectionSourceMemory was also added some checks to allow for this
dummy mode.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/793
Instead of taking resource and send/cancel funcs, take a
MetaWaylandDataSource, which exposes all the vfuncs to do the same on the
internal resource.
This has the added side effect that only MetaWaylandDataSource has a
pointer to the wl_resource, which may be unset untimely.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/842
If a data source is destroyed we first unset the resource, and then try to
unref the related selection source. At this point the only event that might
be emitted by the internal selection machinery is .cancelled, so make sure
we avoid it on destroyed sources.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/842
We are still poking the mimetypes from the previous selection when creating
the new offer. This may come out wrong between changes of the copied
mimetypes.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/789
Otherwise we'll get the warning
../src/core/main.c: In function 'meta_test_init':
../src/core/main.c:755:1: error: function might be candidate for attribute 'noreturn' [-Werror=suggest-attribute=noreturn]
755 | meta_test_init (void)
| ^~~~~~~~~~~~~~
when building without Wayland.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/837
If we did a mode set, the gamma may have been changed by the kernel, and
if we didn't also update the gamma in the same transaction, we have no
way to predict the current gamma ramp state. In this case, read the
gamma state directly from KMS.
This should be relatively harmless regarding the race conditions the
state prediction was meant to solve, as the worst case is we get none or
out of date gamma ramps; and since this is for when gamma ramps are not
updated at mode setting time, we'd get intermediate gamma state to begin
with, so it's not worse than what we currently do anyway.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/851https://gitlab.gnome.org/GNOME/mutter/merge_requests/840
Xkb events should be handled by clutter backend but they are not translated
into an actual clutter event. However we're now handling them and also trying
to push an empty event to clutter queue, causing a critical error.
So in such case, just handle the native event but don't push the non-populated
clutter-event to the queue.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/750https://gitlab.gnome.org/GNOME/mutter/merge_requests/764
A frame callback without damage is still expected to be responded to.
Implement this by simply queuing damage if there are any frame callbacks
requested and there is no damage yet. If there already is damage,
we'll be queued already, but with more correct damage. Without we simply
need to make sure we flush the callbacks if any area of surface is not
occluded.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/457https://gitlab.gnome.org/GNOME/mutter/merge_requests/839
The inhibited state of the monitor was after the initializiation never
updated. meta_idle_monitor_reset_idletime didn't respect the inhibited
state, so it set timeouts if it shouldn't have.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/573
For the most part, a MetaWindow is expected to live roughly as long as
the associated wl_surface, give or take asynchronous API discrepancies.
The exception to this rule is handling of reparenting when decorating or
undecorating a window, when a MetaWindow on X11 is made to survive the
unmap/map cycle. The fact that this didn't hold on Wayland caused
various issues, such as a feedback loop where the X11 window kept being
remapped. By making the MetaWindow lifetime for Xwayland windows being
the same as they are on plain X11, we remove the different semantics
here, which seem to lower the risk of hitting the race condition causing
the feedback loop mentioned above.
What this commit do is separate MetaWindow lifetime handling between
native Wayland windows and Xwayland windows. Wayland windows are handled
just as they were, i.e. unmanaged together as part of the wl_surface
destruction; while during the Xwayland wl_surface destruction, the
MetaWindow <-> MetaWaylandSurface association is simply broken.
Related: https://gitlab.freedesktop.org/xorg/xserver/issues/740
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/762https://gitlab.gnome.org/GNOME/mutter/merge_requests/774
We get implicit, thus auto-removed, transitions, then manage them
manually by stopping them and emitting "completed" signals. This doesn't
work since they are removed and freed when stopped. To be able to emit
the "completed" signal, hold a reference while stopping, so that we
still can emit the signal as before.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/828
Dropping the grab has the side effect that the pointer will be re-picked,
and it might find another surface with a pointer constraint. If that were
the case, the focus change would try to add the pointer constraint before
the now old focus surface released its own.
Just invert these operations, so the constraint is unset before the repick
that might enable another pointer constraint.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/779
Just like sync_focus_surface() does, we shouldn't set a focus surface while
the pointer is hidden, so the illusion that there is none remains.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/779
We can't just update the state of the connector and CRTC from KMS since
it might contain too new updates, e.g. from a from a future hot plug. In
order to not add ad-hoc hot plug detection everywhere, predict the state
changes by looking inside the MetaKmsUpdate object, and let the hot-plug
state changes happen after the actual hot-plug event.
This fixes issues where connectors were discovered as disconnected while
doing a mode-set, meaning assumptions about the connectedness of
monitors elsewhere were broken until the hot plug event was processed.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/782https://gitlab.gnome.org/GNOME/mutter/merge_requests/826
After commit 75cffd0e ("shaped-texture: Implement ClutterContent"), the
input to the meta_wayland_tablet_tool_get_relative_coordinates function
is already scaled correctly. By scaling it again, all stylus events are
getting mapped to the screen incorrectly (for anything != 100% scaling).
See also: d3f30d9ehttps://gitlab.gnome.org/GNOME/mutter/merge_requests/830
Correct silly mistake where the MetaWaylandSurface was passed as the
user_data of the surface actor destroy signal handler, instead of the
expected MetaWaylandActorSurface.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/844
Instead of storing the result of meta_prop_get_latin1_string() into
a temporary string value, g_strdup-ing that temp value storing the
g_strdup result into window->sm_client_id and then g_free-ing the
temporary string, we can pass window->sm_client_id as the place where
meta_prop_get_latin1_string() stores its result, since the result
from meta_prop_get_latin1_string() is itself a g_strdup-ed string,
so there is no need to g_strdup it again.
Note this drops the check to only issue the
"Window %s sets SM_CLIENT_ID on itself ..." warning once. This check is
not necessary as update_sm_hints() is only called once at window
creation time and is never called again.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
Use g_strdup instead of malloc + strcpy, this also gets rid of a bunch
of error checking which is no longer necessary, also adjust the free
path accordingly.
Note that there was a malloc + XFree mismatch in the removed error-handling.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
latin1_string_from_results and utf8_string_from_results use g_strndup,
so the returned string should be freed with g_free, rather then with
free or XFree. This fixes all free-s of buffers returned by these 2
functions to properly use g_free.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
Use g_new0 instead of calloc for motif_hints_from_results and adjust
its callers to use g_free.
Note that in the process_request_frame_extents function this replaces
the wrong original mismatch of calloc + XFree with a matching g_malloc +
g_free pair.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
Clutter actors might emit property changes in dispose, while unparenting.
However we assume that the ::destroy signal is the last one we emit for an
actor, and that starting from this moment the object is not valid anymore,
and so we don't expect any signal emission from it.
To avoid this, freeze the object notifications on an actor during its
disposition, just before the ::destroy signal emission.
Update the actor-destroy test to verify this behavior.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Clutter actors unset their parent on dispose, after emitting the ::destroy
signal, however this could cause ::parent-set signal emission. Since we
assume that after the destruction has been completed the actor isn't valid
anymore, and that during the destroy phase we do all the signal / source
disconnections, this might create unwanted behaviors, as in the signal
callbacks we always assume that the actor isn't in disposed yet.
To avoid this, don't emit ::parent-set signal if the actor is being
destroyed.
Update the actor-destroy test to verify this behavior.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Mutter issues a synchronous grab on the pointer for unfocused client
windows to be able to catch the button events first and raise/focus
client windows accordingly.
When there is a synchronous grab in effect, all events are queued until
the grabbing client releases the event queue as it processes the events.
Mutter does release the events in its event handler function but does so
only if it is able to find the window matching the event. If the window
is a shell widget, that matching may fail and therefore Mutter will not
release the events, hence causing a freeze in pointer events delivery.
To avoid the issue, make sure we sync the pointer events in case we
can't find a matching window.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/821
It was not the lack of forcing the shadow fb that caused slowness, but
rather due to the method the shadow fb content was copied onto the
scanout fb. With 'clutter: Use cogl_blit_framebuffer() for shadow FB'
we'll use a path that shouldn't be slow when copying onto the scanout
fb.
Also 437f6b3d59 accidentally enabled
shadow fb when using hw accelerated contexts, due to the cap being set
to 1 in majority of drivers. While the kernel documentation for the
related field says "hint to userspace to prefer shadow-fb rendering",
the name of the hint when exposed to userspace is
DRM_CAP_DUMB_PREFER_SHADOW, thus should only be taken into consideration
for dumb buffers, not rendering in general.
This reverts commit 437f6b3d59.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/818
The commit 'renderer/native: Use shadow fb on software GL if preferred'
attempted to force using a shadow fb when using llvmpipe in order to
speed up blending, but instead only did so when llvmpipe AND the drm
device explicityl asked for it.
Now instead always force it for llvmpipe and other software rendering
backends, and otherwise just query the drm device (i.e.
DRM_CAP_DUMB_PREFER_SHADOW).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/807
Since the recent clutter-content work, legacy scaling (in contrast
to the new stage-view-scaling) only applies to surfaces that belong
to a window. This broke scaling of DnD surfaces.
As a workaround, apply the same scaling on DnD-surface-actors until
we use stage-view-scaling by default and can remove this again.
Also: small corrections of geometry calculation
https://gitlab.gnome.org/GNOME/mutter/merge_requests/780
This allows us to implement more sophisticated logic for the different
cases. For DnD surfaces, use the geometry scale of the monitor where
the pointer is, instead of incorrectly assuming '1' as it was before.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/780
The meta_display_update_focus_window() call has indirect dependencies
on the X11 focus window, in order to determine the correct focus window
on the Wayland side (i.e. may turn out NULL with certain X windows).
In order to have the right x11_display->focus_xwindow there, we should
perform first the focus update on the X11 display.
Fixes focusing of Java applications, as those don't seem to go through
_NET_ACTIVE_WINDOW.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/819
With the addition of the locate-pointer special keybinding (defaults to
the [Control] key), we have now two separate special modifier keys which
can be triggered separately, one for the locate-pointer action and
another one for overlay.
When processing those special modifier keys, mutter must ensure that the
key was pressed alone, being a modifier, the key could otherwise be part
of another key combo.
As result, if both special modifiers keys are pressed simultaneously,
mutter will try to trigger the function for the second key being
pressed, and since those special modifier keys have no default handler
function set, that will crash mutter.
Check if the handler has a function associated and treat the keybinding
as not found if no handler function is set, as with the special modifier
keys.
https://gitlab.gnome.org/GNOME/mutter/issues/823
The `process_event()` would check for a existing keybinding handler and
abort if there is none, however the test is done after the handler had
been accessed, hence defeating the purpose of the check.
Move the check to verify there is an existing keybinding handler before
actually using it.
https://gitlab.gnome.org/GNOME/mutter/issues/823
There were multiple bugs present after the ClutterContent transition.
Refactor `get_image` to:
- always assume surface coordinates for the clip
- return a cairo_surface in buffer size
- make the offscreen path take size arguments, so we can
easily change the assumption in get_image
- fix some clipping bugs on the way
https://gitlab.gnome.org/GNOME/mutter/merge_requests/758
Some drivers expose EGL_EXT_image_dma_buf_import_modifiers so you can
query supported formats, but don't support any modifiers. Handle this by
treating it like DRM_FORMAT_MOD_INVALID.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/782
Instead of open coding the X11 focus management in display.c, expose
it as a single function with similar arguments to its MetaDisplay
counterpart. This just means less X11 specifics in display.c.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/751
MetaDisplay and MetaX11Display focus windows are slightly decoupled,
we cannot rely here on the MetaDisplay focus to be updated yet. We
however know the X Window that got focused, so lookup the corresponding
MetaWindow (and client X window) from it.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/751
We have a "setup" phase, used internally to initialize early the x11
side of things like the stack tracker, and an "opened" phase where
other upper parts may hook up to. This latter phase is delayed during
initialization so the upper parts have a change to connect to on
plugin creation.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/771
When starting standalone mutter and running using the native backend, we
always fall back on using the us pc105 keyboard layout. This can be very
frustrating if one is used to using some other keyboard layout, such as
dvorak, causing keyboard fumbling everytime when doing something with
standalone mutter.
Avoid this involuntary fumbling by having the default plugin query
localed what layout the user has actually configured the machine to
operate using. It doesn't add any keymap selection user interface, so
it'll always use the first one it encounters.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/787
The commit f2f4af0d50 missed one situation
where mutter does things differently, i.e. changes what surface actor is
associated with a given window actor: reparenting a Xwayland window when
changing whether it is decorated.
To summarize, there are three types of window actors:
X11 window actors - directly tied to the backing X11 window. The
corresponding surface actor is directly owned by the window actor and
will never change.
Wayland window actors - gets its surface actor from MetaWaylandSurface
at construction. A single MetaWaylandSurface may create and destroy
multiple window actors over time, but a single window actor will never
change surface actor.
Xwayland window actors - a mix between the above two types; the window
corresponds to the X11 window, and so does the window actor, but the
surface itself comes from the MetaWaylandSurface.
Normally when a X11 window is unmapped, the corresponding MetaWindow is
unmanaged. With Xwayland, this happens indirectly via the destruction of
the wl_surface. The exception to this is windows that are reparented
during changing their decoration state - in this case on plain X11, the
MetaWindow stays alive. With Xwayland however, there is a race
condition; since the MetaWindow is tied to the wl_surface, if we receive
the new surface ID atom before the destruction of the old wl_surface,
we'll try to associate the existing MetaWindow and MetaWindowActor with
the new wl_surface, hitting the assert. If the surface destruction
arrives first, the MetaWindow and MetaWindowActor will be disposed, and
the we wouldn't hit the assert.
To handle this race gracefully, reinstate handling of replacing the
surface actor of an existing window actor, to handle this race, as it
was handled before.
Eventually, it should be reconsidered whether the MetaWindow lifetime is
tied to the wl_surface or if it should be changed to be consistent with
plain X11, as this re-exposes another bug where the X11 client and
mutter will enter a feedback loop where the window is repeatedly
remapped. See https://gitlab.freedesktop.org/xorg/xserver/issues/740.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/709https://gitlab.gnome.org/GNOME/mutter/merge_requests/773
When using xdg-output v3 or later, the Wayland compositor does not send
xdg_output.done events which are deprecated.
Instead, it should send a wl_output.done event for the matching
wl_output.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/771
When suspending, the devices are removed and the virtual device
associated with the corresponding core pointer is disposed.
Add the pointer accessibility virtual device to the core pointer
on resume to restore pointer accessibility on resume if enabled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/761
When starting a DnD operation, mutter would remove keyboard focus from
the client, only to restore it on the data offer destroy.
However, if the DnD fail, the keyboard focus is not restored, leaving
the user unable to type in the focused window, even after clicking in
the window.
That issue would show only on first attempt, as further DnD attempts
would destroy the previous data offer which would also restore the
keyboard focus.
Make sure we restore the keyboard focus on drag end as well.
https://gitlab.gnome.org/GNOME/mutter/issues/747
On drag start, `data_device_start_drag()` issues a keyboard grab, which
in turn will unset the current input focus.
There is not need to unset the input focus in `data_device_start_drag()`
as this is redone in `meta_wayland_keyboard_start_grab()`
https://gitlab.gnome.org/GNOME/mutter/issues/747
Currently, Clutter does picking by drawing with Cogl and reading
the pixel that's beneath the given point. Since Cogl has a journal
that records drawing operations, and has optimizations to read a
single pixel from a list of rectangle, it would be expected that
we would hit this fast path and not flush the journal while picking.
However, that's not the case: dithering, clipping with scissors, etc,
can all flush the journal, issuing commands to the GPU and making
picking slow. On NVidia-based systems, this glReadPixels() call is
extremely costly.
Introduce geometric picking, and avoid using the Cogl journal entirely.
Do this by introducing a stack of actors in ClutterStage. This stack
is cached, but for now, don't use the cache as much as possible.
The picking routines are still tied to painting.
When projecting the actor vertexes, do it manually and take the modelview
matrix of the framebuffer into account as well.
CPU usage on an Intel i7-7700, tested with two different GPUs/drivers:
| | Intel | Nvidia |
| ------: | --------: | -----: |
| Moving the mouse: |
| Before | 10% | 10% |
| After | 6% | 6% |
| Moving a window: |
| Before | 23% | 81% |
| After | 19% | 40% |
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/154,
https://gitlab.gnome.org/GNOME/mutter/issues/691
Helps significantly with: https://gitlab.gnome.org/GNOME/mutter/issues/283,
https://gitlab.gnome.org/GNOME/mutter/issues/590,
https://gitlab.gnome.org/GNOME/mutter/issues/700
v2: Fix code style issues
Simplify quadrilateral checks
Remove the 0.5f hack
Differentiate axis-aligned rectangles
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
Add a function to check whether a point is inside a quadrilateral
by checking the cross product of vectors with the quadrilateral
points, and the point being checked.
If the passed quadrilateral is zero-sized, no point is ever reported
to be inside it.
This will be used by the next commit when comparing the transformed
actor vertices.
[feaneron: add a commit message and remove unecessary code]
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
If window decoration is modified within a short period of time, mutter
sometimes starts processing the second request before the first
UnmapNotify event has been received. In this situation, it considers
that the window is not mapped and does not expect another UnmapNotify /
MapNotify event sequence to happen.
This adds a separate counter to keep track of the pending reparents. The
input focus is then restored when MapNotify event is received iff all
the expected pending ReparentNotify events have been received.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/657
Threaded swap wait was added for using together with the Nvidia GLX
driver due to the lack of anything equivalent to the INTEL_swap_event
GLX extension. The purpose was to avoid inhibiting the invocation of
idle callbacks when constantly rendering, as the combination of
throttling on swap-interval 1 and glxSwapBuffers() and the frame clock
source having higher priority than the default idle callback sources
meant they would never be invoked.
This was solved in gbz#779039 by introducing a thread that took care of
the vsync waiting, pushing frame completion events to the main thread
meaning the main thread could go idle while waiting to draw the next
frame instead of blocking on glxSwapBuffers().
As of https://gitlab.gnome.org/GNOME/mutter/merge_requests/363, the
main thread will instead use prediction to estimate when the next frame
should be drawn. A side effect of this is that even without
INTEL_swap_event, we would not block as much, or at all, on
glxSwapBuffers(), as at the time it is called, we have likely already
hit the vblank, or will hit it soon.
After having introduced the swap waiting thread, it was observed that
the Nvidia driver used a considerable amount of CPU waiting for the
vblank, effectively wasting CPU time. The need to call glFinish() was
also problematic as it would wait for the frame to finish, before
continuing. Due to this, remove the threaded swap wait, and rely only on
the frame clock not scheduling frames too early.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=781835
Related: https://gitlab.gnome.org/GNOME/mutter/issues/700
[jadahl: Rewrote commit message]
https://gitlab.gnome.org/GNOME/mutter/merge_requests/602
Since Clutter's backend relies on MetaBackend now, initialzation has
to go through meta_init(), both in mutter and in gnome-shell.
However the compositor enum and backend gtype used to enforce the
environment used for tests are private, so instead expose a test
initialization function that can be used from both mutter and
gnome-shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/750
If an application provides its window icon via wmhints, then mutter
loads the pixmap specified by the application into a cairo xlib surface. When
creating the surface it specifies the visual, indirectly, via an XRender
picture format.
This is suboptimal, since XRender picture formats don't have a way to specify
16bpp depth, which an application may be using.
In particular, applications are likely to use 16bpp depth pixmaps for their
icons, if the video card offers a 16bpp framebuffer/root window.
This commit drops the XRender middleman, and just tells cairo a visual to use
directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/715
This currently uses a hack where it pushes a CoglFramebuffer backed by a
texture to the framebuffer stack, then calls clutter_actor_paint() on
the window actor causing it to render into the framebuffer. This has the
effect that all subsurfaces of a window will be drawn as part of the
window.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/752
We are really more interested in when a window is damaged, rather than
when it's painted, for screen casting windows. This also has the benefit
of not listening on the "paint" signal of the actor, meaning it'll open
doors for hacks currently necessary for taking a screenshot of a window
consisting of multiple surfaces.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/752
Make it possible to listen for damage on a window actor. For X11, the
signal is emitted when damage is reported; for Wayland, it is emitted
when any of the surfaces associated with the window is damaged.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/752
Since Clutter's backend relies on MetaBackend now, initialzation has
to go through meta_init(), both in mutter and in gnome-shell.
However the compositor enum and backend gtype used to enforce the
environment used for tests are private, so instead expose a test
initialization function that can be used from both mutter and
gnome-shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/750
Flatten the subsurface actor tree, making all surface actors children
of the window actor.
Save the subsurface state in a GNode tree in MetaWaylandSurface, where
each surface holds two nodes, one branch, which can be the tree root
or be attached to a parent surfaces branch, and a leaf, which is
used to save the position relative to child branch nodes.
Each time a surface is added or reordered in the tree, unparent all
surface actors from the window actor, traverse all leaves of the
tree and readd the corresponding surface actors back to the window
actor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/664
This object can be generally triggered without a X11 display, so make sure
this is alright. For guard window checks, use our internal
meta_stack_tracker_is_guard_window() call, which is already no-x11 aware.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/730
We indirectly were relying on the MetaX11Stack for this. We strictly
need the _NET_CLIENT_LIST* property updates there, so move our own
internal synchronization to common code.
Fixes stacking changes of windows while there's no MetaX11Display.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/730
The MetaShapedTexture created by MetaSurfaceActor used to
be a ClutterActor, which means destruction was taken care
by Clutter.
Now that it's a plain GObject, we need to manually clean it
up.
Cleanup the shaped texture on disposal.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/753
The surface offset allows an application to move itself in relative
coordinates to its previous position. It is rather ill defined and
partly incompatible with other functionality, which is why we ignore
it generally.
For dnd-surfaces though, it is the de-facto standard for applications
to properly position the dnd-icon below the cursor. Therefore apply
the offset on actor sync by setting the feedback actor anchor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/684
Commit b12c92e206 ("wayland: Add MetaWaylandSurface::geometry-changed signal")
Added a "geometry-changed" signal on MetaWaylandSurface, but the matching
changes to src/wayland/meta-pointer-confinement-wayland.c made it listen
for geometry-changed on the surface-actor instead of on the surface itself,
leading to errors like these:
gnome-shell[37805]: ../gobject/gsignal.c:2429: signal 'geometry-changed' is invalid for instance '0x5653aa7cfe50' of type 'MetaSurfaceActorWayland'
This commit fixes this.
Fixes: b12c92e206 ("wayland: Add MetaWaylandSurface::geometry-changed signal")
https://gitlab.gnome.org/GNOME/mutter/merge_requests/751
And add the necessary glue so those initialize a X11 clutter backend.
This should get Clutter tests that are dependent on windowing to work
again, thus they were enabled back again.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendNative, this extends to device manager, input devices,
tools and keymap.
This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendX11, this extends to device manager, input devices,
tools and keymap.
This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
After the introduction of locate-pointer (commit 851b7d063 -
“keybindings: Trigger locate-pointer on key modifier”), inhibiting
shortcuts would no longer forward the overlay key to the client.
Restore the code that was inadvertently removed so that inhibiting
shortcuts works on the overlay key again.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/734
Geometry scale is applied to each surface individually, using
Clutter scales, and not only this breaks subsurfaces, it also
pollutes the toolkit and makes the actor tree slightly too
fragile. If GNOME Shell mistakenly tries to set the actor scale
of any of these surfaces, for example, various artifacts might
happen.
Move geometry scale handling to MetaWindowActor. It is applied
as a child transform operation, so that the Clutter-managed
scale properties are left untouched.
In the future where the entirety of the window is managed by a
ClutterContent itself, the geometry scale will be applied
directly into the transform matrix of MetaWindowActor. However,
doing that now would break the various ClutterClones used by
GNOME Shell, so the child transform is an acceptable compromise
during this transition.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
