isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-27 18:40:40 -05:00
Code Issues Packages Projects Releases Wiki Activity
2b561a369c
mutter/src/backends/native/meta-kms-private.h

75 lines
2.9 KiB
C
Raw Normal View History

backends/native: Add basic KMS abstraction building blocks The intention with KMS abstraction is to hide away accessing the drm functions behind an API that allows us to have different kind of KMS implementations, including legacy non-atomic and atomic. The intention is also that the code interacting with the drm device should be able to be run in a different thread than the main thread. This means that we need to make sure that all drm*() API usage must only occur from within tasks that eventually can be run in the dedicated thread. The idea here is that MetaKms provides a outward facing API other places of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is an internal implementation that only gets interacted with via "tasks" posted via the MetaKms object. These tasks will in the future potentially be run on the dedicated KMS thread. Initially, we don't create any new threads. Likewise, MetaKmsDevice is a outward facing representation of a KMS device, while MetaKmsImplDevice is the corresponding implementation, which only runs from within the MetaKmsImpl tasks. This commit only moves opening and closing the device to this new API, while leaking the fd outside of the impl enclosure, effectively making the isolation for drm*() calls pointless. This, however, is necessary to allow gradual porting of drm interaction, and eventually the file descriptor in MetaGpuKms will be removed. For now, it's harmless, since everything still run in the main thread. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 04:24:44 -05:00
/*
* Copyright (C) 2019 Red Hat
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
* 02111-1307, USA.
*/
#ifndef META_KMS_PRIVATE_H
#define META_KMS_PRIVATE_H
#include "backends/native/meta-kms.h"
tests/kms: Check predicted state is correctly predicted When we're predicting state, i.e. when having posted an update while avoiding reading KMS state, copy the predicted state, update the actual state, and check that the predicted state matches the newly updated one. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
2021-06-28 03:20:10 -04:00
#include <gudev/gudev.h>
backends/native: Add basic KMS abstraction building blocks The intention with KMS abstraction is to hide away accessing the drm functions behind an API that allows us to have different kind of KMS implementations, including legacy non-atomic and atomic. The intention is also that the code interacting with the drm device should be able to be run in a different thread than the main thread. This means that we need to make sure that all drm*() API usage must only occur from within tasks that eventually can be run in the dedicated thread. The idea here is that MetaKms provides a outward facing API other places of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is an internal implementation that only gets interacted with via "tasks" posted via the MetaKms object. These tasks will in the future potentially be run on the dedicated KMS thread. Initially, we don't create any new threads. Likewise, MetaKmsDevice is a outward facing representation of a KMS device, while MetaKmsImplDevice is the corresponding implementation, which only runs from within the MetaKmsImpl tasks. This commit only moves opening and closing the device to this new API, while leaking the fd outside of the impl enclosure, effectively making the isolation for drm*() calls pointless. This, however, is necessary to allow gradual porting of drm interaction, and eventually the file descriptor in MetaGpuKms will be removed. For now, it's harmless, since everything still run in the main thread. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 04:24:44 -05:00
#include "backends/native/meta-kms-types.h"
kms: Add API to post callbacks out of the impl context While the current impl context is in the same thread as the main context, the separation still exists, and to post callbacks from the impl context, it must pass MetaKms to make sure the callback is invoked in the right context. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-03-10 08:36:34 -04:00
typedef void (* MetaKmsCallback) (MetaKms *kms,
gpointer user_data);
kms: Return gpointer from impl tasks Currently only used to return either TRUE or FALSE to communicate success or failure. Will be used to return feedback objects. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 17:47:48 -05:00
typedef gpointer (* MetaKmsImplTaskFunc) (MetaKmsImpl *impl,
backends/native: Add basic KMS abstraction building blocks The intention with KMS abstraction is to hide away accessing the drm functions behind an API that allows us to have different kind of KMS implementations, including legacy non-atomic and atomic. The intention is also that the code interacting with the drm device should be able to be run in a different thread than the main thread. This means that we need to make sure that all drm*() API usage must only occur from within tasks that eventually can be run in the dedicated thread. The idea here is that MetaKms provides a outward facing API other places of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is an internal implementation that only gets interacted with via "tasks" posted via the MetaKms object. These tasks will in the future potentially be run on the dedicated KMS thread. Initially, we don't create any new threads. Likewise, MetaKmsDevice is a outward facing representation of a KMS device, while MetaKmsImplDevice is the corresponding implementation, which only runs from within the MetaKmsImpl tasks. This commit only moves opening and closing the device to this new API, while leaking the fd outside of the impl enclosure, effectively making the isolation for drm*() calls pointless. This, however, is necessary to allow gradual porting of drm interaction, and eventually the file descriptor in MetaGpuKms will be removed. For now, it's harmless, since everything still run in the main thread. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 04:24:44 -05:00
gpointer user_data,
GError **error);
kms: Add API to post callbacks out of the impl context While the current impl context is in the same thread as the main context, the separation still exists, and to post callbacks from the impl context, it must pass MetaKms to make sure the callback is invoked in the right context. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-03-10 08:36:34 -04:00
void meta_kms_queue_callback (MetaKms *kms,
MetaKmsCallback callback,
gpointer user_data,
GDestroyNotify user_data_destroy);
kms: Return gpointer from impl tasks Currently only used to return either TRUE or FALSE to communicate success or failure. Will be used to return feedback objects. https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
2019-11-08 17:47:48 -05:00
gpointer meta_kms_run_impl_task_sync (MetaKms *kms,
backends/native: Add basic KMS abstraction building blocks The intention with KMS abstraction is to hide away accessing the drm functions behind an API that allows us to have different kind of KMS implementations, including legacy non-atomic and atomic. The intention is also that the code interacting with the drm device should be able to be run in a different thread than the main thread. This means that we need to make sure that all drm*() API usage must only occur from within tasks that eventually can be run in the dedicated thread. The idea here is that MetaKms provides a outward facing API other places of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is an internal implementation that only gets interacted with via "tasks" posted via the MetaKms object. These tasks will in the future potentially be run on the dedicated KMS thread. Initially, we don't create any new threads. Likewise, MetaKmsDevice is a outward facing representation of a KMS device, while MetaKmsImplDevice is the corresponding implementation, which only runs from within the MetaKmsImpl tasks. This commit only moves opening and closing the device to this new API, while leaking the fd outside of the impl enclosure, effectively making the isolation for drm*() calls pointless. This, however, is necessary to allow gradual porting of drm interaction, and eventually the file descriptor in MetaGpuKms will be removed. For now, it's harmless, since everything still run in the main thread. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 04:24:44 -05:00
MetaKmsImplTaskFunc func,
gpointer user_data,
GError **error);
backend/native: Add and use transactional KMS API This commit introduces, and makes use of, a transactional API used for setting up KMS state, later to be applied, potentially atomically. From an API point of view, so is always the case, but in the current implementation, it still uses legacy drmMode* API to apply the state non-atomically. The API consists of various buliding blocks: * MetaKmsUpdate - a set of configuration changes, the higher level handle for handing over configuration to the impl backend. It's used to set mode, assign framebuffers to planes, queue page flips and set connector properties. * MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane. Currently used to map a framebuffer to the primary plane of a CRTC. In the legacy KMS implementation, the plane assignment is used to derive the framebuffer used for mode setting and page flipping. This also means various high level changes: State, excluding configuring the cursor plane and creating/destroying DRM framebuffer handles, are applied in the end of a clutter frame, in one go. From an API point of view, this is done atomically, but as mentioned, only the non-atomic implementation exists so far. From MetaRendererNative's point of view, a page flip now initially always succeeds; the handling of EBUSY errors are done asynchronously in the MetaKmsImpl backend (still by retrying at refresh rate, but postponing flip callbacks instead of manipulating the frame clock). Handling of falling back to mode setting instead of page flipping is notified after the fact by a more precise page flip feedback API. EGLStream based page flipping relies on the impl backend not being atomic, as the page flipping is done in the EGLStream backend (e.g. nvidia driver). It uses a 'custom' page flip queueing method, keeping the EGLStream logic inside meta-renderer-native.c. Page flip handling is moved to meta-kms-impl-device.c from meta-gpu-kms.c. It goes via an extra idle callback before reaching meta-renderer-native.c to make sure callbacks are invoked outside of the impl context. While dummy power save page flipping is kept in meta-renderer-native.c, the EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the frame clock, actual page flip callbacks are postponed until all EBUSY retries have either succeeded or failed due to some other error than EBUSY. This effectively inhibits new frames to be drawn, meaning we won't stall waiting on the file descriptor for pending page flips. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-04-04 16:36:41 -04:00
GSource * meta_kms_add_source_in_impl (MetaKms *kms,
GSourceFunc func,
gpointer user_data,
GDestroyNotify user_data_destroy);
kms: Add API to add a GSource that'll be invoked in the impl context The MetaKmsImpl implementation may need to add a GSource that should be invoked in the right context; e.g. a idle callback, timeout etc. It cannot just add it itself, since it's the responsibility of MetaKms to determine what is the impl context and what is the main context, so add API to MetaKms to ensure the callback is invoked correctly. It's the responsibility of the caller to eventually remove and destroy the GSource. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-03-10 08:40:30 -04:00
kms: Add API to register impl file descriptors To let the MetaKmsImpl implementation register file descriptor GSource where the invoke function is ensured to be executed in the impl context. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-03-10 08:48:18 -04:00
GSource * meta_kms_register_fd_in_impl (MetaKms *kms,
int fd,
MetaKmsImplTaskFunc dispatch,
gpointer user_data);
tests/kms: Check predicted state is correctly predicted When we're predicting state, i.e. when having posted an update while avoiding reading KMS state, copy the predicted state, update the actual state, and check that the predicted state matches the newly updated one. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
2021-06-28 03:20:10 -04:00
META_EXPORT_TEST
kms: Rename MetaKmsUpdateChanges to MetaKmsResourceChanges The name had a bit conceptual conflicts with MetaKmsUpdate, as it shared its namespace but had no relation to it. Fix this by renaming it MetaKmsResourceChanges (and the corresponding META_KMS_UPDATE_CHANGE_* to META_KMS_RESOURCE_CHANGE_*). The term "resource" is used since that's already used in the signal, and the fact that the changes partly comes from changes in the DRM resource as retrieved by drmModeGetResources. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2340>
2022-03-17 05:22:05 -04:00
MetaKmsResourceChanges meta_kms_update_states_sync (MetaKms *kms,
GUdevDevice *udev_device);
tests/kms: Check predicted state is correctly predicted When we're predicting state, i.e. when having posted an update while avoiding reading KMS state, copy the predicted state, update the actual state, and check that the predicted state matches the newly updated one. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
2021-06-28 03:20:10 -04:00
backends/native: Add basic KMS abstraction building blocks The intention with KMS abstraction is to hide away accessing the drm functions behind an API that allows us to have different kind of KMS implementations, including legacy non-atomic and atomic. The intention is also that the code interacting with the drm device should be able to be run in a different thread than the main thread. This means that we need to make sure that all drm*() API usage must only occur from within tasks that eventually can be run in the dedicated thread. The idea here is that MetaKms provides a outward facing API other places of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is an internal implementation that only gets interacted with via "tasks" posted via the MetaKms object. These tasks will in the future potentially be run on the dedicated KMS thread. Initially, we don't create any new threads. Likewise, MetaKmsDevice is a outward facing representation of a KMS device, while MetaKmsImplDevice is the corresponding implementation, which only runs from within the MetaKmsImpl tasks. This commit only moves opening and closing the device to this new API, while leaking the fd outside of the impl enclosure, effectively making the isolation for drm*() calls pointless. This, however, is necessary to allow gradual porting of drm interaction, and eventually the file descriptor in MetaGpuKms will be removed. For now, it's harmless, since everything still run in the main thread. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 04:24:44 -05:00
gboolean meta_kms_in_impl_task (MetaKms *kms);
kms: Add assert to check that the main thread is blocked on impl task This is so that we can have code in impl tasks that pokes at the main context objects. https://gitlab.gnome.org/GNOME/mutter/merge_requests/743
2019-09-03 13:12:10 -04:00
gboolean meta_kms_is_waiting_for_impl_task (MetaKms *kms);
kms: Notify about privacy screen changes via predictions When we change the privacy screen, we added a result listener to the KMS update object to notify the upper layer about the privacy screen state change. This was slightly awkward as one might have changed the state multiple times for a single update, thus it was necessary to remove any old result listeners to an update before adding a new one. Doing this will not be possible when updates are fully async and managed by the KMS impl device. To handle this, instead make the post-commit prediction notify about changes that happens in response to a successfully committed update. We already predicted the new privacy screen state, so the necessary change was to plumb the actual change into a callback which emits the signal if there actually was a privacy screen change. This will then be communicated via the same signal listener that already listens to the 'resources-changed' signal. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2340>
2022-03-17 05:33:23 -04:00
void meta_kms_emit_resources_changed (MetaKms *kms,
MetaKmsResourceChanges changes);
backends/native: Add basic KMS abstraction building blocks The intention with KMS abstraction is to hide away accessing the drm functions behind an API that allows us to have different kind of KMS implementations, including legacy non-atomic and atomic. The intention is also that the code interacting with the drm device should be able to be run in a different thread than the main thread. This means that we need to make sure that all drm*() API usage must only occur from within tasks that eventually can be run in the dedicated thread. The idea here is that MetaKms provides a outward facing API other places of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is an internal implementation that only gets interacted with via "tasks" posted via the MetaKms object. These tasks will in the future potentially be run on the dedicated KMS thread. Initially, we don't create any new threads. Likewise, MetaKmsDevice is a outward facing representation of a KMS device, while MetaKmsImplDevice is the corresponding implementation, which only runs from within the MetaKmsImpl tasks. This commit only moves opening and closing the device to this new API, while leaking the fd outside of the impl enclosure, effectively making the isolation for drm*() calls pointless. This, however, is necessary to allow gradual porting of drm interaction, and eventually the file descriptor in MetaGpuKms will be removed. For now, it's harmless, since everything still run in the main thread. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 04:24:44 -05:00
#define meta_assert_in_kms_impl(kms) \
g_assert (meta_kms_in_impl_task (kms))
#define meta_assert_not_in_kms_impl(kms) \
g_assert (!meta_kms_in_impl_task (kms))
kms: Add assert to check that the main thread is blocked on impl task This is so that we can have code in impl tasks that pokes at the main context objects. https://gitlab.gnome.org/GNOME/mutter/merge_requests/743
2019-09-03 13:12:10 -04:00
#define meta_assert_is_waiting_for_kms_impl_task(kms) \
g_assert (meta_kms_is_waiting_for_impl_task (kms))
backends/native: Add basic KMS abstraction building blocks The intention with KMS abstraction is to hide away accessing the drm functions behind an API that allows us to have different kind of KMS implementations, including legacy non-atomic and atomic. The intention is also that the code interacting with the drm device should be able to be run in a different thread than the main thread. This means that we need to make sure that all drm*() API usage must only occur from within tasks that eventually can be run in the dedicated thread. The idea here is that MetaKms provides a outward facing API other places of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is an internal implementation that only gets interacted with via "tasks" posted via the MetaKms object. These tasks will in the future potentially be run on the dedicated KMS thread. Initially, we don't create any new threads. Likewise, MetaKmsDevice is a outward facing representation of a KMS device, while MetaKmsImplDevice is the corresponding implementation, which only runs from within the MetaKmsImpl tasks. This commit only moves opening and closing the device to this new API, while leaking the fd outside of the impl enclosure, effectively making the isolation for drm*() calls pointless. This, however, is necessary to allow gradual porting of drm interaction, and eventually the file descriptor in MetaGpuKms will be removed. For now, it's harmless, since everything still run in the main thread. https://gitlab.gnome.org/GNOME/mutter/issues/548 https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 04:24:44 -05:00
#endif /* META_KMS_PRIVATE_H */
Reference in New Issue Copy Permalink