Commit Graph

28389 Commits

Author SHA1 Message Date
Jonas Ådahl
8cb177499d context/test: Configure test setup during configuration
This includes setting up the GLib test framework, overriding the X11
and Wayland display names.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
2021-07-15 10:43:28 +02:00
Jonas Ådahl
bbf6d88d54 test-utils: Expose helper for ensuring client path
Will be used by the test context to reduce boiler plate.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
2021-07-15 10:43:28 +02:00
Jonas Ådahl
6c6b5b9a48 context: Add entry points for context configuration
Configuration is the first step of the lifetime of a context, after
creation; it's here where argc/argv is processed, and it's determined
what kind of compositor, etc, it is going to be.

The tests always run as Wayand compositors, so the configuration is
quite simple, but will involve more steps later on.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
2021-07-15 10:43:28 +02:00
Jonas Ådahl
bf84b2423d main: Move MetaCompositorType to a new meta-enums.h
It'll be part of and owned by MetaContext, intending to replace
`meta_is_wayland_compositor()`, but place it in a new file for public
enums so that it can be used from wherever.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
2021-07-15 10:43:28 +02:00
Jonas Ådahl
e17bf88d5e tests: Introduce MetaContextTest
This introduces a MetaContext implementation aimed to be used for test
cases, with as little boiler plate as possible needed in the test.

It currently doesn't do anything, just fills out the GObject boiler
plate and sets a name.

Build it into every core test, for compilation, even though it isn't
used anywhere yet.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
2021-07-15 10:43:28 +02:00
Jonas Ådahl
e020fdfddf Introduce mostly empty MetaContext type
This type is intended to replace the scattered functions used to
configure how the Mutter compositor is run. It currently doesn't do
anything, and only has a human readable name, intended to be set to e.g.
"GNOME Shell".

It's an abstract type, and is intended to be used via either a future
`MetaContextMain` for real display server use cases, and a
`MetaContextTest` for test cases.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
2021-07-15 10:43:28 +02:00
Carlos Garnacho
5e8c808cfb ci: Add job for pushing coverity reports
This job does:
1. Download the coverity bundle and untar it
2. Build mutter using clang and the coverity tool
3. Compress the coverity report
4. Upload for analysis

Things to note:
- Analysis are throttled, as per https://scan.coverity.com/faq#frequency
  we qualify for 21 weekly builds, 3 daily. Mutter is sometimes a busy
  project, so it seems we'd get often those consumed early in the day.
  This is something we can resign to, but the times we'll try to upload
  a report to have it rejected make the operation kinda pointless and
  probably better throttled by ourselves.
- The task is manual, given the restrictions above.
- The task only applies on master, as the envvar holding the coverity
  token is protected in gitlab.
- I had to use clang as the coverity tool doesn't seem to work ATM with
  gcc as per recent Fedora.
- The coverity tarball is 1.2GB in size, which is a bit too big to have
  it downloaded each time. As per their upload instructions, the tarball
  gets updated twice yearly, so this is cached to minimize downloads.
- The coverity token for mutter is kept private/hidden in gitlab CI
  settings.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1100>
2021-07-13 15:14:21 +00:00
Jonas Ådahl
23b79f33fa launcher: Remove open/close restricted file API
It has since some time been replaced with MetaDevicePool, and isn't used
by anything anymore, so remove it.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1929>
2021-07-13 12:19:14 +00:00
Daniel van Vugt
0555a5bbc1 clutter/frame-clock: Apply error diffusion (dithering) to dispatch times
But only the dispatch times used when `last_presentation_time_us == 0`
(Nvidia + Xorg).

This ensures the average dispatch interval is always precisely equal
to the refresh interval, regardless of any jitter in the mainloop.

Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1751,
       https://gitlab.gnome.org/GNOME/mutter/-/issues/1758,
       https://gitlab.gnome.org/GNOME/mutter/-/issues/1870

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1826>
2021-07-13 17:18:17 +08:00
Daniel van Vugt
ba1490ec9c clutter/frame-clock: Remember the refresh interval
Instead of recalculating it every time we need it. The performance
gain is not important; this is more because it will be needed in
multiple functions soon.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1826>
2021-07-13 17:18:14 +08:00
Ivan Molodetskikh
a5d1d48bf1 clutter: Add a max render time debug HUD
Not sure how to update the damage or redraw clip or something; at least
this works properly when under a constantly-redrawing window, which is
ok for debugging purposes.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:43 +00:00
Ivan Molodetskikh
f55c9af618 clutter: Add an lg command to set max render time constant
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:43 +00:00
Ivan Molodetskikh
565e34b4d2 clutter: Add a flag to disable heuristic max render time
Debugging purposes: allows to check if frame drops are caused by
heuristic max render time or if they are there even with the old
behavior.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:43 +00:00
Ivan Molodetskikh
592fbee065 clutter: Compute max render time heuristically
Max render time shows how early the frame clock needs to be dispatched
to make it to the predicted next presentation time. Before this commit
it was set to refresh interval minus 2 ms. This means Mutter would
always start compositing 14.7 ms before a display refresh on a 60 Hz
screen or 4.9 ms before a display refresh on a 144 Hz screen. However,
Mutter frequently does not need as much time to finish compositing and
submit buffer to KMS:

      max render time
      /------------\
