1
0
Fork 0
Commit graph

32609 commits

Author SHA1 Message Date
Bilal Elmoussaoui
0d93f805d4 clutter/context: Create a StageManager when constructed
Instead of delegating that to StageManager.get_default and add a private getter
for it.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3962>
2024-08-22 16:45:01 +00:00
Bilal Elmoussaoui
914787294f clutter/stage-manager: Mark as private type
Nothing is supposed to interact with it externally

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3962>
2024-08-22 16:45:01 +00:00
Bilal Elmoussaoui
09c7c2bf7b clutter/stage-manager: Remove unused APIs
As the type will be made private in future commits

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3962>
2024-08-22 16:45:01 +00:00
Bilal Elmoussaoui
5391ab56e8 clutter/stage-manager: Mark as final
It is not something that can be replaced

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3962>
2024-08-22 16:45:00 +00:00
Bilal Elmoussaoui
3fb1c9ab21 clutter/context: Remove unused is_initalized
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3962>
2024-08-22 16:45:00 +00:00
Bilal Elmoussaoui
3453a6e51f clutter/stage-manager: Remove unused default-stage
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3962>
2024-08-22 16:45:00 +00:00
Sebastian Wick
d1750e5bdb build: Enable libdisplay-info by default
So far libdisplay-info has only been used when it was available. This
change requires either libdisplay-info to be available or the user to
explicitly disable it.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3971>
2024-08-22 14:26:51 +02:00
Sebastian Wick
41f0194280 tests: Start pipewire and wireplumber for the native-unit test
So far, the tests relied on the host system to provide pipewire and
wireplumber. This seperates the tests from the host system which is
especially useful if the tests are run in a toolbox which has a
different pipewire installed than the host. It also should make it
harder to have a mismatch between the pipewire library and the pipewire
daemon.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3966>
2024-08-22 08:51:56 +00:00
Sebastian Wick
7bcc8c19cb build: Remove unused CI test setup
The CI uses the default and plain setups but not the CI one. Let's
remove it.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3966>
2024-08-22 08:51:56 +00:00
José Expósito
c7acd6074b wayland/drm-lease: Fix list initialization bug
The new_connectors list must be initialized empty, otherwise, connectors
are duplicated.

Fixes: 115b2c1247 ("wayland/drm-lease: Make MetaDrmLeaseManager::connectors a GList")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3967>
2024-08-21 12:47:57 +00:00
Jonas Ådahl
d2be0b6950 kms: Inhibit real time scheduling until initial mode set
We're already inhibiting real time scheduling when reading new KMS state
after hot plugs, as well as when during mode sets, due to the kernel not
being able to reliably handle these within the 250 ms limit. However, we
didn't do this during initial probing, which meant that occasionally
we'd run into these kind of issues during startup.

Handle this by always inhibiting real time scheduling up front, and
don't uninhibit until all initially discovered device have finished
processing their initial mode set.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3628
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3960>
2024-08-21 12:15:59 +00:00
Peter Hutterer
d866590b78 wayland: Set current tool surface to NULL on prox-out
If an application is maximised, clutter_stage_pick_and_update_device()
goes into the
        if ((flags & CLUTTER_DEVICE_UPDATE_IGNORE_CACHE) == 0)
condition and returns the current actor for the device. This means no
CLUTTER_LEAVE/ENTER events are generated and in turn means the focus is
never invalidated and updated.

This leads to tool->focus_surface always being NULL and all events are
discarded.

Notably, tool->current is set to the right surface but
that one never changes either so meta_wayland_tablet_tool_set_current_surface()
exits early too because surface == tool->current and we thus never call
meta_wayland_input_invalidate_focus().

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3616
Fixes: fb8ac5dff7 ("wayland: Track current tablet tool focus surface")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3956>
2024-08-21 10:21:33 +00:00
Martin Abente Lahaye
eaa416904d ci: Bump CI/CD component version for building system extensions
This new version allows us to specify a branch,  which will be needed
soon to freeze the GNOME OS version used in stable branches e.g. once
GNOME OS 47 is available.

