The ResetIdletime API can be used instead of an "XTest" binary to
programmatically reset the idle time, as if the user pressed a button on
a keyboard.
This is necessary since we stopped using the XSync extension to monitor
idletimes, as it didn't consider inhibitors as busy, and mutter's
clutter code ignores "Core Events" as generated by XTest.
This patch will require minimal changes to gnome-settings-daemon's power
test suite so that "key press" idletime resets are triggered through
this D-Bus interface rather than through XTest and a roundtrip through
the X server.
https://bugzilla.gnome.org/show_bug.cgi?id=705942
Take idle inhibitions into account for when to fire idle watches as
requested by OS components.
This should stop gnome-session and gnome-settings-daemon considering
the session idle when they have been inhibited for longer than their
timeout, for example to avoid the screensaver activating, or the
computer suspending after watching a film.
https://bugzilla.gnome.org/show_bug.cgi?id=705942
Now that we've removed the X11 specific backend of the idle monitor,
add back a cut-down version of it for the explicit purpose of being
told about idle time resets when XTest events are used.
XTest events are usually used by test suites and remote display software
to inject events into an X11 session. We should consider somebody moving
the mouse remotely to be just as "active" as somebody moving it locally.
https://bugzilla.gnome.org/show_bug.cgi?id=705942
And use the old "native" backend for both X11 and Wayland. This will
allow us to share fixes between implementations without having to delve
into the XSync X11 extension code.
https://bugzilla.gnome.org/show_bug.cgi?id=705942
When moving the pending state of an effectively synchronized subsurface
so it is applied together with the parent, perform a merge of the source
MetaWaylandPendingState into the destination one, instead of simply
overwriting the struct.
The other approach had 2 kind of leaks, one that would happen everytime
a wl_surface.commit happens on a sync subsurface (both surface/buffer
damage regions are leaked). The other more unlikely one would apply on
the rest of pending state data, happening whenever the compositor gets
>1 wl_surface.commit calls on the subsurface before the parent surface
gets its own.
The function has also been renamed to use the more descriptive "merge"
term.
Related: gnome-shell#64
Output ID is set equal to 'i' later in the loop. But 'i' was never
incremented, so all outputs were getting the same ID (equal to
the number of CRTCs, because 'i' was reused from the previous loop).
(cherry picked from commit 23c3f8bb18db499d196f1024732ef3234b44f59c)
Compositor effects change the actor size and position, which can lead to
inconsistent output enter/leave notifications, leaving clients' surfaces
without any output set.
Update output enter/leave notifications after all compositor effects are
completed so that we give clients accurate output location.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/104
When using plugins, the effects will affect the MetaWindowActor size
and position.
Add a new signal "effects-completed" wired to the corresponding
MetaWindowActor which is emitted when all effects are completed so that
derived objects can be notified when all effects are completed and use
the actual size and position.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/104
If we attempt GBM surface allocation with a set of modifiers but the
allocation fails, fall back to non-modifier allocations. This fixes
startup on Pineview-based Atom systems, where KMS provides us a set of
modifiers but the GBM implementation doesn't support modifier use.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/84
Rotating an output would show duplicate cursors when the pointer is
located over an area which would be within the output if not rotated.
Make sure to swap the width/height of the output when rotated.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/85
Rendering the next frame (which mostly happens as part of the flush done
in swap buffers) is a task that the GPU can complete independently of
the CPU having to wait for previous page flips. So reverse their order
to get the GPU started earlier, with the aim of greater GPU-CPU
parallelism.
When using two monitors size by side with different scales, once the
cursor moves from one output to another one, its size changes based on
the scale of the given output.
Changing the size of the cursor can cause the cursor area to change
output again if the hotspot is not exactly at the top left corner of the
area, causing the texture of the cursor to change, which will trigger
another output change, so on and so forth causing continuous surface
enter/leave event which flood the clients and eventually kill them.
Change the logic to use only the actual cursor position to determine if
its on the given logical monitor, so that it remains immune to scale
changes induced by output scale differences.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/83
This state tracks hardware devices' state, thus shouldn't be triggered by
events that were emulated/forwarded by the IM. Those may include modifiers
and would result in xkb_state being doubly set, and possibly stuck.
https://gitlab.gnome.org/GNOME/mutter/issues/74Closes: #74
Commit d714a94d9 added support for stable xdg-shell surfaces while
preserving old unstable zxdg-shell v6 ones, but committed a mistake
in checking for both in the xdg_exporter.export error condition
paths. We want to check that the surface is neither of both.
https://gitlab.gnome.org/GNOME/mutter/issues/63Closes: #63
Raising and lowering windows in tandem without a proper grouping
mechanism ended up being more annoying than functional.
This reverts commit e76a0f564c.
We just arbitrarily chose the first EGL config matching the passed
attributes, but we then assumed we always got GBM_FORMAT_XRGB8888. That
was not a correct assumption. Instead, make sure we always pick the
format we expect.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/2
When painting the titlebar, button icons that aren't available in the
desired size need to be scaled. However the current code inverses the
scale factor, with the result that the adjusted icons are much worse
than the original icons, whoops.
This went unnoticed for a long time given that most icons are availa-
ble in the desired 16x16 size, and the most likely exceptions - window
icons - are not shown by default.
https://gitlab.gnome.org/GNOME/mutter/issues/23
In order to let applications gracefully handle version mismatches, add
a version property to the APIs. Also add a warning on the APIs that
these are not meant for public consumption.
If the coordinates was for a stream not at the stage position (0, 0),
they'd be incorrect. Fix this by correctly translating the coordinates
according to the stream position.
Make the Wayland objects push the state relevant to their role to the
MetaSurfaceActor instead of MetaSurfaceActorWayland pulling the state
from the associated surface.
This makes the relationship between the actor and the objects that
constructs it more clear; the actor is a drawable that the protocol
objects control, not the other way around.
This will make it easier to "detach" a surface actor from a surface,
which is necessary when unmapping a window while the underlying surface
is yet to be destroyed and potentially reused.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/5https://bugzilla.gnome.org/show_bug.cgi?id=791938
This commit moves out non-core wl_surface related code into separate
code units, while renaming types to fit a common scheme. The changes
done are:
* ClutterActor based surface roles built upon
MetaWalyandSurfaceRoleActorSurface. This object has been renamed to
MetaWaylandActorSurface and related functionality has moved into
meta-wayland-actor-surface.c.
* The code related to roles backed by a MetaWindow (i.e. built upon
MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c
* The majority of subsurface related code was moved into into
meta-wayland-subsurface.c and the object was renamed
MetaWaylandSubsurface.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/5https://bugzilla.gnome.org/show_bug.cgi?id=791938
mutter would discard the shape region set by the client if its matches
the entire client area in meta_window_x11_update_shape_region().
However, if the window is later resized (maximized or other), the
compositor will fail to update the shape region properly for undecorated
windows because the shape region was discarded, which causes black areas
to appear in place of the updated areas.
If the client window is undecorated, keep the shape region even if when
it matches the client area.
https://gitlab.gnome.org/GNOME/mutter/issues/27Closes: #27
When the buffer modifier is DRM_FORMAT_MOD_LINEAR, we can use the
old code path. That means not specifying any modifier parameter.
It was an issue when the primary GPU was creating a linear GBM surface
and that a secondary GPU (not supporting modifiers) was trying to
import it. It was failing because the driver could not use the
import_modifiers extension even though it could in theory easily
import the buffer.
https://gitlab.gnome.org/GNOME/mutter/issues/18
We were retrieving the supported KMS modifiers for all GPUs even
though what we really need to intersect between these sets of
modifiers:
1) KMS supported modifiers for primary GPU if the GPU is used for
scanout;
2) EGL supported modifiers for secondary GPUs (different than the
primary GPU used for rendering);
3) GBM supported modifiers when creating the surface (already
taken care of by gbm_surface_create_with_modifiers());
https://gitlab.gnome.org/GNOME/mutter/issues/18
So the changes can be instantly applied while the tool is in proximity.
Before we would just do it on proximity-in, which doesn't provide a
good look&feel while modifying the tool settings in g-c-c.
https://gitlab.gnome.org/GNOME/mutter/issues/38Closes: #38
If text_input_enable() is called when there no active IM (eg. running plain
mutter), some ClutterInputFocus method calls that are not allowed while
unfocused will end up called, triggering critical warnings.
If there is no IM return early here, all other calls are superfluous then.
We currently don't handle NULLs on these correctly, yet they can be
so when running nested. Just refrain from sending those wp_tablet(_pad)
events in that case.
The property has been 32 bits since around 2011 and has not changed, mutter
expects it to be 8 bits. The mismatch causes change_property to never
actually change the property.
https://gitlab.gnome.org/GNOME/mutter/issues/26Closes: #26
The window checks in the XPropertyEvent handler were wrong both
ways, so transfers would be left stale after the first chunk was
dealt with.
https://gitlab.gnome.org/GNOME/mutter/issues/1Closes: #1
Plain input stream read() calls don't provide hard guarantees about
the number of bytes read, but the async method callback sort of
relies on bytes being less than requested only when reaching the
end of the transmitted data. If that happens mid transfer, that
doesn't bode well.
This is actually the behavior of g_input_stream_read_all(), so
switch to using it.
This was done by the clutter X11 backend before prior to introducing
MetaRenderer, but during that work, enabling of said extension was lost.
Let's turn it on again.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
This is in order to force running as a X11 window manager/compositing
manager. Useful for debugging and other cases where the automatic
detection does not work as expected.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/15
If for whatever reason, there are stalled files in /tmp/.X11-unix/ the
bind() to the abstract socket will succeed but not the bind() to the
to the UNIX socket.
This causes gnome-shell/mutter to fail because it cannot start Xwayland
(while it could actually, by using a different display).
In case of failure to bind to the UNIX socket, try the next display
instead of failing, to avoid stalled entries in /tmp/.X11-unix.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/13
The shortcut inhibitor protocol states that the “active” event should be
sent every time compositor shortcuts are inhibited on behalf of the
surface.
However, mutter would send that event only if the surface is focused,
which might not be the case if focus is on a shell surface.
Send the “active” event unconditionally to match the protocol
definition.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/10
There seems to be a kernel race when one disconnects an external
monitor connected to a DisplayPort via a USB-C adapter. The race
results in a connector being reported as connected, but without any
modes supported.
This had the side effect that we tried to set a preferred mode to
the first listed mode, but as no modes were available, we instead tried
to dereference the first element of a NULL array, causing a
segmentation fault.
Mitigate this by skipping adding output if no supported modes are
advertised and the output doesn't support scaling, while moving the
fallback path for calculating a preferred output mode to after possibly
adding the common modes, to avoid the unvolentary NULL dereference.
https://bugzilla.gnome.org/show_bug.cgi?id=789501
Opening and closing the device may result into XI2 grabs being cut short,
resulting into pad buttons being rendered ineffective, and other possible
misbehaviors. This is an XInput flaw that fell in the gap between XI1 and
XI2, and has no easy fix. It pays us for mixing both versions, I guess...
Work this around by keeping the XI1 XDevice attached to the
ClutterInputDevice, this way it will live long enough that this is not
a concern.
Investigation of this bug was mostly carried by Peter Hutterer, I'm just
the executing hand.
https://gitlab.gnome.org/GNOME/mutter/issues/7Closes: #7
A comparison in translate_device_event() does not account for the fact
that X's clock wraps about every 49.7 days. When triggered, this causes
an unresponsive GUI.
Replace simple less-than comparison with XSERVER_TIME_IS_BEFORE macro,
which accounts for the wrapping of X's clock.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/12
The tertiary-button-action (see bug 790028) is a place for g-c-c to store
the action which should be performed when a stylus' third button is pressed.
Pressing this button is signaled as a BTN_STYLUS3 event from the kernel or
X11 button 8.
https://bugzilla.gnome.org/show_bug.cgi?id=790033
When a window's workspace is not NULL, on_all_workspace should be FALSE.
Similarly, when on_all_workspace is TRUE, the window workspace should be
NULL.
This is an assumption in multiple places in the code, including when
setting the workspace state, the window is either added or removed from
all workspaces only if the window's workspace is NULL.
This rule is initially enforced at creation in _meta_window_shared_new()
when a initial workspace is set. However, when the initial workspace is
set from the session info, the initial workspace is not marked as “set”
which leads to an assertion failure when unmanaging windows, because the
window is not removed from all the workspaces.
When applying the session info to a window, mark the workspace as “set”.
https://gitlab.gnome.org/GNOME/mutter/issues/4Closes: #4
Having “on_all_workspaces_requested” FALSE on a window does not imply a
workspace is set.
If the X11 window is placed on a secondary monitor while workspaces
applies on primary monitor only (“workspaces-only-on-primary” set) then
“on_all_workspaces_requested” is FALSE while “on_all_workspaces“ is TRUE
and the associated workspace is NULL, leading to a crash when saving the
gnome-shell/mutter session.
So if no workspace is set, use the “initial_workspace” instead to avoid
a NULL pointer dereference.
https://bugzilla.gnome.org/show_bug.cgi?id=792818
Now that we have the list of supported modifiers from the monitor
manager (via the CRTCs to the primary planes), we can use this to inform
EGL it can use those modifiers to allocate the GBM surface with. Doing
so allows us to use tiling and compression for our scanout surfaces.
This requires the Mesa commit in:
Mesa 10.3 (08264e5dad4df448e7718e782ad9077902089a07) or
Mesa 10.2.7 (55d28925e6109a4afd61f109e845a8a51bd17652).
Otherwise Mesa closes the fd behind our back and re-importing will fail.
See FDO bug #76188 for details.
https://bugzilla.gnome.org/show_bug.cgi?id=785779
Newer versions of GBM support buffer modifiers, including multi-plane
buffers. Use this new API to explicitly pull the information from GBM,
and feed it to drmModeAddFB2WithModifiers.
https://bugzilla.gnome.org/show_bug.cgi?id=785779
The KMS IN_FORMATS blob property contains a structure defining which
format/modifier combinations are supported for each plane. Use this to
extract a list of acceptable modifiers to use for the primary plane for
XRGB8888, so we can ask EGL to allocate tiled/compressed buffers for
scanout when available.
https://bugzilla.gnome.org/show_bug.cgi?id=785779
Using 800x600 as minimum logical size is very 4:3 thinking, while a lot of
modern devices are 16:9. The specific reason for this commit is to allow
1.5 scaling at mini-laptops (clamshell devices) with e.g. a 5.5"
1280x720 screen. Given that this device has a keyboard, one obviously
is not holding it very close to ones eyes and at 220 dpi that means the text
is too small at scale 1.0. For one real world example of such a device see:
https://en.wikipedia.org/wiki/GPD_Winhttps://bugzilla.gnome.org/show_bug.cgi?id=792765
Offer the text-input interface global, so it can be used by clients. The
MetaWaylandSeat will also let MetaWaylandTextInput intercept key events
before the keyboard interface handles those.
This is the implementation of the internal text-input protocol that will
be used to communicate IMs (to be implemented by gnome-shell) with clients.
The text_input protocol has its own focus expressed through enter/leave
events, that will typically follow the keyboard's.
The client will be able to communicate its current status (eg. focus state,
cursor rectangle in surface coordinates, text surrounding the cursor
position, ...) and will receive commands from the compositor (eg. preedit
text, committing a string, ...).
Whenever there is an active input method, the compositor will route key
events directly through it. The client will not receive wl_keyboard
events if the event is consumed by the IM.
Issuing a shortcut inhibit request for a surface without a window set
will lead to a crash when trying to show the shortcut inhibitor dialog.
In such a case, it's safer to deny the request.
https://bugzilla.gnome.org/show_bug.cgi?id=792599
The events might fall through if there's no corresponding active
pointer/keyboard/touch interface. Barring bugs this should be safe to do,
just a bit wasteful.
When maximizing a window, the previous location is saved so that
un-maximize would restore the same original window location.
However, if a Wayland client starts with a window maximized, the
previous location will be 0x0, so if we have to force placement in
xdg_toplevel_set_maximized(), we should update the location as well so
that the window is placed on the right monitor when un-maximizing.
For that purpose, add a new flag to force the update of the window
location, and use that flag from xdg_toplevel_set_maximized().
https://bugzilla.gnome.org/show_bug.cgi?id=783901
Wayland clients know their size better, so for Wayland we'd rather not
try to resize the client on un-maximize, but for this to work we need a
new MetaMoveResizeFlags.
https://bugzilla.gnome.org/show_bug.cgi?id=783901
When closing a window and showing a new one, the new one may not be
granted input focus until it gets a buffer on Wayland.
If another window is chosen to receive focus and raised on top of stack,
the newly mapped window is focused but placed underneath that other
window.
Meaning that for Wayland surfaces, we need to defer adding the window to
the stack until we actually get to show it, once we have a buffer
attached.
Rather that checking the windowing backend prior to decide if a window
is stackable or not, introduce a new vfunc is_stackable() which tells
if a window should be added to the stack regardless of the underlying
windowing system.
Also add meta_window_is_in_stack() API rather than checking the stack
position directly (replacing the define WINDOW_IN_STACK only available
in stack.c) and remove a window from the stack only if it is present
in the stack, so that the test in meta_stack_remote() becomes
irrelevant.
https://bugzilla.gnome.org/show_bug.cgi?id=780820
Wayland clients using the wl_shell interface were never receiving mouse
input. It meant they also couldn't be raised with a click.
This was because the call to meta_wayland_surface_set_window for wl_shell
surfaces did nothing while surface->window == window already. As such, it
never called clutter_actor_set_reactive() and the wl_shell window remained
a non-reactive actor.
Just make sure surface->window isn't already set before calling
meta_wayland_surface_set_window so it can actually do what it's meant to.
https://bugzilla.gnome.org/show_bug.cgi?id=790309