---|---------------|---------------|---> presentations
      D----S          D--S

      D - frame clock dispatch
      S - buffer submission

This commit aims to automatically compute a shorter max render time to
make Mutter start compositing as late as possible (but still making it
in time for the presentation):

         max render time
             /-----\
---|---------------|---------------|---> presentations
             D----S          D--S

Why is this better? First of all, Mutter gets application contents to
draw at the time when compositing starts. If new application buffer
arrives after the compositing has started, but before the next
presentation, it won't make it on screen:

---|---------------|---------------|---> presentations
      D----S          D--S
        A-------------X----------->

                   ^ doesn't make it for this presentation

        A - application buffer commit
        X - application buffer sampled by Mutter

Here the application committed just a few ms too late and didn't make on
screen until the next presentation. If compositing starts later in the
frame cycle, applications can commit buffers closer to the presentation.
These buffers will be more up-to-date thereby reducing input latency.

---|---------------|---------------|---> presentations
             D----S          D--S
        A----X---->

                   ^ made it!

Moreover, applications are recommended to render their frames on frame
callbacks, which Mutter sends right after compositing is done. Since
this commit delays the compositing, it also reduces the latency for
applications drawing on frame callbacks. Compare:

---|---------------|---------------|---> presentations
      D----S          D--S
           F--A-------X----------->
              \____________________/
                     latency

---|---------------|---------------|---> presentations
             D----S          D--S
                  F--A-------X---->
                     \_____________/
                      less latency

           F - frame callback received, application starts rendering

So how do we actually estimate max render time? We want it to be as low
as possible, but still large enough so as not to miss any frames by
accident:

         max render time
             /-----\
---|---------------|---------------|---> presentations
             D------S------------->
                   oops, took a little too long

For a successful presentation, the frame needs to be submitted to KMS
and the GPU work must be completed before the vblank. This deadline can
be computed by subtracting the vblank duration (calculated from display
mode) from the predicted next presentation time.

We don't know how long compositing will take, and we also don't know how
long the GPU work will take, since clients can submit buffers with
unfinished GPU work. So we measure and estimate these values.

The frame clock dispatch can be split into two phases:
1. From start of the dispatch to all GPU commands being submitted (but
   not finished)—until the call to eglSwapBuffers().
2. From eglSwapBuffers() to submitting the buffer to KMS and to GPU
   work completing. These happen in parallel, and we want the latest of
   the two to be done before the vblank.

We measure these three durations and store them for the last 16 frames.
The estimate for each duration is a maximum of these last 16 durations.
Usually even taking just the last frame's durations as the estimates
works well enough, but I found that screen-capturing with OBS Studio
increases duration variability enough to cause frequent missed frames
when using that method. Taking a maximum of the last 16 frames smoothes
out this variability.

The durations are naturally quite variable and the estimates aren't
perfect. To take this into account, an additional constant 2 ms is added
to the max render time.

How does it perform in practice? On my desktop with 144 Hz monitors I
get a max render time of 4–5 ms instead of the default 4.9 ms (I had
1 ms manually configured in sway) and on my laptop with a 60 Hz screen I
get a max render time of 4.8–5.5 ms instead of the default 14.7 ms (I
had 5–6 ms manually configured in sway). Weston [1] went with a 7 ms
default.

The main downside is that if there's a sudden heavy batch of work in the
compositing, which would've made it in default 14.7 ms, but doesn't make
it in reduced 6 ms, there is a delayed frame which would otherwise not
be there. Arguably, this happens rarely enough to be a good trade-off
for reduced latency. One possible solution is a "next frame is expected
to be heavy" function which manually increases max render time for the
next frame. This would avoid this single dropped frame at the start of
complex animations.