See https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/872

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3963>
2024-08-20 12:23:58 -04:00
Peter Hutterer
c03e64ef1d wayland: Propagate a tablet's DEVICE_REMOVED to trigger the signals
Clutter's "device-removed" signal is sent in
clutter_seat_handle_event_post(). Our tablet code is set up to handle
that signal to then notify wayland clients of removed tablet devices.

However, returning CLUTTER_EVENT_STOP for a DEVICE_REMOVED event means
we never get to the point where we send out the signals and thus never
remove the tablets.

Fixes: a37fd34bbb ("wayland: Make MetaWaylandSeat in charge of its own tablet seat")

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3615
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3955>
2024-08-20 14:06:32 +00:00
Carlos Garnacho
ae35c1efe0 core: Use event return value defines in keybinding code
Make the fate of the given event in every return path more
evident.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3935>
2024-08-20 10:50:06 +00:00
Carlos Garnacho
cdf427039d core: Let unhandled key release events be propagated by keybindings
This leads to possibly missed key release events being propagated down to
clients, and in the case of X11 clients, to stuck keys e.g. after switching
workspace with Ctrl+Alt+Left/Right and ending up with a X11 client focused.

Fixes: 11a4d56185 ("keybindings: Send trigger when a key accelerator is deactivated")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3935>
2024-08-20 10:50:06 +00:00
Lukáš Tyrychtr
a35326cc93 dbus-interfaces: Fix ApplyMonitorsConfig documentation
The "overscanning" property had its name at least from 2019,
but the documentation was wrong all that time.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3624
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3957>
2024-08-19 13:01:46 +02:00
Michel Dänzer
bd8db38460 kms/impl-device: Track dispatch duration in crtc_frame_deadline_dispatch
And take it into account in meta_kms_crtc_get_deadline_evasion.

This uses the same fundamental approach as clutter frame clock scheduling:

Measure the deadline timer dispatch duration, keep track of the longest
duration, and set the timer to fire such that the longest measured
dispatch duration would result in it completing shortly before start of
vblank.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3612

v2:
* Move DEADLINE_EVASION_CONSTANT_US addition from
  meta_kms_crtc_determine_deadline to meta_kms_crtc_get_deadline_evasion.
* Calculate how long before start of vblank dispatch completed for
  debug output in crtc_frame_deadline_dispatch.
* Shorten over-long lines in crtc_frame_deadline_dispatch.
v3:
* Take VRR into account in crtc_frame_deadline_dispatch &
  meta_kms_crtc_update_shortterm_max_dispatch_duration. (Robert Mader)
v4:
* Check if deadline has already passed in meta_kms_crtc_determine_deadline,
  set the deadline for one refresh interval later if so.
* Fix indentation in crtc_frame_deadline_dispatch.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3934>
2024-08-17 19:16:01 +00:00
Michel Dänzer
d7012d2ad3 kms/impl-device: Use KMS_DEADLINE in crtc_page_flip_feedback_flipped
It's useful for this to match the debug topic in
crtc_frame_deadline_dispatch.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3934>
2024-08-17 19:16:01 +00:00
Sebastian Wick
45dcfeb0cc cogl/gles: Revert to unsized GL_BGRA as internalformat for BGRA_8888
Using GL_BGRA8_EXT as internalformat for TexSubImage2D was not allowed
in the EXT_texture_format_BGRA8888 extension. This changed recently:

https://registry.khronos.org/OpenGL/extensions/EXT/EXT_texture_format_BGRA8888.txt

  1.4, 23/06/2024 Erik Faye-Lund: Add GL_BGRA8_EXT for ES 2.0 and later.

