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).
Make it re-enable:able by a hidden "experimental feature". To enable,
add "kms-modifiers" to the org.gnome.mutter.experimental-features
GSettings entry.
https://gitlab.gnome.org/GNOME/mutter/issues/81
The value is not scaled by default so it needs to be adjusted
depending on the window scaling, as it's done in other places.
Fixes: #87
(cherry picked from commit deda7a52355566723b45dad3d18108d326c06633)
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
(cherry picked from commit e6109cfc22f06412e67bd3c1f9f0dfa6ad7e0b19)
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
(cherry picked from commit ebff7fd7f4ee2c9636412fe661a1fbdf51f218a0)
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.
(cherry picked from commit 6e415353e311655be9936b9dfb9e23c80ef1eae6)
Mutter recently gained the ability to deal with multiple GPUs
rendering at different displays. These GPUs would have a display
connected to them, and Mutter was adapted in order to be aware
of different GPUs and their outputs.
However, one specific edge case appeared: PRIME systems. PRIME
systems have two GPUs:
* The integrated GPU (iGPU), usually Intel, which has connectors
and deals with the routine load.
* The dedicated GPU (dGPU), usually AMD or NVidia, which has no
connectors at all and are there just to aid heavy loads.
On those systems, the dGPU is aggressively put to sleep by the
kernel to avoid energy waste. Waking it up is a costly operation.
With Mutter's adaptation to deal with multiple GPUs, Mutter began
wakening the dGPU every time some rendering had to be done. This
was causing stuttering every time the dGPU was put to sleep, and
Mutter asked it to wake up again.
To fix this situation, this commit ignores GPUs with no connectors
attached.
Issue: #77
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
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 e76a0f564c1e07e32fe857d0f8e5b723c3bbe57d.
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