[1]: https://www.collabora.com/about-us/blog/2015/02/12/weston-repaint-scheduling/

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:43 +00:00
Ivan Molodetskikh
4a4e61c1f1 clutter: Add FRAME_TIMINGS debug key
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:43 +00:00
Ivan Molodetskikh
8d51c5ac55 clutter/frame-clock: Store dispatch timings
Will be used to adjust max render time dynamically.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:43 +00:00
Ivan Molodetskikh
8c4a91ddd6 clutter: Add swap time and GPU rendering duration to FrameInfo
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:43 +00:00
Ivan Molodetskikh
1116b14f38 backends/native: Get rendering and swap timings during scanout
Scanout doesn't go through the usual path of compositing and doing
eglSwapBuffers, therefore it doesn't hit the timestamp query placed in
that path. Instead, get the timings by binding the scanout buffer to an
FBO and doing a timestamp query on the FBO.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:42 +00:00
Ivan Molodetskikh
5a0d3ed4dd backends/native: Remove unneeded NULL check
There seems to be no way to construct this type with an invalid bo.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:42 +00:00
Ivan Molodetskikh
f1024564a2 cogl: Store CPU and GPU rendering timestamps in frame info
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:42 +00:00
Ivan Molodetskikh
8c258d1de1 cogl: Add CPU swap time and GPU rendering query to CoglFrameInfo
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:42 +00:00
Ivan Molodetskikh
fbe6740df1 cogl: Add GPU timestamp querying utilities
Add utilities that allow getting the current GPU timestamp and creating
a query which completes upon completion of all operations currently
submitted on a framebuffer. Combined, these two allow measuring how long
it took the GPU to finish rendering something to a framebuffer.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:42 +00:00
Ivan Molodetskikh
cc08af48f6 cogl: Add prototypes for getting timestamp queries
Will be used for measuring GPU rendering duration.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:42 +00:00
Ivan Molodetskikh
3aa0e3074f clutter: Store vblank duration in ClutterFrameClock
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:42 +00:00
Ivan Molodetskikh
d10567ea3e clutter: Add vblank duration to ClutterStageView
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:42 +00:00
Ivan Molodetskikh
2d939754b1 crtc-mode-info: Add vblank duration field
Only populated for KMS backed modes, as that's where it's relevant.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:42 +00:00
Ivan Molodetskikh
e40ff9d8b7 backends/native: Add meta_calculate_drm_mode_vblank_duration_us()
Computes the vblank duration from mode timings.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:42 +00:00
Ivan Molodetskikh
63b9ac2724 clutter: Record flip time
Will be used for intelligent max render time computation (aka repaint
scheduling).

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
2021-07-13 08:09:42 +00:00
Daniel van Vugt
9f492a0ee0 kms: Add fixed point formatting to MUTTER_DEBUG=kms printing
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1923>
2021-07-13 15:29:14 +08:00
Daniel van Vugt
b59c5386b9 kms: Add a trivial meta_fixed_16_to_double conversion function
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1923>
2021-07-13 15:26:43 +08:00
Daniel van Vugt
ea75ea0b73 kms: Add an internal MetaKmsPropType to distinguish fixed point values
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1923>
2021-07-13 15:26:43 +08:00
Chao-Hsiung Liao
c5c7982e33 Update Chinese (Taiwan) translation 2021-07-10 07:16:38 +00:00
Jonas Ådahl
c2c41bbf0a tests/kms-utils: Add some basic 16:16 fixed tests
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1927>
2021-07-09 22:40:06 +00:00
Jonas Ådahl
021a401bc8 tests: Move out KMS utils unit tests to its own executable
Better to split things up a bit, so one can with more ease run a
specific test.

In the KMS utils case, we don't even need a mutter context, making it
much lighter.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1927>
2021-07-09 22:40:05 +00:00
Carlos Garnacho
ec390b68c5 wayland: Implement the xdg-activation protocol
This protocol implements the IPC necessary to focus application
windows across launcher/launchee. Add support for it.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1845>
2021-07-09 09:34:28 +00:00
Carlos Garnacho
665081d268 core: Add ::timeout signal to MetaStartupSequence
These objects are missing explicit notifications about when they
are going away by themselves, add one.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1845>
2021-07-09 09:34:28 +00:00
Carlos Garnacho
2115debd09 build: Add xdg-activation to build
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1845>
2021-07-09 09:34:28 +00:00
Carlos Garnacho
256939cb84 build: Add support for "staging" wayland protocols
These come in a different folder, with no stable/unstable nomenclature.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1845>
2021-07-09 09:34:28 +00:00
Daniel van Vugt
d996319cf9 kms: Add a missing g_set_error on error
So the GError is not left NULL and then dereferenced.

