We only want the panel autorotation to happen if the laptop has an
accelerometer, and is in tablet mode. Regular laptop mode should
lock the orientation, and let it be configured manually.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
So far, we've expected this signal to not happen whenever autorotation
shouldn't apply (no accelerometer is a strong reason). In future commits
we'll add further checks to this policy, so prevent autorotation to
change the display configuration if the MetaOrientationManager signal
happens but it should be ignored.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
Instead of having everyone check net.hadess.SensorProxy themselves, have
this all controlled by the MetaOrientationManager, and proxied everywhere
else via a readonly property in org.gnome.Mutter.DisplayConfig.
We want to attach more complex policies here, and it seems better to
centralize the handling of the autorotation feature rather than
implementing policy changes all over the place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
We used to pick the "best" output for each builtin/size/edid categories,
and then pick the "best" (in that order) of those for each input device.
This is most often enough, but is prone to wrong results in some corner
cases (eg. 2 outputs with the exact same dimensions).
Change this to a score mechanism that doesn't leave outputs out. The
weights are the same, but the score is accumulated if an output matches
multiple categories. All outputs are evaluated and sorted by score, and
input devices with the best matches are applied first (as they already
did).
This should break the tie if eg. there's 2 outputs with similar dimensions,
but one of them has some EDID match in addition. The output with multiple
matches will score higher up, while it might have been entirely discarded
with the previous implementation.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1175https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1202
The work at https://gitlab.gnome.org/GNOME/gnome-control-center/issues/239
intended to make integrated devices optionally mappable to other outputs
(in order to allow fix mishandling from our heuristics, or to quickly reach
things in other monitor without changing devices).
This was missed in that plan, we do allow cycling outputs, but we still did
prevent it from doing anything for integrated devices. Fix that, and change
output cycling so we don't allow a "NULL" EDID for integrated devices, this
makes those go through the MetaInputMapper (resulting in one output listed
twice), instead of mapping to the full stage.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1186https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1201
The cursor tracker may give us a valid position, and a
valid cursor sprite, and yet the cursor can be hidden,
meaning we must hide the cursor on the stream as well.
Remove cursor from stream buffer if it's hidden.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
Scanouts are taken away after painting. However, when we're
streaming, what we actually want is to capture whatever is
going to end up on screen - and that includes the scanout
if there's any.
Add a before-paint watch that only records new frames if a
scanout is set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
It'll allow subclasses to get notified of the before-paint
signal without having to connect to it. This will allow
MetaStage to have proper watches being fired there without
the cost of the signal handling machinery.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
When there's a direct scanout set in the stage view, we
have to use it instead of the view's regular onscreen
framebuffer.
Use the new CoglScanout API to implement blitting to the
stream framebuffer.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
This will be used when screencasting monitors so that if
there's scanout in place, it'll still be possible to blit
it to a PipeWire-owned framebuffer, and stream it.
Add a new 'blit_to_framebuffer' vfunc to CoglScanout, and
implement it in MetaDrmBufferGbm.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
Just because X11/XI uses a particular terminology doesn't mean we
have to use the same terms in our own API. The replacement terms
are in line with gtk@1c856a208, which seems a better precedent
for consistency.
Follow-up to commit 17417a82a5.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1425
Using opaque painting paths can have a big impact on painting performance.
In order to easily validate whether we use the opaque paths, add a opaque
(green) or blended (purple) overlay over painted areas if the
`META_DEBUG_PAINT_OPAQUE_REGION` `MetaDebugPaintFlag` is set.
You can do so in `lg` via:
`Meta.add_debug_paint_flag(Meta.DebugPaintFlag.OPAQUE_REGION)`
This can be helpful for application developers, as previously it was not
trivial to check whether e.g. Wayland or X11 opaque regions where
properly set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1372
In certain situations it's desirable to keep pipelines around for
the whole lifetime of the session. In order to not leak them and
properly clean them up on shutdown, introduce a new mechanism to
create named pipelines that are bound to their correstponding
context and may be used across file boundries.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1372
Analogous to `ClutterDrawDebugFlag` but intended for concepts that
are not present in Clutter, such as Wayland/X11 opaque regions.
Also add the first flag for the later.
To set the flag, run:
`Meta.add_debug_paint_flag(Meta.DebugPaintFlag.OPAQUE_REGION)`
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1372
This is no longer directly related to DBus messages, but our own event
queue. Change the wording and use CLUTTER_PRIORITY_EVENTS to make it
bolder, even though it's the same than G_PRIORITY_DEFAULT.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1286
We set an idle to coalesce multiple IM events together, as the protocol
requires us to send them in one frame, and unfortunately there is no
idea about whether more IM events are upcoming.
One good hint though are key events generated from the IM, we want to
apply all IM changes before the key event is processed, so make it sure
that the .done event is flushed before the key event is handled.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1286
These are not given directly to the input focus anymore, instead
queued up as events. This way, all actions triggered by the input
method (commit and preedit buffer ones, but also synthesized key
events) queue up the same way, and are thus processed in the exact
same order than they are given to us.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1286
The clutter_input_focus_filter_key_event() function has been made
a more generic filter_event(). Besides its old role about letting
key events go through the IM, it will also process the IM events
that are possibly injected as a result.
Users have been updated to these changes.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1286
When in the overview culling via `self->clip_region` is unavailable.
The region is `NULL` because the paint call has not originated from a
`WindowGroup`, because the overview does not use `WindowGroup`.
So the main wallpaper was being painted in full while in the overview.
That's a waste of effort because `redraw_clip` is going to be used to
stencil/scissor out only the parts that are changing. We don't need to
paint *most* of the wallpaper, only the parts behind anything changing.
For the overview this reduces GPU power usage (intel_gpu_top) roughly
10% and reduces render times almost as much.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1363
`meta_background_content_paint_content` was mixing two different
coordinate systems in `actor_pixel_rect`. It was initialized with
actor-local coordinates and then `if (self->clip_region)` would be
treated as stage coordinates. This worked because `self->clip_region`
was only non-NULL outside of the overview where both coordinate systems
were the same. So it always got the right answer, possibly by accident.
In order to enhance the function however we will need to know which
coordinate system we're working in, so now we make it explicit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1363