Mesa already supports this which is why 7f943613a8 ("cogl: Use sized
internal renderable formats") worked as intended. Technically spec
compliant and our CI had an up-to-date driver.

So while this is no bug, it's still not great because older drivers will
generate GL errors. This commit changes this specific format back to an
unsized internal format which means we could, in theory, get less than
8bpc framebuffers.

We can try to revert this commit when newer driver versions have
propagated far enough.

Fixes: 7f943613a8 ("cogl: Use sized internal renderable formats")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3954>
2024-08-16 14:24:38 +00:00
Sebastian Wick
7610973a94 Replace deprecated g_qsort_with_data with g_sort_array
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3899>
2024-08-15 23:58:53 +02:00
Jonas Ådahl
e5827ea06b monitor-config-utils: Use g_list_copy_deep() to clone lists
It makes things a bit more easy to follow.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Jonas Ådahl
b8394c68f5 monitor-config-store: Use auto pointers in a couple of places
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Jonas Dreßler
4175a37e4c tests/monitor-unit: Add layout mode migration tests
Let's add a bunch of tests for the newly introduced monitor config
migration code. We're verifying that:

- monitor configs get migrated and monitors.xml is updated on startup

- existing monitor configs in LOGICAL layout mode (ie.
"scale-monitor-framebuffers" was enabled before updating mutter) get
migrated

- the migration of various more complex monitor layouts from PHYSICAL
to LOGICAL layout mode works

- for monitor layouts where conversion to LOGICAL fails, the PHYSICAL
layout mode still is migrated, while for LOGICAL at least primary
monitor and disabled monitors are preserved

- simple monitor configurations (with no scaled monitors, or with only
"irrelevant" scaled monitors at the end of the layout) do not go through
the conversion code paths

- monitor configs in PHYSICAL layout mode with integer scale factors
which will result in non-integer logical monitor sizes get converted
to the closest fractional scale factor

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Jonas Dreßler
05cc8a56e1 monitor-config-store: Save configs after layout mode detection/conversion
We don't want to do the work of the layout mode detection and conversion
every time we read the monitors.xml file.

Instead, when the detection logic is used, set a flag to automatically
update the config files after the parsing is finished.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Jonas Dreßler
2c8b383a7e monitor-config-store: Attempt to convert physical to logical layout modes
Introduce some "best effort" conversion code to migrate monitor configurations
from PHYSICAL (the old default) to LOGICAL (the new default on wayland)
layout mode.

This conversion will only be used when the old PHYSICAL layout-mode
configuration is not compatible with the new LOGICAL layout-mode one.
This only applies if 1) there's a monitor that needs scaling in the
layout, and 2) the scaled monitor comes before other monitors in the
coordinate system (ie. it's not the rightmost or bottommost monitor).

There are two algorithms added here to convert monitor layouts:

- One for "simple" 1-dimensional monitor layouts, where all monitors are
aligned on a vertical or horizontal strip.

Here's a few (inaccurate) examples of how this would look with different
layouts (left side is PHYSICAL, right side is LOGICAL, x is the origin of
the coordinate system, the numbers are scales of the monitors):

```
x──────┬──────┬──────┐     x  ┌──────┐
│  2   │  1   │  2   │    2┌──┤  1   ├──┐2
│      │      │      │ ──► └──┤      ├──┘
└──────┴──────┴──────┘        └──────┘

         x    ┌──────┐     x  ┌──────┐
         ┌────┤  1   │     ┌──┤  1   │
         │ 2  │      │ ──► └──┤      │
         └────┴──────┘      2 └──────┘

    x      ┌────┐
    ┌──────┤    │          x──────┐
    │      │    │          │      ├─┬────┐
    │  1   │ 3  │      ──► │  1   │3│ 1  │
    │      │    │          │      ├─┴────┘
    └──────┤    │          └──────┘
           │    ├────┐
           │    │ 1  │
           └────┴────┘
```

- A second more complex algorithm for 2-dimensional monitor layouts with
a common baseline that all monitors are aligned to.

And examples for this one:

```
             x      ┌──────┐
             ┌──────┤      │
             │  1   │  2   │     x──────┐
             │      │      │     │  1   ├────┐
             └──┬───┴───┬──┘ ──► │      │ 2  │
                │  3    │        ├──┬───┴────┘
                │       │        └──┘3
                └───────┘

       x     ┌──────┬──────┐
             │  1   │      │
             │      │      │     x──────┬──────┐
       ┌─────┴──────┤  1   │     │  1   │      │
       │            │      │     │      │      │
       │            │      │ ──► └──┬───┤  1   │
       │     3      │      │        │ 3 │      │
       │            ├──────┘        └───┤      │
       │            │                   │      │
       │            │                   └──────┘
       └────────────┘

x                  ┌───────┐
┌──────┐           │       │     x         ┌───────┐
│  2   │    ┌──────┤   1   │               │       │
│      │    │  1   │       │      2 ┌──────┤   1   │
└────┬─┴────┴─┬────┴───────┘ ──► ┌──┤  1   │       │
     │        │                  ├──┴┬─────┴───────┘
     │   2    │                  │ 2 │
     │        │                  └───┘
     └────────┘
```

These algorithms will fail for any more complex 2d monitor layout, eg.

```
x   ┌───┬────┐
    │ 2 │ 1  │
    │   ├────┘
┌───┴┬──┘
│ 1  │
└────┘

x───┬───┬───┐
│ 1 │ 2 │ 1 │
├───┼───┼───┤
│ 1 │ 1 │ 1 │
├───┼───┼───┤
│ 1 │ 1 │ 1 │
└───┴───┴───┘
```

In those cases where the conversion failed, we fall back to aligning
the monitors on a horizontal line, preserving the scale, the primary
monitor and the disabled monitors.

Note that we also need to convert the scale factor in some cases,
because LOGICAL layout mode also behaves different here:
When the scale results in a fractional logical monitor size (eg.
the native monitor width is 2560px, and a scale of 3 is set =>
2560px / 3 = 853.333px), in LOGICAL mode we won't use that scale.
Instead we have an algorithm (see
meta_monitor_get_closest_scale_factor_for_resolution()) to find
the nearest fractional scale factor which doesn't result in
fractional logical monitor size. We reuse this algorithm here for
the conversion.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Jonas Dreßler
96791f111a monitor: Move check to limit fractional scales to certain monitor sizes
We'll reuse meta_monitor_get_closest_scale_factor_for_resolution() for the
conversion of monitor configs, and during those conversions, we probably don't
want to impose the same limits to fractional scales that we usually impose.
This means that we can even convert physical layout configs where the user
manually changed to a value higher than what our fractional scale calculations
would allow.

Move this check into the calling function so that it's not imposed by
meta_monitor_get_closest_scale_factor_for_resolution() directly.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Jonas Dreßler
078d95cc15 monitor: Make function to calculate fractional scale factor public
We'll need this function for migrating from PHYSICAL layout mode to LOGICAL
layout mode soon, so make it public.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Jonas Dreßler
0d23eb1da8 monitor-config-manager: Move verification of logical monitor configs into utils
We'll need these verification utilities in the next commits where we introduce
detection for physical vs logical layout modes.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Jonas Dreßler
bbb34c2a80 monitor-config-store: Detect unkown layout modes based on the configuration
When there is no layout mode set in a logical monitor config, we currently just
assume the configuration matches the mode that the system expects. This blows
up when the layout mode expected by the system changes (eg. by turning on
"scale-monitor-framebuffers" in mutter): Suddenly configs fail the validation
check and get thrown away.

Since we now can add one configuration for each layout mode to the config store,
we can do better here: Let's only add configurations to the store where we
verified beforehand that the monitor layout is compatible with that mode, either
because we set it ourselves using the <layout_mode> key, or by detecting which
modes the layout is compatible with.

Also update monitor config ifiles to adjust for the new layout_mode, as
they all are assumed to be "logical".

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Jonas Dreßler
becee89fb9 monitor-config-manager: Verify more things about logical monitor configs
Verify even more assumptions we make about logical monitor configs:

- Have a more explicit check that the monitor modes in the logical monitor are
all equal

- Complain if scale factor with physical layout mode is fractional

- Make sure that scale factor with logical layout mode actually scales to a
non-fractional width and height

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Jonas Dreßler
a203020c4b monitor-config-manager: Move some things into common file for config utils
We'll need a few of those things from the monitor config store soon, also it's
generally useful to have a prefix which makes it clear where functions are
defined.

So factor some things out into a new monitor-config-utils.c file.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Jonas Dreßler
076b3664a3 monitor-config-store: Store and load layout mode for each configuration
Store and load the layout mode for each logical monitor configuration in
monitors.xml by introducing a new <layoutmode> element. The value of the
element can be either "logical" or "physical". The layout mode is also
made part of the monitor configuration key.

Right now this isn't doing a lot:

When no <layoutmode> is found on the config (this is the case with all
existing configs), we'll keep using the layout mode expected by the system,
without updating the config file.

When changing an existing, or introducing a new configuration, we'll now
store the current layout mode with the config though, and load it again
on the next start of mutter. This is still not problematic as long as
mutters expected layout mode doesn't change (eg. by turning on/off
"scale-monitor-framebuffers").