Fix provided by Jonas Ådahl <jadahl@gmail.com>

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1878
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1925>
2021-07-09 16:26:11 +08:00
Jonas Ådahl
747dbe2a69 ci: Bump to F34
This drops some custom building of various components that are now up to
date. While at it, start using the FDO_DISTRIBUTION_PACKAGES variable to
install packages, as it with the bumped ci-templates version also
doesn't install weak dependencies.

This also requires tweaking the pipewire dead lock work arounds, as it
changed configuration file paths.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1865>
2021-07-08 13:15:18 +00:00
Jonas Ådahl
8afae2ebaf clutter/xsettings-client: Zero-initialize stack struct
This fixes a warning/error:

In function 'parse_settings',
    inlined from 'read_settings' at ../clutter/clutter/x11/xsettings/xsettings-client.c:398:25:
../clutter/clutter/x11/xsettings/xsettings-client.c:202:13: error: 'buffer.byte_order' may be used uninitialized [-Werror=maybe-uninitialized]
  202 |   if (buffer.byte_order != MSBFirst &&
      |       ~~~~~~^~~~~~~~~~~

This is needed to bump the CI image from F33 to F34, which includes a
upgraded compiler.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1865>
2021-07-08 13:15:18 +00:00
Florian Müllner
357c506ee7 events: Only support super+scroll on wayland
On Xorg, the event only reaches us when the pointer is within the
stage input region. That makes the feature more confusing than
useful, so make it wayland-only.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3759

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1922>
2021-07-08 00:02:41 +02:00
Jonas Ådahl
ce5a5789bb native: Release output device files that are unused
In order to make it possible to e.g. unload an unused DRM device, we
need to make sure that we don't keep the file descriptor open if we
don't need it; otherwise we block anyone from unloading the
corresponding module.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
2021-07-07 21:10:30 +02:00
Jonas Ådahl
3c47661b78 egl: Add eglBindAPI helper
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
2021-07-07 21:03:26 +02:00
Jonas Ådahl
5e45dc15b6 cogl/renderer: Add API to bind the right EGL API
We need to call eglBindAPI() with GLES before we setup the secondary
GPU blit. We've been lucky not really needing this, as it has been
GLES default, which is what the secondary blit uses, in order to not
depend on the default, or if we want to create the secondary blit
objects after initializing cogl, we must make sure to bind the right API
at the right time.

As we need to bind the GLES API when setting up the secondary blit, we
need to make sure that cogl gets the right API bound when that's done,
so Cogl can continue working. For this, add a "bind_api()" method on the
CoglRenderer object, that will know what API is correct to bind.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
2021-07-07 21:03:26 +02:00
Jonas Ådahl
173d895d53 kms: Remove now unused API to get file descriptor
The last user switched to using MetaDeviceFile, so time to clean up.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
2021-07-07 21:03:26 +02:00
Jonas Ådahl
10c4bc6e3f drm-buffer: Create from MetaDeviceFile instead of MetaKmsDevice
The DRM buffers aren't really tied to mode setting, so they shouldn't
need to have an associated mode setting device. Now that we have a
device file level object that can fill this role, port over
MetaDrmBuffer and friends away from MetaKmsDevice to MetaDeviceFile.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
2021-07-07 21:03:26 +02:00
Jonas Ådahl
6613463f58 renderer/native: Decouple device file from MetaKmsDevice
Keep a private MetaDeviceFile instance for the GPU's managed by the
renderer. This is a step towards decoupling rendering from mode setting,
as well as on-demand holding of device file descriptors.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
2021-07-07 21:03:26 +02:00
Jonas Ådahl
e567cb972d renderer/native: Get 'uses-monotonic' state from MetaKmsDevice
It's better suited to be handled by the MetaKmsDevice abstraction.

This eliminates the last caller of drmGetCaps() from outside
MetaKmsImplDevice.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
2021-07-07 21:03:26 +02:00
Jonas Ådahl
86c4369f41 renderer/native: Look up prefers-shadow cap via MetaKmsDevice
This eliminates the second last user of drmGetCap() from outside of
MetaKmsImplDevice.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
2021-07-07 21:03:26 +02:00