1
0
Fork 0
Commit graph

30 commits

Author SHA1 Message Date
Jonas Ådahl
fb38c451b5 kms: Add atomic MetaKmsImplDevice backend
This adds a MetaKmsImplDevice backend using atomic drmMode* API in constrast to
non-atomic legacy drmMode* API used in MetaKmsImplDeviceSimple.

This has various behavioral differences worth noting, compared to the
simple backend:

 * We can only commit once per CRTC per page flip.

This means that we can only update the cursor plane once. If a primary
plane composition missed a dead line, we cannot commit only a cursor
update that would be presented earlier.

 * Partial success is not possible with the atomic backend.

Cursor planes may fail with the simple backend. This is not the case
with the atomic backend. This will instead later be handled using API
specific to the atomic backend, that will effectively translate into
TEST_ONLY commits.

For testing and debugging purposes, the environment variable
MUTTER_DEBUG_ENABLE_ATOMIC_KMS can be set to either 1 or 0 to
force-enable or force-disable atomic mode setting. Setting it to some
other value will cause mutter to abort().

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/548
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 16:47:08 +00:00
Jonas Ådahl
d8279ba474 kms/device: Add plane getter
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 16:47:08 +00:00
Jonas Ådahl
b7441514fe kms: Add some basic debug logging
Enabled using MUTTER_DEBUG=kms or via
Meta.add_verbose_topic(Meta.DebugTopic.KMS) in looking glass.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 16:47:08 +00:00
Jonas Ådahl
7842517519 kms/impl-device: Keep a path string around
This is useful for e.g. logging.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 16:47:08 +00:00
Jonas Ådahl
deb8f07c65 kms/device: Get driver details before constructing impl device
Eventually the type of impl device will depend on the driver details, so
get that information before constructing the impl device. This commit
doesn't introduce any new usage of the details, it just prepares for
the future.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 16:47:08 +00:00
Jonas Ådahl
7137bd4b10 kms: Move impl backend inherit MetaKmsImplDevice instead of MetaKmsImpl
This allows different types of backends to coexist, would e.g. one
device support atomic but another not.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 16:47:08 +00:00
Jonas Ådahl
37fe30c515 kms/update: Make each MetaKmsUpdate update a single device
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>
2021-01-22 16:47:08 +00:00
Jonas Ådahl
a8d724d058 kms/impl: Manage a list of impl devices
Accessing the device list directly from MetaKms might not be safe if we
introduce threads, so keep a list completely within the impl context.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 16:47:08 +00:00
Jonas Ådahl
8808d518cc kms/impl-device: Construct using GInitable
Instead of a constructor method, use the type directly and handle error
reporting using GInitable.

The DRM capability setting is done before construction, as later it'll
determine what type of impl device should be constructed.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 16:47:08 +00:00
Jonas Ådahl
d3abaf46a1 output-kms: Hand over fallback mode management to MetaKms
Eventually we need MetaKmsMode for more than carrying the
drmModeModeInfo, so prepare for that by having the KMS layer create
MetaKmsMode for those as well.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 16:47:08 +00:00
Jonas Ådahl
d73a858dc2 kms/device: Provide driver name and description
Retrieved from drmGetVersion(), to be used to identify what driver a DRM
device is driven by.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1318
2020-08-29 10:32:20 +00:00
Daniel van Vugt
4c513e3e19 backends/native: Remove unused meta_gpu_kms_wait_for_flip and more
Remove unused function `meta_gpu_kms_wait_for_flip` and other code which
only existed to support `meta_gpu_kms_wait_for_flip`.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1388
2020-08-04 08:57:06 +00:00
Jonas Ådahl
227eea1e31 kms-impl-simple: Add fake cursor planes if no real ones
Non-atomic drivers may support drmModeSetCursor() even if no cursor
plane is advertised. To deal with this, add a fake cursor plane for
every CRTC when using MetaKmsImplSimple. This will eventually be
translated to drmModeSetCursor() calls without any explicit cursor plane
usage.

Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/1058

https://gitlab.gnome.org/GNOME/mutter/merge_requests/1079
2020-03-07 21:40:50 +00:00
Jonas Ådahl
f3cdc9906c kms/device: Handle tracking capabilities
Devices have capabilities that other parts need to know about. Instead
of having them probe using drmMode* API, outsource this to
MetaKmsDevice. Currently the only capability tracked is HW cursor size.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2020-02-11 18:32:07 +01:00
Jonas Ådahl
c1fc46e3db kms/device: Fix indentation mistake
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2020-02-11 18:32:07 +01:00
Jonas Ådahl
ec9d7145c8 kms: Return gpointer from impl tasks
Currently only used to return either TRUE or FALSE to communicate
success or failure. Will be used to return feedback objects.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2020-02-11 18:32:07 +01:00
Jonas Ådahl
3a8c545b32 kms/device: Add getter for finding cursor planes
Works the same as the getter for the primary planes.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2020-02-11 18:32:07 +01:00
Pekka Paalanen
79491df2b8 kms: Process impl idle callbacks before pre dispatch flush
mode_set_fallback() schedules a call to mode_set_fallback_feedback_idle(), but
it is possible for Mutter to repaint before the idle callbacks are dispatched.
If that happens, mode_set_fallback_feedback_idle() does not get called before
Mutter enters wait_for_pending_flips(), leading to a deadlock.

