Resume happens after we may have received various events that we've
ignored, so at this point we need to just emit an hotplug event like if
everything changed so that user settings may be re-applied.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
On hotplug events we may get informations about what CRTC or connector
changed a property (and the property itself), so in such case let's just
ignore the changes to the non-affected CRTCs/connectors, and let's read
only the affected one
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
On hotplug events we may receive a "CRTC" or "CONNECTOR" property that
indicates which crtc/connector property ID has changed.
In such case, instead of update data for all the devices, only update the
device containing the relative connector.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
In case we have no devices, after a KMS update (both because they've
all have been removed or because there were none), we may need to behave
differently compared to the case in which nothing changed, so add a more
specific KMS update change type
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
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>
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>
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>
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>
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Suspending might have changed the CRTC configuration, turning some off,
some on, etc. We need to update our internal representation of this
state, so that we know how to reconfigure upon resuming, e.g. what CRTCs
to turn off again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
When we e.g. try to post an direct client buffer scanout update, it
might arbitrarily fail; when this happen we still will want to post the
rest of the update when we try again after having composited the primary
plane. To do this, add a way to preserve the metadata of an update if it
failed, only dropping the failed plane assignments. This involves
unlocking a previously locked MetaKmsUpdate, so that e.g. a new primary
plane can be assigned.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Sealing is a one way operation, but in the next commit, the "seal" will
be broken, so to avoid missusing the "seal" terminology, rename related
methods and variables to use the term "lock" instead. E.g.
meta_update_is_sealed() is now meta_update_is_locked().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Something might want to affect the next update that is going to be
posted, but without posting it immediately. For example, changing the
cursor might need to wait for mode setting. Make it possible to get
feedback from posting the update, in order to gracefully handle any
errors.
Note, the API for notifiying about results take out the result listener
from the update, and notifies them in an open coded for loop. The reason
for this is that in the next commit we'll sometimes reuse updates, and
we only want notify about the results once.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of a "post all pending updates", pass an update specific to a
single device. This gets rid of the awkward "combine feedback" function,
and makes it possible to queue updates to a multiple devices without
always posting them together.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
For now feedbacks from an update are combined, meaning we might lose
error information. The feedback API may have to be reconsidered and
redesigned when planes gets a more front seat position.
This means we need to avoid trying to post updates if we're in power
save mode, as it may be empty.
Note that this is an intermediate state during refactoring that aims to
introduce atomic mode setting support, and we'll stop combining
feedbacks completely in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This contains a copy of a drmModeModeInfo, describing a mode. It also
has an unused pointer to the impl device it is associated with. It'll
later be used to get a blob ID for the mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
When testing a laptop with intel and DisplayLink devices, attempting to set the
DL output as the only active output resulted in GNOME/Wayland freezing. The
main event loop was running fine, but nothing on screen would get updated once
the DL output become the only one. This patch fixes that issue.
DisplayLink USB 3 devices use an out-of-tree kernel DRM driver called EVDI.
EVDI can sometimes fail drmModePageFlip(). For me, the flip fails reliably when
hotplugging the DL dock and when changing display configuration to DL only.
Mutter has a workaround for failing flips, it just calls drmModeSetCrtc() and
that succeeds.
What does not work reliably in the fallback path is Mutter keeping track of the
pageflip. Since drmModePageFlip() failed, there will not be a pageflip event
coming and instead Mutter queues a callback in its stead. When you have more
than one output, some other output repainting will attempt to swap buffers and
calls wait_for_pending_flips() which has the side-effect of dispatching any
queued flip callbacks. With multiple outputs, you don't get stuck (unless they
all fail the exact same way at the same time?). When you have only one output,
it cannot proceed to repaint and buffer swap because the pageflip is not marked
complete yet. Nothing dispatches the flip callback, leading to the freeze.
The flip callback is intended to be an idle callback, implemented with a
GSource. It is supposed to be called as soon as execution returns to the main
event loop. The setup of the GSource is incomplete, so it will never dispatch.
Fix the GSource setup by setting its ready-time to be always in the past. That
gets it dispatched on the next cycle of the main event loop. This is now the
default behavior for all sources created by meta_kms_add_source_in_impl().
Sources that need a delay continue to do that by overriding the ready-time
explicitly.
An alternative solution could have been to implement GSource prepare and check
callbacks returning TRUE. However, since meta_kms_add_source_in_impl() is used
by flip retry code as well, and that code needs a delay through the ready-time,
I was afraid I might break the flip retry code. Hence I decided to use
ready-time instead.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1209
This is so that cogl-trace.h can start using things from cogl-macros.h,
and so that it doesn't leak cogl-config.h into the world, while exposing
it to e.g. gnome-shell so that it can make use of it as well. There is
no practical reason why we shouldn't just include cogl-trace.h via
cogl.h as we do with everything else.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1059
The current API as all synchronous, so they can be made to return
feedback immediately. This will be needed for the cursor renderer which
needs to know whether it should fall back to OpenGL cursor rendering.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
meta_kms_update_process_..() makes it sound like it's a MetaKmsUpdate
function called update_..() but in fact it's a MetaKms function that
calls the corresponding process-update impl function. Clear up this
naming confusion.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
This is inspired by 98892391d7 where the usage of
`g_signal_handler_disconnect()` without resetting the corresponding
handler id later resulted in a bug. Using `g_clear_signal_handler()`
makes sure we avoid similar bugs and is almost always the better
alternative. We use it for new code, let's clean up the old code to
also use it.
A further benefit is that it can get called even if the passed id is
0, allowing us to remove a lot of now unnessecary checks, and the fact
that `g_clear_signal_handler()` checks for the right type size, forcing us
to clean up all places where we used `guint` instead of `gulong`.
No functional changes intended here and all changes should be trivial,
thus bundled in one big commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
We can't just update the state of the connector and CRTC from KMS since
it might contain too new updates, e.g. from a from a future hot plug. In
order to not add ad-hoc hot plug detection everywhere, predict the state
changes by looking inside the MetaKmsUpdate object, and let the hot-plug
state changes happen after the actual hot-plug event.
This fixes issues where connectors were discovered as disconnected while
doing a mode-set, meaning assumptions about the connectedness of
monitors elsewhere were broken until the hot plug event was processed.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/782https://gitlab.gnome.org/GNOME/mutter/merge_requests/826
Add meta-kms and meta-monitor-manager-kms listener for the udev
device-removed signal and on this signal update the device state /
re-enumerate the monitors, so that the monitors properly get updated
to disconnected state on GPU removal.
We really should also have meta-backend-native remove the GPU itself
from our list of GPU objects. But that is more involved, see:
https://gitlab.gnome.org/GNOME/mutter/issues/710
This commit at least gets us to a point where we properly update the
list of monitors when a GPU gets unplugged; and where we no longer
crash the first time the user changes the monitor configuration after
a GPU was unplugged.
Specifically before this commit we would hit the first g_error () in
meta_renderer_native_create_view () as soon as some monitor
(re)configuration is done after a GPU was unplugged.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/713
This commit introduces, and makes use of, a transactional API used for
setting up KMS state, later to be applied, potentially atomically. From
an API point of view, so is always the case, but in the current
implementation, it still uses legacy drmMode* API to apply the state
non-atomically.
The API consists of various buliding blocks:
* MetaKmsUpdate - a set of configuration changes, the higher level
handle for handing over configuration to the impl backend. It's used to
set mode, assign framebuffers to planes, queue page flips and set
connector properties.
* MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane.
Currently used to map a framebuffer to the primary plane of a CRTC. In
the legacy KMS implementation, the plane assignment is used to derive
the framebuffer used for mode setting and page flipping.
This also means various high level changes:
State, excluding configuring the cursor plane and creating/destroying
DRM framebuffer handles, are applied in the end of a clutter frame, in
one go. From an API point of view, this is done atomically, but as
mentioned, only the non-atomic implementation exists so far.
From MetaRendererNative's point of view, a page flip now initially
always succeeds; the handling of EBUSY errors are done asynchronously in
the MetaKmsImpl backend (still by retrying at refresh rate, but
postponing flip callbacks instead of manipulating the frame clock).
Handling of falling back to mode setting instead of page flipping is
notified after the fact by a more precise page flip feedback API.
EGLStream based page flipping relies on the impl backend not being
atomic, as the page flipping is done in the EGLStream backend (e.g.
nvidia driver). It uses a 'custom' page flip queueing method, keeping
the EGLStream logic inside meta-renderer-native.c.
Page flip handling is moved to meta-kms-impl-device.c from
meta-gpu-kms.c. It goes via an extra idle callback before reaching
meta-renderer-native.c to make sure callbacks are invoked outside of the
impl context.
While dummy power save page flipping is kept in meta-renderer-native.c, the
EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the
frame clock, actual page flip callbacks are postponed until all EBUSY retries
have either succeeded or failed due to some other error than EBUSY. This
effectively inhibits new frames to be drawn, meaning we won't stall waiting on
the file descriptor for pending page flips.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
The MetaKmsImpl implementation may need to add a GSource that should be
invoked in the right context; e.g. a idle callback, timeout etc. It
cannot just add it itself, since it's the responsibility of MetaKms to
determine what is the impl context and what is the main context, so add
API to MetaKms to ensure the callback is invoked correctly.
It's the responsibility of the caller to eventually remove and destroy
the GSource.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
Move reading state into a struct for MetaCrtcKms to use instead of
querying KMS itself. The state is fetched in the impl context, but
consists of only simple data types, so is made accessible publicly. As
of this, MetaCrtcKms construction does not involve any manual KMS
interaction outside of the MetaKms abstraction.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
The intention with KMS abstraction is to hide away accessing the drm
functions behind an API that allows us to have different kind of KMS
implementations, including legacy non-atomic and atomic. The intention
is also that the code interacting with the drm device should be able to
be run in a different thread than the main thread. This means that we
need to make sure that all drm*() API usage must only occur from within
tasks that eventually can be run in the dedicated thread.
The idea here is that MetaKms provides a outward facing API other places
of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is
an internal implementation that only gets interacted with via "tasks"
posted via the MetaKms object. These tasks will in the future
potentially be run on the dedicated KMS thread. Initially, we don't
create any new threads.
Likewise, MetaKmsDevice is a outward facing representation of a KMS
device, while MetaKmsImplDevice is the corresponding implementation,
which only runs from within the MetaKmsImpl tasks.
This commit only moves opening and closing the device to this new API,
while leaking the fd outside of the impl enclosure, effectively making
the isolation for drm*() calls pointless. This, however, is necessary to
allow gradual porting of drm interaction, and eventually the file
descriptor in MetaGpuKms will be removed. For now, it's harmless, since
everything still run in the main thread.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
