As with the compositor type enum, also have the X11 display policy enum,
as it's also effectively part of the context configuration. But as with
the compositor type, move it to a header file for enums only, and since
this is a private one, create a private variant meta-enums.h.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
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>
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>
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>
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>
Tags are meant to make it possible for a device file opener to tag a
file if it has affected the state the file descriptor is in; e.g. if it
has enabled a DRM capability.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
Handle open() failing due to being interrupted by trying again until it
either succeeds, or fails due to some other error. This was an error
handling path taken when opening sysfs files; do the same here to not
potentially regress once we open sysfs files with the device pool.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
It's only when we take/release from/to logind we need these two
integers, so only retrieve them when that's done. Making this change
makes it possible to open devices that don't have these parameters.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
This changes the way the KMS backends load; if we're headless, we always
use the dummy one and fail otherwise; in other cases, we first try the
atomic backend, and if that fails, fall back on the simple one.
The aim for this is to have the impl device open and close the device
when needed, using the device pool directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
This practically does the same thing as part of MetaLauncher, except
with added thread safety and caching. For example, opening the same file
a second time will return the same MetaDeviceFile, and only once all
acquired MetaDeviceFile's are released, will the file descriptor be
closed and control of the device released.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
ClutterInputDevice's get_group_n_modes() vfunc is meant to return
-1 for groups that are out of the known range, not within. Fix the
early return condition, and let the native backend return correctly
the number of modes for the given group.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1920>
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.
Inspired by (and commit log mostly copied from) e6a13e5d57
("monitor-stream-src: Add before-paint watch to catch scanouts").
v2:
* Do not call stage_painted from before_stage_painted (Georges Basile
Stavracas Neto)
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1707
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1902>
When drmModePageFlip() or drmModeAtomicCommit() unexpectedly failed (e.g.
ENOSPC, which has been seen in the wild), this failure was not handled
very gracefully. The page flip listener for the scanout was left in the
MetaKmsUpdate, meaning when the primary plane composition was later page
flipped, two page flip listeners were added, one for the primary plane,
and one for the scanout. This caused the 'page-flipped' event to be
handled twice, the second time being fatal.
Handle this by making 'no-discard' listener flag be somewhat reversed,
and say 'drop-on-error', and then drop all 'drop-on-error' listeners
when a MetaKmsUpdate failed to be processed.
Also for a "preserve" flagged update, don't ever trigger "discard"
callbacks just yet, as preserved updates are used again for the primary
plane composition, in order to not miss e.g. CRTC gamma updates, or
cursor plane updates, which were added separately.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1809
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1910>
There is an udev rule marking whether a device should be ignored by
mutter or not, but it was only respected on hotplug events not on init,
partly defeating its purpose. Fix this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1892>
A view is only a 'CoglOnscreen' if it ends up on a CRTC, thus needs a
mode. Other views are for virtual monitors, and require no mode setting,
so exclude them from the pending mode set list.
This avoids a dead lock when we'll be waiting indefinitely for mode
setting on a virtual monitor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1891>
This object takes over the functionality of meta-idle-monitor-dbus.c,
meta-idle-monitor.c and meta-backend.c, all related to higher level
management of idle watches etc.
The idle D-Bus API is changed to be initialized by the backend instead
of MetaDisplay, as it's more of a backend functionality than what
MetaDisplay usually deals with.
It also takes over the work of implementing "core" idle monitors. The
singleton API is replaced with thin wrapper functions on the backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1859>
Wayland support is not really a "backend" thing, it just lacked a better
place to store its instance pointer. Eventually we'll have a better
place, but prepare for that by initializing it together with the more
similar subsystems.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1833>
Commit 64c9c9c5b0 fixed monitor
screencasting, when fractional screencasting is enabled.
For the remote desktop usage, NotifyPointerMotionAbsolute() submits
the new mouse pointer position in addition to the stream, where the
mouse pointer was moved.
When not using fractional scaling, the mouse pointer position is
correct.
With the usage of fractional scaling, the mouse pointer position is
wrong, as the scale of the position is applied two times.
Fix this behaviour, by reverting the second scale by dividing by the
logical monitor scale, when fractional scaling is used.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1808
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1867>
When finalizing, the MetaDisplay instance will already be gone, so to be
able to gracefully tear down the clipboard integration, make sure to
close sessions before the display is closed, i.e. on prepare-shutdown.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1853>
This commit adds scaling support to clutter_stage_capture_into, which
is currently used when screencasting monitors. This is supposed to
fix graphical issues that arise when using fractional scaling.
Fixes#1131
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1855>
It keeps references to cursors, and cursors keep references to DRM
buffers. In order to be able to clean up on exit, explicitly destroy the
cursor tracker on shutdown.
We can't rely on GObject reference counting, as gjs might hold onto a
reference until it's garbage collected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
Various things, e.g, the renderer, the stage, either directly or
indirectly depends on GPU objects being alive during tear-down. Make it
so, by moving GPU cleanup after the other cleaning. This will allow
tearing down a couple of more objects.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
The first phase happens early, which discards pending page flips,
meaning the references held by those page flip closures are released.
The second phase happens late, after other units depending on the KMS
abstraction, have been cleaned up.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
We already swapped the front buffer, and even if it didn't get
presented, we should still swap our representation of the state, to not
get into a confused buffer tracking state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
All pointer a11y is a fabrication of Clutter backend-independent
code, with the help of a ClutterVirtualInputDevice and with some
UI on top.
On the other hand, MetaInputSettings is a backend implementation
detail, this has 2 gotchas:
- In the native backend, the MetaInputSettings (and pointer a11y
with it) are initialized early, before the ClutterSeat core
pointer is set up.
- Doing this from the MetaInputSettings also means another dubious
access from the input thread into main thread territory.
Move the pointer a11y into ClutterSettings, making this effectively
backend-independent business, invariably done from the main thread
and ensured to happen after seat initialization.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1765
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1849>
Virtual Kernel Mode Setting (vkms) is a virtual /dev/dri/card* device
not backed by any actual hardware. It's intended for testing purposes,
e.g. to run tests suites with a reproducable setup, or in continuous
integration pipelines.
Currently mutter don't have any tests that can run on top of vkms, but
will eventually get that. To prepare for the ability to do that, and
having said kernel module loaded without causing wierd issues with any
active session, add an udev rule that tells mutter to ignore any vkms
device.
Otherwise, when vkms is loaded, mutter would detect it, assume it's a
regular monitor, configure it as such, thus add a region of the stage
that ends up nowhere, which isn't very helpful. It might also conflict
with running actual tests that need to interact with vkms if the active
session has taken control of it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1740>
With atomic mode setting, commits don't work when CRTCs aren't enabled,
which they aren't when we're power saving. This means the gamma state
fails to being update. To fix night light and for whatever other reason
gamma ramps was changed during power saving by marking the CRTC gamma
state as invalid when leaving power saving, as well as when resuming.
This means that the next frame will append the CRTC gamma state to the
KMS commit.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1755
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1835>
This GSource is not being properly unref nor the variable holding it
cleared. This on one hand leaks the GSource memory, on the other hand
may trigger warnings in keyboard_repeat() as the source may be
(reentrantly) cleared, yet we don't exit early as
seat_impl->repeat_source is never NULL.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1839>
The X server generates a property change notification whenever it processes a
property change request, even if the value of the property is not changing. This
triggers libgdk to probe all display outputs, which can be slow depending on
which display driver and hardware are in use.
#0 0x00007f8e4d5e91a0 in XRRUpdateConfiguration () at /usr/lib/libXrandr.so.2
#1 0x00007f8e505208da in _gdk_x11_screen_size_changed (screen=0x5566e4b7e080, event=0x7ffe0e44bd60) at ../gdk/x11/gdkscreen-x11.c:1199
#2 0x00007f8e505066d1 in gdk_x11_display_translate_event (translator=0x5566e4b5b110, display=0x5566e4b5b110, event=0x7f8dec001b20, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkdisplay-x11.c:1201
#3 0x00007f8e505135a0 in _gdk_x11_event_translator_translate (translator=0x5566e4b5b110, display=0x5566e4b5b110, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkeventtranslator.c:51
#4 0x00007f8e50512c97 in gdk_event_source_translate_event (event_source=0x5566e4b764a0, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkeventsource.c:243
#5 0x00007f8e50512f57 in _gdk_x11_display_queue_events (display=0x5566e4b5b110) at ../gdk/x11/gdkeventsource.c:341
#6 0x00007f8e50497644 in gdk_display_get_event (display=0x5566e4b5b110) at ../gdk/gdkdisplay.c:442
#7 0x00007f8e5051301f in gdk_event_source_dispatch (source=0x5566e4b764a0, callback=0x0, user_data=0x0) at ../gdk/x11/gdkeventsource.c:363
#8 0x00007f8e516ecf9c in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#9 0x00007f8e51740a49 in () at /usr/lib/libglib-2.0.so.0
#10 0x00007f8e516ec503 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#11 0x00007f8e508ef5fd in meta_run_main_loop () at ../src/core/main.c:928
#12 0x00007f8e508ef60e in meta_run () at ../src/core/main.c:943
#13 0x00005566e450842a in ()
#14 0x00007f8e50649b25 in __libc_start_main () at /usr/lib/libc.so.6
When GNOME is animating a display fade when the night light feature is toggled
on or off, it sends a lot of change requests for the CTM property in the
process, which triggers a lot of display probes from gdk. In the case of the
night light feature, the CTM itself is not actually changing, so these requests
are redundant. Fix this by caching the CTM value in the MetaOutputXrandr and
skipping the server requests if it's not being changed.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3978
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1816>
When we set the matrix, we checked the device mapping mode in the main
thread, then passed along the calculated matrix to the input thread for
application. This could however be racy, as the mapping mode is managed
in the input thread. Fix this by sending the unaltered matrix, having
the input thread checking the mapping mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1806>
The connector state wasn't properly predicted, as it earlied out if
the connector wasn't part of a mode set connector list.
Instead use the old CRTC to check whether it was used in any mode set,
and whether the connector was part of any new mode set, to predict
whether the connector is inactive or active.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1821>
When a device only had mode sets which turned off monitors, not enabling
anything, there would be no KMS update created and posted, and the
active monitors would remain on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1821>
On hybrid graphics system, the primary path used to transfer the stage
framebuffer onto the dedicated GPU's video memory preparing for scanout,
is using the dedicated GPU to glBlitFramebuffer() the content from the
iGPU texture onto the scanout buffer.
After we have done this, we reset the current EGL context back to the
one managed by cogl. What we failed to do, however, was to reset the
current EGL context when we inhibited the actual page flip due to having
entered power save mode.
When we later started to paint again, Cogl thought the current EGL
context was still the correct one, but in fact it was the one used for
the iGPU -> dGPU blit, causing various EGL surface errors, and as a side
effect, eventually hitting an assert.
Fix this by making sure we reset to the Cogl managed EGL context also
for this case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1803>
Destroying the EGLSurface frees the underlying container structs. When
we call gbm_surface_release_buffer() with a gbm_surface the EGLSurface
was created from, doing that after the EGLSurface was destroyed results
in attempts to access freed memory. Fix this by releasing any buffer
first, followed by destroying the EGLSurface, and lastly, the
gbm_surface.
This was not a problem prior to CoglOnscreen turning into a GObject, as
in that case, the dispose-chain was not setup correctly, and the
EGLSurface destruction was done in the native backend implementation.
This also changes a g_return_if_fail() to a g_warn_if_fail(), as if we
hit the unexpected case, we still need to call up to the parent dispose
vfunc to not cause critical issues.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1803>
It's handled by CoglOnscreenEgl's dispose() implementation. It was
failed to be invoked in the past because the old non-GObject web of
vtables were not setup correctly, meaning the old generic EGL layer of
the CoglOnscreen de-init was never invoked.
When the type inheritence was cleaned up, this mistake was not cleaned
up, so do that now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1803>
Meson doesn't seem to handle depending on generated headers, at least
when those headers are pulled in indirectly via another header file.
Luckily, we don't actually need to include the generated D-Bus boiler
plate in meta-monitor-manager-private.h, since the MetaMonitorManager
type no longer is based on the D-Bus service skeleton.
So, by moving the inclusion of the generated D-Bus header file into
meta-monitor-manager.c, we should hopefully get rid of the sporadic
build issues.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1682
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1819>
If there was only a single mode, add the common modes to provide options
to select other resolutions than the built in default. This avoids
issues where the connector listed multiple supported modes, but where
the common modes added would exceed the possible bandwidth. We could
probably make an attempt to filter out more modes from the common mode
list to avoid these issues, but it's likely that the driver already
lists suitable modes, meaning there is no point in adding the common
modes.
The common modes were initially added[0] to add modes to connectors with
a single bundled mode, so we shouldn't regress the original bug fix.
[0] https://bugzilla.gnome.org/show_bug.cgi?id=744544
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1232
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1824>