When the expected layout mode of mutter switches between
restarts, the monitor config is now still loaded but remains unused,
and mutter will create (and store) a new one with the other layout mode.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Jonas Dreßler
de56634fd0 Remove monitor migration support from v1 monitors.xml format
We'll introduce some new migration code with the next few commits to introduce
a layout_mode property in monitors.xml. This will be significantly easier
without keeping around the old monitor migration code, so drop it.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Jonas Dreßler
4105827254 monitor-config-manager: Do more verification of logical monitor configs
We have meta_verify_logical_monitor_config() already, and it does a few checks that
meta_verify_monitors_config() doesn't do yet, so let's also call
meta_verify_logical_monitor_config() when verifying the whole config.

We'll rely on this being part of meta_verify_monitors_config() soon, because we'll
stop calling meta_verify_logical_monitor_config() from the config parser.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Jonas Dreßler
72b324d686 monitor-config-manager: Verify the whole monitor layout is connected
We forgot to check whether multiple groups of monitors are actually
all connected with each other, so fix that.

[jadahl: Rewrote algorithm to detect split groups]
[jadahl: Added test case]

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
2024-08-14 13:07:47 +00:00
Sebastian Wick
ce5f97fde1 cogl/gles: Explain GLES2 requirement of matching internalformat & format
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3914>
2024-08-14 12:17:18 +00:00
Sebastian Wick
c3eb01e547 cogl/gles: Use the GL_BGRA8_EXT internalformat instead of the format
There is one define for the format (GL_BGRA_EXT) and one for the
internal format (GL_BGRA8_EXT). Use them appropriately.

