isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-30 20:01:00 -05:00
Code Issues Packages Projects Releases Wiki Activity
a8d11161b6
mutter/src/backends/native/meta-kms.h

75 lines
2.5 KiB
C
Raw Normal View History

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-01-29 04:24:44 -05:00
/*
* Copyright (C) 2018 Red Hat
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
* 02111-1307, USA.
*/
#ifndef META_KMS_H
#define META_KMS_H
#include <glib-object.h>
#include "backends/meta-backend-private.h"
#include "backends/native/meta-kms-types.h"
kms: Add way to run without mode setting 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>
2021-01-19 08:54:45 -05:00
typedef enum _MetaKmsFlags
{
META_KMS_FLAG_NONE = 0,
META_KMS_FLAG_NO_MODE_SETTING = 1 << 0,
} MetaKmsFlags;
kms: Add way to preserve failed update 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>
2020-10-02 10:48:34 -04:00
typedef enum _MetaKmsUpdateFlag
{
META_KMS_UPDATE_FLAG_NONE = 0,
META_KMS_UPDATE_FLAG_PRESERVE_ON_ERROR = 1 << 0,
} MetaKmsUpdateFlag;
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-01-29 04:24:44 -05:00
#define META_TYPE_KMS (meta_kms_get_type ())
G_DECLARE_FINAL_TYPE (MetaKms, meta_kms, META, KMS, GObject)
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>
2020-07-16 17:38:10 -04:00
MetaKmsUpdate * meta_kms_ensure_pending_update (MetaKms *kms,
MetaKmsDevice *device);
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-04-04 16:36:41 -04:00
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>
2020-07-16 17:38:10 -04:00
MetaKmsUpdate * meta_kms_get_pending_update (MetaKms *kms,
MetaKmsDevice *device);
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-04-04 16:36:41 -04:00
kms: Add way to preserve failed update 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>
2020-10-02 10:48:34 -04:00
MetaKmsFeedback * meta_kms_post_pending_update_sync (MetaKms *kms,
MetaKmsDevice *device,
MetaKmsUpdateFlag flags);
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-04-04 16:36:41 -04:00
void meta_kms_discard_pending_page_flips (MetaKms *kms);
native: Release output device files that are unused 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>
2021-04-12 10:25:53 -04:00
void meta_kms_notify_modes_set (MetaKms *kms);
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-01-29 04:24:44 -05:00
MetaBackend * meta_kms_get_backend (MetaKms *kms);
kms: Post pending updates per device 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>
2020-10-02 04:38:57 -04:00
GList * meta_kms_get_devices (MetaKms *kms);
kms: Update device state when resuming 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>
2020-12-15 16:42:55 -05:00
void meta_kms_resume (MetaKms *kms);
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-01-29 04:24:44 -05:00
MetaKmsDevice * meta_kms_create_device (MetaKms *kms,
const char *path,
MetaKmsDeviceFlag flags,
GError **error);
backend/native: Split up KMS shutdown in two phases 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>
2021-04-13 12:18:46 -04:00
void meta_kms_prepare_shutdown (MetaKms *kms);
kms: Add way to run without mode setting 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>
2021-01-19 08:54:45 -05:00
MetaKms * meta_kms_new (MetaBackend *backend,
MetaKmsFlags flags,
GError **error);
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-01-29 04:24:44 -05:00
#endif /* META_KMS_H */
Reference in New Issue Copy Permalink