Add the needed interfaces so that meta_kms_device_dispatch_sync() can flush all
the implementation idle callbacks before it checks if any "events" are
available. This prevents the deadlock by ensuring
mode_set_fallback_feedback_idle() does get called before potentially waiting
for actual DRM events.

Presumably this call would not be needed if the implementation was running in
its own thread, since it would eventually dispatch its idle callbacks before
going to sleep polling on the DRM fd. This call might even be unnecessary
overhead in that case, synchronizing with the implementation thread needlessly.
But the thread does not exist yet, so this is needed for now.

This is part 1 of 2 fixing a complete desktop freeze when drmModePageFlip()
fails with EINVAL and the fallback to drmModeSetCrtc() succeeds but the success
is not registered correctly as completed "flip". The freeze occurs under
wait_for_pending_flips() which calls down into meta_kms_impl_device_dispatch()
which ends up poll()'ing the DRM fd even though drmModeSetCrtc() will not
produce a DRM event, hence the poll() never returns. The freeze was observed
when hotplugging a DisplayLink dock for the first time on Ubuntu 19.10.

CC stable: gnome-3-34

https://gitlab.gnome.org/GNOME/mutter/merge_requests/953
2019-12-06 15:55:35 +00:00
Jonas Ådahl
104bdde746 kms: Predict state changes when processing update
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/782

https://gitlab.gnome.org/GNOME/mutter/merge_requests/826
2019-10-07 14:59:18 +00:00
Michal Lazo
4d0869e206 kms-device: Free path when finalizing
free path in finalize

https://gitlab.gnome.org/GNOME/mutter/merge_requests/775
2019-09-16 16:41:46 +00:00
Michal Lazo
d13cea6ccb kms-device: Handle impl device creation failure
Properly free kms-device in case of invalid initialization

https://gitlab.gnome.org/GNOME/mutter/merge_requests/772
2019-09-16 16:34:39 +00:00
Jonas Ådahl
4cf828323d kms/impl-device: Add and remove connectors on hot plug
Connectors may disappear and appear on hot plugs, e.g. when a docking
station is connected, so when processing a hot plug event, make sure we
remove connectors that are now gone, and add new ones that have appeared
since last time.

Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/728

https://gitlab.gnome.org/GNOME/mutter/merge_requests/743
2019-09-05 08:03:36 +00:00
Jonas Ådahl
1c25b75571 kms-impl-device: Fail if we can't enable universal planes
We currently don't handle the lack of DRM_CLIENT_CAP_UNIVERSAL_PLANES
KMS capability. Fail constructing a device that can't handle this up
front, so later made assumptions, such as presence of a primary plane,
are actually valid.

If we want to support lack of said capability, the required planes need
to be emulated by a dummy MetaKmsPlane object.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/665
2019-07-01 11:55:47 +02:00
Jonas Ådahl
75dff3e7c9 backend/native: Add and use transactional KMS API
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/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-20 13:31:56 +00:00
Jonas Ådahl
d84c7269b2 crtc/kms: Use MetaKmsPlane to check supported rotations and formats
Instead of manually retrieving supported transforms and formats from the
primary plane of the CRTC, use the MetaKmsPlane abstraction to find the
primary plane of the CRTC and check compatibility using the
MetaKmsPlane API. This removes the last user of direct KMS API usage
except for applying configuration.

https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-20 13:31:56 +00:00
Jonas Ådahl
596376c408 crtc/kms: Outsource CRTC state fetching to MetaKmsCrtc
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/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-20 13:31:55 +00:00
Jonas Ådahl
f59d62bc8f kms: Add connector representation
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/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-20 13:31:55 +00:00
Jonas Ådahl
4d3e804391 kms: Add plane representation
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/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-20 13:31:55 +00:00
Jonas Ådahl
15a2ccd21b kms: Add CRTC representation
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/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-20 13:31:55 +00:00
Jonas Ådahl
fef5753a19 backends/native: Add basic KMS abstraction building blocks
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/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-20 13:31:55 +00:00