This also adds defines to consistenly not use the _EXT postfix.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3914>
2024-08-14 12:17:18 +00:00
Sebastian Wick
d820fe030a cogl/gles: Use a premul required format for opaque fp16 Cogl formats
The opaque fp16 Cogl format variants need a required format that is
already premultiplied whereas the fp16 formats with an alpha channel can
be either straight or premult.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3914>
2024-08-14 12:17:18 +00:00
Sebastian Wick
41700d3cc7 cogl/gl: Use internal formats without alpha for non-alpha Cogl formats
The formats COGL_PIXEL_FORMAT_RGB_888 and COGL_PIXEL_FORMAT_BGR_888 for
the gl driver were using internal formats with an alpha channel.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3914>
2024-08-14 12:17:18 +00:00
Carlos Garnacho
2e82a2049f wayland: Register touchpoint info on CLUTTER_ENTER
The first event happening for a new touch will be the CLUTTER_ENTER
event generated when picking it. Use this event for registration of
the touch info, so that MetaWaylandEventHandler.get_focus_surface may
get the right focus surface for the device/sequence on the first try.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3889>
2024-08-14 11:47:01 +02:00
Carlos Garnacho
77b21ef8dc wayland: Only cancel touch when a new event handler takes over
And notably, don't cancel touch when an event handler is being
removed. Touch events are largely unaffected by most Wayland
grabs (pointer constraints, popups), so we might be cancelling
input too early if one of these wayland grabs was effective when
touch interaction began, but stopped sometime between touch updates.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3889>
2024-08-14 11:47:01 +02:00
Carlos Garnacho
08c903a359 wayland: Ignore touch events in seat default focus handler
Touch events are implicitly grabbed to the surface they began in,
and are not affected by the focus handler. However these events
will appear to come from the core pointer device, which might lead
to the wrong device being updated.

Ignore events with a sequence, since the default focus handler
does not intend to do anything with them.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3889>
2024-08-14 11:46:55 +02:00
Daniel van Vugt
c436e7cb17 kms/impl-device: Add/remove deadline timer as required
On a hybrid machine with i915 primary and nvidia-drm (470) secondary,
`meta_render_device_egl_stream_initable_init` calls
`meta_kms_inhibit_kernel_thread` to change from the default 'kernel'
thread type to 'user'. And soon after that it would
`meta_render_device_egl_stream_finalize` because I'm not actually
using that GPU, and calls `meta_kms_uninhibit_kernel_thread`.

