As with CRTC state, variable connector state is now fetched via the
MetaKmsConnector. The existance of a connector state is equivalent of
the connector being connected. MetaOutputKms is changed to fetch
variable connector state via MetaKmsConnector intsead of KMS directly.
The drmModeConnector is still used for constructing the MetaOutputKms to
find properties used for applying configuration.
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
Represents drmModeConnector; both connected and disconnected. Currently
only provides non-changing meta data. MetaOutputKms is changed to use
MetaKmsConnector to get basic metadata, but variable metadata, those
changing depending on what is connected (e.g. physical dimension, EDID,
etc), are still manually retrieved by MetaOutputKms.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
A plane is one of three possible: primary, overlay and cursor. Each
plane can have various properties, such as possible rotations, formats
etc. Each plane can also be used with a set of CRTCs.
A primary plane is the "backdrop" of a CRTC, i.e. the primary output for
the composited frame that covers the whole CRTC. In general, mutter
composites to a stage view frame onto a framebuffer that is then put on
the primary plane.
An overlay plane is a rectangular area that can be displayed on top of
the primary plane. Eventually it will be used to place non-fullscreen
surfaces, potentially avoiding stage redraws.
A cursor plane is a plane placed on top of all the other planes, usually
used to put the mouse cursor sprite.
Initially, we only fetch the rotation properties, and we so far
blacklist all rotations except ones that ends up with the same
dimensions as with no rotations. This is because non-180° rotations
doesn't work yet due to incorrect buffer modifiers. To make it possible
to use non-180° rotations, changes necessary include among other things
finding compatible modifiers using atomic modesetting. Until then,
simply blacklist the ones we know doesn't work.
https://gitlab.gnome.org/GNOME/mutter/issues/548https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
Add MetaKmsCrtc to represent a CRTC on the associated device. Change
MetaCrtcKms to use the ones discovered by the KMS abstraction. It still
reads the resources handed over by MetaGpuKms, but eventually it will
use only MetaKmsCrtc.
MetaKmsCrtc is a type of object that is usable both from an impl task
and from outside. All the API exposed via the non-private header is
expected to be accessible from outside of the meta-kms namespace.
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
DPMS is configured from a bit all over the place: via D-Bus, via X11 and
when reading the current KMS state. Each of these places did it slightly
differently, directly poking at the field in MetaMonitorManager.
To make things a bit more managable, move the field into a new
MetaMonitorManagerPrivate, and add helpers to get and set the current
value. Prior to this, there were for example situations where the DPMS
setting was changed, but without signal listeners being notified about
it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
We might fail to page flip a new buffer, often after resuming, due to
the FIFO being full. Prior to this commit, we handled this by switching
over to plain mode setting instead of page flipping. This is bad because
we won't be synchronized to the refresh rate anymore, but just the
clock.
Instead, deal with this by trying again until the FIFO is no longer
full. Do this on a v-sync based interval, until it works.
This also changes the error handling code for drivers not supporting
page flipping to rely on them returning -EINVAL. The handling is moved
from pretending a page flip working to explicit mode setting in
meta-renderer-native.c.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/460
Add a flags field to MetaGpuKms. In following commits, the flags defined
here will be set and used for choosing the primary GPU.
Co-authored by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/271
DRM_EVENT_CONTEXT_VERSION is the latest context version supported by
whatever version of libdrm is present. Mutter was blindly asserting it
supported whatever version that may be, even if it actually didn't.
With libdrm 2.4.78, setting a higher context version than 2 will attempt
to call the page_flip_handler2 vfunc if it was non-NULL, which being a
random chunk of stack memory, it might well have been.
Set the version as 2, which should be bumped only with the appropriate
version checks.
https://bugzilla.gnome.org/show_bug.cgi?id=781034
Add support for getting hardware presentation times from KMS (Wayland
sessions). Also implement cogl_get_clock_time which is required to compare
and judge the age of presentation timestamps.
For single monitor systems this is straightforward. For multi-monitor
systems though we have to choose a display to sync to. The compositor
already partially solves this for us in the case of only one display
updating because it will only use the subset of monitors that are
changing. In the case of multiple monitors consuming the same frame
concurrently however, we choose the fastest one (in use at the time).
Note however that we also need !73 to land in order to fully realize
multiple monitors running at full speed.
drmModePageFlip() is guaranteed to fail for the invalid FB id 0.
Therefore it never makes sense to call this function with such argument.
Disabling a CRTC must be done with SetCrtc instead, for example.
Trying to flip to FB 0 not only fails, but it also causes Mutter to
never try page flip on this output again, using drmModeSetCrtc()
instead.
We need a way for mutter to exit if no available GPUs are going to work.
For example if gdm starts gnome-shell and we're using a DRM driver that
doesn't work with KMS then we should exit so that GDM can try with Xorg,
rather than operating in headless mode.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/223
If drmModeSetCrtc() is called with no fb, mode or connectors for some
CRTC it may still fail, and we should handle that gracefully instead of
assuming it failed to set a non-disabled state.
Closes https://gitlab.gnome.org/GNOME/mutter/issues/70
When using the EGLStream backend, the MetaRendererNative passed a
GClosure to KMS when using EGLStreams, but KMS flip callback event
handler in meta-gpu-kms.c expected a closure wrapped in a closure
container, meaning it'd instead crash when using EGLStreams. Make the
flip handler get what it expects also when using EGLStreams by wrapping
the flip closure in the container before handing it over to EGL.
https://bugzilla.gnome.org/show_bug.cgi?id=790316
There seems to be a kernel race when one disconnects an external
monitor connected to a DisplayPort via a USB-C adapter. The race
results in a connector being reported as connected, but without any
modes supported.
This had the side effect that we tried to set a preferred mode to
the first listed mode, but as no modes were available, we instead tried
to dereference the first element of a NULL array, causing a
segmentation fault.
Mitigate this by skipping adding output if no supported modes are
advertised and the output doesn't support scaling, while moving the
fallback path for calculating a preferred output mode to after possibly
adding the common modes, to avoid the unvolentary NULL dereference.
https://bugzilla.gnome.org/show_bug.cgi?id=789501
If a monitor's max resolution is a portrait resolution, then assume it is
a native portrait monitor and add portrait versions of the common modes.
https://bugzilla.gnome.org/show_bug.cgi?id=782294
The DRM properties container must be destroyed with
drmModeFreeObjectProperties, and the connectors must be freed on every
caller. Also make it sure that gbm_device structs are destroyed with the
MetaRendererNativeGpuData that owns them.
https://bugzilla.gnome.org/show_bug.cgi?id=789984
When drmHandleEvent() returns an error and errno is set to EAGAIN,
instead of ending up in a busy loop, poll() the fd until there is
anything to read.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
In order to eventually support multilpe GPUs with their own connectors,
split out related meta data management (i.e. outputs, CRTCs and CRTC
modes) into a new MetaGpu GObject.
The Xrandr backend always assumes there is always only a single "GPU" as
the GPU is abstracted by the X server; only the native backend (aside
from the test backend) will eventually see more than one GPU.
The Xrandr backend still moves some management to MetaGpuXrandr, in
order to behave more similarly to the KMS counterparts.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
