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
33529426a9
mutter/src/backends/native/meta-kms-impl-device-simple.c

1689 lines
56 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
/*
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>
2020-07-17 03:38:11 -04:00
* Copyright (C) 2019-2020 Red Hat
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
*
* 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.
*/
#include "config.h"
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>
2020-07-17 03:38:11 -04:00
#include "backends/native/meta-kms-impl-device-simple.h"
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: Have the device impl open device files themself 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>
2021-04-06 06:14:24 -04:00
#include "backends/native/meta-backend-native-private.h"
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
#include "backends/native/meta-drm-buffer-gbm.h"
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
#include "backends/native/meta-kms-connector-private.h"
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>
2020-07-17 03:38:11 -04:00
#include "backends/native/meta-kms-crtc-private.h"
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
#include "backends/native/meta-kms-device-private.h"
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>
2020-07-17 03:38:11 -04:00
#include "backends/native/meta-kms-mode-private.h"
kms/update: Make plane assignment take rotation instead of property list Instead of having MetaKmsPlaneAssignment carry a low level property list, set the actual state change, and then have the implementation translate that into the necessary property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 09:10:50 -04:00
#include "backends/native/meta-kms-plane-private.h"
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
#include "backends/native/meta-kms-private.h"
#include "backends/native/meta-kms-update-private.h"
#include "backends/native/meta-kms-utils.h"
kms/impl-device/simple: Make process update vfunc type a typedef It made the function type declaration a bit unreadable, so split it out. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-19 13:26:14 -05:00
typedef gboolean (* MetaKmsSimpleProcessFunc) (MetaKmsImplDevice *impl_device,
MetaKmsUpdate *update,
gpointer entry_data,
GError **error);
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
typedef struct _CachedModeSet
{
GList *connectors;
drmModeModeInfo *drm_mode;
} CachedModeSet;
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
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>
2020-07-17 03:38:11 -04:00
struct _MetaKmsImplDeviceSimple
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
{
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>
2020-07-17 03:38:11 -04:00
MetaKmsImplDevice parent;
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
GSource *mode_set_fallback_feedback_source;
GList *mode_set_fallback_page_flip_datas;
GList *pending_page_flip_retries;
GSource *retry_page_flips_source;
GList *postponed_page_flip_datas;
GList *postponed_mode_set_fallback_datas;
kms/impl-simple: Clean up pending page flip datas on finalize They might be holding on to references, so lets keep track of them and clean up on finalize. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-10 19:36:42 -04:00
GList *posted_page_flip_datas;
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
GHashTable *cached_mode_sets;
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
};
kms: Have the device impl open device files themself 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>
2021-04-06 06:14:24 -04:00
static GInitableIface *initable_parent_iface;
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
static void
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>
2020-07-17 03:38:11 -04:00
initable_iface_init (GInitableIface *iface);
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: 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>
2020-07-17 03:38:11 -04:00
G_DEFINE_TYPE_WITH_CODE (MetaKmsImplDeviceSimple, meta_kms_impl_device_simple,
META_TYPE_KMS_IMPL_DEVICE,
G_IMPLEMENT_INTERFACE (G_TYPE_INITABLE,
initable_iface_init))
static void
flush_postponed_page_flip_datas (MetaKmsImplDeviceSimple *impl_device_simple);
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
kms/update: Make power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
static gboolean
get_connector_property (MetaKmsImplDevice *impl_device,
MetaKmsConnector *connector,
MetaKmsConnectorProp prop,
uint64_t *value,
GError **error)
{
uint32_t prop_id;
int fd;
drmModeConnector *drm_connector;
int i;
gboolean found;
prop_id = meta_kms_connector_get_prop_id (connector, prop);
if (!prop_id)
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_NOT_SUPPORTED,
"Property (%s) not found on connector %u",
meta_kms_connector_get_prop_name (connector, prop),
meta_kms_connector_get_id (connector));
return FALSE;
}
fd = meta_kms_impl_device_get_fd (impl_device);
drm_connector = drmModeGetConnector (fd,
meta_kms_connector_get_id (connector));
if (!drm_connector)
{
g_set_error (error, G_IO_ERROR, g_io_error_from_errno (errno),
"Failed to get connector %u resources: %s",
meta_kms_connector_get_id (connector),
g_strerror (errno));
return FALSE;
}
found = FALSE;
for (i = 0; i < drm_connector->count_props; i++)
{
if (drm_connector->props[i] == prop_id)
{
*value = drm_connector->prop_values[i];
found = TRUE;
break;
}
}
drmModeFreeConnector (drm_connector);
if (!found)
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_NOT_FOUND,
"Connector property %u not found", prop_id);
return FALSE;
}
return TRUE;
}
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
static gboolean
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>
2020-07-17 03:38:11 -04:00
set_connector_property (MetaKmsImplDevice *impl_device,
MetaKmsConnector *connector,
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
MetaKmsConnectorProp prop,
uint64_t value,
GError **error)
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/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
uint32_t prop_id;
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
int fd;
int ret;
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
prop_id = meta_kms_connector_get_prop_id (connector, prop);
if (!prop_id)
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_NOT_SUPPORTED,
"Property (%s) not found on connector %u",
meta_kms_connector_get_prop_name (connector, prop),
meta_kms_connector_get_id (connector));
return FALSE;
}
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
fd = meta_kms_impl_device_get_fd (impl_device);
ret = drmModeObjectSetProperty (fd,
meta_kms_connector_get_id (connector),
DRM_MODE_OBJECT_CONNECTOR,
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
prop_id,
value);
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
if (ret != 0)
{
g_set_error (error, G_IO_ERROR, g_io_error_from_errno (-ret),
"Failed to set connector %u property %u: %s",
meta_kms_connector_get_id (connector),
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
prop_id,
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
g_strerror (-ret));
return FALSE;
}
return TRUE;
}
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
static gboolean
kms/update: Make power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
process_power_save (MetaKmsImplDevice *impl_device,
GError **error)
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
{
kms/update: Make power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
GList *l;
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
kms/update: Make power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
for (l = meta_kms_impl_device_peek_connectors (impl_device); l; l = l->next)
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
{
kms/update: Make power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
MetaKmsConnector *connector = l->data;
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
kms/update: Make power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
"[simple] Setting DPMS of connector %u (%s) to OFF",
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>
2020-10-02 12:37:18 -04:00
meta_kms_connector_get_id (connector),
kms/update: Make power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
meta_kms_impl_device_get_path (impl_device));
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>
2020-10-02 12:37:18 -04:00
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>
2020-07-17 03:38:11 -04:00
if (!set_connector_property (impl_device,
connector,
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
META_KMS_CONNECTOR_PROP_DPMS,
kms/update: Make power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
DRM_MODE_DPMS_OFF,
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
error))
return FALSE;
}
kms/update: Make power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
return TRUE;
}
static gboolean
process_connector_update (MetaKmsImplDevice *impl_device,
MetaKmsUpdate *update,
gpointer update_entry,
GError **error)
{
MetaKmsConnectorUpdate *connector_update = update_entry;
MetaKmsConnector *connector = connector_update->connector;
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
if (connector_update->underscanning.has_update &&
connector_update->underscanning.is_active)
{
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Setting underscanning on connector %u (%s) to "
"%" G_GUINT64_FORMAT "x%" G_GUINT64_FORMAT,
meta_kms_connector_get_id (connector),
meta_kms_impl_device_get_path (impl_device),
connector_update->underscanning.hborder,
connector_update->underscanning.vborder);
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>
2020-07-17 03:38:11 -04:00
if (!set_connector_property (impl_device,
connector,
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
META_KMS_CONNECTOR_PROP_UNDERSCAN,
1,
error))
return FALSE;
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>
2020-07-17 03:38:11 -04:00
if (!set_connector_property (impl_device,
connector,
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
META_KMS_CONNECTOR_PROP_UNDERSCAN_HBORDER,
connector_update->underscanning.hborder,
error))
return FALSE;
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>
2020-07-17 03:38:11 -04:00
if (!set_connector_property (impl_device,
connector,
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
META_KMS_CONNECTOR_PROP_UNDERSCAN_VBORDER,
connector_update->underscanning.vborder,
error))
return FALSE;
}
else if (connector_update->underscanning.has_update)
{
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Unsetting underscanning on connector %u (%s)",
meta_kms_connector_get_id (connector),
meta_kms_impl_device_get_path (impl_device));
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>
2020-07-17 03:38:11 -04:00
if (!set_connector_property (impl_device,
connector,
kms/connector: Set DPMS and underscanning directly on the update Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector property changes, make the update itself aware of the changes, making the impl side translate that to property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 10:48:47 -04:00
META_KMS_CONNECTOR_PROP_UNDERSCAN,
0,
error))
return FALSE;
}
return TRUE;
}
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
static CachedModeSet *
cached_mode_set_new (GList *connectors,
const drmModeModeInfo *drm_mode)
{
CachedModeSet *cached_mode_set;
cached_mode_set = g_new0 (CachedModeSet, 1);
*cached_mode_set = (CachedModeSet) {
.connectors = g_list_copy (connectors),
Change all g_memdup() to g_memdup2() Using g_memdup() is dangerous due to the type of the size argument. See https://gitlab.gnome.org/GNOME/glib/-/issues/2319 and https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1926 for details. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1708>
2021-02-04 12:45:59 -05:00
.drm_mode = g_memdup2 (drm_mode, sizeof *drm_mode),
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
};
return cached_mode_set;
}
static void
cached_mode_set_free (CachedModeSet *cached_mode_set)
{
g_list_free (cached_mode_set->connectors);
g_free (cached_mode_set->drm_mode);
g_free (cached_mode_set);
}
static void
fill_connector_ids_array (GList *connectors,
uint32_t **out_connectors,
int *out_n_connectors)
{
GList *l;
int i;
*out_n_connectors = g_list_length (connectors);
*out_connectors = g_new0 (uint32_t, *out_n_connectors);
i = 0;
for (l = connectors; l; l = l->next)
{
MetaKmsConnector *connector = l->data;
(*out_connectors)[i++] = meta_kms_connector_get_id (connector);
}
}
kms/update: Make plane assignment take rotation instead of property list Instead of having MetaKmsPlaneAssignment carry a low level property list, set the actual state change, and then have the implementation translate that into the necessary property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 09:10:50 -04:00
static gboolean
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>
2020-07-17 03:38:11 -04:00
set_plane_rotation (MetaKmsImplDevice *impl_device,
MetaKmsPlane *plane,
uint64_t rotation,
GError **error)
kms/update: Make plane assignment take rotation instead of property list Instead of having MetaKmsPlaneAssignment carry a low level property list, set the actual state change, and then have the implementation translate that into the necessary property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 09:10:50 -04:00
{
int fd;
uint32_t rotation_prop_id;
int ret;
fd = meta_kms_impl_device_get_fd (impl_device);
rotation_prop_id = meta_kms_plane_get_prop_id (plane,
META_KMS_PLANE_PROP_ROTATION);
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Setting plane %u (%s) rotation to %" G_GUINT64_FORMAT,
meta_kms_plane_get_id (plane),
meta_kms_impl_device_get_path (impl_device),
rotation);
kms/update: Make plane assignment take rotation instead of property list Instead of having MetaKmsPlaneAssignment carry a low level property list, set the actual state change, and then have the implementation translate that into the necessary property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 09:10:50 -04:00
ret = drmModeObjectSetProperty (fd,
meta_kms_plane_get_id (plane),
DRM_MODE_OBJECT_PLANE,
rotation_prop_id,
rotation);
if (ret != 0)
{
g_set_error (error, G_IO_ERROR, g_io_error_from_errno (-ret),
"Failed to rotation property (%u) to %" G_GUINT64_FORMAT
" on plane %u: %s",
rotation_prop_id,
rotation,
meta_kms_plane_get_id (plane),
g_strerror (-ret));
return FALSE;
}
return TRUE;
}
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
static gboolean
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>
2020-07-17 03:38:11 -04:00
process_mode_set (MetaKmsImplDevice *impl_device,
MetaKmsUpdate *update,
gpointer update_entry,
GError **error)
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: 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>
2020-07-17 03:38:11 -04:00
MetaKmsImplDeviceSimple *impl_device_simple =
META_KMS_IMPL_DEVICE_SIMPLE (impl_device);
kms-impl-simple: Add helper to process update entries This avoids some loop iteration boiler plate. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 05:30:18 -05:00
MetaKmsModeSet *mode_set = update_entry;
kms-impl/simple: Removing extra semi colon https://gitlab.gnome.org/GNOME/mutter/merge_requests/634
2019-06-24 04:35:47 -04:00
MetaKmsCrtc *crtc = mode_set->crtc;
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
g_autofree uint32_t *connectors = NULL;
int n_connectors;
MetaKmsPlaneAssignment *plane_assignment;
kms/update: Make change updates to take MetaKmsMode This will be needed for state keeping connected to turning mode infos into blobs later used by the atomic modesetting implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-02 09:58:59 -04:00
drmModeModeInfo *drm_mode;
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
uint32_t x, y;
uint32_t fb_id;
int fd;
int ret;
crtc = mode_set->crtc;
kms/update: Make change updates to take MetaKmsMode This will be needed for state keeping connected to turning mode infos into blobs later used by the atomic modesetting implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-02 09:58:59 -04:00
if (mode_set->mode)
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: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
MetaDrmBuffer *buffer;
kms/update: Make power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
GList *l;
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
kms/update: Make change updates to take MetaKmsMode This will be needed for state keeping connected to turning mode infos into blobs later used by the atomic modesetting implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-02 09:58:59 -04:00
drm_mode = g_alloca (sizeof *drm_mode);
*drm_mode = *meta_kms_mode_get_drm_mode (mode_set->mode);
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
fill_connector_ids_array (mode_set->connectors,
&connectors,
&n_connectors);
kms/update: Add helper to get primary plane assignment Replaces a private static function, with no functional changes made to it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/826
2019-10-04 05:48:46 -04:00
plane_assignment = meta_kms_update_get_primary_plane_assignment (update,
crtc);
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
if (!plane_assignment)
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
"Missing primary plane assignment for legacy mode set on CRTC %u",
meta_kms_crtc_get_id (crtc));
return FALSE;
}
x = meta_fixed_16_to_int (plane_assignment->src_rect.x);
y = meta_fixed_16_to_int (plane_assignment->src_rect.y);
kms/update: Make plane assignment take rotation instead of property list Instead of having MetaKmsPlaneAssignment carry a low level property list, set the actual state change, and then have the implementation translate that into the necessary property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 09:10:50 -04:00
if (plane_assignment->rotation)
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: 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>
2020-07-17 03:38:11 -04:00
if (!set_plane_rotation (impl_device,
kms/update: Make plane assignment take rotation instead of property list Instead of having MetaKmsPlaneAssignment carry a low level property list, set the actual state change, and then have the implementation translate that into the necessary property changes. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-14 09:10:50 -04:00
plane_assignment->plane,
plane_assignment->rotation,
error))
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
return FALSE;
}
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
buffer = plane_assignment->buffer;
drm-buffer: Don't always generate fb_id on construction It might not be needed by the user of the buffer, so don't always require it up front. Instead make sure that any user that needs it first calls "meta_drm_buffer_ensure_fb_id()" to create the ID. Only the plain gbm implementation creates the ID lazilly, the other still does it on construction due to the objects used to create them only existing during construction. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
2021-05-05 08:35:48 -04:00
if (!meta_drm_buffer_ensure_fb_id (buffer, error))
return FALSE;
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
fb_id = meta_drm_buffer_get_fb_id (buffer);
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>
2020-10-02 12:37:18 -04:00
kms/update: Make power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
for (l = mode_set->connectors; l; l = l->next)
{
MetaKmsConnector *connector = l->data;
uint64_t dpms_value;
if (!get_connector_property (impl_device,
connector,
META_KMS_CONNECTOR_PROP_DPMS,
&dpms_value,
error))
return FALSE;
if (dpms_value != DRM_MODE_DPMS_ON)
{
meta_topic (META_DEBUG_KMS,
"[simple] Setting DPMS of connector %u (%s) to ON",
meta_kms_connector_get_id (connector),
meta_kms_impl_device_get_path (impl_device));
if (!set_connector_property (impl_device,
connector,
META_KMS_CONNECTOR_PROP_DPMS,
DRM_MODE_DPMS_ON,
error))
return FALSE;
}
}
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Setting mode of CRTC %u (%s) to %s",
meta_kms_crtc_get_id (crtc),
meta_kms_impl_device_get_path (impl_device),
drm_mode->name);
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
}
else
{
kms/update: Make change updates to take MetaKmsMode This will be needed for state keeping connected to turning mode infos into blobs later used by the atomic modesetting implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-02 09:58:59 -04:00
drm_mode = NULL;
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
x = y = 0;
n_connectors = 0;
connectors = NULL;
fb_id = 0;
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Unsetting mode of CRTC %u (%s)",
meta_kms_crtc_get_id (crtc),
meta_kms_impl_device_get_path (impl_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
}
fd = meta_kms_impl_device_get_fd (impl_device);
ret = drmModeSetCrtc (fd,
meta_kms_crtc_get_id (crtc),
fb_id,
x, y,
connectors, n_connectors,
kms/update: Make change updates to take MetaKmsMode This will be needed for state keeping connected to turning mode infos into blobs later used by the atomic modesetting implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-02 09:58:59 -04:00
drm_mode);
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
if (ret != 0)
{
g_set_error (error, G_IO_ERROR, g_io_error_from_errno (-ret),
kms-impl-simple: Include mode name in error message https://gitlab.gnome.org/GNOME/mutter/merge_requests/1007
2020-01-14 05:23:04 -05:00
"Failed to set mode %s on CRTC %u: %s",
kms/update: Make change updates to take MetaKmsMode This will be needed for state keeping connected to turning mode infos into blobs later used by the atomic modesetting implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-02 09:58:59 -04:00
drm_mode ? drm_mode->name : "off",
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
meta_kms_crtc_get_id (crtc),
g_strerror (-ret));
return FALSE;
}
kms/update: Make change updates to take MetaKmsMode This will be needed for state keeping connected to turning mode infos into blobs later used by the atomic modesetting implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-02 09:58:59 -04:00
if (drm_mode)
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: 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>
2020-07-17 03:38:11 -04:00
g_hash_table_replace (impl_device_simple->cached_mode_sets,
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
crtc,
cached_mode_set_new (mode_set->connectors,
kms/update: Make change updates to take MetaKmsMode This will be needed for state keeping connected to turning mode infos into blobs later used by the atomic modesetting implementation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-02 09:58:59 -04:00
drm_mode));
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
}
else
{
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>
2020-07-17 03:38:11 -04:00
g_hash_table_remove (impl_device_simple->cached_mode_sets, crtc);
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
}
return TRUE;
}
monitor-manager/kms: Use KMS abstraction to get and set CRTC gamma Still doesn't synchronize with frame drawing, but no point in doing that until gamma is managed by mutter itself and not gnome-settings-daemon. https://gitlab.gnome.org/GNOME/mutter/merge_requests/634
2019-05-03 13:20:21 -04:00
static gboolean
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>
2020-07-17 03:38:11 -04:00
process_crtc_gamma (MetaKmsImplDevice *impl_device,
MetaKmsUpdate *update,
gpointer update_entry,
GError **error)
monitor-manager/kms: Use KMS abstraction to get and set CRTC gamma Still doesn't synchronize with frame drawing, but no point in doing that until gamma is managed by mutter itself and not gnome-settings-daemon. https://gitlab.gnome.org/GNOME/mutter/merge_requests/634
2019-05-03 13:20:21 -04:00
{
kms-impl-simple: Add helper to process update entries This avoids some loop iteration boiler plate. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 05:30:18 -05:00
MetaKmsCrtcGamma *gamma = update_entry;
monitor-manager/kms: Use KMS abstraction to get and set CRTC gamma Still doesn't synchronize with frame drawing, but no point in doing that until gamma is managed by mutter itself and not gnome-settings-daemon. https://gitlab.gnome.org/GNOME/mutter/merge_requests/634
2019-05-03 13:20:21 -04:00
MetaKmsCrtc *crtc = gamma->crtc;
int fd;
int ret;
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Setting CRTC %u (%s) gamma, size: %d",
meta_kms_crtc_get_id (crtc),
meta_kms_impl_device_get_path (impl_device),
gamma->size);
monitor-manager/kms: Use KMS abstraction to get and set CRTC gamma Still doesn't synchronize with frame drawing, but no point in doing that until gamma is managed by mutter itself and not gnome-settings-daemon. https://gitlab.gnome.org/GNOME/mutter/merge_requests/634
2019-05-03 13:20:21 -04:00
fd = meta_kms_impl_device_get_fd (impl_device);
ret = drmModeCrtcSetGamma (fd, meta_kms_crtc_get_id (crtc),
gamma->size,
gamma->red,
gamma->green,
gamma->blue);
if (ret != 0)
{
g_set_error (error, G_IO_ERROR, g_io_error_from_errno (-ret),
"drmModeCrtcSetGamma on CRTC %u failed: %s",
meta_kms_crtc_get_id (crtc),
g_strerror (-ret));
return FALSE;
}
return TRUE;
}
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
static gboolean
is_timestamp_earlier_than (uint64_t ts1,
uint64_t ts2)
{
if (ts1 == ts2)
return FALSE;
else
return ts2 - ts1 < UINT64_MAX / 2;
}
typedef struct _RetryPageFlipData
{
MetaKmsCrtc *crtc;
uint32_t fb_id;
MetaKmsPageFlipData *page_flip_data;
float refresh_rate;
uint64_t retry_time_us;
kms/update: Encapsulate custom page flip fields in object Makes more sense to pass around an encapsulated object with the relevant data, than passing around a vfunc and a gpointer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 05:31:18 -05:00
MetaKmsCustomPageFlip *custom_page_flip;
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
} RetryPageFlipData;
static void
retry_page_flip_data_free (RetryPageFlipData *retry_page_flip_data)
{
g_assert (!retry_page_flip_data->page_flip_data);
kms/update: Encapsulate custom page flip fields in object Makes more sense to pass around an encapsulated object with the relevant data, than passing around a vfunc and a gpointer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 05:31:18 -05:00
g_clear_pointer (&retry_page_flip_data->custom_page_flip,
meta_kms_custom_page_flip_free);
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
g_free (retry_page_flip_data);
}
kms-impl-simple: Handle mode set race conditions gracefully If we end up trying to do a mode set on a DRM state that has already changed behind our back without us yet having seen the hotplug event we may fail with `EINVAL`. Since the renderer layer doesn't handle mode set failure, it'll still try to page flip later on, which will then also fail. When failing, it'll try to look up the cached mode set in order to retry the mode set later on, as is needed to handle other error conditions. However, if the mode set prior to the page flip failed, we won't cache the mode set, and the page flip error handling code will get confused. Instead of asserting that a page flip always has a valid cached mode set ready to look up, handle it being missing more gracefully by failing to mode set. It is expected that things will correct themself as there should be a hotplug event waiting around the the corner, to reconfigure the monitor configuration setting new modes. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/917 https://gitlab.gnome.org/GNOME/mutter/merge_requests/1007
2020-01-14 05:16:09 -05:00
static CachedModeSet *
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>
2020-07-17 03:38:11 -04:00
get_cached_mode_set (MetaKmsImplDeviceSimple *impl_device_simple,
MetaKmsCrtc *crtc)
kms-impl-simple: Handle mode set race conditions gracefully If we end up trying to do a mode set on a DRM state that has already changed behind our back without us yet having seen the hotplug event we may fail with `EINVAL`. Since the renderer layer doesn't handle mode set failure, it'll still try to page flip later on, which will then also fail. When failing, it'll try to look up the cached mode set in order to retry the mode set later on, as is needed to handle other error conditions. However, if the mode set prior to the page flip failed, we won't cache the mode set, and the page flip error handling code will get confused. Instead of asserting that a page flip always has a valid cached mode set ready to look up, handle it being missing more gracefully by failing to mode set. It is expected that things will correct themself as there should be a hotplug event waiting around the the corner, to reconfigure the monitor configuration setting new modes. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/917 https://gitlab.gnome.org/GNOME/mutter/merge_requests/1007
2020-01-14 05:16:09 -05:00
{
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>
2020-07-17 03:38:11 -04:00
return g_hash_table_lookup (impl_device_simple->cached_mode_sets, crtc);
kms-impl-simple: Handle mode set race conditions gracefully If we end up trying to do a mode set on a DRM state that has already changed behind our back without us yet having seen the hotplug event we may fail with `EINVAL`. Since the renderer layer doesn't handle mode set failure, it'll still try to page flip later on, which will then also fail. When failing, it'll try to look up the cached mode set in order to retry the mode set later on, as is needed to handle other error conditions. However, if the mode set prior to the page flip failed, we won't cache the mode set, and the page flip error handling code will get confused. Instead of asserting that a page flip always has a valid cached mode set ready to look up, handle it being missing more gracefully by failing to mode set. It is expected that things will correct themself as there should be a hotplug event waiting around the the corner, to reconfigure the monitor configuration setting new modes. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/917 https://gitlab.gnome.org/GNOME/mutter/merge_requests/1007
2020-01-14 05:16:09 -05:00
}
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
static float
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>
2020-07-17 03:38:11 -04:00
get_cached_crtc_refresh_rate (MetaKmsImplDeviceSimple *impl_device_simple,
MetaKmsCrtc *crtc)
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
{
CachedModeSet *cached_mode_set;
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>
2020-07-17 03:38:11 -04:00
cached_mode_set = g_hash_table_lookup (impl_device_simple->cached_mode_sets,
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
crtc);
g_assert (cached_mode_set);
return meta_calculate_drm_mode_refresh_rate (cached_mode_set->drm_mode);
}
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>
2020-07-17 03:38:11 -04:00
#define meta_assert_in_kms_impl(kms) \
g_assert (meta_kms_in_impl_task (kms))
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
static gboolean
retry_page_flips (gpointer user_data)
{
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>
2020-07-17 03:38:11 -04:00
MetaKmsImplDeviceSimple *impl_device_simple =
META_KMS_IMPL_DEVICE_SIMPLE (user_data);
MetaKmsImplDevice *impl_device = META_KMS_IMPL_DEVICE (impl_device_simple);
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
uint64_t now_us;
GList *l;
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>
2020-07-17 03:38:11 -04:00
now_us = g_source_get_time (impl_device_simple->retry_page_flips_source);
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: 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>
2020-07-17 03:38:11 -04:00
l = impl_device_simple->pending_page_flip_retries;
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
while (l)
{
RetryPageFlipData *retry_page_flip_data = l->data;
MetaKmsCrtc *crtc = retry_page_flip_data->crtc;
GList *l_next = l->next;
int fd;
int ret;
MetaKmsPageFlipData *page_flip_data;
kms/update: Encapsulate custom page flip fields in object Makes more sense to pass around an encapsulated object with the relevant data, than passing around a vfunc and a gpointer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 05:31:18 -05:00
MetaKmsCustomPageFlip *custom_page_flip;
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
if (is_timestamp_earlier_than (now_us,
retry_page_flip_data->retry_time_us))
{
l = l_next;
continue;
}
kms/update: Encapsulate custom page flip fields in object Makes more sense to pass around an encapsulated object with the relevant data, than passing around a vfunc and a gpointer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 05:31:18 -05:00
custom_page_flip = retry_page_flip_data->custom_page_flip;
if (custom_page_flip)
kms: Use custom page flip function when retrying failed flips When using its EGLStream-based presentation path with the proprietary NVIDIA driver, mutter will use a different function to process page flips - custom_egl_stream_page_flip. If that fails due to an EBUSY error, it will attempt to retry the flip. However, when retrying, it unconditionally uses the libdrm-based path. In practice, this causes a segfault when attempting to access plane_assignments->fb_id, since plane_assignments will be NULL in the EGLStream case. The issue can be reproduced reliably by VT-switching away from GNOME and back again while an EGL application is running. This patch has mutter also use the custom page flip function when retrying the failed flip. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1375
2020-07-17 16:38:55 -04:00
{
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Retrying custom page flip on CRTC %u (%s)",
meta_kms_crtc_get_id (crtc),
meta_kms_impl_device_get_path (impl_device));
kms/update: Encapsulate custom page flip fields in object Makes more sense to pass around an encapsulated object with the relevant data, than passing around a vfunc and a gpointer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 05:31:18 -05:00
ret = custom_page_flip->func (custom_page_flip->user_data,
retry_page_flip_data->page_flip_data);
kms: Use custom page flip function when retrying failed flips When using its EGLStream-based presentation path with the proprietary NVIDIA driver, mutter will use a different function to process page flips - custom_egl_stream_page_flip. If that fails due to an EBUSY error, it will attempt to retry the flip. However, when retrying, it unconditionally uses the libdrm-based path. In practice, this causes a segfault when attempting to access plane_assignments->fb_id, since plane_assignments will be NULL in the EGLStream case. The issue can be reproduced reliably by VT-switching away from GNOME and back again while an EGL application is running. This patch has mutter also use the custom page flip function when retrying the failed flip. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1375
2020-07-17 16:38:55 -04:00
}
else
{
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Retrying page flip on CRTC %u (%s) with %u",
meta_kms_crtc_get_id (crtc),
meta_kms_impl_device_get_path (impl_device),
retry_page_flip_data->fb_id);
kms: Use custom page flip function when retrying failed flips When using its EGLStream-based presentation path with the proprietary NVIDIA driver, mutter will use a different function to process page flips - custom_egl_stream_page_flip. If that fails due to an EBUSY error, it will attempt to retry the flip. However, when retrying, it unconditionally uses the libdrm-based path. In practice, this causes a segfault when attempting to access plane_assignments->fb_id, since plane_assignments will be NULL in the EGLStream case. The issue can be reproduced reliably by VT-switching away from GNOME and back again while an EGL application is running. This patch has mutter also use the custom page flip function when retrying the failed flip. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1375
2020-07-17 16:38:55 -04:00
fd = meta_kms_impl_device_get_fd (impl_device);
ret = drmModePageFlip (fd,
meta_kms_crtc_get_id (crtc),
retry_page_flip_data->fb_id,
DRM_MODE_PAGE_FLIP_EVENT,
retry_page_flip_data->page_flip_data);
}
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
if (ret == -EBUSY)
{
float refresh_rate;
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Rescheduling page flip retry on CRTC %u (%s)",
meta_kms_crtc_get_id (crtc),
meta_kms_impl_device_get_path (impl_device));
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>
2020-07-17 03:38:11 -04:00
refresh_rate =
get_cached_crtc_refresh_rate (impl_device_simple, crtc);
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
retry_page_flip_data->retry_time_us +=
(uint64_t) (G_USEC_PER_SEC / refresh_rate);
l = l_next;
continue;
}
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>
2020-07-17 03:38:11 -04:00
impl_device_simple->pending_page_flip_retries =
g_list_remove_link (impl_device_simple->pending_page_flip_retries, l);
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
page_flip_data = g_steal_pointer (&retry_page_flip_data->page_flip_data);
if (ret != 0)
{
g_autoptr (GError) error = NULL;
g_set_error (&error, G_IO_ERROR, g_io_error_from_errno (-ret),
"drmModePageFlip on CRTC %u failed: %s",
meta_kms_crtc_get_id (crtc),
g_strerror (-ret));
if (!g_error_matches (error,
G_IO_ERROR,
G_IO_ERROR_PERMISSION_DENIED))
g_critical ("Failed to page flip: %s", error->message);
meta_kms_page_flip_data_discard_in_impl (page_flip_data, error);
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
meta_kms_impl_device_unhold_fd (impl_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/impl-simple: Clean up pending page flip datas on finalize They might be holding on to references, so lets keep track of them and clean up on finalize. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-10 19:36:42 -04:00
else
{
impl_device_simple->posted_page_flip_datas =
g_list_prepend (impl_device_simple->posted_page_flip_datas,
page_flip_data);
}
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
retry_page_flip_data_free (retry_page_flip_data);
l = l_next;
}
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>
2020-07-17 03:38:11 -04:00
if (impl_device_simple->pending_page_flip_retries)
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
{
GList *l;
uint64_t earliest_retry_time_us = 0;
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>
2020-07-17 03:38:11 -04:00
for (l = impl_device_simple->pending_page_flip_retries; l; l = l->next)
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
{
RetryPageFlipData *retry_page_flip_data = l->data;
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>
2020-07-17 03:38:11 -04:00
if (l == impl_device_simple->pending_page_flip_retries ||
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
is_timestamp_earlier_than (retry_page_flip_data->retry_time_us,
earliest_retry_time_us))
earliest_retry_time_us = retry_page_flip_data->retry_time_us;
}
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>
2020-07-17 03:38:11 -04:00
g_source_set_ready_time (impl_device_simple->retry_page_flips_source,
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
earliest_retry_time_us);
return G_SOURCE_CONTINUE;
}
else
{
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>
2020-07-17 03:38:11 -04:00
g_clear_pointer (&impl_device_simple->retry_page_flips_source,
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
g_source_unref);
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>
2020-07-17 03:38:11 -04:00
flush_postponed_page_flip_datas (impl_device_simple);
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
return G_SOURCE_REMOVE;
}
}
static void
kms/update: Encapsulate custom page flip fields in object Makes more sense to pass around an encapsulated object with the relevant data, than passing around a vfunc and a gpointer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 05:31:18 -05:00
schedule_retry_page_flip (MetaKmsImplDeviceSimple *impl_device_simple,
MetaKmsCrtc *crtc,
uint32_t fb_id,
float refresh_rate,
MetaKmsPageFlipData *page_flip_data,
MetaKmsCustomPageFlip *custom_page_flip)
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
{
RetryPageFlipData *retry_page_flip_data;
uint64_t now_us;
uint64_t retry_time_us;
now_us = g_get_monotonic_time ();
retry_time_us = now_us + (uint64_t) (G_USEC_PER_SEC / refresh_rate);
retry_page_flip_data = g_new0 (RetryPageFlipData, 1);
*retry_page_flip_data = (RetryPageFlipData) {
.crtc = crtc,
.fb_id = fb_id,
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
.page_flip_data = page_flip_data,
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
.refresh_rate = refresh_rate,
.retry_time_us = retry_time_us,
kms/update: Encapsulate custom page flip fields in object Makes more sense to pass around an encapsulated object with the relevant data, than passing around a vfunc and a gpointer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 05:31:18 -05:00
.custom_page_flip = custom_page_flip,
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: 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>
2020-07-17 03:38:11 -04:00
if (!impl_device_simple->retry_page_flips_source)
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: 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>
2020-07-17 03:38:11 -04:00
MetaKmsImplDevice *impl_device =
META_KMS_IMPL_DEVICE (impl_device_simple);
MetaKmsDevice *device = meta_kms_impl_device_get_device (impl_device);
MetaKms *kms = meta_kms_device_get_kms (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
GSource *source;
source = meta_kms_add_source_in_impl (kms, retry_page_flips,
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>
2020-07-17 03:38:11 -04:00
impl_device_simple, NULL);
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
g_source_set_ready_time (source, retry_time_us);
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>
2020-07-17 03:38:11 -04:00
impl_device_simple->retry_page_flips_source = source;
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
}
else
{
GList *l;
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>
2020-07-17 03:38:11 -04:00
for (l = impl_device_simple->pending_page_flip_retries; l; l = l->next)
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
{
RetryPageFlipData *pending_retry_page_flip_data = l->data;
uint64_t pending_retry_time_us =
pending_retry_page_flip_data->retry_time_us;
if (is_timestamp_earlier_than (retry_time_us, pending_retry_time_us))
{
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>
2020-07-17 03:38:11 -04:00
g_source_set_ready_time (impl_device_simple->retry_page_flips_source,
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
retry_time_us);
break;
}
}
}
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>
2020-07-17 03:38:11 -04:00
impl_device_simple->pending_page_flip_retries =
g_list_append (impl_device_simple->pending_page_flip_retries,
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
retry_page_flip_data);
}
static void
kms/impl-simple: Add helper for dispatching page flip datas Instead of a invoke helper, and a clear helper, use a single dispatch helper that does both. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-10 19:32:13 -04:00
dispatch_page_flip_datas (GList **page_flip_datas,
GFunc func,
gpointer user_data)
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/impl-simple: Add helper for dispatching page flip datas Instead of a invoke helper, and a clear helper, use a single dispatch helper that does both. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-10 19:32:13 -04:00
g_list_foreach (*page_flip_datas, func, user_data);
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
g_clear_pointer (page_flip_datas, g_list_free);
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
}
static gboolean
mode_set_fallback_feedback_idle (gpointer user_data)
{
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>
2020-07-17 03:38:11 -04:00
MetaKmsImplDeviceSimple *impl_device_simple = user_data;
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: 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>
2020-07-17 03:38:11 -04:00
g_clear_pointer (&impl_device_simple->mode_set_fallback_feedback_source,
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
g_source_unref);
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>
2020-07-17 03:38:11 -04:00
if (impl_device_simple->pending_page_flip_retries)
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: 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>
2020-07-17 03:38:11 -04:00
impl_device_simple->postponed_mode_set_fallback_datas =
g_steal_pointer (&impl_device_simple->mode_set_fallback_page_flip_datas);
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
}
else
{
kms/impl-simple: Add helper for dispatching page flip datas Instead of a invoke helper, and a clear helper, use a single dispatch helper that does both. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-10 19:32:13 -04:00
dispatch_page_flip_datas (&impl_device_simple->mode_set_fallback_page_flip_datas,
(GFunc) meta_kms_page_flip_data_mode_set_fallback_in_impl,
NULL);
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
}
return G_SOURCE_REMOVE;
}
static gboolean
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>
2020-07-17 03:38:11 -04:00
mode_set_fallback (MetaKmsImplDeviceSimple *impl_device_simple,
MetaKmsUpdate *update,
MetaKmsPlaneAssignment *plane_assignment,
MetaKmsPageFlipData *page_flip_data,
GError **error)
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: 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>
2020-07-17 03:38:11 -04:00
MetaKmsImplDevice *impl_device = META_KMS_IMPL_DEVICE (impl_device_simple);
MetaKmsDevice *device = meta_kms_impl_device_get_device (impl_device);
MetaKms *kms = meta_kms_device_get_kms (device);
kms/update: Make explicit page flip just listeners Page flipping shouldn't necessarily be an actively requested action, but happen implicitly depending on the given state. Thus, change the "page flip" update into adding listeners for page flip feedback instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:06:35 -04:00
MetaKmsCrtc *crtc = meta_kms_page_flip_data_get_crtc (page_flip_data);
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
CachedModeSet *cached_mode_set;
g_autofree uint32_t *connectors = NULL;
int n_connectors;
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
uint32_t fb_id;
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
uint32_t x, y;
int fd;
int ret;
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>
2020-07-17 03:38:11 -04:00
cached_mode_set = g_hash_table_lookup (impl_device_simple->cached_mode_sets,
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
crtc);
kms-impl-simple: Handle lack of cached mode set in flip fallback When a page flip fails with a certain error code, we've treated this as a hint that page flipping is broken and we should try to use mode setting instead. On some drivers, it seems that this error is also reported when there was no mode set, which means we'll have no cached mode set to use in the fallback. The lack of prior mode set tends to happen when we hit a race when the DRM objects change before we have the time to process a hotplug event. Handle the lack a missing mode set in the flip fallback path, with the assumption that we'll get a hotplug event that'll fix things up for us eventually. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/917
2020-01-17 02:28:17 -05:00
if (!cached_mode_set)
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
"Missing mode set for page flip fallback");
return FALSE;
}
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
drm-buffer: Don't always generate fb_id on construction It might not be needed by the user of the buffer, so don't always require it up front. Instead make sure that any user that needs it first calls "meta_drm_buffer_ensure_fb_id()" to create the ID. Only the plain gbm implementation creates the ID lazilly, the other still does it on construction due to the objects used to create them only existing during construction. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
2021-05-05 08:35:48 -04:00
if (!meta_drm_buffer_ensure_fb_id (plane_assignment->buffer, error))
return FALSE;
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
fill_connector_ids_array (cached_mode_set->connectors,
&connectors,
&n_connectors);
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
fb_id = meta_drm_buffer_get_fb_id (plane_assignment->buffer);
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
x = meta_fixed_16_to_int (plane_assignment->src_rect.x);
y = meta_fixed_16_to_int (plane_assignment->src_rect.y);
fd = meta_kms_impl_device_get_fd (impl_device);
ret = drmModeSetCrtc (fd,
meta_kms_crtc_get_id (crtc),
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
fb_id,
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
x, y,
connectors, n_connectors,
cached_mode_set->drm_mode);
if (ret != 0)
{
g_set_error (error, G_IO_ERROR, g_io_error_from_errno (-ret),
"drmModeSetCrtc mode '%s' on CRTC %u failed: %s",
cached_mode_set->drm_mode->name,
meta_kms_crtc_get_id (crtc),
g_strerror (-ret));
return FALSE;
}
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>
2020-07-17 03:38:11 -04:00
if (!impl_device_simple->mode_set_fallback_feedback_source)
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
{
GSource *source;
source = meta_kms_add_source_in_impl (kms,
mode_set_fallback_feedback_idle,
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>
2020-07-17 03:38:11 -04:00
impl_device_simple,
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
NULL);
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>
2020-07-17 03:38:11 -04:00
impl_device_simple->mode_set_fallback_feedback_source = source;
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: 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>
2020-07-17 03:38:11 -04:00
impl_device_simple->mode_set_fallback_page_flip_datas =
g_list_prepend (impl_device_simple->mode_set_fallback_page_flip_datas,
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
page_flip_data);
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
return TRUE;
}
kms: Add symbolic page flips and cogl frame infos This makes it possible to post a symbolic page flip and frame callback, meant to be used by immediate symbolic page flip reply when emulating cursor plane changes using legacy drmMode* functions. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-09 18:52:11 -04:00
static gboolean
symbolic_page_flip_idle (gpointer user_data)
{
MetaKmsPageFlipData *page_flip_data = user_data;
MetaKmsImplDevice *impl_device;
MetaKmsCrtc *crtc;
impl_device = meta_kms_page_flip_data_get_impl_device (page_flip_data);
crtc = meta_kms_page_flip_data_get_crtc (page_flip_data);
meta_topic (META_DEBUG_KMS,
"[simple] Handling symbolic page flip callback from %s, data: %p, CRTC: %u",
meta_kms_impl_device_get_path (impl_device),
page_flip_data,
meta_kms_crtc_get_id (crtc));
meta_kms_impl_device_handle_page_flip_callback (impl_device, page_flip_data);
return G_SOURCE_REMOVE;
}
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
static gboolean
kms/update: Make explicit page flip just listeners Page flipping shouldn't necessarily be an actively requested action, but happen implicitly depending on the given state. Thus, change the "page flip" update into adding listeners for page flip feedback instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:06:35 -04:00
dispatch_page_flip (MetaKmsImplDevice *impl_device,
MetaKmsUpdate *update,
MetaKmsPageFlipData *page_flip_data,
GError **error)
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: 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>
2020-07-17 03:38:11 -04:00
MetaKmsImplDeviceSimple *impl_device_simple =
META_KMS_IMPL_DEVICE_SIMPLE (impl_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
MetaKmsCrtc *crtc;
MetaKmsPlaneAssignment *plane_assignment;
kms/update: Encapsulate custom page flip fields in object Makes more sense to pass around an encapsulated object with the relevant data, than passing around a vfunc and a gpointer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 05:31:18 -05:00
g_autoptr (MetaKmsCustomPageFlip) custom_page_flip = NULL;
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
int fd;
int ret;
kms/update: Make explicit page flip just listeners Page flipping shouldn't necessarily be an actively requested action, but happen implicitly depending on the given state. Thus, change the "page flip" update into adding listeners for page flip feedback instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:06:35 -04:00
crtc = meta_kms_page_flip_data_get_crtc (page_flip_data);
kms/update: Add helper to get primary plane assignment Replaces a private static function, with no functional changes made to it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/826
2019-10-04 05:48:46 -04:00
plane_assignment = meta_kms_update_get_primary_plane_assignment (update,
crtc);
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: Encapsulate custom page flip fields in object Makes more sense to pass around an encapsulated object with the relevant data, than passing around a vfunc and a gpointer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 05:31:18 -05:00
custom_page_flip = meta_kms_update_take_custom_page_flip_func (update);
kms: Add symbolic page flips and cogl frame infos This makes it possible to post a symbolic page flip and frame callback, meant to be used by immediate symbolic page flip reply when emulating cursor plane changes using legacy drmMode* functions. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-09 18:52:11 -04:00
kms/update: Encapsulate custom page flip fields in object Makes more sense to pass around an encapsulated object with the relevant data, than passing around a vfunc and a gpointer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 05:31:18 -05:00
if (!plane_assignment && !custom_page_flip)
kms: Add symbolic page flips and cogl frame infos This makes it possible to post a symbolic page flip and frame callback, meant to be used by immediate symbolic page flip reply when emulating cursor plane changes using legacy drmMode* functions. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-09 18:52:11 -04:00
{
MetaKmsDevice *device = meta_kms_impl_device_get_device (impl_device);
MetaKms *kms = meta_kms_device_get_kms (device);
GSource *source;
meta_kms_page_flip_data_make_symbolic (page_flip_data);
source = meta_kms_add_source_in_impl (kms,
symbolic_page_flip_idle,
page_flip_data,
NULL);
g_source_set_ready_time (source, 0);
g_source_unref (source);
return TRUE;
}
drm-buffer: Don't always generate fb_id on construction It might not be needed by the user of the buffer, so don't always require it up front. Instead make sure that any user that needs it first calls "meta_drm_buffer_ensure_fb_id()" to create the ID. Only the plain gbm implementation creates the ID lazilly, the other still does it on construction due to the objects used to create them only existing during construction. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
2021-05-05 08:35:48 -04:00
if (plane_assignment && plane_assignment->buffer &&
!meta_drm_buffer_ensure_fb_id (plane_assignment->buffer, error))
return FALSE;
kms: Add symbolic page flips and cogl frame infos This makes it possible to post a symbolic page flip and frame callback, meant to be used by immediate symbolic page flip reply when emulating cursor plane changes using legacy drmMode* functions. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-09 18:52:11 -04:00
fd = meta_kms_impl_device_get_fd (impl_device);
kms/update: Encapsulate custom page flip fields in object Makes more sense to pass around an encapsulated object with the relevant data, than passing around a vfunc and a gpointer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 05:31:18 -05:00
if (custom_page_flip)
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 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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Invoking custom page flip on CRTC %u (%s)",
meta_kms_crtc_get_id (crtc),
meta_kms_impl_device_get_path (impl_device));
kms/update: Encapsulate custom page flip fields in object Makes more sense to pass around an encapsulated object with the relevant data, than passing around a vfunc and a gpointer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 05:31:18 -05:00
ret = custom_page_flip->func (custom_page_flip->user_data,
page_flip_data);
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
}
else
{
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
uint32_t fb_id;
fb_id = meta_drm_buffer_get_fb_id (plane_assignment->buffer);
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Page flipping CRTC %u (%s) with %u, data: %p",
meta_kms_crtc_get_id (crtc),
meta_kms_impl_device_get_path (impl_device),
fb_id,
page_flip_data);
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
ret = drmModePageFlip (fd,
meta_kms_crtc_get_id (crtc),
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
fb_id,
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
DRM_MODE_PAGE_FLIP_EVENT,
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
page_flip_data);
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
}
if (ret == -EBUSY)
{
kms-impl-simple: Handle mode set race conditions gracefully If we end up trying to do a mode set on a DRM state that has already changed behind our back without us yet having seen the hotplug event we may fail with `EINVAL`. Since the renderer layer doesn't handle mode set failure, it'll still try to page flip later on, which will then also fail. When failing, it'll try to look up the cached mode set in order to retry the mode set later on, as is needed to handle other error conditions. However, if the mode set prior to the page flip failed, we won't cache the mode set, and the page flip error handling code will get confused. Instead of asserting that a page flip always has a valid cached mode set ready to look up, handle it being missing more gracefully by failing to mode set. It is expected that things will correct themself as there should be a hotplug event waiting around the the corner, to reconfigure the monitor configuration setting new modes. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/917 https://gitlab.gnome.org/GNOME/mutter/merge_requests/1007
2020-01-14 05:16:09 -05:00
CachedModeSet *cached_mode_set;
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Scheduling page flip retry on CRTC %u (%s)",
meta_kms_crtc_get_id (crtc),
meta_kms_impl_device_get_path (impl_device));
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>
2020-07-17 03:38:11 -04:00
cached_mode_set = get_cached_mode_set (impl_device_simple, crtc);
kms-impl-simple: Handle mode set race conditions gracefully If we end up trying to do a mode set on a DRM state that has already changed behind our back without us yet having seen the hotplug event we may fail with `EINVAL`. Since the renderer layer doesn't handle mode set failure, it'll still try to page flip later on, which will then also fail. When failing, it'll try to look up the cached mode set in order to retry the mode set later on, as is needed to handle other error conditions. However, if the mode set prior to the page flip failed, we won't cache the mode set, and the page flip error handling code will get confused. Instead of asserting that a page flip always has a valid cached mode set ready to look up, handle it being missing more gracefully by failing to mode set. It is expected that things will correct themself as there should be a hotplug event waiting around the the corner, to reconfigure the monitor configuration setting new modes. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/917 https://gitlab.gnome.org/GNOME/mutter/merge_requests/1007
2020-01-14 05:16:09 -05:00
if (cached_mode_set)
{
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
uint32_t fb_id;
kms-impl-simple: Handle mode set race conditions gracefully If we end up trying to do a mode set on a DRM state that has already changed behind our back without us yet having seen the hotplug event we may fail with `EINVAL`. Since the renderer layer doesn't handle mode set failure, it'll still try to page flip later on, which will then also fail. When failing, it'll try to look up the cached mode set in order to retry the mode set later on, as is needed to handle other error conditions. However, if the mode set prior to the page flip failed, we won't cache the mode set, and the page flip error handling code will get confused. Instead of asserting that a page flip always has a valid cached mode set ready to look up, handle it being missing more gracefully by failing to mode set. It is expected that things will correct themself as there should be a hotplug event waiting around the the corner, to reconfigure the monitor configuration setting new modes. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/917 https://gitlab.gnome.org/GNOME/mutter/merge_requests/1007
2020-01-14 05:16:09 -05:00
drmModeModeInfo *drm_mode;
float refresh_rate;
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
if (plane_assignment)
fb_id = meta_drm_buffer_get_fb_id (plane_assignment->buffer);
else
fb_id = 0;
kms-impl-simple: Handle mode set race conditions gracefully If we end up trying to do a mode set on a DRM state that has already changed behind our back without us yet having seen the hotplug event we may fail with `EINVAL`. Since the renderer layer doesn't handle mode set failure, it'll still try to page flip later on, which will then also fail. When failing, it'll try to look up the cached mode set in order to retry the mode set later on, as is needed to handle other error conditions. However, if the mode set prior to the page flip failed, we won't cache the mode set, and the page flip error handling code will get confused. Instead of asserting that a page flip always has a valid cached mode set ready to look up, handle it being missing more gracefully by failing to mode set. It is expected that things will correct themself as there should be a hotplug event waiting around the the corner, to reconfigure the monitor configuration setting new modes. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/917 https://gitlab.gnome.org/GNOME/mutter/merge_requests/1007
2020-01-14 05:16:09 -05:00
drm_mode = cached_mode_set->drm_mode;
refresh_rate = meta_calculate_drm_mode_refresh_rate (drm_mode);
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
meta_kms_impl_device_hold_fd (impl_device);
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>
2020-07-17 03:38:11 -04:00
schedule_retry_page_flip (impl_device_simple,
kms-impl-simple: Handle mode set race conditions gracefully If we end up trying to do a mode set on a DRM state that has already changed behind our back without us yet having seen the hotplug event we may fail with `EINVAL`. Since the renderer layer doesn't handle mode set failure, it'll still try to page flip later on, which will then also fail. When failing, it'll try to look up the cached mode set in order to retry the mode set later on, as is needed to handle other error conditions. However, if the mode set prior to the page flip failed, we won't cache the mode set, and the page flip error handling code will get confused. Instead of asserting that a page flip always has a valid cached mode set ready to look up, handle it being missing more gracefully by failing to mode set. It is expected that things will correct themself as there should be a hotplug event waiting around the the corner, to reconfigure the monitor configuration setting new modes. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/917 https://gitlab.gnome.org/GNOME/mutter/merge_requests/1007
2020-01-14 05:16:09 -05:00
crtc,
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
fb_id,
kms-impl-simple: Handle mode set race conditions gracefully If we end up trying to do a mode set on a DRM state that has already changed behind our back without us yet having seen the hotplug event we may fail with `EINVAL`. Since the renderer layer doesn't handle mode set failure, it'll still try to page flip later on, which will then also fail. When failing, it'll try to look up the cached mode set in order to retry the mode set later on, as is needed to handle other error conditions. However, if the mode set prior to the page flip failed, we won't cache the mode set, and the page flip error handling code will get confused. Instead of asserting that a page flip always has a valid cached mode set ready to look up, handle it being missing more gracefully by failing to mode set. It is expected that things will correct themself as there should be a hotplug event waiting around the the corner, to reconfigure the monitor configuration setting new modes. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/917 https://gitlab.gnome.org/GNOME/mutter/merge_requests/1007
2020-01-14 05:16:09 -05:00
refresh_rate,
kms: Use custom page flip function when retrying failed flips When using its EGLStream-based presentation path with the proprietary NVIDIA driver, mutter will use a different function to process page flips - custom_egl_stream_page_flip. If that fails due to an EBUSY error, it will attempt to retry the flip. However, when retrying, it unconditionally uses the libdrm-based path. In practice, this causes a segfault when attempting to access plane_assignments->fb_id, since plane_assignments will be NULL in the EGLStream case. The issue can be reproduced reliably by VT-switching away from GNOME and back again while an EGL application is running. This patch has mutter also use the custom page flip function when retrying the failed flip. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1375
2020-07-17 16:38:55 -04:00
page_flip_data,
kms/update: Encapsulate custom page flip fields in object Makes more sense to pass around an encapsulated object with the relevant data, than passing around a vfunc and a gpointer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-22 05:31:18 -05:00
g_steal_pointer (&custom_page_flip));
kms/impl-simple: Clean up pending page flip datas on finalize They might be holding on to references, so lets keep track of them and clean up on finalize. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-10 19:36:42 -04:00
return TRUE;
kms-impl-simple: Handle mode set race conditions gracefully If we end up trying to do a mode set on a DRM state that has already changed behind our back without us yet having seen the hotplug event we may fail with `EINVAL`. Since the renderer layer doesn't handle mode set failure, it'll still try to page flip later on, which will then also fail. When failing, it'll try to look up the cached mode set in order to retry the mode set later on, as is needed to handle other error conditions. However, if the mode set prior to the page flip failed, we won't cache the mode set, and the page flip error handling code will get confused. Instead of asserting that a page flip always has a valid cached mode set ready to look up, handle it being missing more gracefully by failing to mode set. It is expected that things will correct themself as there should be a hotplug event waiting around the the corner, to reconfigure the monitor configuration setting new modes. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/917 https://gitlab.gnome.org/GNOME/mutter/merge_requests/1007
2020-01-14 05:16:09 -05:00
}
else
{
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
"Page flip of %u failed, and no mode set available",
meta_kms_crtc_get_id (crtc));
return FALSE;
}
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
}
else if (ret == -EINVAL)
{
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Falling back to mode set on CRTC %u (%s)",
meta_kms_crtc_get_id (crtc),
meta_kms_impl_device_get_path (impl_device));
kms/impl-simple: Clean up pending page flip datas on finalize They might be holding on to references, so lets keep track of them and clean up on finalize. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-10 19:36:42 -04:00
return mode_set_fallback (impl_device_simple,
update,
plane_assignment,
page_flip_data,
error);
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
}
else if (ret != 0)
{
g_set_error (error, G_IO_ERROR, g_io_error_from_errno (-ret),
"drmModePageFlip on CRTC %u failed: %s",
meta_kms_crtc_get_id (crtc),
g_strerror (-ret));
return FALSE;
}
kms/impl-simple: Clean up pending page flip datas on finalize They might be holding on to references, so lets keep track of them and clean up on finalize. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-10 19:36:42 -04:00
else
{
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
meta_kms_impl_device_hold_fd (impl_device);
kms/impl-simple: Clean up pending page flip datas on finalize They might be holding on to references, so lets keep track of them and clean up on finalize. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-10 19:36:42 -04:00
impl_device_simple->posted_page_flip_datas =
g_list_prepend (impl_device_simple->posted_page_flip_datas,
page_flip_data);
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/impl-simple: Clean up pending page flip datas on finalize They might be holding on to references, so lets keep track of them and clean up on finalize. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-10 19:36:42 -04:00
return TRUE;
}
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 explicit page flip just listeners Page flipping shouldn't necessarily be an actively requested action, but happen implicitly depending on the given state. Thus, change the "page flip" update into adding listeners for page flip feedback instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:06:35 -04:00
static GList *
generate_page_flip_datas (MetaKmsImplDevice *impl_device,
MetaKmsUpdate *update)
{
GList *listeners;
GList *page_flip_datas = NULL;
listeners = g_list_copy (meta_kms_update_get_page_flip_listeners (update));
while (listeners)
{
MetaKmsPageFlipListener *listener = listeners->data;
MetaKmsCrtc *crtc = listener->crtc;
MetaKmsPageFlipData *page_flip_data;
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
gpointer user_data;
GDestroyNotify destroy_notify;
kms/update: Make explicit page flip just listeners Page flipping shouldn't necessarily be an actively requested action, but happen implicitly depending on the given state. Thus, change the "page flip" update into adding listeners for page flip feedback instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:06:35 -04:00
GList *l;
page_flip_data = meta_kms_page_flip_data_new (impl_device, crtc);
page_flip_datas = g_list_append (page_flip_datas, page_flip_data);
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
user_data = g_steal_pointer (&listener->user_data);
destroy_notify = g_steal_pointer (&listener->destroy_notify);
kms/update: Make explicit page flip just listeners Page flipping shouldn't necessarily be an actively requested action, but happen implicitly depending on the given state. Thus, change the "page flip" update into adding listeners for page flip feedback instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:06:35 -04:00
meta_kms_page_flip_data_add_listener (page_flip_data,
listener->vtable,
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
listener->flags,
user_data,
destroy_notify);
kms/update: Make explicit page flip just listeners Page flipping shouldn't necessarily be an actively requested action, but happen implicitly depending on the given state. Thus, change the "page flip" update into adding listeners for page flip feedback instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:06:35 -04:00
listeners = g_list_delete_link (listeners, listeners);
l = listeners;
while (l)
{
MetaKmsPageFlipListener *other_listener = l->data;
GList *l_next = l->next;
if (other_listener->crtc == crtc)
{
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
gpointer other_user_data;
GDestroyNotify other_destroy_notify;
other_user_data = g_steal_pointer (&other_listener->user_data);
other_destroy_notify =
g_steal_pointer (&other_listener->destroy_notify);
kms/update: Make explicit page flip just listeners Page flipping shouldn't necessarily be an actively requested action, but happen implicitly depending on the given state. Thus, change the "page flip" update into adding listeners for page flip feedback instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:06:35 -04:00
meta_kms_page_flip_data_add_listener (page_flip_data,
other_listener->vtable,
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
other_listener->flags,
other_user_data,
other_destroy_notify);
kms/update: Make explicit page flip just listeners Page flipping shouldn't necessarily be an actively requested action, but happen implicitly depending on the given state. Thus, change the "page flip" update into adding listeners for page flip feedback instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:06:35 -04:00
listeners = g_list_delete_link (listeners, l);
}
l = l_next;
}
}
return page_flip_datas;
}
static gboolean
maybe_dispatch_page_flips (MetaKmsImplDevice *impl_device,
MetaKmsUpdate *update,
GList **failed_planes,
kms: Gracefully handle page flipping direct scanouts failing 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>
2021-07-01 13:45:03 -04:00
MetaKmsUpdateFlag flags,
kms/update: Make explicit page flip just listeners Page flipping shouldn't necessarily be an actively requested action, but happen implicitly depending on the given state. Thus, change the "page flip" update into adding listeners for page flip feedback instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:06:35 -04:00
GError **error)
{
g_autoptr (GList) page_flip_datas = NULL;
GList *l;
page_flip_datas = generate_page_flip_datas (impl_device, update);
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
while (page_flip_datas)
kms/update: Make explicit page flip just listeners Page flipping shouldn't necessarily be an actively requested action, but happen implicitly depending on the given state. Thus, change the "page flip" update into adding listeners for page flip feedback instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:06:35 -04:00
{
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
g_autoptr (GList) l = NULL;
MetaKmsPageFlipData *page_flip_data;
l = page_flip_datas;
page_flip_datas = g_list_remove_link (page_flip_datas, l);
page_flip_data = g_steal_pointer (&l->data);
kms/update: Make explicit page flip just listeners Page flipping shouldn't necessarily be an actively requested action, but happen implicitly depending on the given state. Thus, change the "page flip" update into adding listeners for page flip feedback instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:06:35 -04:00
if (!dispatch_page_flip (impl_device, update, page_flip_data, error))
{
if (!g_error_matches (*error,
G_IO_ERROR,
G_IO_ERROR_PERMISSION_DENIED))
{
MetaKmsCrtc *crtc =
meta_kms_page_flip_data_get_crtc (page_flip_data);
MetaKmsPlaneAssignment *plane_assignment;
MetaKmsPlaneFeedback *plane_feedback;
plane_assignment =
meta_kms_update_get_primary_plane_assignment (update, crtc);
plane_feedback =
meta_kms_plane_feedback_new_take_error (plane_assignment->plane,
plane_assignment->crtc,
g_error_copy (*error));
*failed_planes = g_list_prepend (*failed_planes, plane_feedback);
}
kms: Gracefully handle page flipping direct scanouts failing 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>
2021-07-01 13:45:03 -04:00
if (!(flags & META_KMS_UPDATE_FLAG_PRESERVE_ON_ERROR))
meta_kms_page_flip_data_discard_in_impl (page_flip_data, *error);
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
goto err;
kms/update: Make explicit page flip just listeners Page flipping shouldn't necessarily be an actively requested action, but happen implicitly depending on the given state. Thus, change the "page flip" update into adding listeners for page flip feedback instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:06:35 -04:00
}
}
return TRUE;
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
err:
kms: Gracefully handle page flipping direct scanouts failing 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>
2021-07-01 13:45:03 -04:00
if (!(flags & META_KMS_UPDATE_FLAG_PRESERVE_ON_ERROR))
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
{
kms: Gracefully handle page flipping direct scanouts failing 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>
2021-07-01 13:45:03 -04:00
for (l = page_flip_datas; l; l = l->next)
{
MetaKmsPageFlipData *page_flip_data = l->data;
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
kms: Gracefully handle page flipping direct scanouts failing 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>
2021-07-01 13:45:03 -04:00
meta_kms_page_flip_data_discard_in_impl (page_flip_data, *error);
}
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
}
g_list_free (page_flip_datas);
return FALSE;
kms/update: Make explicit page flip just listeners Page flipping shouldn't necessarily be an actively requested action, but happen implicitly depending on the given state. Thus, change the "page flip" update into adding listeners for page flip feedback instead. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:06:35 -04:00
}
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
static gboolean
kms/impl-device/simple: Make process update vfunc type a typedef It made the function type declaration a bit unreadable, so split it out. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-19 13:26:14 -05:00
process_entries (MetaKmsImplDevice *impl_device,
MetaKmsUpdate *update,
GList *entries,
MetaKmsSimpleProcessFunc func,
GError **error)
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
{
GList *l;
kms-impl-simple: Add helper to process update entries This avoids some loop iteration boiler plate. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 05:30:18 -05:00
for (l = entries; l; l = l->next)
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: 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>
2020-07-17 03:38:11 -04:00
if (!func (impl_device, update, l->data, error))
kms-impl-simple: Add helper to process update entries This avoids some loop iteration boiler plate. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 05:30:18 -05:00
return FALSE;
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-impl-simple: Add helper to process update entries This avoids some loop iteration boiler plate. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 05:30:18 -05:00
return TRUE;
}
monitor-manager/kms: Use KMS abstraction to get and set CRTC gamma Still doesn't synchronize with frame drawing, but no point in doing that until gamma is managed by mutter itself and not gnome-settings-daemon. https://gitlab.gnome.org/GNOME/mutter/merge_requests/634
2019-05-03 13:20:21 -04:00
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
static gboolean
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>
2020-07-17 03:38:11 -04:00
process_cursor_plane_assignment (MetaKmsImplDevice *impl_device,
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
MetaKmsUpdate *update,
MetaKmsPlaneAssignment *plane_assignment,
GError **error)
{
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>
2020-07-17 03:38:11 -04:00
uint32_t crtc_id;
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
int fd;
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>
2020-07-17 03:38:11 -04:00
crtc_id = meta_kms_crtc_get_id (plane_assignment->crtc),
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
fd = meta_kms_impl_device_get_fd (impl_device);
if (!(plane_assignment->flags & META_KMS_ASSIGN_PLANE_FLAG_FB_UNCHANGED))
{
int width, height;
kms/plane-assignment: Add API to set cursor hotspot metadata The transactional KMS API has been modelled after atomic KMS. Atomic KMS currently doesn't support forwarding cursor hotspot metadata, thus it was left out of the transactional KMS API having the user set the simply create a plane assigment with the cursor sprite assigned to a cursor plane using regular coordinates. This, however, proved to be inadequate for virtual machines using "seamless mouse mode" where they rely on the cursor position to correspond to the actual cursor position of the virtual machine, not the cursor plane. In effect, this caused cursor positions to look "shifted". Fix this by adding back the hotspot metadata, right now as a optional field to the plane assignment. In the legacy KMS implementation, this is translated into drmModeSetCursor2() just as before, while still falling back to drmModeSetCursor() with the plane coordinates, if either there was no hotspot set, or if drmModeSetCursor2() failed. Eventually, the atomic KMS API will learn about hotspots, but when adding our own atomic KMS backend to the transacitonal KMS API, we must until then still fall back to legacy KMS for virtual machines. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1136
2020-03-19 04:01:03 -04:00
int ret = -1;
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
uint32_t handle_u32;
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
kms/update: Make dst_rect a int rectangle It's never used as a 16.16 fixed point rectangle so no reason it should be passed around as one. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 12:00:36 -04:00
width = plane_assignment->dst_rect.width;
height = plane_assignment->dst_rect.height;
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
if (plane_assignment->buffer)
{
MetaDrmBufferGbm *buffer_gbm =
META_DRM_BUFFER_GBM (plane_assignment->buffer);
struct gbm_bo *bo;
union gbm_bo_handle handle;
bo = meta_drm_buffer_gbm_get_bo (buffer_gbm);
handle = gbm_bo_get_handle (bo);
handle_u32 = handle.u32;
}
else
{
handle_u32 = 0;
}
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Setting HW cursor of CRTC %u (%s) to %u "
"(size: %dx%d, hot: (%d, %d))",
crtc_id,
meta_kms_impl_device_get_path (impl_device),
handle_u32,
width, height,
plane_assignment->cursor_hotspot.x,
plane_assignment->cursor_hotspot.y);
kms/plane-assignment: Add API to set cursor hotspot metadata The transactional KMS API has been modelled after atomic KMS. Atomic KMS currently doesn't support forwarding cursor hotspot metadata, thus it was left out of the transactional KMS API having the user set the simply create a plane assigment with the cursor sprite assigned to a cursor plane using regular coordinates. This, however, proved to be inadequate for virtual machines using "seamless mouse mode" where they rely on the cursor position to correspond to the actual cursor position of the virtual machine, not the cursor plane. In effect, this caused cursor positions to look "shifted". Fix this by adding back the hotspot metadata, right now as a optional field to the plane assignment. In the legacy KMS implementation, this is translated into drmModeSetCursor2() just as before, while still falling back to drmModeSetCursor() with the plane coordinates, if either there was no hotspot set, or if drmModeSetCursor2() failed. Eventually, the atomic KMS API will learn about hotspots, but when adding our own atomic KMS backend to the transacitonal KMS API, we must until then still fall back to legacy KMS for virtual machines. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1136
2020-03-19 04:01:03 -04:00
if (plane_assignment->cursor_hotspot.is_valid)
{
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>
2020-07-17 03:38:11 -04:00
ret = drmModeSetCursor2 (fd,
crtc_id,
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
handle_u32,
kms/plane-assignment: Add API to set cursor hotspot metadata The transactional KMS API has been modelled after atomic KMS. Atomic KMS currently doesn't support forwarding cursor hotspot metadata, thus it was left out of the transactional KMS API having the user set the simply create a plane assigment with the cursor sprite assigned to a cursor plane using regular coordinates. This, however, proved to be inadequate for virtual machines using "seamless mouse mode" where they rely on the cursor position to correspond to the actual cursor position of the virtual machine, not the cursor plane. In effect, this caused cursor positions to look "shifted". Fix this by adding back the hotspot metadata, right now as a optional field to the plane assignment. In the legacy KMS implementation, this is translated into drmModeSetCursor2() just as before, while still falling back to drmModeSetCursor() with the plane coordinates, if either there was no hotspot set, or if drmModeSetCursor2() failed. Eventually, the atomic KMS API will learn about hotspots, but when adding our own atomic KMS backend to the transacitonal KMS API, we must until then still fall back to legacy KMS for virtual machines. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1136
2020-03-19 04:01:03 -04:00
width, height,
plane_assignment->cursor_hotspot.x,
plane_assignment->cursor_hotspot.y);
}
if (ret != 0)
{
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>
2020-07-17 03:38:11 -04:00
ret = drmModeSetCursor (fd, crtc_id,
kms/update: Assign planes with MetaDrmBuffer instead of fb ids This will eventually allow better lifetime control. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 13:32:46 -04:00
handle_u32,
kms/plane-assignment: Add API to set cursor hotspot metadata The transactional KMS API has been modelled after atomic KMS. Atomic KMS currently doesn't support forwarding cursor hotspot metadata, thus it was left out of the transactional KMS API having the user set the simply create a plane assigment with the cursor sprite assigned to a cursor plane using regular coordinates. This, however, proved to be inadequate for virtual machines using "seamless mouse mode" where they rely on the cursor position to correspond to the actual cursor position of the virtual machine, not the cursor plane. In effect, this caused cursor positions to look "shifted". Fix this by adding back the hotspot metadata, right now as a optional field to the plane assignment. In the legacy KMS implementation, this is translated into drmModeSetCursor2() just as before, while still falling back to drmModeSetCursor() with the plane coordinates, if either there was no hotspot set, or if drmModeSetCursor2() failed. Eventually, the atomic KMS API will learn about hotspots, but when adding our own atomic KMS backend to the transacitonal KMS API, we must until then still fall back to legacy KMS for virtual machines. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1136
2020-03-19 04:01:03 -04:00
width, height);
}
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
if (ret != 0)
{
g_set_error (error, G_IO_ERROR, g_io_error_from_errno (-ret),
"drmModeSetCursor failed: %s", g_strerror (-ret));
return FALSE;
}
}
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Moving HW cursor of CRTC %u (%s) to (%d, %d)",
crtc_id,
meta_kms_impl_device_get_path (impl_device),
plane_assignment->dst_rect.x,
plane_assignment->dst_rect.y);
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
drmModeMoveCursor (fd,
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>
2020-07-17 03:38:11 -04:00
crtc_id,
kms/update: Make dst_rect a int rectangle It's never used as a 16.16 fixed point rectangle so no reason it should be passed around as one. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-09-21 12:00:36 -04:00
plane_assignment->dst_rect.x,
plane_assignment->dst_rect.y);
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
return TRUE;
}
static gboolean
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>
2020-07-17 03:38:11 -04:00
process_plane_assignment (MetaKmsImplDevice *impl_device,
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
MetaKmsUpdate *update,
MetaKmsPlaneAssignment *plane_assignment,
MetaKmsPlaneFeedback **plane_feedback)
{
MetaKmsPlane *plane;
MetaKmsPlaneType plane_type;
GError *error = NULL;
plane = plane_assignment->plane;
plane_type = meta_kms_plane_get_plane_type (plane);
switch (plane_type)
{
case META_KMS_PLANE_TYPE_PRIMARY:
/* Handled as part of the mode-set and page flip. */
return TRUE;
case META_KMS_PLANE_TYPE_CURSOR:
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>
2020-07-17 03:38:11 -04:00
if (!process_cursor_plane_assignment (impl_device, update,
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
plane_assignment,
&error))
{
*plane_feedback =
meta_kms_plane_feedback_new_take_error (plane,
plane_assignment->crtc,
g_steal_pointer (&error));
return FALSE;
}
else
{
return TRUE;
}
case META_KMS_PLANE_TYPE_OVERLAY:
error = g_error_new_literal (G_IO_ERROR, G_IO_ERROR_FAILED,
"Overlay planes cannot be assigned");
*plane_feedback =
meta_kms_plane_feedback_new_take_error (plane,
plane_assignment->crtc,
g_steal_pointer (&error));
return TRUE;
}
g_assert_not_reached ();
}
kms: Allow update passing with failed plane assignments This will later make it possible to pass cursor plane assignments, together with a complete update including the primary plane, but not failing the whole update if just processing the cursor plane failed. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 09:45:28 -04:00
static gboolean
process_plane_assignments (MetaKmsImplDevice *impl_device,
MetaKmsUpdate *update,
GList **failed_planes,
GError **error)
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
{
GList *l;
for (l = meta_kms_update_get_plane_assignments (update); l; l = l->next)
{
MetaKmsPlaneAssignment *plane_assignment = l->data;
MetaKmsPlaneFeedback *plane_feedback;
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>
2020-07-17 03:38:11 -04:00
if (!process_plane_assignment (impl_device, update, plane_assignment,
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
&plane_feedback))
{
kms: Allow update passing with failed plane assignments This will later make it possible to pass cursor plane assignments, together with a complete update including the primary plane, but not failing the whole update if just processing the cursor plane failed. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 09:45:28 -04:00
if (g_error_matches (plane_feedback->error,
G_IO_ERROR,
G_IO_ERROR_PERMISSION_DENIED))
{
g_propagate_error (error,
g_steal_pointer (&plane_feedback->error));
meta_kms_plane_feedback_free (plane_feedback);
return FALSE;
}
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
kms: Allow update passing with failed plane assignments This will later make it possible to pass cursor plane assignments, together with a complete update including the primary plane, but not failing the whole update if just processing the cursor plane failed. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 09:45:28 -04:00
*failed_planes = g_list_prepend (*failed_planes, plane_feedback);
if (plane_assignment->flags & META_KMS_ASSIGN_PLANE_FLAG_ALLOW_FAIL)
{
continue;
}
else
{
g_propagate_error (error, g_error_copy (plane_feedback->error));
return FALSE;
}
}
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
}
kms: Allow update passing with failed plane assignments This will later make it possible to pass cursor plane assignments, together with a complete update including the primary plane, but not failing the whole update if just processing the cursor plane failed. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 09:45:28 -04:00
return TRUE;
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
}
kms/impl-device: Make the actual implementation handle the drm event The way drm events are handled depends on whether we're using atomic or not. Lets move the handling to the implementation, so that later the atomic backend can handle the event they it need to. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:56:10 -04:00
static void
page_flip_handler (int fd,
unsigned int sequence,
unsigned int tv_sec,
unsigned int tv_usec,
void *user_data)
{
MetaKmsPageFlipData *page_flip_data = user_data;
MetaKmsImplDevice *impl_device;
kms/impl-simple: Clean up pending page flip datas on finalize They might be holding on to references, so lets keep track of them and clean up on finalize. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-10 19:36:42 -04:00
MetaKmsImplDeviceSimple *impl_device_simple;
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>
2020-10-02 12:37:18 -04:00
MetaKmsCrtc *crtc;
kms/impl-device: Make the actual implementation handle the drm event The way drm events are handled depends on whether we're using atomic or not. Lets move the handling to the implementation, so that later the atomic backend can handle the event they it need to. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:56:10 -04:00
meta_kms_page_flip_data_set_timings_in_impl (page_flip_data,
sequence, tv_sec, tv_usec);
impl_device = meta_kms_page_flip_data_get_impl_device (page_flip_data);
kms/impl-simple: Clean up pending page flip datas on finalize They might be holding on to references, so lets keep track of them and clean up on finalize. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-10 19:36:42 -04:00
impl_device_simple = META_KMS_IMPL_DEVICE_SIMPLE (impl_device);
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>
2020-10-02 12:37:18 -04:00
crtc = meta_kms_page_flip_data_get_crtc (page_flip_data);
meta_topic (META_DEBUG_KMS,
"[simple] Handling page flip callback from %s, data: %p, CRTC: %u",
meta_kms_impl_device_get_path (impl_device),
page_flip_data,
meta_kms_crtc_get_id (crtc));
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
meta_kms_impl_device_unhold_fd (impl_device);
kms/impl-device: Make the actual implementation handle the drm event The way drm events are handled depends on whether we're using atomic or not. Lets move the handling to the implementation, so that later the atomic backend can handle the event they it need to. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:56:10 -04:00
meta_kms_impl_device_handle_page_flip_callback (impl_device, page_flip_data);
kms/impl-simple: Clean up pending page flip datas on finalize They might be holding on to references, so lets keep track of them and clean up on finalize. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-10 19:36:42 -04:00
impl_device_simple->posted_page_flip_datas =
g_list_remove (impl_device_simple->posted_page_flip_datas,
page_flip_data);
kms/impl-device: Make the actual implementation handle the drm event The way drm events are handled depends on whether we're using atomic or not. Lets move the handling to the implementation, so that later the atomic backend can handle the event they it need to. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:56:10 -04:00
}
static void
kms/impl-device: Fix some argument naming mistakes It was left-overs from when the MetaKmsImpl was not per device. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1820>
2021-04-01 05:56:22 -04:00
meta_kms_impl_device_simple_setup_drm_event_context (MetaKmsImplDevice *impl_device,
kms/impl-device: Make the actual implementation handle the drm event The way drm events are handled depends on whether we're using atomic or not. Lets move the handling to the implementation, so that later the atomic backend can handle the event they it need to. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:56:10 -04:00
drmEventContext *drm_event_context)
{
drm_event_context->version = 2;
drm_event_context->page_flip_handler = page_flip_handler;
}
kms: Make update processing return direct feedback 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
2019-11-08 18:14:36 -05:00
static MetaKmsFeedback *
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>
2020-07-17 03:38:11 -04:00
meta_kms_impl_device_simple_process_update (MetaKmsImplDevice *impl_device,
kms: Gracefully handle page flipping direct scanouts failing 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>
2021-07-01 13:45:03 -04:00
MetaKmsUpdate *update,
MetaKmsUpdateFlag flags)
kms-impl-simple: Add helper to process update entries This avoids some loop iteration boiler plate. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 05:30:18 -05:00
{
kms: Make update processing return direct feedback 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
2019-11-08 18:14:36 -05:00
GError *error = NULL;
kms: Allow update passing with failed plane assignments This will later make it possible to pass cursor plane assignments, together with a complete update including the primary plane, but not failing the whole update if just processing the cursor plane failed. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 09:45:28 -04:00
GList *failed_planes = NULL;
monitor-manager/kms: Use KMS abstraction to get and set CRTC gamma Still doesn't synchronize with frame drawing, but no point in doing that until gamma is managed by mutter itself and not gnome-settings-daemon. https://gitlab.gnome.org/GNOME/mutter/merge_requests/634
2019-05-03 13:20:21 -04:00
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Processing update %" G_GUINT64_FORMAT,
meta_kms_update_get_sequence_number (update));
kms/update: Make power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
if (meta_kms_update_is_power_save (update))
{
if (!process_power_save (impl_device, &error))
goto err;
goto out;
}
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>
2020-07-17 03:38:11 -04:00
if (!process_entries (impl_device,
kms-impl-simple: Add helper to process update entries This avoids some loop iteration boiler plate. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 05:30:18 -05:00
update,
kms/update: Make power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
meta_kms_update_get_mode_sets (update),
process_mode_set,
kms: Make update processing return direct feedback 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
2019-11-08 18:14:36 -05:00
&error))
kms: Allow update passing with failed plane assignments This will later make it possible to pass cursor plane assignments, together with a complete update including the primary plane, but not failing the whole update if just processing the cursor plane failed. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 09:45:28 -04:00
goto err;
kms-impl-simple: Add helper to process update entries This avoids some loop iteration boiler plate. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 05:30:18 -05:00
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>
2020-07-17 03:38:11 -04:00
if (!process_entries (impl_device,
kms-impl-simple: Add helper to process update entries This avoids some loop iteration boiler plate. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 05:30:18 -05:00
update,
kms/update: Make power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
meta_kms_update_get_connector_updates (update),
process_connector_update,
kms: Make update processing return direct feedback 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
2019-11-08 18:14:36 -05:00
&error))
kms: Allow update passing with failed plane assignments This will later make it possible to pass cursor plane assignments, together with a complete update including the primary plane, but not failing the whole update if just processing the cursor plane failed. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 09:45:28 -04:00
goto err;
kms-impl-simple: Add helper to process update entries This avoids some loop iteration boiler plate. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 05:30:18 -05:00
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>
2020-07-17 03:38:11 -04:00
if (!process_entries (impl_device,
kms-impl-simple: Add helper to process update entries This avoids some loop iteration boiler plate. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 05:30:18 -05:00
update,
meta_kms_update_get_crtc_gammas (update),
process_crtc_gamma,
kms: Make update processing return direct feedback 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
2019-11-08 18:14:36 -05:00
&error))
kms: Allow update passing with failed plane assignments This will later make it possible to pass cursor plane assignments, together with a complete update including the primary plane, but not failing the whole update if just processing the cursor plane failed. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 09:45:28 -04:00
goto err;
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
kms: Allow update passing with failed plane assignments This will later make it possible to pass cursor plane assignments, together with a complete update including the primary plane, but not failing the whole update if just processing the cursor plane failed. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 09:45:28 -04:00
if (!process_plane_assignments (impl_device, update, &failed_planes, &error))
goto err;
kms-impl-simple: Add helper to process update entries This avoids some loop iteration boiler plate. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 05:30:18 -05:00
kms: Gracefully handle page flipping direct scanouts failing 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>
2021-07-01 13:45:03 -04:00
if (!maybe_dispatch_page_flips (impl_device, update, &failed_planes, flags,
&error))
kms: Allow update passing with failed plane assignments This will later make it possible to pass cursor plane assignments, together with a complete update including the primary plane, but not failing the whole update if just processing the cursor plane failed. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 09:45:28 -04:00
goto err;
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 power saving an update wide change This makes "power save" (i.e. when you make a monitor go into power save mode, or make it come out of power save mode), a per device action when turning on power saving (power save being set to 'off'), and implicitly handled when turning off power saving (power save being set to 'on') when doing a mode set. This is needed as with atomic mode setting, the configuration of DPMS (Display Power Management Signaling), is replaced by directly turning on or off CRTCs, and via the CRTC drm properties. Thus in order to handle both with a common API, make that API high level enough for both cases being covered. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-21 11:38:44 -04:00
out:
kms: Allow update passing with failed plane assignments This will later make it possible to pass cursor plane assignments, together with a complete update including the primary plane, but not failing the whole update if just processing the cursor plane failed. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 09:45:28 -04:00
return meta_kms_feedback_new_passed (failed_planes);
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
kms: Allow update passing with failed plane assignments This will later make it possible to pass cursor plane assignments, together with a complete update including the primary plane, but not failing the whole update if just processing the cursor plane failed. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 09:45:28 -04:00
err:
kms/impl-simple: Add cursor plane processing A cursor plane can now be assigned, and for the simple KMS implementation, it'll translate into drmModeSetCursor() and drmModeMoveCursor() calls. When assignments failed, the cursor planes that failed to be assigned are communicated via the feedback object. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 18:17:33 -05:00
return meta_kms_feedback_new_failed (failed_planes, error);
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
}
static void
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>
2020-07-17 03:38:11 -04:00
flush_postponed_page_flip_datas (MetaKmsImplDeviceSimple *impl_device_simple)
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/impl-simple: Add helper for dispatching page flip datas Instead of a invoke helper, and a clear helper, use a single dispatch helper that does both. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-10 19:32:13 -04:00
dispatch_page_flip_datas (&impl_device_simple->postponed_page_flip_datas,
(GFunc) meta_kms_page_flip_data_flipped_in_impl,
NULL);
dispatch_page_flip_datas (&impl_device_simple->postponed_mode_set_fallback_datas,
(GFunc) meta_kms_page_flip_data_mode_set_fallback_in_impl,
NULL);
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
}
static void
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>
2020-07-17 03:38:11 -04:00
meta_kms_impl_device_simple_handle_page_flip_callback (MetaKmsImplDevice *impl_device,
MetaKmsPageFlipData *page_flip_data)
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: 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>
2020-07-17 03:38:11 -04:00
MetaKmsImplDeviceSimple *impl_device_simple =
META_KMS_IMPL_DEVICE_SIMPLE (impl_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: 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>
2020-07-17 03:38:11 -04:00
if (impl_device_simple->pending_page_flip_retries)
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: 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>
2020-07-17 03:38:11 -04:00
impl_device_simple->postponed_page_flip_datas =
g_list_append (impl_device_simple->postponed_page_flip_datas,
kms/page-flip: Pass ownership of listener user data along with closure In order to reliably manage the reference count of the user data passed to page flip listeners - being the stage view - make the ownership of this data travel through the different objects that take responsibility of the next step. Initially this is the MetaKmsPageFlipListener that belongs to a MetaKmsUpdate. When a page flip is successfully queued, the ownership is transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the simple impl device, the MetaKmsPageFlipData is passed to drmModePageFlip(), then returned back via the DRM event. In the future atomic impl device, the MetaKmsPageFlipData is stored in a table, then retrieved when DRM event are handled. When the DRM events are handled, the page flip listener's interface callbacks are invoked, and after that, the user data is freed using the passed GDestroyNotify function, in the main context, the same as where the interface callbacks were called. When a page flip fails, the ownership is also transferred to a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page flip data will be passed to the main context via a callback, where it will discard the page flip, and free the user data using the provided GDestroyNotify. Note that this adds back a page flip listener type flag for telling the KMS implementation whether to actively discard a page flip via the interface, or just free the user data. Avoiding discarding via the interface is needed for the direct scanout case, where we immediately need to know the result in order to fall back to the composite pipeline if the direct scanout failed. We do in fact also need active discard via the interface paths, e.g. in the simple impl device when we're asynchronously retrying a page flip, so replace the ad-hoc discard paths in meta-renderer-native.c and replace them by not asking for no-discard page flip error handling. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-12-16 02:41:14 -05:00
page_flip_data);
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
}
else
{
meta_kms_page_flip_data_flipped_in_impl (page_flip_data);
}
}
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
static void
dispose_page_flip_data (MetaKmsPageFlipData *page_flip_data,
MetaKmsImplDevice *impl_device)
{
meta_kms_page_flip_data_discard_in_impl (page_flip_data, NULL);
meta_kms_impl_device_unhold_fd (impl_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
static void
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>
2020-07-17 03:38:11 -04:00
meta_kms_impl_device_simple_discard_pending_page_flips (MetaKmsImplDevice *impl_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: 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>
2020-07-17 03:38:11 -04:00
MetaKmsImplDeviceSimple *impl_device_simple =
META_KMS_IMPL_DEVICE_SIMPLE (impl_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
GList *l;
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>
2020-07-17 03:38:11 -04:00
if (!impl_device_simple->pending_page_flip_retries)
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
return;
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>
2020-07-17 03:38:11 -04:00
for (l = impl_device_simple->pending_page_flip_retries; l; l = l->next)
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
{
RetryPageFlipData *retry_page_flip_data = l->data;
MetaKmsPageFlipData *page_flip_data;
page_flip_data = g_steal_pointer (&retry_page_flip_data->page_flip_data);
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Discarding page flip retry for CRTC %u (%s)",
meta_kms_crtc_get_id (
meta_kms_page_flip_data_get_crtc (page_flip_data)),
meta_kms_impl_device_get_path (
meta_kms_page_flip_data_get_impl_device (page_flip_data)));
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
dispose_page_flip_data (page_flip_data, impl_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
retry_page_flip_data_free (retry_page_flip_data);
}
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>
2020-07-17 03:38:11 -04:00
g_clear_pointer (&impl_device_simple->pending_page_flip_retries, g_list_free);
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: 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>
2020-07-17 03:38:11 -04:00
g_clear_pointer (&impl_device_simple->retry_page_flips_source,
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
g_source_destroy);
}
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
static void
meta_kms_impl_device_simple_prepare_shutdown (MetaKmsImplDevice *impl_device)
{
MetaKmsImplDeviceSimple *impl_device_simple =
META_KMS_IMPL_DEVICE_SIMPLE (impl_device);
g_list_foreach (impl_device_simple->posted_page_flip_datas,
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
(GFunc) dispose_page_flip_data,
impl_device);
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
g_clear_list (&impl_device_simple->posted_page_flip_datas, NULL);
}
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-02-21 06:06:28 -05:00
static void
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>
2020-07-17 03:38:11 -04:00
meta_kms_impl_device_simple_finalize (GObject *object)
{
MetaKmsImplDeviceSimple *impl_device_simple =
META_KMS_IMPL_DEVICE_SIMPLE (object);
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
MetaKmsImplDevice *impl_device = META_KMS_IMPL_DEVICE (impl_device_simple);
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>
2020-07-17 03:38:11 -04:00
g_list_free_full (impl_device_simple->pending_page_flip_retries,
(GDestroyNotify) retry_page_flip_data_free);
kms-impl/simple: Discard pending flips when finalizing Removing the reference isn't enough, the callbacks needs to be invoked so the buffer state machinery gets notified about the page flips being discarded. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-15 10:32:53 -04:00
dispatch_page_flip_datas (&impl_device_simple->postponed_page_flip_datas,
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
(GFunc) dispose_page_flip_data,
impl_device);
kms-impl/simple: Discard pending flips when finalizing Removing the reference isn't enough, the callbacks needs to be invoked so the buffer state machinery gets notified about the page flips being discarded. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
2021-04-15 10:32:53 -04:00
dispatch_page_flip_datas (&impl_device_simple->postponed_mode_set_fallback_datas,
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
(GFunc) dispose_page_flip_data,
impl_device);
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>
2020-07-17 03:38:11 -04:00
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
g_assert (!impl_device_simple->posted_page_flip_datas);
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>
2020-07-17 03:38:11 -04:00
g_clear_pointer (&impl_device_simple->mode_set_fallback_feedback_source,
g_source_destroy);
g_hash_table_destroy (impl_device_simple->cached_mode_sets);
G_OBJECT_CLASS (meta_kms_impl_device_simple_parent_class)->finalize (object);
}
kms: Have the device impl open device files themself 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>
2021-04-06 06:14:24 -04:00
static MetaDeviceFile *
meta_kms_impl_device_simple_open_device_file (MetaKmsImplDevice *impl_device,
const char *path,
GError **error)
{
MetaKmsDevice *device = meta_kms_impl_device_get_device (impl_device);
MetaKms *kms = meta_kms_device_get_kms (device);
MetaBackend *backend = meta_kms_get_backend (kms);
MetaDevicePool *device_pool =
meta_backend_native_get_device_pool (META_BACKEND_NATIVE (backend));
kms/impl-device: Set universal plane client cap when opening file This means it will be set again if the file is reopened. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
2021-04-11 06:15:23 -04:00
g_autoptr (MetaDeviceFile) device_file = NULL;
kms: Have the device impl open device files themself 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>
2021-04-06 06:14:24 -04:00
kms/impl-device: Set universal plane client cap when opening file This means it will be set again if the file is reopened. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
2021-04-11 06:15:23 -04:00
device_file = meta_device_pool_open (device_pool, path,
META_DEVICE_FILE_FLAG_TAKE_CONTROL,
error);
if (!device_file)
return NULL;
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
if (!meta_device_file_has_tag (device_file,
META_DEVICE_FILE_TAG_KMS,
META_KMS_DEVICE_FILE_TAG_SIMPLE))
kms/impl-device: Set universal plane client cap when opening file This means it will be set again if the file is reopened. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
2021-04-11 06:15:23 -04:00
{
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
int fd = meta_device_file_get_fd (device_file);
g_warn_if_fail (!meta_device_file_has_tag (device_file,
META_DEVICE_FILE_TAG_KMS,
META_KMS_DEVICE_FILE_TAG_ATOMIC));
if (drmSetClientCap (fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1) != 0)
{
g_set_error (error, META_KMS_ERROR, META_KMS_ERROR_NOT_SUPPORTED,
"DRM_CLIENT_CAP_UNIVERSAL_PLANES not supported");
return NULL;
}
meta_device_file_tag (device_file,
META_DEVICE_FILE_TAG_KMS,
META_KMS_DEVICE_FILE_TAG_SIMPLE);
kms/impl-device: Set universal plane client cap when opening file This means it will be set again if the file is reopened. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
2021-04-11 06:15:23 -04:00
}
return g_steal_pointer (&device_file);
kms: Have the device impl open device files themself 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>
2021-04-06 06:14:24 -04:00
}
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>
2020-07-17 03:38:11 -04:00
static gboolean
meta_kms_impl_device_simple_initable_init (GInitable *initable,
GCancellable *cancellable,
GError **error)
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-02-21 06:06:28 -05:00
{
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>
2020-07-17 03:38:11 -04:00
MetaKmsImplDeviceSimple *impl_device_simple =
META_KMS_IMPL_DEVICE_SIMPLE (initable);
MetaKmsImplDevice *impl_device = META_KMS_IMPL_DEVICE (impl_device_simple);
MetaKmsDevice *device = meta_kms_impl_device_get_device (impl_device);
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-02-21 06:06:28 -05:00
GList *l;
kms: Have the device impl open device files themself 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>
2021-04-06 06:14:24 -04:00
if (!initable_parent_iface->init (initable, cancellable, error))
return FALSE;
kms/impl-device: Make non-abstract types explicitly init mode setting This is a step towards making it possible to add a MetaKmsImplDevice that doesn't actually do any mode setting. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-18 12:27:07 -05:00
if (!meta_kms_impl_device_init_mode_setting (impl_device, error))
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>
2020-07-17 03:38:11 -04:00
return FALSE;
impl_device_simple->cached_mode_sets =
g_hash_table_new_full (NULL,
NULL,
NULL,
(GDestroyNotify) cached_mode_set_free);
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-02-21 06:06:28 -05:00
for (l = meta_kms_device_get_crtcs (device); l; l = l->next)
{
MetaKmsCrtc *crtc = l->data;
MetaKmsPlane *plane;
plane = meta_kms_device_get_cursor_plane_for (device, crtc);
if (plane)
continue;
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>
2020-10-02 12:37:18 -04:00
meta_topic (META_DEBUG_KMS,
"[simple] Adding fake cursor plane for CRTC %u (%s)",
meta_kms_crtc_get_id (crtc),
meta_kms_impl_device_get_path (impl_device));
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-02-21 06:06:28 -05:00
meta_kms_device_add_fake_plane_in_impl (device,
META_KMS_PLANE_TYPE_CURSOR,
crtc);
}
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>
2020-07-17 03:38:11 -04:00
kms: Have the device impl open device files themself 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>
2021-04-06 06:14:24 -04:00
g_message ("Added device '%s' (%s) using non-atomic mode setting.",
meta_kms_impl_device_get_path (impl_device),
meta_kms_impl_device_get_driver_name (impl_device));
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>
2020-07-17 03:38:11 -04:00
return TRUE;
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-02-21 06:06:28 -05:00
}
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
static void
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>
2020-07-17 03:38:11 -04:00
meta_kms_impl_device_simple_init (MetaKmsImplDeviceSimple *impl_device_simple)
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
{
}
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
static void
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>
2020-07-17 03:38:11 -04:00
initable_iface_init (GInitableIface *iface)
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
{
kms: Have the device impl open device files themself 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>
2021-04-06 06:14:24 -04:00
initable_parent_iface = g_type_interface_peek_parent (iface);
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>
2020-07-17 03:38:11 -04:00
iface->init = meta_kms_impl_device_simple_initable_init;
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
}
static void
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>
2020-07-17 03:38:11 -04:00
meta_kms_impl_device_simple_class_init (MetaKmsImplDeviceSimpleClass *klass)
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
{
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
GObjectClass *object_class = G_OBJECT_CLASS (klass);
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>
2020-07-17 03:38:11 -04:00
MetaKmsImplDeviceClass *impl_device_class =
META_KMS_IMPL_DEVICE_CLASS (klass);
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: 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>
2020-07-17 03:38:11 -04:00
object_class->finalize = meta_kms_impl_device_simple_finalize;
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: Have the device impl open device files themself 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>
2021-04-06 06:14:24 -04:00
impl_device_class->open_device_file =
meta_kms_impl_device_simple_open_device_file;
kms/impl-device: Make the actual implementation handle the drm event The way drm events are handled depends on whether we're using atomic or not. Lets move the handling to the implementation, so that later the atomic backend can handle the event they it need to. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 10:56:10 -04:00
impl_device_class->setup_drm_event_context =
meta_kms_impl_device_simple_setup_drm_event_context;
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>
2020-07-17 03:38:11 -04:00
impl_device_class->process_update =
meta_kms_impl_device_simple_process_update;
impl_device_class->handle_page_flip_callback =
meta_kms_impl_device_simple_handle_page_flip_callback;
impl_device_class->discard_pending_page_flips =
meta_kms_impl_device_simple_discard_pending_page_flips;
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
impl_device_class->prepare_shutdown =
meta_kms_impl_device_simple_prepare_shutdown;
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
}
Reference in New Issue Copy Permalink