So during startup Mutter would default to a realtime kernel thread,
switch to a user thread (which doesn't support realtime), and then
switch back to a realtime kernel thread.

In the middle of all that, while the thread type was 'user' and
realtime disabled, something was invoking `ensure_crtc_frame` which
created a `CrtcFrame` without a deadline timer. Soon after that the
thread type changed back to 'kernel' with deadline timers expected, but
our existing `CrtcFrame` has no deadline timer associated with it. And
so it would never fire, causing the cursor to freeze whenever the primary
plane isn't changing. And the problem was permanent, not just the first
frame because each `CrtcFrame` gets repeatedly reused (maybe shouldn't
be called a "Frame"?).

Now we adapt to switching between kernel and user thread types by adding
and removing the deadline timer as required.

Close: https://gitlab.gnome.org/GNOME/mutter/-/issues/3464
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3950>
2024-08-14 15:50:48 +08:00
Sebastian Wick
82fa9e676a color-device: Don't create colord profiles for virtual monitors
Colord is a system service which will result in a polkit dialog showing
up when connecting a remote session.

We want to get rid of colord eventually anyway, so disconnecting virtual
monitors from colord isn't an issue.

Fixes: f5ce2ddf3c ("color-manager: Create color devices also for virtual monitors")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3942>
2024-08-13 22:10:03 +00:00
Robert Mader
bb55a1e83a compositor-view/native: Add debug flag to force-disable direct scanout
In order to make it easier to test composited paths.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3949>
2024-08-13 21:09:50 +02:00
Bilal Elmoussaoui
4ea693bc20 surface-actor: Pass damage area as MtkRectangle
All the corresponding calls ends up creating a rectangle anyways

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3945>
2024-08-13 14:08:48 +02:00
Bilal Elmoussaoui
cbe88c8e71 surface-actor: Replace \r\n with \n
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3945>
2024-08-13 14:08:48 +02:00
Jonas Ådahl
8e2587c197 kms: Don't disarm deadline timer when compositing
If we finish compositing in time, the composited result will be
submitted prior to the deadline timer is triggered, and we'll be fine,
and if not, at least the cursor updates will be smooth, which makes it
appear smoother than not.

There is a risk that this can negatively impact composited updates when
moving the cursor, so make it possible to toggle a paint-debug flag for
now until this has been more tested.

This also mean we need to disarm the deadline timer after handling
update, as there might be a scheduled cursor update pending, but we
already handled it, so disarm the timer.

Here is an illustration of the difference.

In the following scenario, with disarming, the composited frame E, and
the cursor movement C gets presented. With this branch, only the cursor
movement C gets presented.
```
 * A: beginning of composited frame
 * B: begin notification reaches KMS thread
 * C: cursor moved
 * D: calculated deadline dispatch time (disabled with the branch)
 * E: KMS update posted
 * F: KMS update reaches KMS thread
 * G: actual deadline (and with branch and gets committed)
Compositor thread: --------A---------------E---------
                            \               \
                             \               \
KMS thread:        -----------B------C----D---F-G----
```

In the following scenario, by not disarming, the cursor update C will be
presented, and the would-be-delayed composited frame E would be delayed
anyway, i.e. fixing cursor stutter.
```
 * A: beginning of composited frame
 * B: begin notification reaches KMS thread
 * C: cursor moved
 * D: calculated deadline dispatch time (and with branch will be dispatched)
 * E: KMS update posted
 * F: actual deadline
 * G: KMS update reaches KMS thread (and with branch gets postponed)
Compositor thread: --------A---------------E---------
                            \               \
                             \               \
KMS thread:        -----------B------C----D-F-G------
```

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3184>
2024-08-13 10:09:05 +00:00
Jonas Ådahl
6ec1312384 renderer-view/native: Update deadline evasion each frame
The deadline evasion depends on debug flags, but they are not trackable,
so update the deadline evasion each time we schedule an update.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3184>
2024-08-13 10:09:05 +00:00