If a window already is being pinged, it doesn't make sense to send more
pings to the window, instead we should just wait for that answer or
timeout until we send a new one.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/891
Using a timestamp twice in a row (e.g. when activating two windows in
response to the same event or due to other bugs) will break the window
detection and show a close dialog on the wrong window. This is a grave
error that should never happen, so check every timestamp before sending
the ping for uniqueness and if the timestamp was already used and its
ping is still pending, log a warning message and don't send the ping.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/891
Increase the number of checks whether a window is still responsive and
ping windows on every call to `meta_window_focus()` instead of
`meta_window_activate_full()`. This ensures the window is also pinged in
case normal interaction like clicks on the window happen and a close
dialog will eventually get shown.
Related https://gitlab.gnome.org/GNOME/mutter/issues/395https://gitlab.gnome.org/GNOME/mutter/merge_requests/891
Currently when a window is requested to be unredirected, the
corresponding pixmap and texture can get cleared before the window has
been unredirected by the X server. This can result in the windows behind
showing through which causes a short flicker after showing an OSD or
notification when a fullscreen application is running.
Fix this by ensuring the texture is only cleared after the window has
been unredirected by the server.
Similarly when the window is being redirected again, the pixmap of the
window can only be requested after the redirection has been completed by
the server. This currently can happen in a different frame than the next
redraw of the actor resulting in an empty texture until the next redraw.
Fix this by queuing a redraw immediately after redirecting.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/997
By default clutter will show an actor as it is added to a parent. This
means that after we create the window actor, when it's added to the
window group, we implicitly show it. What we really want is to not show
it until the window is supposed to be shown, which happens when
meta_window_actor_show() is called, as showing prior to that, could
cause issues.
Avoid the implicit show by setting the "show-on-set-parent" property on
the window actor to `FALSE` on window actor construction.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1066
We didn't log what we enabled, just g_info():ed what failed to be
enabled. Change this to g_warning() what failed to be enabled, and
g_message() on what was enabled, so that both will be visible in the
logs.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1061
We preserve the core one, which represents the union of all input
devices. It might make sense to make this per-seat in the future,
but certainly the per-device granularity is unused (at last!) and
useless.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1039
XWayland clients get their opaque region set from their window, not the
surface. Doing both resulted in the surface constantly overwriting the
opaque region - effectively disabling culling of XWayland clients.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1049
Devices have capabilities that other parts need to know about. Instead
of having them probe using drmMode* API, outsource this to
MetaKmsDevice. Currently the only capability tracked is HW cursor size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
Turns the cursor setting and movement into cursor plane assignment
primitives. In the current simple implementation, this in turn
translates into legacy drmModeSetCursor() and drmModeMoveCursor() calls.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
A cursor plane can now be assigned, and for the simple KMS
implementation, it'll translate into drmModeSetCursor() and
drmModeMoveCursor() calls.
When assignments failed, the cursor planes that failed to be assigned
are communicated via the feedback object.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
The current API as all synchronous, so they can be made to return
feedback immediately. This will be needed for the cursor renderer which
needs to know whether it should fall back to OpenGL cursor rendering.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
meta_kms_update_process_..() makes it sound like it's a MetaKmsUpdate
function called update_..() but in fact it's a MetaKms function that
calls the corresponding process-update impl function. Clear up this
naming confusion.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
The frame bounds as returned by `meta_window_actor_get_frame_bounds()`
would be used as cropping values when streaming a window content.
But, as its name implies, it returns the actual frame bounds, whereas we
may want to include the whole buffer, to include client side shadows for
example.
Rename the `get_frame_bounds()` API to `get_buffer_bounds()` (which was
previously partly removed with commit 11bd84789) and return the actual
buffer bounds to use as the cropping area when streaming a window.
Fixes: 931934511 - "Implement MetaScreenCastWindow interface"
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1022
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1018
The clip bounds passed in `meta_window_actor_capture_into()` represent
the actual allocated buffer size where the window actor image will be
eventually copied.
As such, it is completely agnostic to the scaling factors that might
affect the different surface actors which compose the window actor.
So instead of trying to compute the scale factor by which the given
clipping bounds need to be adjusted, simply clip the resulting image
based on the given bounds to make sure we never overflow the destination
buffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1022
