Since we cache already all the KMS parameters we care about let's check at
each device update if anything has really changed and only in such case
emit a resources-changed signal.
In this way we can also filter out the DRM parameters that when changed
don't require a full monitors rebuild.
Examples are the gamma settings or the privacy screen parameters, that
emits an udev "hotplug" event when changed, but we want to register those
only when we handle the changed property.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
This commit adds support to atomic KMS backend for optional plane property
prop_fb_damage_clips. Some drivers (e.g. EVDI) take advantage of this
property and process only updated regions of the screen instead of
processing the full frame. This can save system resources.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1879>
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>
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>
