brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
mutter/src/backends/native/meta-kms-update.c

1118 lines
32 KiB
C
Raw Normal View History

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 22:36:41 +02:00
/*
* Copyright (C) 2018 Red Hat
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
Update license access method Dropped obsolete Free Software Foundation address pointing to the FSF website instead as suggested by https://www.gnu.org/licenses/gpl-howto.html keeping intact the important part of the historical notice as requested by the license. Resolving rpmlint reported issue E: incorrect-fsf-address. Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com> Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3155>
2023-08-07 11:50:23 +02:00
* along with this program; if not, see <http://www.gnu.org/licenses/>.
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 22:36:41 +02:00
*/
#include "config.h"
#include "backends/native/meta-kms-update.h"
#include "backends/native/meta-kms-update-private.h"
#include "backends/meta-display-config-shared.h"
kms/update: Make each MetaKmsUpdate update a single device For now feedbacks from an update are combined, meaning we might lose error information. The feedback API may have to be reconsidered and redesigned when planes gets a more front seat position. This means we need to avoid trying to post updates if we're in power save mode, as it may be empty. Note that this is an intermediate state during refactoring that aims to introduce atomic mode setting support, and we'll stop combining feedbacks completely in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-16 23:38:10 +02:00
#include "backends/native/meta-kms-connector.h"
kms/update: Fix a couple of style issues Include macro order was incorrect, and a line was incorrectly indented. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-17 09:39:32 +02:00
#include "backends/native/meta-kms-crtc.h"
kms/impl-device: Move fd hold to update when processing This will let us move the update ownership to the backend, allowing it to handle it with less restrictions. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
2022-06-22 00:23:03 +02:00
#include "backends/native/meta-kms-impl-device.h"
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 15:58:59 +02:00
#include "backends/native/meta-kms-mode-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 22:36:41 +02:00
#include "backends/native/meta-kms-plane.h"
kms/result-listener: Let listeners own a feedback ref Dispatch results via a helper, and let each result hold a reference to the feedback. This allows for more asynchronous feedback management. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2023-02-14 20:15:51 +01:00
#include "backends/native/meta-kms-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 22:36:41 +02:00
struct _MetaKmsUpdate
{
kms/update: Make each MetaKmsUpdate update a single device For now feedbacks from an update are combined, meaning we might lose error information. The feedback API may have to be reconsidered and redesigned when planes gets a more front seat position. This means we need to avoid trying to post updates if we're in power save mode, as it may be empty. Note that this is an intermediate state during refactoring that aims to introduce atomic mode setting support, and we'll stop combining feedbacks completely in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-16 23:38:10 +02:00
MetaKmsDevice *device;
kms/update: Change lock() to seal() At first it was called seal(), but then updates could be amended after being posted, given a flag. That flag has been removed, so we can go back to sealing, since it's once again acts more as a seal. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2022-06-13 22:43:57 +02:00
gboolean is_sealed;
kms-update: Seal updates when posting them This makes sure that we won't accidentally change KMS transaction updates after they have been posted. https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-19 22:15:12 +02:00
kms/impl-device: Add deadline based KMS commit scheduling This makes it possible to post KMS updates that will always defer until just before the scanout deadline. This is useful to allow queuing cursor updates where we don't want to post them to KMS immediately, but rather wait until as late as possible to get lower latency. We cannot delay primary plane compositions however, and this is due to how the kernel may prioritize GPU work - not until a pipeline gets attached to a atomic commit will it in some drivers get bumped to high priority. This means we still need to post any update that depends on OpenGL pipelines as soon as possible. To avoid working on compositing, then getting stomped on the feet by the deadline scheduler, the deadline timer is disarmed whenever there is a frame currently being painted. This will still allow new cursor updates to arrive during composition, but will delay the actual KMS commit until the primary plane update has been posted. Still, even for cursor-only we still need higher than default timing capabilities, thus the deadline scheduler depends on the KMS thread getting real-time scheduling priority. When the thread isn't realtime scheduled, the KMS thread instead asks the main thread to "flush" the commit as part of the regular frame update. A flushing update means one that isn't set to always defer and has a latching CRTC. The verbose KMS debug logging makes the processing take too long, making us more likely to miss the deadline. Avoid this by increasing the evasion length when debug logging is enabled. Not the best, but better than changing the behavior completely. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-10-26 19:08:30 +02:00
gboolean is_latchable;
MetaKmsCrtc *latch_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 22:36:41 +02:00
GList *mode_sets;
GList *plane_assignments;
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 16:48:47 +02:00
GList *connector_updates;
backends/native: Rename crtc_gamma to crtc_color_updates We need to update more CRTC color pipeline properties in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-17 23:18:39 +01:00
GList *crtc_color_updates;
kms/update: Make custom page flip be per update Custom page flips are meant to allow using e.g. EGLStream API to indirectly trigger page flip queueing, when the KMS API cannot be used directly. This is really something that is specific to a device, so instead of making part of the page flip API, make it a configuration of the update itself. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-01 18:28:13 +02: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 11:31:18 +01:00
MetaKmsCustomPageFlip *custom_page_flip;
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 16:06:35 +02:00
GList *page_flip_listeners;
kms/update: Add way to receive result from later posted update Something might want to affect the next update that is going to be posted, but without posting it immediately. For example, changing the cursor might need to wait for mode setting. Make it possible to get feedback from posting the update, in order to gracefully handle any errors. Note, the API for notifiying about results take out the result listener from the update, and notifies them in an open coded for loop. The reason for this is that in the next commit we'll sometimes reuse updates, and we only want notify about the results once. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:35:42 +02:00
GList *result_listeners;
kms/impl-device: Move fd hold to update when processing This will let us move the update ownership to the backend, allowing it to handle it with less restrictions. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
2022-06-22 00:23:03 +02:00
backends/native: Let updates require ALLOW_MODESET Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
2023-03-02 01:59:41 +01:00
gboolean needs_modeset;
kms/impl-device: Move fd hold to update when processing This will let us move the update ownership to the backend, allowing it to handle it with less restrictions. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
2022-06-22 00:23:03 +02:00
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 22:36:41 +02: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-09 00:17:33 +01:00
void
meta_kms_plane_feedback_free (MetaKmsPlaneFeedback *plane_feedback)
{
g_error_free (plane_feedback->error);
g_free (plane_feedback);
}
MetaKmsPlaneFeedback *
meta_kms_plane_feedback_new_take_error (MetaKmsPlane *plane,
MetaKmsCrtc *crtc,
GError *error)
{
MetaKmsPlaneFeedback *plane_feedback;
plane_feedback = g_new0 (MetaKmsPlaneFeedback, 1);
*plane_feedback = (MetaKmsPlaneFeedback) {
.plane = plane,
.crtc = crtc,
.error = error,
};
return plane_feedback;
}
kms: Add update test API This API can be used to construct a MetaKmsUpdate with plane assignments that in isolation will be tested against the current KMS state. How it is tested depends on the KMS implementation; in the simple / legacy KMS backend, the tests are identical to the current scanout requirements (dimension, stride, format, modifiers, all must match), and with atomic KMS, it uses the TEST_ONLY on a real constructed atomic mode setting commit. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2146>
2021-12-08 21:20:52 +01:00
MetaKmsPlaneFeedback *
meta_kms_plane_feedback_new_failed (MetaKmsPlane *plane,
MetaKmsCrtc *crtc,
const char *error_message)
{
GError *error;
error = g_error_new_literal (G_IO_ERROR, G_IO_ERROR_FAILED, error_message);
return meta_kms_plane_feedback_new_take_error (plane, crtc, error);
}
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-09 00:14:36 +01:00
MetaKmsFeedback *
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 15:45:28 +02:00
meta_kms_feedback_new_passed (GList *failed_planes)
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-09 00:14:36 +01:00
{
MetaKmsFeedback *feedback;
feedback = g_new0 (MetaKmsFeedback, 1);
*feedback = (MetaKmsFeedback) {
.result = META_KMS_FEEDBACK_PASSED,
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 15:45:28 +02:00
.failed_planes = failed_planes,
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-09 00:14:36 +01:00
};
kms: Make KMS feedback struct ref counted It'll later be sent asynchronously; to prepare for that make it ref counted with an atomic ref counter. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2022-01-10 17:01:41 +01:00
g_atomic_ref_count_init (&feedback->ref_count);
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-09 00:14:36 +01:00
return feedback;
}
MetaKmsFeedback *
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-09 00:17:33 +01:00
meta_kms_feedback_new_failed (GList *failed_planes,
GError *error)
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-09 00:14:36 +01:00
{
MetaKmsFeedback *feedback;
feedback = g_new0 (MetaKmsFeedback, 1);
*feedback = (MetaKmsFeedback) {
.result = META_KMS_FEEDBACK_FAILED,
.error = 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-09 00:17:33 +01:00
.failed_planes = failed_planes,
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-09 00:14:36 +01:00
};
kms: Make KMS feedback struct ref counted It'll later be sent asynchronously; to prepare for that make it ref counted with an atomic ref counter. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2022-01-10 17:01:41 +01:00
g_atomic_ref_count_init (&feedback->ref_count);
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-09 00:14:36 +01:00
return feedback;
}
kms: Make KMS feedback struct ref counted It'll later be sent asynchronously; to prepare for that make it ref counted with an atomic ref counter. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2022-01-10 17:01:41 +01:00
MetaKmsFeedback *
meta_kms_feedback_ref (MetaKmsFeedback *feedback)
{
g_atomic_ref_count_inc (&feedback->ref_count);
return feedback;
}
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-09 00:14:36 +01:00
void
kms: Make KMS feedback struct ref counted It'll later be sent asynchronously; to prepare for that make it ref counted with an atomic ref counter. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2022-01-10 17:01:41 +01:00
meta_kms_feedback_unref (MetaKmsFeedback *feedback)
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-09 00:14:36 +01:00
{
kms: Make KMS feedback struct ref counted It'll later be sent asynchronously; to prepare for that make it ref counted with an atomic ref counter. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2022-01-10 17:01:41 +01:00
if (g_atomic_ref_count_dec (&feedback->ref_count))
{
g_list_free_full (feedback->failed_planes,
(GDestroyNotify) meta_kms_plane_feedback_free);
g_clear_error (&feedback->error);
g_free (feedback);
}
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-09 00:14:36 +01:00
}
MetaKmsFeedbackResult
kms/feedback: Make getter take consts This will be necessary later, as places that wants to use them will only have the const variants of the feedback pointers. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-07 11:04:35 +01:00
meta_kms_feedback_get_result (const MetaKmsFeedback *feedback)
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-09 00:14:36 +01:00
{
return feedback->result;
}
kms/update: Add helper to checking if an update passed Instead of comparing values, just add a `did_pass()` helper. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2023-05-05 16:37:34 +02:00
gboolean
meta_kms_feedback_did_pass (const MetaKmsFeedback *feedback)
{
return feedback->result == META_KMS_FEEDBACK_PASSED;
}
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-09 00:17:33 +01:00
GList *
kms/feedback: Make getter take consts This will be necessary later, as places that wants to use them will only have the const variants of the feedback pointers. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-07 11:04:35 +01:00
meta_kms_feedback_get_failed_planes (const MetaKmsFeedback *feedback)
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-09 00:17:33 +01:00
{
return feedback->failed_planes;
}
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-09 00:14:36 +01:00
const GError *
kms/feedback: Make getter take consts This will be necessary later, as places that wants to use them will only have the const variants of the feedback pointers. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2021-01-07 11:04:35 +01:00
meta_kms_feedback_get_error (const MetaKmsFeedback *feedback)
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-09 00:14:36 +01:00
{
return feedback->error;
}
kms/result-listener: Let listeners own a feedback ref Dispatch results via a helper, and let each result hold a reference to the feedback. This allows for more asynchronous feedback management. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2023-02-14 20:15:51 +01:00
void
meta_kms_feedback_dispatch_result (MetaKmsFeedback *feedback,
MetaKms *kms,
GList *result_listeners)
{
GList *l;
for (l = result_listeners; l; l = l->next)
{
MetaKmsResultListener *listener = l->data;
meta_kms_result_listener_set_feedback (listener, feedback);
meta_kms_queue_result_callback (kms, listener);
}
g_list_free (result_listeners);
}
kms: Allow passing framebuffer damage metadata This commit adds support to atomic KMS backend for optional plane property prop_fb_damage_clips. Some drivers (e.g. EVDI) take advantage of this property and process only updated regions of the screen instead of processing the full frame. This can save system resources. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1879>
2021-09-03 19:39:12 +01:00
static void
meta_kms_fb_damage_free (MetaKmsFbDamage *fb_damage)
{
g_free (fb_damage->rects);
g_free (fb_damage);
}
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 22:36:41 +02:00
static void
meta_kms_plane_assignment_free (MetaKmsPlaneAssignment *plane_assignment)
{
kms: Allow passing framebuffer damage metadata This commit adds support to atomic KMS backend for optional plane property prop_fb_damage_clips. Some drivers (e.g. EVDI) take advantage of this property and process only updated regions of the screen instead of processing the full frame. This can save system resources. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1879>
2021-09-03 19:39:12 +01:00
g_clear_pointer (&plane_assignment->fb_damage, meta_kms_fb_damage_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 22:36:41 +02:00
g_free (plane_assignment);
}
static void
meta_kms_mode_set_free (MetaKmsModeSet *mode_set)
{
g_list_free (mode_set->connectors);
g_free (mode_set);
}
kms/impl-device: Add deadline based KMS commit scheduling This makes it possible to post KMS updates that will always defer until just before the scanout deadline. This is useful to allow queuing cursor updates where we don't want to post them to KMS immediately, but rather wait until as late as possible to get lower latency. We cannot delay primary plane compositions however, and this is due to how the kernel may prioritize GPU work - not until a pipeline gets attached to a atomic commit will it in some drivers get bumped to high priority. This means we still need to post any update that depends on OpenGL pipelines as soon as possible. To avoid working on compositing, then getting stomped on the feet by the deadline scheduler, the deadline timer is disarmed whenever there is a frame currently being painted. This will still allow new cursor updates to arrive during composition, but will delay the actual KMS commit until the primary plane update has been posted. Still, even for cursor-only we still need higher than default timing capabilities, thus the deadline scheduler depends on the KMS thread getting real-time scheduling priority. When the thread isn't realtime scheduled, the KMS thread instead asks the main thread to "flush" the commit as part of the regular frame update. A flushing update means one that isn't set to always defer and has a latching CRTC. The verbose KMS debug logging makes the processing take too long, making us more likely to miss the deadline. Avoid this by increasing the evasion length when debug logging is enabled. Not the best, but better than changing the behavior completely. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-10-26 19:08:30 +02:00
void
kms/page-flip-listener: Make object reference counted The _ref() variant will be added later, when it gets a user, to avoid a unused compiler warning. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2022-06-05 21:16:11 +02:00
meta_kms_page_flip_listener_unref (MetaKmsPageFlipListener *listener)
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 08:41:14 +01:00
{
kms/update: Use callback helper to free page flip listener data Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-12-21 18:51:05 +01:00
MetaKmsDevice *device;
kms/page-flip-listener: Make object reference counted The _ref() variant will be added later, when it gets a user, to avoid a unused compiler warning. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2022-06-05 21:16:11 +02:00
if (!g_atomic_ref_count_dec (&listener->ref_count))
return;
kms/update: Use callback helper to free page flip listener data Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-12-21 18:51:05 +01:00
device = meta_kms_crtc_get_device (listener->crtc);
meta_kms_queue_callback (meta_kms_device_get_kms (device),
listener->main_context,
NULL,
g_steal_pointer (&listener->user_data),
g_steal_pointer (&listener->destroy_notify));
g_free (listener);
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 08:41:14 +01:00
}
kms/update: If reassigning a plane handle the fb changed flag If we reassign e.g. a cursor plane twice before it's updated, we need to make sure the 'fb-unchanged' flag is correctly handled, so that if we changed the fb first, then updated the assignment again only changing the position, the new assignment should not be flagged with fb-unchanged. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:53:16 +02:00
static gboolean
drop_plane_assignment (MetaKmsUpdate *update,
MetaKmsPlane *plane,
MetaKmsAssignPlaneFlag *out_flags)
kms: Add way to preserve failed update When we e.g. try to post an direct client buffer scanout update, it might arbitrarily fail; when this happen we still will want to post the rest of the update when we try again after having composited the primary plane. To do this, add a way to preserve the metadata of an update if it failed, only dropping the failed plane assignments. This involves unlocking a previously locked MetaKmsUpdate, so that e.g. a new primary plane can be assigned. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:48:34 +02:00
{
GList *l;
for (l = update->plane_assignments; l; l = l->next)
{
MetaKmsPlaneAssignment *plane_assignment = l->data;
if (plane_assignment->plane == plane)
{
update->plane_assignments =
g_list_delete_link (update->plane_assignments, l);
kms/update: If reassigning a plane handle the fb changed flag If we reassign e.g. a cursor plane twice before it's updated, we need to make sure the 'fb-unchanged' flag is correctly handled, so that if we changed the fb first, then updated the assignment again only changing the position, the new assignment should not be flagged with fb-unchanged. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:53:16 +02:00
if (out_flags)
*out_flags = plane_assignment->flags;
kms: Add way to preserve failed update When we e.g. try to post an direct client buffer scanout update, it might arbitrarily fail; when this happen we still will want to post the rest of the update when we try again after having composited the primary plane. To do this, add a way to preserve the metadata of an update if it failed, only dropping the failed plane assignments. This involves unlocking a previously locked MetaKmsUpdate, so that e.g. a new primary plane can be assigned. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:48:34 +02:00
meta_kms_plane_assignment_free (plane_assignment);
kms/update: If reassigning a plane handle the fb changed flag If we reassign e.g. a cursor plane twice before it's updated, we need to make sure the 'fb-unchanged' flag is correctly handled, so that if we changed the fb first, then updated the assignment again only changing the position, the new assignment should not be flagged with fb-unchanged. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:53:16 +02:00
return TRUE;
kms: Add way to preserve failed update When we e.g. try to post an direct client buffer scanout update, it might arbitrarily fail; when this happen we still will want to post the rest of the update when we try again after having composited the primary plane. To do this, add a way to preserve the metadata of an update if it failed, only dropping the failed plane assignments. This involves unlocking a previously locked MetaKmsUpdate, so that e.g. a new primary plane can be assigned. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:48:34 +02:00
}
}
kms/update: If reassigning a plane handle the fb changed flag If we reassign e.g. a cursor plane twice before it's updated, we need to make sure the 'fb-unchanged' flag is correctly handled, so that if we changed the fb first, then updated the assignment again only changing the position, the new assignment should not be flagged with fb-unchanged. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:53:16 +02:00
return FALSE;
}
kms/impl-device: Add deadline based KMS commit scheduling This makes it possible to post KMS updates that will always defer until just before the scanout deadline. This is useful to allow queuing cursor updates where we don't want to post them to KMS immediately, but rather wait until as late as possible to get lower latency. We cannot delay primary plane compositions however, and this is due to how the kernel may prioritize GPU work - not until a pipeline gets attached to a atomic commit will it in some drivers get bumped to high priority. This means we still need to post any update that depends on OpenGL pipelines as soon as possible. To avoid working on compositing, then getting stomped on the feet by the deadline scheduler, the deadline timer is disarmed whenever there is a frame currently being painted. This will still allow new cursor updates to arrive during composition, but will delay the actual KMS commit until the primary plane update has been posted. Still, even for cursor-only we still need higher than default timing capabilities, thus the deadline scheduler depends on the KMS thread getting real-time scheduling priority. When the thread isn't realtime scheduled, the KMS thread instead asks the main thread to "flush" the commit as part of the regular frame update. A flushing update means one that isn't set to always defer and has a latching CRTC. The verbose KMS debug logging makes the processing take too long, making us more likely to miss the deadline. Avoid this by increasing the evasion length when debug logging is enabled. Not the best, but better than changing the behavior completely. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-10-26 19:08:30 +02:00
static void
update_latch_crtc (MetaKmsUpdate *update,
MetaKmsCrtc *crtc)
{
if (update->is_latchable)
{
if (update->latch_crtc)
{
if (update->latch_crtc != crtc)
{
update->is_latchable = FALSE;
update->latch_crtc = NULL;
}
}
else
{
update->latch_crtc = 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 22:36:41 +02:00
MetaKmsPlaneAssignment *
kms/update: Add flags to plane assignment Currently unused, but will used to let the implementation know when it can avoid setting the plane content (i.e. not call drmModeSetCursor()). https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 23:54:43 +01:00
meta_kms_update_assign_plane (MetaKmsUpdate *update,
MetaKmsCrtc *crtc,
MetaKmsPlane *plane,
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 19:32:46 +02:00
MetaDrmBuffer *buffer,
kms/update: Add flags to plane assignment Currently unused, but will used to let the implementation know when it can avoid setting the plane content (i.e. not call drmModeSetCursor()). https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 23:54:43 +01:00
MetaFixed16Rectangle src_rect,
mutter: Completely replace MetaRectangle with MtkRectangle There are still various helpers that might be worth to move to mtk as well Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3128>
2023-07-20 01:46:15 +02:00
MtkRectangle dst_rect,
kms/update: Add flags to plane assignment Currently unused, but will used to let the implementation know when it can avoid setting the plane content (i.e. not call drmModeSetCursor()). https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 23:54:43 +01:00
MetaKmsAssignPlaneFlag flags)
backend/native: Add and use transactional KMS API This commit introduces, and makes use of, a transactional API used for setting up KMS state, later to be applied, potentially atomically. From an API point of view, so is always the case, but in the current implementation, it still uses legacy drmMode* API to apply the state non-atomically. The API consists of various buliding blocks: * MetaKmsUpdate - a set of configuration changes, the higher level handle for handing over configuration to the impl backend. It's used to set mode, assign framebuffers to planes, queue page flips and set connector properties. * MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane. Currently used to map a framebuffer to the primary plane of a CRTC. In the legacy KMS implementation, the plane assignment is used to derive the framebuffer used for mode setting and page flipping. This also means various high level changes: State, excluding configuring the cursor plane and creating/destroying DRM framebuffer handles, are applied in the end of a clutter frame, in one go. From an API point of view, this is done atomically, but as mentioned, only the non-atomic implementation exists so far. From MetaRendererNative's point of view, a page flip now initially always succeeds; the handling of EBUSY errors are done asynchronously in the MetaKmsImpl backend (still by retrying at refresh rate, but postponing flip callbacks instead of manipulating the frame clock). Handling of falling back to mode setting instead of page flipping is notified after the fact by a more precise page flip feedback API. EGLStream based page flipping relies on the impl backend not being atomic, as the page flipping is done in the EGLStream backend (e.g. nvidia driver). It uses a 'custom' page flip queueing method, keeping the EGLStream logic inside meta-renderer-native.c. Page flip handling is moved to meta-kms-impl-device.c from meta-gpu-kms.c. It goes via an extra idle callback before reaching meta-renderer-native.c to make sure callbacks are invoked outside of the impl context. While dummy power save page flipping is kept in meta-renderer-native.c, the EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the frame clock, actual page flip callbacks are postponed until all EBUSY retries have either succeeded or failed due to some other error than EBUSY. This effectively inhibits new frames to be drawn, meaning we won't stall waiting on the file descriptor for pending page flips. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-04-04 22:36:41 +02:00
{
MetaKmsPlaneAssignment *plane_assignment;
kms/update: If reassigning a plane handle the fb changed flag If we reassign e.g. a cursor plane twice before it's updated, we need to make sure the 'fb-unchanged' flag is correctly handled, so that if we changed the fb first, then updated the assignment again only changing the position, the new assignment should not be flagged with fb-unchanged. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:53:16 +02:00
MetaKmsAssignPlaneFlag old_flags;
backend/native: Add and use transactional KMS API This commit introduces, and makes use of, a transactional API used for setting up KMS state, later to be applied, potentially atomically. From an API point of view, so is always the case, but in the current implementation, it still uses legacy drmMode* API to apply the state non-atomically. The API consists of various buliding blocks: * MetaKmsUpdate - a set of configuration changes, the higher level handle for handing over configuration to the impl backend. It's used to set mode, assign framebuffers to planes, queue page flips and set connector properties. * MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane. Currently used to map a framebuffer to the primary plane of a CRTC. In the legacy KMS implementation, the plane assignment is used to derive the framebuffer used for mode setting and page flipping. This also means various high level changes: State, excluding configuring the cursor plane and creating/destroying DRM framebuffer handles, are applied in the end of a clutter frame, in one go. From an API point of view, this is done atomically, but as mentioned, only the non-atomic implementation exists so far. From MetaRendererNative's point of view, a page flip now initially always succeeds; the handling of EBUSY errors are done asynchronously in the MetaKmsImpl backend (still by retrying at refresh rate, but postponing flip callbacks instead of manipulating the frame clock). Handling of falling back to mode setting instead of page flipping is notified after the fact by a more precise page flip feedback API. EGLStream based page flipping relies on the impl backend not being atomic, as the page flipping is done in the EGLStream backend (e.g. nvidia driver). It uses a 'custom' page flip queueing method, keeping the EGLStream logic inside meta-renderer-native.c. Page flip handling is moved to meta-kms-impl-device.c from meta-gpu-kms.c. It goes via an extra idle callback before reaching meta-renderer-native.c to make sure callbacks are invoked outside of the impl context. While dummy power save page flipping is kept in meta-renderer-native.c, the EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the frame clock, actual page flip callbacks are postponed until all EBUSY retries have either succeeded or failed due to some other error than EBUSY. This effectively inhibits new frames to be drawn, meaning we won't stall waiting on the file descriptor for pending page flips. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-04-04 22:36:41 +02:00
kms/update: Make each MetaKmsUpdate update a single device For now feedbacks from an update are combined, meaning we might lose error information. The feedback API may have to be reconsidered and redesigned when planes gets a more front seat position. This means we need to avoid trying to post updates if we're in power save mode, as it may be empty. Note that this is an intermediate state during refactoring that aims to introduce atomic mode setting support, and we'll stop combining feedbacks completely in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-16 23:38:10 +02:00
g_assert (meta_kms_crtc_get_device (crtc) == update->device);
g_assert (meta_kms_plane_get_device (plane) == update->device);
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 15:45:28 +02:00
g_assert (meta_kms_plane_get_plane_type (plane) !=
META_KMS_PLANE_TYPE_PRIMARY ||
!(flags & META_KMS_ASSIGN_PLANE_FLAG_ALLOW_FAIL));
kms-update: Seal updates when posting them This makes sure that we won't accidentally change KMS transaction updates after they have been posted. https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-19 22:15:12 +02:00
kms/update: If reassigning a plane handle the fb changed flag If we reassign e.g. a cursor plane twice before it's updated, we need to make sure the 'fb-unchanged' flag is correctly handled, so that if we changed the fb first, then updated the assignment again only changing the position, the new assignment should not be flagged with fb-unchanged. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:53:16 +02:00
if (drop_plane_assignment (update, plane, &old_flags))
{
if (!(old_flags & META_KMS_ASSIGN_PLANE_FLAG_FB_UNCHANGED))
flags &= ~META_KMS_ASSIGN_PLANE_FLAG_FB_UNCHANGED;
}
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 22:36:41 +02:00
plane_assignment = g_new0 (MetaKmsPlaneAssignment, 1);
*plane_assignment = (MetaKmsPlaneAssignment) {
kms-update: Seal updates when posting them This makes sure that we won't accidentally change KMS transaction updates after they have been posted. https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-19 22:15:12 +02:00
.update = update,
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 22:36:41 +02:00
.crtc = crtc,
.plane = plane,
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 19:32:46 +02:00
.buffer = 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 22:36:41 +02:00
.src_rect = src_rect,
.dst_rect = dst_rect,
kms/update: Add flags to plane assignment Currently unused, but will used to let the implementation know when it can avoid setting the plane content (i.e. not call drmModeSetCursor()). https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 23:54:43 +01:00
.flags = flags,
backend/native: Add and use transactional KMS API This commit introduces, and makes use of, a transactional API used for setting up KMS state, later to be applied, potentially atomically. From an API point of view, so is always the case, but in the current implementation, it still uses legacy drmMode* API to apply the state non-atomically. The API consists of various buliding blocks: * MetaKmsUpdate - a set of configuration changes, the higher level handle for handing over configuration to the impl backend. It's used to set mode, assign framebuffers to planes, queue page flips and set connector properties. * MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane. Currently used to map a framebuffer to the primary plane of a CRTC. In the legacy KMS implementation, the plane assignment is used to derive the framebuffer used for mode setting and page flipping. This also means various high level changes: State, excluding configuring the cursor plane and creating/destroying DRM framebuffer handles, are applied in the end of a clutter frame, in one go. From an API point of view, this is done atomically, but as mentioned, only the non-atomic implementation exists so far. From MetaRendererNative's point of view, a page flip now initially always succeeds; the handling of EBUSY errors are done asynchronously in the MetaKmsImpl backend (still by retrying at refresh rate, but postponing flip callbacks instead of manipulating the frame clock). Handling of falling back to mode setting instead of page flipping is notified after the fact by a more precise page flip feedback API. EGLStream based page flipping relies on the impl backend not being atomic, as the page flipping is done in the EGLStream backend (e.g. nvidia driver). It uses a 'custom' page flip queueing method, keeping the EGLStream logic inside meta-renderer-native.c. Page flip handling is moved to meta-kms-impl-device.c from meta-gpu-kms.c. It goes via an extra idle callback before reaching meta-renderer-native.c to make sure callbacks are invoked outside of the impl context. While dummy power save page flipping is kept in meta-renderer-native.c, the EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the frame clock, actual page flip callbacks are postponed until all EBUSY retries have either succeeded or failed due to some other error than EBUSY. This effectively inhibits new frames to be drawn, meaning we won't stall waiting on the file descriptor for pending page flips. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-04-04 22:36:41 +02:00
};
update->plane_assignments = g_list_prepend (update->plane_assignments,
plane_assignment);
kms/impl-device: Add deadline based KMS commit scheduling This makes it possible to post KMS updates that will always defer until just before the scanout deadline. This is useful to allow queuing cursor updates where we don't want to post them to KMS immediately, but rather wait until as late as possible to get lower latency. We cannot delay primary plane compositions however, and this is due to how the kernel may prioritize GPU work - not until a pipeline gets attached to a atomic commit will it in some drivers get bumped to high priority. This means we still need to post any update that depends on OpenGL pipelines as soon as possible. To avoid working on compositing, then getting stomped on the feet by the deadline scheduler, the deadline timer is disarmed whenever there is a frame currently being painted. This will still allow new cursor updates to arrive during composition, but will delay the actual KMS commit until the primary plane update has been posted. Still, even for cursor-only we still need higher than default timing capabilities, thus the deadline scheduler depends on the KMS thread getting real-time scheduling priority. When the thread isn't realtime scheduled, the KMS thread instead asks the main thread to "flush" the commit as part of the regular frame update. A flushing update means one that isn't set to always defer and has a latching CRTC. The verbose KMS debug logging makes the processing take too long, making us more likely to miss the deadline. Avoid this by increasing the evasion length when debug logging is enabled. Not the best, but better than changing the behavior completely. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-10-26 19:08:30 +02:00
update_latch_crtc (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 22:36:41 +02:00
return plane_assignment;
}
kms/update: Add unassign_plane() API Meant to disable a plane. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-01 15:23:19 +01:00
MetaKmsPlaneAssignment *
meta_kms_update_unassign_plane (MetaKmsUpdate *update,
MetaKmsCrtc *crtc,
MetaKmsPlane *plane)
{
MetaKmsPlaneAssignment *plane_assignment;
kms/update: Make each MetaKmsUpdate update a single device For now feedbacks from an update are combined, meaning we might lose error information. The feedback API may have to be reconsidered and redesigned when planes gets a more front seat position. This means we need to avoid trying to post updates if we're in power save mode, as it may be empty. Note that this is an intermediate state during refactoring that aims to introduce atomic mode setting support, and we'll stop combining feedbacks completely in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-16 23:38:10 +02:00
g_assert (meta_kms_crtc_get_device (crtc) == update->device);
g_assert (meta_kms_plane_get_device (plane) == update->device);
kms/update: Add unassign_plane() API Meant to disable a plane. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-01 15:23:19 +01:00
kms: Avoid queuing multiple (un)assignments to the same plane in an update Just like we already do in `meta_kms_update_assign_plane`. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2620>
2022-09-08 16:45:29 +08:00
drop_plane_assignment (update, plane, NULL);
kms/update: Add unassign_plane() API Meant to disable a plane. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-01 15:23:19 +01:00
plane_assignment = g_new0 (MetaKmsPlaneAssignment, 1);
*plane_assignment = (MetaKmsPlaneAssignment) {
.update = update,
.crtc = crtc,
.plane = plane,
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 19:32:46 +02:00
.buffer = NULL,
kms/update: Add unassign_plane() API Meant to disable a plane. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-01 15:23:19 +01:00
};
update->plane_assignments = g_list_prepend (update->plane_assignments,
plane_assignment);
kms/impl-device: Add deadline based KMS commit scheduling This makes it possible to post KMS updates that will always defer until just before the scanout deadline. This is useful to allow queuing cursor updates where we don't want to post them to KMS immediately, but rather wait until as late as possible to get lower latency. We cannot delay primary plane compositions however, and this is due to how the kernel may prioritize GPU work - not until a pipeline gets attached to a atomic commit will it in some drivers get bumped to high priority. This means we still need to post any update that depends on OpenGL pipelines as soon as possible. To avoid working on compositing, then getting stomped on the feet by the deadline scheduler, the deadline timer is disarmed whenever there is a frame currently being painted. This will still allow new cursor updates to arrive during composition, but will delay the actual KMS commit until the primary plane update has been posted. Still, even for cursor-only we still need higher than default timing capabilities, thus the deadline scheduler depends on the KMS thread getting real-time scheduling priority. When the thread isn't realtime scheduled, the KMS thread instead asks the main thread to "flush" the commit as part of the regular frame update. A flushing update means one that isn't set to always defer and has a latching CRTC. The verbose KMS debug logging makes the processing take too long, making us more likely to miss the deadline. Avoid this by increasing the evasion length when debug logging is enabled. Not the best, but better than changing the behavior completely. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-10-26 19:08:30 +02:00
update_latch_crtc (update, crtc);
kms/update: Add unassign_plane() API Meant to disable a plane. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-01 15:23:19 +01:00
return plane_assignment;
}
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 22:36:41 +02:00
void
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 15:58:59 +02:00
meta_kms_update_mode_set (MetaKmsUpdate *update,
MetaKmsCrtc *crtc,
GList *connectors,
MetaKmsMode *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 22:36:41 +02:00
{
MetaKmsModeSet *mode_set;
kms/update: Make each MetaKmsUpdate update a single device For now feedbacks from an update are combined, meaning we might lose error information. The feedback API may have to be reconsidered and redesigned when planes gets a more front seat position. This means we need to avoid trying to post updates if we're in power save mode, as it may be empty. Note that this is an intermediate state during refactoring that aims to introduce atomic mode setting support, and we'll stop combining feedbacks completely in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-16 23:38:10 +02:00
g_assert (meta_kms_crtc_get_device (crtc) == update->device);
kms-update: Seal updates when posting them This makes sure that we won't accidentally change KMS transaction updates after they have been posted. https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-19 22:15:12 +02: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 22:36:41 +02:00
mode_set = g_new0 (MetaKmsModeSet, 1);
*mode_set = (MetaKmsModeSet) {
.crtc = crtc,
.connectors = 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 15:58:59 +02:00
.mode = 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 22:36:41 +02:00
};
update->mode_sets = g_list_prepend (update->mode_sets, mode_set);
}
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 16:48:47 +02:00
static MetaKmsConnectorUpdate *
ensure_connector_update (MetaKmsUpdate *update,
kms/update: Fix a couple of style issues Include macro order was incorrect, and a line was incorrectly indented. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-17 09:39:32 +02:00
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 16:48:47 +02:00
{
GList *l;
MetaKmsConnectorUpdate *connector_update;
for (l = update->connector_updates; l; l = l->next)
{
connector_update = l->data;
if (connector_update->connector == connector)
return connector_update;
}
connector_update = g_new0 (MetaKmsConnectorUpdate, 1);
connector_update->connector = connector;
update->connector_updates = g_list_prepend (update->connector_updates,
connector_update);
return connector_update;
}
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 22:36:41 +02:00
void
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 16:48:47 +02:00
meta_kms_update_set_underscanning (MetaKmsUpdate *update,
MetaKmsConnector *connector,
uint64_t hborder,
uint64_t vborder)
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 22:36:41 +02: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 16:48:47 +02:00
MetaKmsConnectorUpdate *connector_update;
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 22:36:41 +02:00
kms/update: Make each MetaKmsUpdate update a single device For now feedbacks from an update are combined, meaning we might lose error information. The feedback API may have to be reconsidered and redesigned when planes gets a more front seat position. This means we need to avoid trying to post updates if we're in power save mode, as it may be empty. Note that this is an intermediate state during refactoring that aims to introduce atomic mode setting support, and we'll stop combining feedbacks completely in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-16 23:38:10 +02:00
g_assert (meta_kms_connector_get_device (connector) == update->device);
kms-update: Seal updates when posting them This makes sure that we won't accidentally change KMS transaction updates after they have been posted. https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-19 22:15:12 +02: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 16:48:47 +02:00
connector_update = ensure_connector_update (update, connector);
connector_update->underscanning.has_update = TRUE;
connector_update->underscanning.is_active = TRUE;
connector_update->underscanning.hborder = hborder;
connector_update->underscanning.vborder = vborder;
}
void
meta_kms_update_unset_underscanning (MetaKmsUpdate *update,
MetaKmsConnector *connector)
{
MetaKmsConnectorUpdate *connector_update;
kms/update: Make each MetaKmsUpdate update a single device For now feedbacks from an update are combined, meaning we might lose error information. The feedback API may have to be reconsidered and redesigned when planes gets a more front seat position. This means we need to avoid trying to post updates if we're in power save mode, as it may be empty. Note that this is an intermediate state during refactoring that aims to introduce atomic mode setting support, and we'll stop combining feedbacks completely in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-16 23:38:10 +02:00
g_assert (meta_kms_connector_get_device (connector) == update->device);
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 16:48:47 +02:00
connector_update = ensure_connector_update (update, connector);
connector_update->underscanning.has_update = TRUE;
connector_update->underscanning.is_active = FALSE;
}
backends/kms: Implement privacy screen handling and setting Privacy screen events on connector are handled as notification events that won't cause any monitors reconfiguration but will emit monitors changed on DBus, so that the new value can be fetched. We monitor the hardware state so that we can also handle the case of devices with hw-switchers only. In case a software state is available it means we can also support changing the state, and if so expose the state as unlocked. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
2021-03-22 01:27:39 +01:00
void
meta_kms_update_set_privacy_screen (MetaKmsUpdate *update,
MetaKmsConnector *connector,
gboolean enabled)
{
MetaKmsConnectorUpdate *connector_update;
g_assert (meta_kms_connector_get_device (connector) == update->device);
connector_update = ensure_connector_update (update, connector);
connector_update->privacy_screen.has_update = TRUE;
connector_update->privacy_screen.is_enabled = enabled;
}
kms-update: Add function meta_kms_update_set_max_bpc Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2412>
2022-05-13 16:26:10 +08:00
void
meta_kms_update_set_max_bpc (MetaKmsUpdate *update,
MetaKmsConnector *connector,
uint64_t max_bpc)
{
MetaKmsConnectorUpdate *connector_update;
g_assert (meta_kms_connector_get_device (connector) == update->device);
onscreen/native: Use max bpc support from OutputInfo The max bpc support is already tracked in the OutputInfo, so let's use that instead of querying the KMS Connector directly. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3552>
2024-01-23 20:49:54 +01:00
g_return_if_fail (meta_kms_connector_is_max_bpc_supported (connector,
max_bpc));
kms-update: Add function meta_kms_update_set_max_bpc Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2412>
2022-05-13 16:26:10 +08:00
connector_update = ensure_connector_update (update, connector);
connector_update->max_bpc.value = max_bpc;
connector_update->max_bpc.has_update = TRUE;
}
backends/native: Add color space and HDR metadata updates Allows to prepare KMS updates to set the color space and HDR Static Metadata on the output. For some reason we need ALLOW_MODESET on commits which change the HDR Static Metadata InfoFrame on AMDGPU. There is no technical reason why one needs to mode set to send an InfoFrame and the driver should just manage without ALLOW_MODESET. Until this is resolved in the kernel we just prepare KMS updates which might mode set. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
2023-03-02 02:04:12 +01:00
void
meta_kms_update_set_color_space (MetaKmsUpdate *update,
MetaKmsConnector *connector,
MetaOutputColorspace color_space)
{
MetaKmsConnectorUpdate *connector_update;
g_assert (meta_kms_connector_get_device (connector) == update->device);
connector_update = ensure_connector_update (update, connector);
connector_update->colorspace.has_update = TRUE;
connector_update->colorspace.value = color_space;
}
void
meta_kms_update_set_hdr_metadata (MetaKmsUpdate *update,
MetaKmsConnector *connector,
MetaOutputHdrMetadata *metadata)
{
MetaKmsConnectorUpdate *connector_update;
g_assert (meta_kms_connector_get_device (connector) == update->device);
g_return_if_fail (meta_kms_connector_is_hdr_metadata_supported (connector));
connector_update = ensure_connector_update (update, connector);
connector_update->hdr.has_update = TRUE;
connector_update->hdr.value = *metadata;
/* Currently required on AMDGPU but should in general not require mode sets */
update->needs_modeset = TRUE;
}
kms/connector: Add support for the Broadcast RGB property It can be used to force a specific RGB range. Some monitors don't follow the specification and expect a signal different from what we send. This property allows to force a mode which hopefully then works correctly for the sink. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3535>
2024-01-17 13:22:56 +01:00
void
meta_kms_update_set_broadcast_rgb (MetaKmsUpdate *update,
MetaKmsConnector *connector,
MetaOutputRGBRange rgb_range)
{
MetaKmsConnectorUpdate *connector_update;
g_assert (meta_kms_connector_get_device (connector) == update->device);
g_return_if_fail (meta_kms_connector_is_broadcast_rgb_supported (connector,
rgb_range));
connector_update = ensure_connector_update (update, connector);
connector_update->broadcast_rgb.has_update = TRUE;
connector_update->broadcast_rgb.value = rgb_range;
}
backends/native: Introduce MetaKmsCrtcColorUpdate To store gamma updates. In the future this will grow other CRTC level color pipeline properties. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-17 23:47:04 +01:00
static MetaKmsCrtcColorUpdate *
ensure_color_update (MetaKmsUpdate *update,
MetaKmsCrtc *crtc)
{
GList *l;
MetaKmsCrtcColorUpdate *color_update;
for (l = update->crtc_color_updates; l; l = l->next)
{
color_update = l->data;
if (color_update->crtc == crtc)
return color_update;
}
color_update = g_new0 (MetaKmsCrtcColorUpdate, 1);
color_update->crtc = crtc;
update->crtc_color_updates = g_list_prepend (update->crtc_color_updates,
color_update);
return color_update;
}
kms/crtc: Make MetaKmsCrtcGamma reusable Expose it outside the private realms of MetaKms* so that e.g. MetaMonitorManagerKms can use it too. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-10 11:18:10 +02:00
void
backends/native: Replace MetaKmsCrtcGamma with MetaGammaLut They are the same type now so there is no reason to keep both of them around. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-18 03:13:57 +01:00
meta_kms_update_set_crtc_gamma (MetaKmsUpdate *update,
MetaKmsCrtc *crtc,
const MetaGammaLut *gamma)
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 19:20:21 +02:00
{
backends/native: Introduce MetaKmsCrtcColorUpdate To store gamma updates. In the future this will grow other CRTC level color pipeline properties. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-17 23:47:04 +01:00
MetaKmsCrtcColorUpdate *color_update;
backends/native: Replace MetaKmsCrtcGamma with MetaGammaLut They are the same type now so there is no reason to keep both of them around. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-18 03:13:57 +01:00
MetaGammaLut *gamma_update = NULL;
backends/native: Handle gamma sizes independent of the KMS LUT Allows for creating LUTs at some fixed size which maintains enough precision for concatenating or otherwise manipulating the LUT without having to care about the precision of the hardware. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-18 18:32:24 +01:00
const MetaKmsCrtcState *crtc_state = meta_kms_crtc_get_current_state (crtc);
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 19:20:21 +02:00
kms/update: Make each MetaKmsUpdate update a single device For now feedbacks from an update are combined, meaning we might lose error information. The feedback API may have to be reconsidered and redesigned when planes gets a more front seat position. This means we need to avoid trying to post updates if we're in power save mode, as it may be empty. Note that this is an intermediate state during refactoring that aims to introduce atomic mode setting support, and we'll stop combining feedbacks completely in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-16 23:38:10 +02:00
g_assert (meta_kms_crtc_get_device (crtc) == update->device);
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 19:20:21 +02:00
backends/native: Replace MetaKmsCrtcGamma with MetaGammaLut They are the same type now so there is no reason to keep both of them around. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-18 03:13:57 +01:00
if (gamma)
backends/native: Handle gamma sizes independent of the KMS LUT Allows for creating LUTs at some fixed size which maintains enough precision for concatenating or otherwise manipulating the LUT without having to care about the precision of the hardware. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-18 18:32:24 +01:00
gamma_update = meta_gamma_lut_copy_to_size (gamma, crtc_state->gamma.size);
backends/native: Replace MetaKmsCrtcGamma with MetaGammaLut They are the same type now so there is no reason to keep both of them around. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-18 03:13:57 +01:00
backends/native: Introduce MetaKmsCrtcColorUpdate To store gamma updates. In the future this will grow other CRTC level color pipeline properties. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-17 23:47:04 +01:00
color_update = ensure_color_update (update, crtc);
backends/native: Replace MetaKmsCrtcGamma with MetaGammaLut They are the same type now so there is no reason to keep both of them around. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-18 03:13:57 +01:00
color_update->gamma.state = gamma_update;
backends/native: Introduce MetaKmsCrtcColorUpdate To store gamma updates. In the future this will grow other CRTC level color pipeline properties. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-17 23:47:04 +01:00
color_update->gamma.has_update = TRUE;
kms/impl-device: Add deadline based KMS commit scheduling This makes it possible to post KMS updates that will always defer until just before the scanout deadline. This is useful to allow queuing cursor updates where we don't want to post them to KMS immediately, but rather wait until as late as possible to get lower latency. We cannot delay primary plane compositions however, and this is due to how the kernel may prioritize GPU work - not until a pipeline gets attached to a atomic commit will it in some drivers get bumped to high priority. This means we still need to post any update that depends on OpenGL pipelines as soon as possible. To avoid working on compositing, then getting stomped on the feet by the deadline scheduler, the deadline timer is disarmed whenever there is a frame currently being painted. This will still allow new cursor updates to arrive during composition, but will delay the actual KMS commit until the primary plane update has been posted. Still, even for cursor-only we still need higher than default timing capabilities, thus the deadline scheduler depends on the KMS thread getting real-time scheduling priority. When the thread isn't realtime scheduled, the KMS thread instead asks the main thread to "flush" the commit as part of the regular frame update. A flushing update means one that isn't set to always defer and has a latching CRTC. The verbose KMS debug logging makes the processing take too long, making us more likely to miss the deadline. Avoid this by increasing the evasion length when debug logging is enabled. Not the best, but better than changing the behavior completely. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-10-26 19:08:30 +02:00
update_latch_crtc (update, crtc);
backends/native: Introduce MetaKmsCrtcColorUpdate To store gamma updates. In the future this will grow other CRTC level color pipeline properties. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-17 23:47:04 +01:00
}
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 19:20:21 +02:00
backends/native: Introduce MetaKmsCrtcColorUpdate To store gamma updates. In the future this will grow other CRTC level color pipeline properties. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-17 23:47:04 +01:00
static void
meta_kms_crtc_color_updates_free (MetaKmsCrtcColorUpdate *color_update)
{
if (color_update->gamma.has_update)
backends/native: Replace MetaKmsCrtcGamma with MetaGammaLut They are the same type now so there is no reason to keep both of them around. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-18 03:13:57 +01:00
g_clear_pointer (&color_update->gamma.state, meta_gamma_lut_free);
kms/update: Free struct in meta_kms_crtc_color_updates_free() The free function was only freeing the structs its members were pointing to, but not the struct itself, causing a small leak. Fixes: 0180ffdaa ("backends/native: Introduce MetaKmsCrtcColorUpdate") Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3188>
2023-08-16 21:13:20 +02:00
g_free (color_update);
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 19:20:21 +02: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 22:36:41 +02:00
void
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 16:06:35 +02:00
meta_kms_update_add_page_flip_listener (MetaKmsUpdate *update,
MetaKmsCrtc *crtc,
const MetaKmsPageFlipListenerVtable *vtable,
kms/update: Allow page flip callback listeners on any thread This hooks into the MetaThread GMainContext callback machinery just added; and allows receiving page flip callbacks on any thread. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2021-07-09 19:49:56 +02:00
GMainContext *main_context,
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 08:41:14 +01:00
gpointer user_data,
GDestroyNotify destroy_notify)
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 22:36:41 +02: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 16:06:35 +02:00
MetaKmsPageFlipListener *listener;
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 22:36:41 +02:00
kms/update: Make each MetaKmsUpdate update a single device For now feedbacks from an update are combined, meaning we might lose error information. The feedback API may have to be reconsidered and redesigned when planes gets a more front seat position. This means we need to avoid trying to post updates if we're in power save mode, as it may be empty. Note that this is an intermediate state during refactoring that aims to introduce atomic mode setting support, and we'll stop combining feedbacks completely in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-16 23:38:10 +02:00
g_assert (meta_kms_crtc_get_device (crtc) == update->device);
kms-update: Seal updates when posting them This makes sure that we won't accidentally change KMS transaction updates after they have been posted. https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-19 22:15:12 +02:00
kms/update: Treat NULL main context as default for page flips too Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-12-21 18:52:01 +01:00
if (!main_context)
main_context = g_main_context_default ();
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 16:06:35 +02:00
listener = g_new0 (MetaKmsPageFlipListener, 1);
*listener = (MetaKmsPageFlipListener) {
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 22:36:41 +02:00
.crtc = crtc,
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 16:06:35 +02:00
.vtable = vtable,
kms/update: Allow page flip callback listeners on any thread This hooks into the MetaThread GMainContext callback machinery just added; and allows receiving page flip callbacks on any thread. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2021-07-09 19:49:56 +02:00
.main_context = main_context,
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 22:36:41 +02:00
.user_data = 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 08:41:14 +01:00
.destroy_notify = destroy_notify,
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 22:36:41 +02:00
};
kms/page-flip-listener: Make object reference counted The _ref() variant will be added later, when it gets a user, to avoid a unused compiler warning. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2022-06-05 21:16:11 +02:00
g_atomic_ref_count_init (&listener->ref_count);
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 22:36:41 +02: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 16:06:35 +02:00
update->page_flip_listeners = g_list_prepend (update->page_flip_listeners,
listener);
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 22:36:41 +02:00
}
void
kms/update: Make custom page flip be per update Custom page flips are meant to allow using e.g. EGLStream API to indirectly trigger page flip queueing, when the KMS API cannot be used directly. This is really something that is specific to a device, so instead of making part of the page flip API, make it a configuration of the update itself. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-01 18:28:13 +02:00
meta_kms_update_set_custom_page_flip (MetaKmsUpdate *update,
MetaKmsCustomPageFlipFunc 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 22:36:41 +02: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 11:31:18 +01:00
MetaKmsCustomPageFlip *custom_page_flip;
custom_page_flip = g_new0 (MetaKmsCustomPageFlip, 1);
custom_page_flip->func = func;
custom_page_flip->user_data = user_data;
update->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 22:36:41 +02:00
}
kms: Allow passing framebuffer damage metadata This commit adds support to atomic KMS backend for optional plane property prop_fb_damage_clips. Some drivers (e.g. EVDI) take advantage of this property and process only updated regions of the screen instead of processing the full frame. This can save system resources. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1879>
2021-09-03 19:39:12 +01:00
void
meta_kms_plane_assignment_set_fb_damage (MetaKmsPlaneAssignment *plane_assignment,
const int *rectangles,
int n_rectangles)
{
MetaKmsFbDamage *fb_damage;
struct drm_mode_rect *mode_rects;
int i;
mode_rects = g_new0 (struct drm_mode_rect, n_rectangles);
for (i = 0; i < n_rectangles; ++i)
{
mode_rects[i].x1 = rectangles[i * 4];
mode_rects[i].y1 = rectangles[i * 4 + 1];
mode_rects[i].x2 = mode_rects[i].x1 + rectangles[i * 4 + 2];
mode_rects[i].y2 = mode_rects[i].y1 + rectangles[i * 4 + 3];
}
fb_damage = g_new0 (MetaKmsFbDamage, 1);
*fb_damage = (MetaKmsFbDamage) {
.rects = mode_rects,
.n_rects = n_rectangles,
};
plane_assignment->fb_damage = fb_damage;
}
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 22:36:41 +02:00
void
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 15:10:50 +02:00
meta_kms_plane_assignment_set_rotation (MetaKmsPlaneAssignment *plane_assignment,
backends/native: Use MetaKmsPlaneRotation in plane updates The ImplDeviceAtomic converts the MetaKmsPlaneRotation back to the concrete KMS value. The MetaMonitorTransform is always directly converted to a MetaKmsPlaneRotation. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2379>
2022-04-20 22:54:27 +02:00
MetaKmsPlaneRotation 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 22:36:41 +02:00
{
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 15:10:50 +02:00
g_warn_if_fail (rotation);
kms-update: Seal updates when posting them This makes sure that we won't accidentally change KMS transaction updates after they have been posted. https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-06-19 22:15:12 +02:00
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 15:10:50 +02:00
plane_assignment->rotation = 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 22:36:41 +02:00
}
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 09:01:03 +01:00
void
meta_kms_plane_assignment_set_cursor_hotspot (MetaKmsPlaneAssignment *plane_assignment,
int x,
int y)
{
backends/native: Set hotspot property on updates Add a `has_update` flag to the cursor hotspot struct to allow selective update of the hotsport property only when it will take an effect. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3337>
2024-01-08 15:40:52 +01:00
plane_assignment->cursor_hotspot.has_update = TRUE;
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 09:01:03 +01:00
plane_assignment->cursor_hotspot.is_valid = TRUE;
plane_assignment->cursor_hotspot.x = x;
plane_assignment->cursor_hotspot.y = y;
}
kms/update: Add way to receive result from later posted update Something might want to affect the next update that is going to be posted, but without posting it immediately. For example, changing the cursor might need to wait for mode setting. Make it possible to get feedback from posting the update, in order to gracefully handle any errors. Note, the API for notifiying about results take out the result listener from the update, and notifies them in an open coded for loop. The reason for this is that in the next commit we'll sometimes reuse updates, and we only want notify about the results once. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:35:42 +02:00
void
kms: Make result listener take a vtable too As with the page flip listener, prepare to make result listeners more capable by allowing more vfuncs for the same listener instance in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-12-21 18:17:33 +01:00
meta_kms_update_add_result_listener (MetaKmsUpdate *update,
const MetaKmsResultListenerVtable *vtable,
GMainContext *main_context,
kms/update: Add destroy-notify to result listener user data No thread guarantees, users need to handle it themselves. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2023-04-20 16:32:41 +02:00
gpointer user_data,
GDestroyNotify destroy_notify)
kms/update: Add way to receive result from later posted update Something might want to affect the next update that is going to be posted, but without posting it immediately. For example, changing the cursor might need to wait for mode setting. Make it possible to get feedback from posting the update, in order to gracefully handle any errors. Note, the API for notifiying about results take out the result listener from the update, and notifies them in an open coded for loop. The reason for this is that in the next commit we'll sometimes reuse updates, and we only want notify about the results once. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:35:42 +02:00
{
MetaKmsResultListener *listener;
listener = g_new0 (MetaKmsResultListener, 1);
*listener = (MetaKmsResultListener) {
kms/result-listener: Allow setting a custom main context While the default when passing NULL will be the main context of the main thread, make it possible to specify another main context, so that result handlers can be invoked on the right thread. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2023-02-14 20:18:26 +01:00
.main_context = main_context,
kms: Make result listener take a vtable too As with the page flip listener, prepare to make result listeners more capable by allowing more vfuncs for the same listener instance in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-12-21 18:17:33 +01:00
.vtable = vtable,
kms/update: Add way to receive result from later posted update Something might want to affect the next update that is going to be posted, but without posting it immediately. For example, changing the cursor might need to wait for mode setting. Make it possible to get feedback from posting the update, in order to gracefully handle any errors. Note, the API for notifiying about results take out the result listener from the update, and notifies them in an open coded for loop. The reason for this is that in the next commit we'll sometimes reuse updates, and we only want notify about the results once. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:35:42 +02:00
.user_data = user_data,
kms/update: Add destroy-notify to result listener user data No thread guarantees, users need to handle it themselves. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2023-04-20 16:32:41 +02:00
.destroy_notify = destroy_notify,
kms/update: Add way to receive result from later posted update Something might want to affect the next update that is going to be posted, but without posting it immediately. For example, changing the cursor might need to wait for mode setting. Make it possible to get feedback from posting the update, in order to gracefully handle any errors. Note, the API for notifiying about results take out the result listener from the update, and notifies them in an open coded for loop. The reason for this is that in the next commit we'll sometimes reuse updates, and we only want notify about the results once. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:35:42 +02:00
};
update->result_listeners = g_list_append (update->result_listeners,
listener);
}
GList *
meta_kms_update_take_result_listeners (MetaKmsUpdate *update)
{
return g_steal_pointer (&update->result_listeners);
}
kms/result-listener: Allow setting a custom main context While the default when passing NULL will be the main context of the main thread, make it possible to specify another main context, so that result handlers can be invoked on the right thread. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2023-02-14 20:18:26 +01:00
GMainContext *
meta_kms_result_listener_get_main_context (MetaKmsResultListener *listener)
{
return listener->main_context;
}
kms/update: Add way to receive result from later posted update Something might want to affect the next update that is going to be posted, but without posting it immediately. For example, changing the cursor might need to wait for mode setting. Make it possible to get feedback from posting the update, in order to gracefully handle any errors. Note, the API for notifiying about results take out the result listener from the update, and notifies them in an open coded for loop. The reason for this is that in the next commit we'll sometimes reuse updates, and we only want notify about the results once. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:35:42 +02:00
void
kms/result-listener: Let listeners own a feedback ref Dispatch results via a helper, and let each result hold a reference to the feedback. This allows for more asynchronous feedback management. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2023-02-14 20:15:51 +01:00
meta_kms_result_listener_set_feedback (MetaKmsResultListener *listener,
MetaKmsFeedback *feedback)
kms/update: Add way to receive result from later posted update Something might want to affect the next update that is going to be posted, but without posting it immediately. For example, changing the cursor might need to wait for mode setting. Make it possible to get feedback from posting the update, in order to gracefully handle any errors. Note, the API for notifiying about results take out the result listener from the update, and notifies them in an open coded for loop. The reason for this is that in the next commit we'll sometimes reuse updates, and we only want notify about the results once. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:35:42 +02:00
{
kms/result-listener: Let listeners own a feedback ref Dispatch results via a helper, and let each result hold a reference to the feedback. This allows for more asynchronous feedback management. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2023-02-14 20:15:51 +01:00
g_return_if_fail (!listener->feedback);
listener->feedback = meta_kms_feedback_ref (feedback);
}
void
meta_kms_result_listener_notify (MetaKmsResultListener *listener)
{
g_return_if_fail (listener->feedback);
kms: Make result listener take a vtable too As with the page flip listener, prepare to make result listeners more capable by allowing more vfuncs for the same listener instance in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-12-21 18:17:33 +01:00
if (listener->vtable->feedback)
listener->vtable->feedback (listener->feedback, listener->user_data);
kms/update: Add way to receive result from later posted update Something might want to affect the next update that is going to be posted, but without posting it immediately. For example, changing the cursor might need to wait for mode setting. Make it possible to get feedback from posting the update, in order to gracefully handle any errors. Note, the API for notifiying about results take out the result listener from the update, and notifies them in an open coded for loop. The reason for this is that in the next commit we'll sometimes reuse updates, and we only want notify about the results once. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:35:42 +02:00
}
void
meta_kms_result_listener_free (MetaKmsResultListener *listener)
{
kms/update: Add destroy-notify to result listener user data No thread guarantees, users need to handle it themselves. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2023-04-20 16:32:41 +02:00
if (listener->destroy_notify)
listener->destroy_notify (listener->user_data);
kms/result-listener: Let listeners own a feedback ref Dispatch results via a helper, and let each result hold a reference to the feedback. This allows for more asynchronous feedback management. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2023-02-14 20:15:51 +01:00
g_clear_pointer (&listener->feedback, meta_kms_feedback_unref);
kms/update: Add way to receive result from later posted update Something might want to affect the next update that is going to be posted, but without posting it immediately. For example, changing the cursor might need to wait for mode setting. Make it possible to get feedback from posting the update, in order to gracefully handle any errors. Note, the API for notifiying about results take out the result listener from the update, and notifies them in an open coded for loop. The reason for this is that in the next commit we'll sometimes reuse updates, and we only want notify about the results once. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:35:42 +02:00
g_free (listener);
}
kms/update: Add getter for cursor plane assignment To be used in tests. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
2021-06-16 10:21:55 +02:00
static MetaKmsPlaneAssignment *
get_first_plane_assignment (MetaKmsUpdate *update,
MetaKmsCrtc *crtc,
MetaKmsPlaneType plane_type)
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 11:48:46 +02:00
{
GList *l;
for (l = meta_kms_update_get_plane_assignments (update); l; l = l->next)
{
MetaKmsPlaneAssignment *plane_assignment = l->data;
kms/plane: Make get_primary_plane() actually get the primary plane The plane was not type checked, so it retrieved whatever plane happened to come first. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-09 22:06:19 +02:00
if (meta_kms_plane_get_plane_type (plane_assignment->plane) !=
kms/update: Add getter for cursor plane assignment To be used in tests. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
2021-06-16 10:21:55 +02:00
plane_type)
kms/plane: Make get_primary_plane() actually get the primary plane The plane was not type checked, so it retrieved whatever plane happened to come first. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-09 22:06:19 +02:00
continue;
if (plane_assignment->crtc != crtc)
continue;
return plane_assignment;
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 11:48:46 +02:00
}
return NULL;
}
kms/update: Add getter for cursor plane assignment To be used in tests. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
2021-06-16 10:21:55 +02:00
MetaKmsPlaneAssignment *
meta_kms_update_get_primary_plane_assignment (MetaKmsUpdate *update,
MetaKmsCrtc *crtc)
{
return get_first_plane_assignment (update, crtc, META_KMS_PLANE_TYPE_PRIMARY);
}
MetaKmsPlaneAssignment *
meta_kms_update_get_cursor_plane_assignment (MetaKmsUpdate *update,
MetaKmsCrtc *crtc)
{
return get_first_plane_assignment (update, crtc, META_KMS_PLANE_TYPE_CURSOR);
}
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 22:36:41 +02:00
GList *
meta_kms_update_get_plane_assignments (MetaKmsUpdate *update)
{
return update->plane_assignments;
}
GList *
meta_kms_update_get_mode_sets (MetaKmsUpdate *update)
{
return update->mode_sets;
}
GList *
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 16:06:35 +02:00
meta_kms_update_get_page_flip_listeners (MetaKmsUpdate *update)
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 22:36:41 +02: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 16:06:35 +02:00
return update->page_flip_listeners;
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 22:36:41 +02:00
}
GList *
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 16:48:47 +02:00
meta_kms_update_get_connector_updates (MetaKmsUpdate *update)
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 22:36:41 +02: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 16:48:47 +02:00
return update->connector_updates;
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 22:36:41 +02:00
}
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 19:20:21 +02:00
GList *
backends/native: Rename crtc_gamma to crtc_color_updates We need to update more CRTC color pipeline properties in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-17 23:18:39 +01:00
meta_kms_update_get_crtc_color_updates (MetaKmsUpdate *update)
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 19:20:21 +02:00
{
backends/native: Rename crtc_gamma to crtc_color_updates We need to update more CRTC color pipeline properties in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-17 23:18:39 +01:00
return update->crtc_color_updates;
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 19:20:21 +02:00
}
kms/update: Make each MetaKmsUpdate update a single device For now feedbacks from an update are combined, meaning we might lose error information. The feedback API may have to be reconsidered and redesigned when planes gets a more front seat position. This means we need to avoid trying to post updates if we're in power save mode, as it may be empty. Note that this is an intermediate state during refactoring that aims to introduce atomic mode setting support, and we'll stop combining feedbacks completely in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-16 23:38:10 +02:00
MetaKmsDevice *
meta_kms_update_get_device (MetaKmsUpdate *update)
{
return update->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 11:31:18 +01:00
MetaKmsCustomPageFlip *
meta_kms_update_take_custom_page_flip_func (MetaKmsUpdate *update)
{
return g_steal_pointer (&update->custom_page_flip);
}
kms/update: Make custom page flip be per update Custom page flips are meant to allow using e.g. EGLStream API to indirectly trigger page flip queueing, when the KMS API cannot be used directly. This is really something that is specific to a device, so instead of making part of the page flip API, make it a configuration of the update itself. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-01 18:28:13 +02:00
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 11:31:18 +01:00
meta_kms_custom_page_flip_free (MetaKmsCustomPageFlip *custom_page_flip)
kms/update: Make custom page flip be per update Custom page flips are meant to allow using e.g. EGLStream API to indirectly trigger page flip queueing, when the KMS API cannot be used directly. This is really something that is specific to a device, so instead of making part of the page flip API, make it a configuration of the update itself. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-01 18:28:13 +02: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 11:31:18 +01:00
g_free (custom_page_flip);
kms/update: Make custom page flip be per update Custom page flips are meant to allow using e.g. EGLStream API to indirectly trigger page flip queueing, when the KMS API cannot be used directly. This is really something that is specific to a device, so instead of making part of the page flip API, make it a configuration of the update itself. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-01 18:28:13 +02:00
}
kms/update: Support merging updates with mode sets Will be helpful to allow constructing each initial mode set update per CRTC, merging them later on-demand. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2022-10-20 21:34:25 +02:00
static GList *
find_mode_set_link_for (MetaKmsUpdate *update,
MetaKmsCrtc *crtc)
{
GList *l;
for (l = update->mode_sets; l; l = l->next)
{
MetaKmsModeSet *mode_set = l->data;
if (mode_set->crtc == crtc)
return l;
}
return NULL;
}
static void
merge_mode_sets (MetaKmsUpdate *update,
MetaKmsUpdate *other_update)
{
while (other_update->mode_sets)
{
GList *l = other_update->mode_sets;
MetaKmsModeSet *other_mode_set = l->data;
MetaKmsCrtc *crtc = other_mode_set->crtc;
GList *el;
other_update->mode_sets =
g_list_remove_link (other_update->mode_sets, l);
el = find_mode_set_link_for (update, crtc);
if (el)
{
meta_kms_mode_set_free (el->data);
update->mode_sets =
g_list_insert_before_link (update->mode_sets, el, l);
update->mode_sets =
g_list_delete_link (update->mode_sets, el);
}
else
{
update->mode_sets =
g_list_insert_before_link (update->mode_sets,
update->mode_sets,
l);
}
}
}
kms/update: Add API to merge two updates This is intended to be used only for plane assignment, and CRTC like changes, so that one can e.g. change a cursor plane on a pending update that changes the primary plane, before it has been committed to KMS. The kms-updates test overrides the get-state function MetaKmsCrtc. This is needd to not have the update mechanism not clamp the gamma size to 0, as vkms reports the gamma length 0. By pretending it's 3, we can test a simple and small gamma lut is merged correctly when merging updates. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2021-06-18 15:01:35 +02:00
static GList *
find_plane_assignment_link_for (MetaKmsUpdate *update,
MetaKmsPlane *plane)
{
GList *l;
for (l = update->plane_assignments; l; l = l->next)
{
MetaKmsPlaneAssignment *plane_assignment = l->data;
if (plane_assignment->plane == plane)
return l;
}
return NULL;
}
static void
merge_plane_assignments_from (MetaKmsUpdate *update,
MetaKmsUpdate *other_update)
{
while (other_update->plane_assignments)
{
GList *l = other_update->plane_assignments;
MetaKmsPlaneAssignment *other_plane_assignment = l->data;
MetaKmsPlane *plane = other_plane_assignment->plane;
GList *el;
other_update->plane_assignments =
g_list_remove_link (other_update->plane_assignments, l);
el = find_plane_assignment_link_for (update, plane);
if (el)
{
meta_kms_plane_assignment_free (el->data);
update->plane_assignments =
g_list_insert_before_link (update->plane_assignments, el, l);
update->plane_assignments =
g_list_delete_link (update->plane_assignments, el);
}
else
{
update->plane_assignments =
g_list_insert_before_link (update->plane_assignments,
update->plane_assignments,
l);
}
other_plane_assignment->update = update;
}
}
static GList *
find_color_update_link_for (MetaKmsUpdate *update,
MetaKmsCrtc *crtc)
{
GList *l;
for (l = update->crtc_color_updates; l; l = l->next)
{
MetaKmsCrtcColorUpdate *color_update = l->data;
if (color_update->crtc == crtc)
return l;
}
return NULL;
}
static void
merge_crtc_color_updates_from (MetaKmsUpdate *update,
MetaKmsUpdate *other_update)
{
while (other_update->crtc_color_updates)
{
GList *l = other_update->crtc_color_updates;
MetaKmsCrtcColorUpdate *other_crtc_color_update = l->data;
MetaKmsCrtc *crtc = other_crtc_color_update->crtc;
GList *el;
other_update->crtc_color_updates =
g_list_remove_link (other_update->crtc_color_updates, l);
el = find_color_update_link_for (update, crtc);
if (el)
{
meta_kms_crtc_color_updates_free (el->data);
update->crtc_color_updates =
g_list_insert_before_link (update->crtc_color_updates, el, l);
update->crtc_color_updates =
g_list_delete_link (update->crtc_color_updates, el);
}
else
{
update->crtc_color_updates =
g_list_insert_before_link (update->crtc_color_updates,
update->crtc_color_updates,
l);
}
}
}
kms/update: Merge connector updates too This includes privacy screen updates, underscanning etc; this is needed when merging mode set updates that happen to change these too, which is rather likely. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2881>
2023-03-02 22:09:16 +01:00
static GList *
find_connector_update_link_for (MetaKmsUpdate *update,
MetaKmsConnector *connector)
{
GList *l;
for (l = update->connector_updates; l; l = l->next)
{
MetaKmsConnectorUpdate *connector_update = l->data;
if (connector_update->connector == connector)
return l;
}
return NULL;
}
static void
merge_connector_updates_from (MetaKmsUpdate *update,
MetaKmsUpdate *other_update)
{
while (other_update->connector_updates)
{
GList *l = other_update->connector_updates;
MetaKmsConnectorUpdate *other_connector_update = l->data;
MetaKmsConnector *connector = other_connector_update->connector;
GList *el;
other_update->connector_updates =
g_list_remove_link (other_update->connector_updates, l);
el = find_connector_update_link_for (update, connector);
if (el)
{
MetaKmsConnectorUpdate *connector_update = el->data;
if (other_connector_update->underscanning.has_update)
{
connector_update->underscanning =
other_connector_update->underscanning;
}
if (other_connector_update->privacy_screen.has_update)
{
connector_update->privacy_screen =
other_connector_update->privacy_screen;
}
if (other_connector_update->max_bpc.has_update)
{
connector_update->max_bpc =
other_connector_update->max_bpc;
}
backends/native: Add color space and HDR metadata updates Allows to prepare KMS updates to set the color space and HDR Static Metadata on the output. For some reason we need ALLOW_MODESET on commits which change the HDR Static Metadata InfoFrame on AMDGPU. There is no technical reason why one needs to mode set to send an InfoFrame and the driver should just manage without ALLOW_MODESET. Until this is resolved in the kernel we just prepare KMS updates which might mode set. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
2023-03-02 02:04:12 +01:00
if (other_connector_update->colorspace.has_update)
{
connector_update->colorspace =
other_connector_update->colorspace;
}
if (other_connector_update->hdr.has_update)
{
connector_update->hdr = other_connector_update->hdr;
}
kms/update: Merge connector updates too This includes privacy screen updates, underscanning etc; this is needed when merging mode set updates that happen to change these too, which is rather likely. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2881>
2023-03-02 22:09:16 +01:00
}
else
{
update->connector_updates =
g_list_insert_before_link (update->connector_updates,
update->connector_updates,
l);
}
}
}
kms/update: Add API to merge two updates This is intended to be used only for plane assignment, and CRTC like changes, so that one can e.g. change a cursor plane on a pending update that changes the primary plane, before it has been committed to KMS. The kms-updates test overrides the get-state function MetaKmsCrtc. This is needd to not have the update mechanism not clamp the gamma size to 0, as vkms reports the gamma length 0. By pretending it's 3, we can test a simple and small gamma lut is merged correctly when merging updates. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2021-06-18 15:01:35 +02:00
static void
merge_custom_page_flip_from (MetaKmsUpdate *update,
MetaKmsUpdate *other_update)
{
g_warn_if_fail ((!update->custom_page_flip &&
!other_update->custom_page_flip) ||
((!!update->custom_page_flip) ^
(!!other_update->custom_page_flip)));
g_clear_pointer (&update->custom_page_flip, meta_kms_custom_page_flip_free);
update->custom_page_flip = g_steal_pointer (&other_update->custom_page_flip);
}
static void
merge_page_flip_listeners_from (MetaKmsUpdate *update,
MetaKmsUpdate *other_update)
{
update->page_flip_listeners =
g_list_concat (update->page_flip_listeners,
g_steal_pointer (&other_update->page_flip_listeners));
}
static void
merge_result_listeners_from (MetaKmsUpdate *update,
MetaKmsUpdate *other_update)
{
update->result_listeners =
g_list_concat (update->result_listeners,
g_steal_pointer (&other_update->result_listeners));
}
void
meta_kms_update_merge_from (MetaKmsUpdate *update,
MetaKmsUpdate *other_update)
{
g_return_if_fail (update->device == other_update->device);
kms/update: Support merging updates with mode sets Will be helpful to allow constructing each initial mode set update per CRTC, merging them later on-demand. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2022-10-20 21:34:25 +02:00
merge_mode_sets (update, other_update);
kms/update: Add API to merge two updates This is intended to be used only for plane assignment, and CRTC like changes, so that one can e.g. change a cursor plane on a pending update that changes the primary plane, before it has been committed to KMS. The kms-updates test overrides the get-state function MetaKmsCrtc. This is needd to not have the update mechanism not clamp the gamma size to 0, as vkms reports the gamma length 0. By pretending it's 3, we can test a simple and small gamma lut is merged correctly when merging updates. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2021-06-18 15:01:35 +02:00
merge_plane_assignments_from (update, other_update);
merge_crtc_color_updates_from (update, other_update);
kms/update: Merge connector updates too This includes privacy screen updates, underscanning etc; this is needed when merging mode set updates that happen to change these too, which is rather likely. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2881>
2023-03-02 22:09:16 +01:00
merge_connector_updates_from (update, other_update);
kms/update: Add API to merge two updates This is intended to be used only for plane assignment, and CRTC like changes, so that one can e.g. change a cursor plane on a pending update that changes the primary plane, before it has been committed to KMS. The kms-updates test overrides the get-state function MetaKmsCrtc. This is needd to not have the update mechanism not clamp the gamma size to 0, as vkms reports the gamma length 0. By pretending it's 3, we can test a simple and small gamma lut is merged correctly when merging updates. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2021-06-18 15:01:35 +02:00
merge_custom_page_flip_from (update, other_update);
merge_page_flip_listeners_from (update, other_update);
merge_result_listeners_from (update, other_update);
}
backends/native: Let updates require ALLOW_MODESET Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
2023-03-02 01:59:41 +01:00
gboolean
meta_kms_update_get_needs_modeset (MetaKmsUpdate *update)
{
return update->needs_modeset || update->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 22:36:41 +02:00
MetaKmsUpdate *
kms/update: Make each MetaKmsUpdate update a single device For now feedbacks from an update are combined, meaning we might lose error information. The feedback API may have to be reconsidered and redesigned when planes gets a more front seat position. This means we need to avoid trying to post updates if we're in power save mode, as it may be empty. Note that this is an intermediate state during refactoring that aims to introduce atomic mode setting support, and we'll stop combining feedbacks completely in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-16 23:38:10 +02:00
meta_kms_update_new (MetaKmsDevice *device)
backend/native: Add and use transactional KMS API This commit introduces, and makes use of, a transactional API used for setting up KMS state, later to be applied, potentially atomically. From an API point of view, so is always the case, but in the current implementation, it still uses legacy drmMode* API to apply the state non-atomically. The API consists of various buliding blocks: * MetaKmsUpdate - a set of configuration changes, the higher level handle for handing over configuration to the impl backend. It's used to set mode, assign framebuffers to planes, queue page flips and set connector properties. * MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane. Currently used to map a framebuffer to the primary plane of a CRTC. In the legacy KMS implementation, the plane assignment is used to derive the framebuffer used for mode setting and page flipping. This also means various high level changes: State, excluding configuring the cursor plane and creating/destroying DRM framebuffer handles, are applied in the end of a clutter frame, in one go. From an API point of view, this is done atomically, but as mentioned, only the non-atomic implementation exists so far. From MetaRendererNative's point of view, a page flip now initially always succeeds; the handling of EBUSY errors are done asynchronously in the MetaKmsImpl backend (still by retrying at refresh rate, but postponing flip callbacks instead of manipulating the frame clock). Handling of falling back to mode setting instead of page flipping is notified after the fact by a more precise page flip feedback API. EGLStream based page flipping relies on the impl backend not being atomic, as the page flipping is done in the EGLStream backend (e.g. nvidia driver). It uses a 'custom' page flip queueing method, keeping the EGLStream logic inside meta-renderer-native.c. Page flip handling is moved to meta-kms-impl-device.c from meta-gpu-kms.c. It goes via an extra idle callback before reaching meta-renderer-native.c to make sure callbacks are invoked outside of the impl context. While dummy power save page flipping is kept in meta-renderer-native.c, the EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the frame clock, actual page flip callbacks are postponed until all EBUSY retries have either succeeded or failed due to some other error than EBUSY. This effectively inhibits new frames to be drawn, meaning we won't stall waiting on the file descriptor for pending page flips. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-04-04 22:36:41 +02:00
{
kms/update: Make each MetaKmsUpdate update a single device For now feedbacks from an update are combined, meaning we might lose error information. The feedback API may have to be reconsidered and redesigned when planes gets a more front seat position. This means we need to avoid trying to post updates if we're in power save mode, as it may be empty. Note that this is an intermediate state during refactoring that aims to introduce atomic mode setting support, and we'll stop combining feedbacks completely in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-16 23:38:10 +02:00
MetaKmsUpdate *update;
update = g_new0 (MetaKmsUpdate, 1);
update->device = device;
kms/impl-device: Add deadline based KMS commit scheduling This makes it possible to post KMS updates that will always defer until just before the scanout deadline. This is useful to allow queuing cursor updates where we don't want to post them to KMS immediately, but rather wait until as late as possible to get lower latency. We cannot delay primary plane compositions however, and this is due to how the kernel may prioritize GPU work - not until a pipeline gets attached to a atomic commit will it in some drivers get bumped to high priority. This means we still need to post any update that depends on OpenGL pipelines as soon as possible. To avoid working on compositing, then getting stomped on the feet by the deadline scheduler, the deadline timer is disarmed whenever there is a frame currently being painted. This will still allow new cursor updates to arrive during composition, but will delay the actual KMS commit until the primary plane update has been posted. Still, even for cursor-only we still need higher than default timing capabilities, thus the deadline scheduler depends on the KMS thread getting real-time scheduling priority. When the thread isn't realtime scheduled, the KMS thread instead asks the main thread to "flush" the commit as part of the regular frame update. A flushing update means one that isn't set to always defer and has a latching CRTC. The verbose KMS debug logging makes the processing take too long, making us more likely to miss the deadline. Avoid this by increasing the evasion length when debug logging is enabled. Not the best, but better than changing the behavior completely. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-10-26 19:08:30 +02:00
update->is_latchable = TRUE;
kms/update: Make each MetaKmsUpdate update a single device For now feedbacks from an update are combined, meaning we might lose error information. The feedback API may have to be reconsidered and redesigned when planes gets a more front seat position. This means we need to avoid trying to post updates if we're in power save mode, as it may be empty. Note that this is an intermediate state during refactoring that aims to introduce atomic mode setting support, and we'll stop combining feedbacks completely in the future. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-07-16 23:38:10 +02:00
return update;
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 22:36:41 +02:00
}
void
meta_kms_update_free (MetaKmsUpdate *update)
{
kms/impl-device: Move fd hold to update when processing This will let us move the update ownership to the backend, allowing it to handle it with less restrictions. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
2022-06-22 00:23:03 +02:00
if (update->impl_device)
meta_kms_impl_device_unhold_fd (update->impl_device);
kms/update: Add way to receive result from later posted update Something might want to affect the next update that is going to be posted, but without posting it immediately. For example, changing the cursor might need to wait for mode setting. Make it possible to get feedback from posting the update, in order to gracefully handle any errors. Note, the API for notifiying about results take out the result listener from the update, and notifies them in an open coded for loop. The reason for this is that in the next commit we'll sometimes reuse updates, and we only want notify about the results once. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
2020-10-02 16:35:42 +02:00
g_list_free_full (update->result_listeners,
(GDestroyNotify) meta_kms_result_listener_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 22:36:41 +02:00
g_list_free_full (update->plane_assignments,
(GDestroyNotify) meta_kms_plane_assignment_free);
g_list_free_full (update->mode_sets,
(GDestroyNotify) meta_kms_mode_set_free);
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 08:41:14 +01:00
g_list_free_full (update->page_flip_listeners,
kms/page-flip-listener: Make object reference counted The _ref() variant will be added later, when it gets a user, to avoid a unused compiler warning. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2022-06-05 21:16:11 +02:00
(GDestroyNotify) meta_kms_page_flip_listener_unref);
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 16:48:47 +02:00
g_list_free_full (update->connector_updates, g_free);
backends/native: Introduce MetaKmsCrtcColorUpdate To store gamma updates. In the future this will grow other CRTC level color pipeline properties. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
2023-02-17 23:47:04 +01:00
g_list_free_full (update->crtc_color_updates,
(GDestroyNotify) meta_kms_crtc_color_updates_free);
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 11:31:18 +01:00
g_clear_pointer (&update->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 22:36:41 +02:00
g_free (update);
}
kms/impl-device: Move fd hold to update when processing This will let us move the update ownership to the backend, allowing it to handle it with less restrictions. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
2022-06-22 00:23:03 +02:00
void
meta_kms_update_realize (MetaKmsUpdate *update,
MetaKmsImplDevice *impl_device)
{
update->impl_device = impl_device;
meta_kms_impl_device_hold_fd (impl_device);
}
kms/impl-device: Add deadline based KMS commit scheduling This makes it possible to post KMS updates that will always defer until just before the scanout deadline. This is useful to allow queuing cursor updates where we don't want to post them to KMS immediately, but rather wait until as late as possible to get lower latency. We cannot delay primary plane compositions however, and this is due to how the kernel may prioritize GPU work - not until a pipeline gets attached to a atomic commit will it in some drivers get bumped to high priority. This means we still need to post any update that depends on OpenGL pipelines as soon as possible. To avoid working on compositing, then getting stomped on the feet by the deadline scheduler, the deadline timer is disarmed whenever there is a frame currently being painted. This will still allow new cursor updates to arrive during composition, but will delay the actual KMS commit until the primary plane update has been posted. Still, even for cursor-only we still need higher than default timing capabilities, thus the deadline scheduler depends on the KMS thread getting real-time scheduling priority. When the thread isn't realtime scheduled, the KMS thread instead asks the main thread to "flush" the commit as part of the regular frame update. A flushing update means one that isn't set to always defer and has a latching CRTC. The verbose KMS debug logging makes the processing take too long, making us more likely to miss the deadline. Avoid this by increasing the evasion length when debug logging is enabled. Not the best, but better than changing the behavior completely. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
2022-10-26 19:08:30 +02:00
void
meta_kms_update_set_flushing (MetaKmsUpdate *update,
MetaKmsCrtc *crtc)
{
update_latch_crtc (update, crtc);
}
MetaKmsCrtc *
meta_kms_update_get_latch_crtc (MetaKmsUpdate *update)
{
return update->latch_crtc;
}
gboolean
meta_kms_update_is_empty (MetaKmsUpdate *update)
{
return (!update->mode_sets &&
!update->plane_assignments &&
!update->connector_updates &&
!update->crtc_color_updates);
}
Reference in New Issue Copy Permalink