Install include files in
$prefix/include/mutter-$apiversion/[clutter,cogl,...,meta]/, and
datafiles in /usr/share/mutter-$apiversion/.... We still would conflict
e.g. given that our gettext name is "mutter", and how keybindings are
installed, but it's a step in the right direction.
This is the filename convention you get when you define a shared module
in meson, and since there is no particular reason to not include the
"lib" prefix, lets make it easier to port it over. While at it,
de-duplicate the retrieval of the plugin name.
It'll be installed in the meta/ directory, so put the template files in
the corresponding directory in the tarball. This will also simplify the
port to meson.
While leaving the runtime checks in place, requiring xrandr 1.5 at build
time allows us to remove some seemingly unnecessary conditional
inclusion of functionality.
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
testboxes was a binary that did unit testing, but it wasn't integrated
to the test system, so in effect, it was never run. Instead integrate it
into the other mutter unit tests. This includes changing a few of
meta_warning()s into g_warning()s so that the GTest framework can handle
them.
Closing a GdkDisplay during an event handler is not currently supported by Gdk
and it will result in a crash when doing e.g. 'mutter --replace'. Using an idle
function will close it safely in a subsequent main loop iteration.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/595
meta_workspace_manager_override_workspace_layout is implemented by
calling meta_workspace_manager_update_workspace_layout which
respects the workspace_layout_overridden flag. After the first call
to meta_workspace_manager_override_workspace_layout all subsequent
calls fail silently.
Reset workspace_layout_overridden to FALSE before calling
meta_workspace_manager_update_workspace_layout.
https://gitlab.gnome.org/GNOME/mutter/issues/270
drmModePageFlip() is guaranteed to fail for the invalid FB id 0.
Therefore it never makes sense to call this function with such argument.
Disabling a CRTC must be done with SetCrtc instead, for example.
Trying to flip to FB 0 not only fails, but it also causes Mutter to
never try page flip on this output again, using drmModeSetCrtc()
instead.
There was a race in setting next_fb_id when a secondary GPU was using
the CPU copy path. Losing this race caused the attempt to
drmModePageFlip () to FB ID 0 which is invalid and always fails. Failing
to flip causes Mutter to fall back to drmModeSetCrtc () permanently.
In meta_onscreen_native_swap_buffers_with_damage ():
- update_secondary_gpu_state_pre_swap_buffers ()
- copy_shared_framebuffer_cpu () but only on the CPU copy path
- secondary_gpu_state->gbm.next_fb_id is set
- wait_for_pending_flips ()
- Waits for any remaining page flip events and executes and destroys
the related page flip closures.
- on_crtc_flipped ()
- meta_onscreen_native_swap_drm_fb ()
- swap_secondary_drm_fb ()
- secondary_gpu_state->gbm.next_fb_id = 0;
- meta_onscreen_native_flip_crtcs ()
- meta_onscreen_native_flip_crtc ()
- meta_gpu_kms_flip_crtc () gets called with fb_id = 0
This race was observed lost when running 'mutter --wayland' on a machine
with two outputs on Intel and one output on DisplayLink USB dock, and
wiggling around a weston-terminal window between the Intel and
DisplayLink outputs. It took from a second to a minute to trigger. For
testing with DisplayLink outputs Mutter also needed a patch to take the
DisplayLink output into use, as it would have otherwise been ignored
being a platform device rather than a PCI device.
Fix this race by first waiting for pending flips and only then
proceeding with the swap operations. This should be safe, because the
pending flips could have completed already before entering
meta_onscreen_native_swap_buffers_with_damage ().
We might unset focus, or already be out of focus (e.g. an X11 client or
clutter text entry is focused) when a text-input state is committed by
the client. We handled this before, except when text input was
explicitly disabled by the client, the Wayland text-input was in focus
by the input method, and it focused itself out.
Simplify the logic a bit by just dropping the state on the floor in all
cases where after any potential focus changes were done, we are not
focused.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/353
Commit 840378ae68 changed the code to use XmbTextPropertyToTextList()
instead of gdk_text_property_to_utf8_list_for_display(), but didn't
take into account that the replacement returns text in the current
locale's encoding, while any callers (rightfully) expect UTF8.
Fix this by converting the text if necessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/227
The WM_NAME property is of type TEXT_PROPERTY, which is supposed to be
returned as UTF-8. Commit 840378ae68 broke that assumption, resulting
in crashes with non-UTF8 locales; however the "fix" of converting from
LATIN1 to UTF8 is wrong as well, as the conversion will spit out garbage
when the input encoding isn't actually LATIN1.
Now that the original issue in text_property_to_utf8() has been fixed,
we can simply revert the relevant bits of commit d62491f46e.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/227
In order to allow a window with a custom rule placement to be moved
together with its parent, the final rule used derived from the
constraining were used for subsequent constraints. This was not enough
as some constraining cannot be translated into a rule, such as sliding
across some axis.
Instead, make it a bit simpler and just remember the position relative
to the parent window, and use that the next time.
This is a rework of 5376c31a33 which
caused the unwanted side effects.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/332
When constructing MetaMonitorsConfig objects, store which type
of switch_config they are for (or UNKNOWN if it is not such
type of config).
Stop unconditionally setting current_switch_config to UNKNOWN when
handling monitors changed events. Instead, set it to the switch_config
type stored in the MonitorsConfig in the codepath that updates logical
state. In addition to being called in the hotplug case along the same
code flow that generates monitors changed events, this is also called
in the coldplug case where a secondary monitor was connected before
mutter was started.
When creating the default linear display config, create it as a
switch_config so that internal state gets updated to represent
linear mode when this config is used.
The previous behaviour of unconditionally resetting current_switch_config
to UNKNOWN was breaking the internal state machine for display config
switching, causing misbehaviour in gnome-shell's switchMonitor UI when
using display switch hotkeys. The lack of internal tracking when the
displays are already in the default "Join Displays" linear mode was
then causing the first display switch hotkey press to do nothing
(it would attempt to select "Join Displays" mode, but that was already
active).
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/281https://gitlab.gnome.org/GNOME/mutter/merge_requests/213
When repicking after a surface was destroyed, if the destroyed surface
was the drag focus, we'd try to focus-out from it after it was
destroyed, causing a NULL pointer dereference.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/336
With Wayland, a window is not showing until it's shown. Until this
patch, the initial state of MetaWindow, on the other hand, was that a
window is initialized as showing. This means that for a window to
actually be classified as shown (MetaWindow::hidden set to FALSE),
something would first have to hide it.
Normally, this wasn't an issue, as normally we'd first create a window,
determine it shouldn't be visible (due to missing buffer), hide it
before the next paint, then eventually show it. This doesn't work if
mutter isn't drawing any frames at the moment (e.g. the user switched
VT), as we'd miss the hiding before showing as e result of a buffer
being attached. The most visible side effect is that a window can't be
moved as the window actor remains frozen.
This commit fixes this issue by correctly classifying a newly created
Wayland window as "hidden".
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/331
The clip and opaque region are both in a translated stage coordinate
space, where the origin is in the top left corner of the painted
texture. The painting, however, is in the texture coordinate space,
so when the texture is scaled, the coordinate spaces differ.
Handle this by transforming the clip and opaque region to texture
coordinate space before computing the blend region and the opaque region
to paint.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/300
They were int before entering MetaShapedTexture, used as ints in the
cairo regions and rectangles, so there is no reason they should be
stored as unsigned.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/300
meta_renderer_native_gles3_read_pixels() was assuming that the target
buffer stride == width * 4. This is not generally true. When a DRM
driver allocates a dumb buffer, it is free to choose a stride so that
the buffer can actually work on the hardware.
Record the driver chosen stride in MetaDumbBuffer, and use it in the CPU
copy path. This should fix any possible stride issues in
meta_renderer_native_gles3_read_pixels().
Track the allocated dumb buffer size in MetaDumbBuffer. Assert that the
size is as expected in copy_shared_framebuffer_cpu().
This is just to ensure that Cogl and the real size match. The size from
Cogl was used in the copy, so getting that wrong might have written
beyond the allocation.
This is a safety measure and has not been observed to happen yet.
If drmModeAddFB2() does not work, the fallback to drmModeAddFB() can
only handle a single specific format. Make sure the requested format is
that one format, and fail the operation otherwise.
This should at least makes the failure mode obvious on such old systems
where the kernel does not support AddFB2, rather than producing wrong
colors.
To avoid a known race condition in the wl_output protocol documented in
https://phabricator.freedesktop.org/T7722, mutter delays the `wl_output`
destruction but nullify the `logical_monitor` associated with the
`wl_output` and the binding routine `bind_output()` makes sure not to
send wl_output events if the `logical_monitor` is `NULL` (see commit
1923db97).
The binding routine for `xdg_output` however does not check for such a
condition, hence if the output configuration changes while a client is
binding to xdg-output (typically Xwayland at startup), mutter would
crash while trying to access the `logical_monitor` which was nullified
by the change in configuration.
Just like `bind_output()` does for wl_output, do not send xdg-output
events if there is no `logical_monitor` yet.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/194
Changes in window decoration result in the window being reparented
in and out its frame. This in turn causes unmap/map events, and
XI_FocusOut if the window happened to be focused.
In order to preserve the focused window across the decoration change,
add a flag so that the focus may be restored on MapNotify.
Closes: #273
The compositor will automatically unredirect the top most window which
is fully visible on screen. When unredirecting windows, it also shapes
the compositor overlay window (COW) so that other redirected windows
still shows correctly.
The function `get_top_visible_window_actor()` however will simply walks
down the window list, so if a window is placed on a layer above and
unredirected, then iconified by the client, it will still be picked up
by `get_top_visible_window_actor()` and he compositor will reckon it's
still unredirected while not in a visible state anymore, thus leaving a
black area on screen.
Make sure we skip the windows not known to the compositor while picking
the top visible window actor to avoid this issue.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/306
Previously, trackballs were detected based on the presence of the
substring "trackball" in the device name. This had the downside of
missing devices, such as the Kensington Expert Mouse, which don't have
"trackball" in their names.
Rather than depending on the device name, use the ID_INPUT_TRACKBALL
property from udev to determine whether or not to treat a device as a
trackball.
This adds a new function, `is_trackball_device`, to MetaInputEvents, and
eliminates the `meta_input_device_is_trackball` function.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/258
On Wayland, xdg-foreign would leave a modal dialog managed even after
the imported surface is destroyed.
This is sub-optimal and this breaks the atomic relationship one would
expect between the parent and its modal dialog.
Make sure we unmanage the dialog if transient_for is unset even for
Wayland native windows.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/174
Related: https://gitlab.gnome.org/GNOME/mutter/issues/221
When we update the main monitor, there is a rule that makes it so that
popup windows use the same main monitor as their parent. In the commit
f4d07caa38 the call that updates and
fetches the main monitor of the toplevel accidentally changed to update
from itself, causing a indefinite recursion eventually resulting in a
crash.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/279
A window placed using a placement rule should keep that relative
position even if the parent window moves, as the position tied to the
parent window, not to the stage. Thus, if the parent window moves, the
child window should move with it.
In the implementation in this commit, the constraints engine is not
used when repositioning the children; the window is simply positioned
according to the effective placement rule that was derived from the
initial constraining, as the a xdg_popup at the moment cannot move
(relative its parent) after being mapped.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/274
As with xdg-toplevel, a gtk-surface can be unmanaged by the compositor
without the client knowing about it, meaning the client may still send
updates and make requests. Handle this gracefully by ignoring them. The
client needs to reset all the state anyway, if it wants to remap the
same surface.
https://gitlab.gnome.org/GNOME/mutter/issues/240
As with xdg-toplevel proper, a legacy xdg-toplevel can be unmanaged by
the compositor without the client knowing about it, meaning the client
may still send updates and make requests. Handle this gracefully by
ignoring them. The client needs to reassign the surface the legacy
xdg-toplevel role again, if it wants to remap the same surface, meaning
all state would be reset anyway.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/240
A toplevel window can be unmanaged without the client knowing it (e.g. a
modal dialog being unmapped together with its parent. When this has
happened, take frame callbacks queued on a commit and cache them on the
generic surface queue. If the toplevel is to be remapped because the
surface was reassigned the toplevel role, the cached frame callbacks
will be queued on the surface actor and dispatched accordingly.
https://gitlab.gnome.org/GNOME/mutter/issues/240
A window can be unmanaged without asking the client to do it, for
example as a side effect of a parent window being unmanaged, if the
child window was a attached dialog.
This means that the client might still make requests post updates to it
after that it was unmapped. Handle this gracefully by NULL-checking the
surface's MetaWindow pointer. We're not loosing any state due to this,
as if the client wants to map the same surface again, it needs to either
reassign it the toplevel role, or reset the xdg-toplevel, both resulting
in all state being lost anyway.
https://gitlab.gnome.org/GNOME/mutter/issues/240
A toplevel window can be unmanaged without the client knowing it (e.g. a
modal dialog being unmapped together with its parent. When this has
happened, take frame callbacks queued on a commit and cache them on the
generic surface queue. If the toplevel is to be remapped, either because
the surface was reassigned the toplevel role, or if it was reset and
remapped, the cached frame callbacks will be queued on the surface actor
and dispatched accordingly.
https://gitlab.gnome.org/GNOME/mutter/issues/240
A popup can be reset, and when that happens, window and actor are
destroyed, and won't be created again unless it is reassigned the
popup role.
If a client queued frame callbacks when resetting a popup, the frame
callbacks would be left in the pending state, as they were not queued on
the actor, meaning we'd hit an assert about the frame callbacks not
being handled. Fix this by caching them on the MetaWaylandSurface, so
that they either are cleaned up on destruction, or queued on the actor
would the surface be re-assigned the popup role.
https://gitlab.gnome.org/GNOME/mutter/issues/240
Sometimes it may be useful for roles to put callbacks in the generic
surface frame callback queue. The surface frame callback queue will
either eventually be processed on the next surface role assignment that
places the frame callbacks in a role specific queue, processed at some
other point in time by a role, or cleaned up on surface destruction.
https://gitlab.gnome.org/GNOME/mutter/issues/240
When a xdg-toplevel is reset, the window and actor are recreated, and
all state is cleared. When this happened, we earlied out from the
xdg-toplevel commit handler, which would mean that if the client had
queued frame callbacks when resetting, they'd be left in the pending
commit state, later hitting an assert as they were not handled.
Fix this by queuing the frame callbacks no the new actor, so that they
are emitted whenever the actor is eventually painted.
https://gitlab.gnome.org/GNOME/mutter/issues/240
This was done for input regions in commit 718a89eb2f (Thanks Jonas
for the archaeology!) but opaque regions follow the same scaling.
This brings less evident issues as opaque regions are just used for
culling optimizations.
Commit 6a92c6f83 unintendedly broke input/opaque region calculations
on hidpi. Most visible side effect is that clicking is only allowed
in the upper-left quarter of windows.
The surface coordinates are returned in logical unscaled buffer
size. We're however interested in actor coordinates (thus real
pixels) here.
As it is a bit of a detour how the scale to be applied is calculated,
refactor a meta_wayland_actor_surface_get_geometry_scale() function
that we can use it here, and use it consistently for surface size and
the given regions.
Commit a3da4b8d5b changed updating of
window monitors to always use take affect when it was done from a
non-user operation. This could cause feed back loops when a non-user
driven operation would trigger the changing of a monitor, which itself
would trigger changing of the monitor again due to a window scale
change.
The reason for the change, was that when the window monitor changed due
to a hot plug, if it didn't actually change, eventually the window
monitor pointer would be pointing to freed memory.
Instead of force updating the monitor on all non-user operations, just
do it on hot plugs. This allows for the feedback loop preventing logic
to still do what its supposed to do, without risking dangling pointers
on hot plugs.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/189
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/192
The bool determines whether the call was directly from a user operation
or not. To add more state into the call without having to add more
boolenas, change the boolean to a flag (so far with 'none' and 'user-op'
as possible values). No functional changes were made.
https://gitlab.gnome.org/GNOME/mutter/issues/192
The "backends: Move MetaOutput::crtc field into private struct"
accidentally changed the view transform calculation code to assume that
"MetaCrtc::transform" corresponds to the transform of the CRTC; so is
not the case yet; one must calculate the transform from the logical
monitor, and check whether it is supported by the CRTC using
meta_monitor_manager_is_transform_handled(). This commit restores the
old behaviour that doesn't use MetaCrtc::transform when calculating the
view transform.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/216
XcursorLibraryLoadCursor can return 'None' if the current cursor theme
is missing the requested icon. If XFreeCursor is then called on this
cursor, it generates a BadCursor error causing gnome-shell to crash.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/254
We need a way for mutter to exit if no available GPUs are going to work.
For example if gdm starts gnome-shell and we're using a DRM driver that
doesn't work with KMS then we should exit so that GDM can try with Xorg,
rather than operating in headless mode.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/223
As per specification
> The compositor ignores the parts of the input region that
> fall outside of the surface.
> The compositor ignores the parts of the opaque region that
> fall outside of the surface
This fixes culling problems under certain conditions.
Currently xdg-shell applies a geometry set with set_window_geometry
unconditionally. But the specification requires:
> When applied, the effective window geometry will be
> the set window geometry clamped to the bounding rectangle of the
> combined geometry of the surface of the xdg_surface and the
> associated subsurfaces.
This is especially important to implement viewporter and
transformation.
By using the shm file when sending the keymap to all clients, we
effectively allows any client to change the keymap, as any client has
the ability to change the content of the file. Sending a read-only file
descriptor, or making the file itself read-only before unlinking, can
be worked around by the client by using chmod(2) and open(2) on
/proc/<pid>/<fd>.
Using memfd could potentially solve this issue, but as the usage of
mmap with MAP_SHARED is wide spread among clients, such a change can
not be introduced without causing wide spread compatibility issues.
So, to avoid allowing clients to interfere with each other, create a
separate shm file for each wl_keyboard resource when sending the
keymap. We could eventually do this per client, but in most cases,
there will only be one wl_keyboard resource per client anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=784206
If a client maps a popup in response to a key-down event, but the
mapping doesn't occur until after the user has already released the same
button, we'd immediately dismiss the popup. This is problematic, as one
often presses and releases a key quite quickly, meaning any popup mapped
on key-down are likely to be dismissed.
Avoid this race condition by accepting serials for key down events, if
the most recent key-up event had the same keycode.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/180
This protocol supersedes the internal gtk_text_input protocol that
was in place. Functionally it is very similar, with just some more
verbosity in both ways (text_change_cause, .done event), and some
improvements wrt the pre-edit text styling.
meta_backend_x11_grab_device is performing X server clock comparison
using the MAX macro, which comes down to a simple greater-than.
Use XSERVER_TIME_IS_BEFORE, which is a better macro for X server
clock comparisons, as it accounts for 32-bit wrap-around.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/174
Commit c0d9b08ef9 replaced the old GBM API calls
with the multi-plane GBM API. However, the call to gbm_bo_get_handle_for_plane
fails for some DRI drivers (in particular i915). Due to missing error checks,
the subsequent call to drmModeAddFB[2] fails and the screen output locks up.
This commit adds the missing error checks and falls back to the old GBM API
(non-planar) if necessary.
v5: test success of gbm_bo_get_handle_for_plane instead of errno
This commit adopts solution proposed by Daniel van Vugt to check the return
value of gbm_bo_get_handle_for_plane on plane 0 and fall back to old
non-planar method if the call fails. This removes the errno check (for
ENOSYS) that could abort if mesa ever sets a different value.
Related to: https://gitlab.gnome.org/GNOME/mutter/issues/127
If the surface is gone before `meta_xwayland_keyboard_grab_end()` is
called, we would bail out early leaving an empty grab, which will cause
a segfault as soon as a key is pressed later on.
Make sure we clean up the keyboard grab even if the surface is gone.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/255
The string used to point to memory owned by libwayland-server, but
with the ability to override the display name, we took over ownership
by copying the string as necessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
The function is intentionally provided as macro to not require a
cast. Recently the macro was improved to check that the passed in
pointer matches the free function, so the cast to GDestroyNotify
is now even harmful.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
Thanks to G_DEFINE_DYNAMIC_TYPE_EXTENDED(), this is a trivial addition that
will allow using G_IMPLEMENT_INTERFACE_DYNAMIC() or G_ADD_PRIVATE_DYNAMIC()
when declaring a plugin.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
For historical reasons meta_monitor_is_active() checked whether it is
active by checking whether the main output have a CRTC assigned and
whether that CRTC has a current mode. At a later point, the MetaMonitor
got its own mode abstraction (MetaMonitorMode), but
meta_monitor_is_active() was never updated to use this.
An issue with checking the main output's CRTC state is that, if there is
some CRTC mode combination that for some reason isn't properly detected
by the MetaMonitorMode abstraction (e.g. some tiling configuration not
yet handled), meta_monitor_is_active() would return TRUE, even though no
(abstracted) mode was set. This would cause confusion here and there,
leading to NULL pointer dereferences due to the assumption that if a
monitor is active, it has an active mode.
Instead, change meta_monitor_is_active() to directly check the current
monitor mode, and log a warning if the main output still happen to have
a CRTC with a mode assigned to it. This way, when an not undrestood CRTC
mode combination is encountered, instead of dereferencing NULL pointers,
simply assume the monitor is not active, which means that it will not be
managed or rendered by mutter at all.
https://gitlab.gnome.org/GNOME/mutter/issues/130
When a transient window is destroyed, the expected behavior is that
focus is passed to the ancestor if possible. This was broken for
quite a while until the previous commit, so add a test case to make
sure it doesn't happen again.
https://gitlab.gnome.org/GNOME/mutter/issues/15
Since commit b3b9d9e16 we no longer have to pass the unmanaging window
to make sure we don't try to focus it again, however the parameter also
influences the focus policy by giving ancestors preference over the normal
stack order.
https://gitlab.gnome.org/GNOME/mutter/issues/15
We refuse to move focus while a grab operation is in place. While this
generally makes sense, there's no reason why the window that owns the
grab shouldn't be given the regular input focus as well - we pretty
much assume that the grab window is also the focus window anyway.
In fact there's a strong reason for allowing the focus change here:
If the grab window isn't the focus window, it probably has a modal
transient that is focused instead, and a likely reason for the focus
request is that the transient is being unmanaged and we must move
the focus elsewhere.
https://gitlab.gnome.org/GNOME/mutter/issues/15
Avoid exporting through org.gnome.Mutter.DisplayConfig.GetCurrentState
excessively-low screen resolutions setting both a minimum width and a minimum
height. GetCurrentState is e.g. used by Gnome Control Center to build a list of
selectable resolutions.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=793223
If a client asks for xdg-output before we have set the output's logical
monitor, we would end up crashing with a NULL pointer dereference.
Make sure we clear the resource's user data when marking an output as
inert on monitor change so that we don't end up with a Wayland output
without a logical monitor.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/194
If drmModeSetCrtc() is called with no fb, mode or connectors for some
CRTC it may still fail, and we should handle that gracefully instead of
assuming it failed to set a non-disabled state.
Closes https://gitlab.gnome.org/GNOME/mutter/issues/70
meta_window_wayland_update_main_monitor() would skip the monitor update
if the difference in scale between the old and the new monitor would
cause another monitor change.
While this is suitable when the monitor change results from a user
interactively moving the surface between monitors of different scales,
this can leave dangling pointers to freed monitors when this is
triggered by a change of monitor configuration.
Make sure we update the monitor unconditionally if not from a user
operation.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/189
Add API to let GNOME Shell have the ability to get notified about remote
access sessions (remote desktop, remote control and screen cast), and
with a way to close them.
This is done by adding an abstraction above the remote desktop and
screen cast session objects, to avoid exposing their objects to outside
of mutter. Doing that would result in external parts holding references
to the objects, complicating their lifetimes. By using separate wrapper
objects, we avoid this issue all together.
This test aims at checking that the transient relationship set using the
xdg-foreign API is respected by mutter and that no crash occurs, such as
the one in issue !174.
Note: the crash from issue !174 occurs only if "attach_modal_dialogs" is
set, so one has to change that default value to "true" to be able to
trigger the crash:
gsettings set org.gnome.mutter attach-modal-dialogs true
Related: https://gitlab.gnome.org/GNOME/mutter/issues/174
Add a "set_parent_exported" command to test the xdg-foreign support, so
that we can add a test which uses the GDK API for exported window:
`gdk_wayland_window_set_transient_for_exported()`
That will allow to detect if transient is applied correctly between
foreign windows and detect possible crashes such as issue !174.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/174
Monitor whether UPower is running ourselves. That allows us to keep the
same value for "lid-is-closed" throughout the process of UPower
restarting, preventing unwanted monitor re-configuration through the process.
Fixes another screen black out when UPower restarts and the laptop lid
is closed.
Rather than handle UpClient in both MetaBackend (to reset the idletime
when the lid is opened), and in MetaMonitorManager and
MetaMonitorConfigManager (to turn the screen under the lid on/off
depending on its status), move the ability to get the lid status from
UPower or mock it in one place, in MetaBackend.
Restarting UPower will make every property of UpClient emit a "notify"
signal (as a GDBusProxy would). Avoid mutter reconfiguring the displays
when upower restarts by caching the last known value of "lid-is-closed"
and only reconfiguring the displays if it actually changed.
This fixes a black out of the screen when UPower restarts.
Previously we relied on the test-client to make sure that a window was
shown. For X11, we did not need to do anything, but for Wayland we had
to make sure we had drawn the first frame, otherwise mutter wouldn't
have a buffer making the window not showable.
Doing it this way doesn't work anymore however, since the 'after-paint'
event will be emitted even if we didn't actually paint anything. This is
the case with current Gtk under Wayland, where we won't draw until the
compositor has configured the surface. In effect, this mean we'll get a
dummy after-paint emission before the first frame is actually painted.
Instead, move the verification that a "show" command has completed by
having the test-runner wait for a "shown" signal on the window, which is
emitted in the end of meta_window_show(). This requires an additional
call to gdk_display_sync() in the test-client after creating the window,
to make sure that the window creation vents has been received in the
compositor.
As of "stack-tracker: Keep override redirect windows on top"
(e3d5bc077d), we always sorted all
override redirect on top of regular windows, as so is expected by
regular override redirect windows. This had an unwanted consequence,
however, which is that we should still not sort such override redirect
windows on top if they are behind the guard window, as that'd result in
windows hidden behind it now getting restacked anyway.
Fix this by only sorting the override redirect windows that are found
above the guard window on top. This fixes the override-redirect stacking
test.
The special ::pick implementation there makes clutter fall into paths
that do require a get_paint_volume() implementation, or an infinite
area will be used.
Providing a paint volume here is easier on the invalidation mechanism.
This optimization was presumably added before Clutter was able to
invalidate selected regions of an actor. Paint volumes are supposed
to be invariable as long as the actor conditions don't change.
Stacking of other actors shouldn't affect the paint volume, so it's
actually wrong to optimize those areas away here.
The framerate for screen cast sources was set to variable within 1 FPS
and the framerate of the monitor being screen casted. This meant that if
the sink didn't match the framerate (e.g. had a lower max framerate),
the formats would not match and a stream would not be established.
Allow letting the sink clamp the framerate range by setting it as
'unset', allowing it to be negotiated.
The PipeWire master branch saw some backports from the work branch,
including API changes making the 0.1 series more aligned with future
plans. Make mutter use the new API. This is needed to avoid dead locks
that existed in the older version.
xdg-foreign clears the `transient_for` of a modal dialog when its
imported parent is destroyed, which would later cause a crash in
`constrain_modal_dialog()` because the transient `NULL`.
So in case a modal dialog has no parent, do not try to constrain it
against its parent.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/174
The test fix in commit 859bea629b broke distcheck, probably because
abs_srcdir is prefixed with a relative $BUILDROOT. Hopefully this is
the last autotools breakage before switching to meson, so don't
bother investigating too much ...
Force update the cursor renderer after theme or size changes; otherwise
we'll be stuck with the old theme and/or size until something else
triggers resetting of the cursor.
MetaDisplay still had workspace signals, but nothing emitted them,
meaning we wouldn't get warnings if handlers were added there instead
of to MetaWorkspaceManager.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
If we wait with opening the X11 window decoration GDK connection, we
might end up with a terminated X11 server before we finish
initializing, depending on the things happening after spawning Xwayland
and before opening the MetaX11Dispaly. In gnome-shell, this involves
e.g. creating a couple of temporary X11 connections, and on disconnect,
if they happen to be the last client, the X server will terminate
itself.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Under Xorg the cursor size preference was pre-scaled originating from
gtk, while with Wayland it came directly from GSettings remaining
unscaled. Under Xwayland this caused the X11 display code to set the
wrong size with HiDPI configurations, which was often later overridden
by the equivalent code in gtk, but not always.
Fix this by always having the cursor size preference unscaled, scaling
the size correctly where it's used, depending on how it's used.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
GTK+ won't be initialized if X11 is not available
Instead, when setting gtk-shell-shows-app-menu,
meta_prefs_set_show_fallback_app_menu should be
called as well.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Allow removing a prefs handler that was already removed. This allows us
to remove prefs from the dispose function without having to keep track
of it in every place.
- Stop using CurrentTime, introduce META_CURRENT_TIME
- Use g_get_monotonic_time () instead of relying on an
X server running and making roundtrip to it
https://bugzilla.gnome.org/show_bug.cgi?id=759538
This moves following objects from MetaScreen to MetaDisplay
- workareas_later and in_fullscreen_later signals and functions
- startup_sequences signals and functions
- tile_preview functions
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Split X11 specific parts into MetaX11Display. This also required
changing MetaScreen to stop listening to any signals by itself, but
instead relying on MetaDisplay forwarding them. This was to ensure the
ordering. MetaDisplay listens to both the internal and external
monitors-changed signal so that it can pass the external one via the
redundant MetaDisplay(prev MetaScreen)::monitors-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
They are X11 specific functions, used for X11 code. They have been
improved per jadahl's suggestion to use gdk_x11_lookup_xdisplay and
gdk_x11_display_error_trap_* functions, instead of current code.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
- Moved xdisplay, name and various atoms from MetaDisplay
- Moved xroot, screen_name, default_depth and default_xvisual
from MetaScreen
- Moved some X11 specific functions from screen.c and display.c
to meta-x11-display.c
https://bugzilla.gnome.org/show_bug.cgi?id=759538
These files are used to run mutter-test tools and using relative
paths won't work if the builddir doesn't match the srcdir.
This won't affect their installation (in case the build option is passed)
Make it so that each logical monitor has a reference to all the
monitors that are assigned to it.
All monitors has a reference to each output that belongs to it.
Each output has a reference to any CRTC it has been assigned.
https://bugzilla.gnome.org/show_bug.cgi?id=786929
For some reason "backends: Remove X11 idle-monitor backend" removed
unrelated warning messages for when generated monitor configurations
that should work didn't, which also made the unit tests fail.
This commit adds them back, which also makes the tests pass again.
Commit 22723ca37 moved buffer realization to
meta_wayland_surface_commit() so that it wouldn't be part of
meta_wayland_buffer_attach().
However, creation of dmabuf buffers would call into
meta_wayland_buffer_attach() directly without realizing the buffer
first. attach() would then fail and mutter would effectively shut down
any clients using the zwp_linux_dmabuf protocol (note that if such
client was Xwayland, mutter itself would shut down as well).
Add the missing bit in order to make zwp_linux_dmabuf protocol work
again.
One of the current limitations of EGLStreams is that there's no way to
resize a surface consumer without re-creating the entire stream.
Therefore, while resizing, clients will send wl_surface::attach requests
so the compositor can re-create its endpoint of the stream, but no
buffer will be available actually. If we proceed with the rest of the
attach operation we'll be presenting an empty buffer.
In order to fix this, a separate wl_eglstream_controller protocol has
been introduced that clients can use to request a stream re-creation
without overloading wl_surface::attach for that purpose.
This change adds the required logic to create the corresponding
wl_eglstream_controller global interface that clients can bind to.
Whenever a client requests a stream to be created, we just need to
create and realize the new EGLStream buffer. The same buffer resource
will be given at a later time to wl_surface::attach, whenever new
content is made available by the application, so we can proceed to
acquire the stream buffer and update the surface state.
https://bugzilla.gnome.org/show_bug.cgi?id=782575
Clients using EGLStream-backed buffers will expect the stream to be
functional after wl_surface::attach(). That means the compositor-side
stream must be created and a consumer attached to it.
To resolve the above, this change realizes buffers even when the attach
operation is deferred (e.g. synchronized subsurfaces).
https://bugzilla.gnome.org/show_bug.cgi?id=782575
When dealing with synchronized subsurfaces, we defer buffer attachments
until the parent surface state is applied.
That causes interaction issues with EGLStream backed buffers, as the
client expects the compositor-side stream to be functional after it
requests a wl_surface::attach.
By allowing the compositor to realize buffers without attaching them, we
could resolve the issue above if we define a realized EGLStream buffer
as a functional EGLStream (EGLStream + attached consumer).
This change moves the texture consumer creation part from the attach
function to the realize one.
https://bugzilla.gnome.org/show_bug.cgi?id=782575
Commit 712ec30cd9 added the logic to only
choose EGL configs that match the GBM_FORMAT_XRGB8888 pixel format.
However, there won't be any EGL config satisfying such criteria for
non-GBM backends, such as EGLDevice.
This change will let us choose the first EGL config for the EGLDevice
backend, while still forcing GBM_FORMAT_XRGB8888 configs for the GBM
one.
Related to: https://gitlab.gnome.org/GNOME/mutter/issues/2
Where to realize a hardware cursor depends on where on the screen it
will be displayed. For example it only needs buffers for the cursor
plane on a certain GPU if it overlaps with a monitor that is connected
said GPU.
Previously, we were too eager with uploading the cursor plane buffers,
which in effect resulted in the secondary GPU always being woken up
when changing the cursor, even though the cursor plane would actually
never be set unless the pointer cursor was moved to a monitor connected
to the secondary GPU. These wake-ups caused noticable stuttering; thus
by uploading the buffers more lazilly, the stuttering is avoided.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
When a cursor is hidden, the native backend will properly hide the HW
cursor sprite as well, but it would communicate this as if the cursor
was not handled by the backend, while in fact it still was. This caused
the generic cursor rendering layer to queue a redraw.
https://gitlab.gnome.org/GNOME/mutter/issues/77
When force-updating the HW state we might end up with a situation where
the HW cursor is no longer usable. If this would happen, we'd before
this commit not trigger the fallback paths using a GL texture.
https://gitlab.gnome.org/GNOME/mutter/issues/77
It is already handled by the monitor-updated-internal signal handler in
meta-cursor-renderer-native.c, which will always be called indirectly
by resuming the monitor manager.
While at it, remove a useless comment.
https://gitlab.gnome.org/GNOME/mutter/issues/77
Call it meta_cursor_renderer_update_cursor. This avoids confusing it
with the update_cursor MetaCursorRendererClass vfunc when navigating
the file.
https://gitlab.gnome.org/GNOME/mutter/issues/77
It knows better when it's needed. For now, just do it just as before,
before drawing. Eventually, we can conditionalize where to realize
depending on the cursor sprite position.
https://gitlab.gnome.org/GNOME/mutter/issues/77
Use a common entry point into the cursor renderer implementations HW
cursor realization paths for all cursor sprite types. This is in
preparation for realizing at more strategic times.
https://gitlab.gnome.org/GNOME/mutter/issues/77
The end goal here is to being able to realize at any point in time
through a single API, so start by moving state into the cursor sprite
implementation.
https://gitlab.gnome.org/GNOME/mutter/issues/77
Remove some X11 compositing manager specific code from the general
purpose cursor tracker into a new MetaCursorSprite based special
purpose XFIXES cursor sprite.
https://gitlab.gnome.org/GNOME/mutter/issues/77
Introduce a new type MetaCursorSpriteXcursor that is a MetaCursorSprite
implementation backed by Xcursor images. A plain MetaCursorSprite can
still be created "bare bone", but must be manually provided with a
texture. These usages will eventually be wrapped into new
MetaCursorSprite types while turning MetaCursorSprite into an abstract
type.
https://gitlab.gnome.org/GNOME/mutter/issues/77
It was prefixed with meta_cursor_, but it took a X11 Display, so update
the naming. Eventually it should be duplicated depending if it's a
frontend X11 connection call or a backend X11 connection call and moved
to the corresponding layers, but let's just do this minor cleanup for
now.
https://gitlab.gnome.org/GNOME/mutter/issues/77
This makes it possible to move out backing store specific code (such as
Xcursor handling) to separate units, while also making it easier to add
more types).
https://gitlab.gnome.org/GNOME/mutter/issues/77
Rename the two cursor role types according to the convention used by the
other roles. This means that MetaWaylandSurfaceRoleCursor was renamed to
MetaWaylandCursorSurface, and MetaWaylandSurfaceRoleTabletCursor was
renamed to MetaWaylandTabletCursorSurface. The corresponding filenames
were renamed accordingly too.
https://gitlab.gnome.org/GNOME/mutter/issues/77
drmModeAddFB2 allows userspace to specify a real format enum on
non-ancient kernels, as an improvement over the legacy drmModeAddFB
which derives format from a fixed depth/bpp mapping.
As an optimisation, Weston used to decide at the first failure of
drmModeAddFB2 that the ioctl was unavailable: as non-existent DRM
ioctls return -EINVAL rather than -ENOSYS or similar, bad parameters are
not distinguishable from the ioctl not being present.
Mutter has also implemented the same optimisation for dumb framebuffers,
which potentially papers over errors for the gain of avoiding one ioctl
which will rapidly fail on ancient kernels. Remove the optimisation and
always use AddFB2 where possible.
Closes: #14
And ensure the actor is no longer reactive even though it might live longer
because of close effects, GCs, and whatnot. This ensures the actor is not
eligible for pointer picking within the destruction of its surface.
Closes: #188
The MetaCloseDialog implementation object may stay artifically alive
for a longer period. This was usually fine till gnome-shell commit
b03bcc85aad, as the check_alive() timeout will keep running even
though the window went unmanaged/destroyed, leading to crashes.
In order to fix this, forcibly hide the dialog if it is visible and
the window is being unmanaged, so the timeout is stopped in time.
The order of role creation is undetermined, so we can't account that
the parent surface will have a role (and an actor) at the time of
creating the wl_subsurface role for a child surface.
So we must do it both ways, add the subsurface as a child on
get_subsurface() if the parent already got a role, and lazily add
child subsurface actors to the current one if the parent surface got
it at a later point.
Related: #132
When using the EGLStream backend, the MetaRendererNative passed a
GClosure to KMS when using EGLStreams, but KMS flip callback event
handler in meta-gpu-kms.c expected a closure wrapped in a closure
container, meaning it'd instead crash when using EGLStreams. Make the
flip handler get what it expects also when using EGLStreams by wrapping
the flip closure in the container before handing it over to EGL.
https://bugzilla.gnome.org/show_bug.cgi?id=790316
Commit 47131b1d ("frames: Handle touch events") introduced an assert to
make sure that all mouse button actions are handled in mutter.
However, mice can have a more than 5 buttons, so simply ignore the
"other" actions instead of aborting.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/160
After 20176d03, the Wayland backend only synchronizes with the
compositor after a geometry was set, and it was different from
the current geometry.
That commit was mistakenly comparing the geometry before chaining
up, which would yield a false negative on the case where the
client didn't call set_geometry() before commit().
Fix that by caching the old geometry locally, chain up (and thus
apply the new geometry rectangle), then comparing the old and
current geometry rectangles.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/150
This avoids overwhelming the GPU with trying to update mipmaps at a high
rate. Because doing so could easily cause a reduction in the compositor
frame rate and thus actually reduce visual quality.
In the case of a window that is constantly animating in the overview,
this reduces mutter's render time by around 20%-30%.
This is just done on wayland as it'll break horribly on X11, we let
this happen through pointer emulated events in XISelectEvents evmask
instead.
Some things had to be made slightly more generic to accomodate touch
events. The MetaFrames shall lock onto a single touch at a time, we
don't allow crazy stuff like multi-window drag nor multi-edge resizes.
https://bugzilla.gnome.org/show_bug.cgi?id=770185
While MetaStage, MetaWindowGroup and MetaDBusDisplayConfigSkeleton don't
appear explicitly in the public API, their gtypes are still exposed via
meta_get_stage_for_screen(), meta_get_*window_group_for_screen() and
MetaMonitorManager's parent type. Newer versions of gjs will warn about
undefined properties if it encounters a gtype without introspection
information, so expose those types to shut up the warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
Various code assumed PipeWire function calls would never fail. Some can
actually fail for real reasons, and some currently can only fail due to
OOM situations, but we should still not assume that will always be the
case.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/102
The destroyed signal that was emitted if an imported surface was not
available when created, for example if the handle was invalid or
already unexported, was emitted on the wrong resource.
To check if a subsurface is effectively synchronized, we walk the
subsurface hierarchy to look for a non-subsurface parent or a subsurface
being synchronized.
However, when client is closing, the parent surface might already be
gone, in which case we end up with a surface being NULL which causes a
NULL pointer dereference and a crash.
Check if the parent surface is NULL to avoid the crash, and consider
it's already synchronized if it is NULL to avoid further updates.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/124
The current implementation of the XdgSurface v6 protocol does not check
if the window changed before calling meta_window_wayland_move_resize().
The problem with this approach is that calling this function is a costly
operation since we enter the compositor side. In GNOME Shell case, it is
in JavaScript, which triggers a GJS trampoline. Calling this function on
every mouse movement is naturally as terrible as it could be - and is
exactly what happens now.
This commit adds the necessary checks to only call move_resize() when
the window actually changed, or when it needs to be updated.
https://bugzilla.gnome.org/show_bug.cgi?id=780292
Issue: #78
This will be used by the next commit to determine when a window
geometry change should be ignored or not. Normally, it would be
enough to just check if the position and sizes changed.
The position, in this case, is relative to the client buffer, not
the global position. But because it is not global, there is one,
admitedly unlikely, situation where the window state is updated
while the client size and relative positions don't change.
One can trigger this by e.g. tiling the window to the half-left of
the monitor, then immediately tile it to half-right. In this case,
the window didn't change, just it's state, but nonetheless we need
to notify the compositor and run the full move/resize routines.
When that case happens, though, the MetaWindowWayland is tracking
the pending state change or a move. And this is what we need to
expose.
https://bugzilla.gnome.org/show_bug.cgi?id=780292
Issue: #78
In the old, synchronous X.org world, we could assume that
a state change always meant a synchronizing the window
geometry right after. After firing an operation that
would change the window state, such as maximizing or
tiling the window,
With Wayland, however, this is not valid anymore, since
Wayland is asynchronous. In this scenario, we call
meta_window_move_resize_internal() twice: when the user
executes an state-changing operation, and when the server
ACKs this operation. This breaks the previous assumptions,
and as a consequence, it breaks the GNOME Shell animations
in Wayland.
The solution is giving the MetaWindow control over the time
when the window geometry is synchronized with the compositor.
That is done by introducing a new result flag. Wayland asks
for a compositor sync after receiving an ACK from the server,
while X11 asks for it right away.
Fixes#78
Before we just set it to "none", but this was not enough since various
calls will depend on not just the context being active, but the main
rendering surface.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/21
When deriving the global scale directly from the current hardware state
(as done when using the X11 backend) we are inspecting the logical
state they had prior to the most recent hot plug. That means that a
primary monitor might have been disabled, and a new primary monitor may
not have been assigned yet.
Stop assuming a primary monitor has an active mode before having
reconstructed the logical state by finding some active monitor if the
old primary monitor was disabled. This avoids a crash when trying to
derive the global scale from a disabled monitor.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/130
These paths implicitly relied on the forwarded IM key events having
a source_device backed by a real HW device. This assumption is no
longer held true since commit b5328c977.
Explicitly check the INPUT_METHOD flag so they are handled as they
should despite not being "real HW" events.
As a follow up to the patch from a95cbd0a, we need to make sure
that the pointer is out of the way as well when monitors changed,
since that's the event that will prevail in some cases. Besides,
this is also consistent with what the code before a95cbd0a was,
which initialized the pointer position in the same way both in
this case and in the real_post_init() function.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/157
We used to maintain an actor for cursors, even though we would possibly
use hw overlays or even some other overlay actor for those. This happens
no more, so check whether we are dealing with an actor-backed surface role
before fiddling with it.
All surface roles that do need a backing actor inherit from this
class, it makes sense to move actor management there. This also
means the MetaWaylandActorSurface is in charge of emitting
::geometry-changed on the MetaWaylandSurface.
Instead of scheduling a meta_later, keep track of the unassociated
windows, and look for matches as soon as the MetaWaylandSurface is
created on our side.
This will ensure the surface is given the Xwayland role before receiving
the first wl_surface.commit.
In the synchronized subsurface case, the destination list may
contain other elements from previous wl_surface.commit calls.
Resetting the list will leave those dangling frame callbacks
that will lead to invalid writes when those get to be destroyed
(eg. on client shutdown).
Gtk now is caching the themed cairo surfaces, then as per
commit gtk@e36b629c the surface device scale is used to figure
out the current paint scaling.
Without this when using background-image's for window buttons
the -gtk-scaled icons isn't properly resized.
Fixes#99
Centering the pointer at startup causes undesired behaviour if
it ends up hovering over reactive elements, that might react
to that positioning, causing confusion. This is the case of
the login dialog when a list of different users is shown, as
centering the pointer at startup in that case will get the
user in the center of the screen pre-selected, which is not
the expected behaviour (i.e. pre-selecting the first one).
Fix this by simply moving the pointer out of the way, close
to the bottom-right corner, during initialization.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/157
Right now if Xwayland crashes, we crash, too.
On some level that makes sense, since we're supposed to control the
lifecycle of Xwayland, and by it crashing we've lost that control.
But practically speaking, the knock-on crash adds noise to the logs,
bug trackers, and retrace servers that only makes debugging harder.
And the crash isn't something mutter can "fix", since it's
ultimately from a bug in Xwayland anyway.
This commit makes mutter exit instead of crash if Xwayland goes away
unexpectedly.
Right now we explicitly g_clear_error any error we find, but that
makes it tricky to return early from the function, which a
subsequent commit will want to to do.
This commit switches GError to use g_autoptr so the error clearing
happens automatically.
This is a small mistake spotted while working on a solution
for #77. When a GPU fails to initialize, we're adding them
anyway, which might have pretty bad consequences when trying
to use these NULL GPUs.
Issue: #77
Make it re-enable:able by a hidden "experimental feature". To enable, add
"kms-modifiers" to the org.gnome.mutter.experimental-features GSettings entry.
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
