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 09:24:44 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2019 Red Hat
|
2019-11-29 10:50:30 +00:00
|
|
|
* Copyright (C) 2019 DisplayLink (UK) Ltd.
|
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 09:24:44 +00:00
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License as
|
|
|
|
* published by the Free Software Foundation; either version 2 of the
|
|
|
|
* License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
|
|
|
|
* 02111-1307, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
|
2020-08-04 17:03:17 +00:00
|
|
|
#include "backends/native/meta-kms-connector.h"
|
|
|
|
#include "backends/native/meta-kms-crtc.h"
|
2019-03-08 18:19:18 +00:00
|
|
|
#include "backends/native/meta-kms-device-private.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 09:24:44 +00:00
|
|
|
#include "backends/native/meta-kms-device.h"
|
|
|
|
|
kms: Add way to run without mode setting
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 13:54:45 +00:00
|
|
|
#include <fcntl.h>
|
|
|
|
#include <sys/stat.h>
|
|
|
|
#include <sys/types.h>
|
2020-07-16 20:17:04 +00:00
|
|
|
#include <xf86drm.h>
|
|
|
|
|
2021-03-31 16:34:45 +00:00
|
|
|
#include "backends/native/meta-backend-native-private.h"
|
|
|
|
#include "backends/native/meta-device-pool.h"
|
2020-10-09 23:25:06 +00:00
|
|
|
#include "backends/native/meta-kms-impl-device-atomic.h"
|
kms: Add way to run without mode setting
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 13:54:45 +00:00
|
|
|
#include "backends/native/meta-kms-impl-device-dummy.h"
|
2020-07-17 07:38:11 +00:00
|
|
|
#include "backends/native/meta-kms-impl-device-simple.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 09:24:44 +00:00
|
|
|
#include "backends/native/meta-kms-impl-device.h"
|
|
|
|
#include "backends/native/meta-kms-impl.h"
|
2019-03-09 17:23:28 +00:00
|
|
|
#include "backends/native/meta-kms-plane.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 09:24:44 +00:00
|
|
|
#include "backends/native/meta-kms-private.h"
|
2021-06-24 10:30:00 +00:00
|
|
|
#include "backends/native/meta-kms-update-private.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 09:24:44 +00:00
|
|
|
|
|
|
|
struct _MetaKmsDevice
|
|
|
|
{
|
|
|
|
GObject parent;
|
|
|
|
|
|
|
|
MetaKms *kms;
|
|
|
|
|
|
|
|
MetaKmsImplDevice *impl_device;
|
|
|
|
|
|
|
|
MetaKmsDeviceFlag flags;
|
|
|
|
char *path;
|
2020-06-17 15:49:12 +00:00
|
|
|
char *driver_name;
|
|
|
|
char *driver_description;
|
2019-01-29 17:33:00 +00:00
|
|
|
|
|
|
|
GList *crtcs;
|
2019-03-08 15:23:15 +00:00
|
|
|
GList *connectors;
|
kms: Add plane representation
A plane is one of three possible: primary, overlay and cursor. Each
plane can have various properties, such as possible rotations, formats
etc. Each plane can also be used with a set of CRTCs.
A primary plane is the "backdrop" of a CRTC, i.e. the primary output for
the composited frame that covers the whole CRTC. In general, mutter
composites to a stage view frame onto a framebuffer that is then put on
the primary plane.
An overlay plane is a rectangular area that can be displayed on top of
the primary plane. Eventually it will be used to place non-fullscreen
surfaces, potentially avoiding stage redraws.
A cursor plane is a plane placed on top of all the other planes, usually
used to put the mouse cursor sprite.
Initially, we only fetch the rotation properties, and we so far
blacklist all rotations except ones that ends up with the same
dimensions as with no rotations. This is because non-180° rotations
doesn't work yet due to incorrect buffer modifiers. To make it possible
to use non-180° rotations, changes necessary include among other things
finding compatible modifiers using atomic modesetting. Until then,
simply blacklist the ones we know doesn't work.
https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-31 17:48:19 +00:00
|
|
|
GList *planes;
|
2019-11-11 17:05:32 +00:00
|
|
|
|
|
|
|
MetaKmsDeviceCaps caps;
|
2020-07-02 09:54:56 +00:00
|
|
|
|
|
|
|
GList *fallback_modes;
|
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 09:24:44 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
G_DEFINE_TYPE (MetaKmsDevice, meta_kms_device, G_TYPE_OBJECT);
|
|
|
|
|
2020-07-16 21:38:10 +00:00
|
|
|
MetaKms *
|
|
|
|
meta_kms_device_get_kms (MetaKmsDevice *device)
|
|
|
|
{
|
|
|
|
return device->kms;
|
|
|
|
}
|
|
|
|
|
2019-03-08 18:19:18 +00:00
|
|
|
MetaKmsImplDevice *
|
|
|
|
meta_kms_device_get_impl_device (MetaKmsDevice *device)
|
|
|
|
{
|
|
|
|
return device->impl_device;
|
|
|
|
}
|
|
|
|
|
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 09:24:44 +00:00
|
|
|
const char *
|
|
|
|
meta_kms_device_get_path (MetaKmsDevice *device)
|
|
|
|
{
|
|
|
|
return device->path;
|
|
|
|
}
|
|
|
|
|
2020-06-17 15:49:12 +00:00
|
|
|
const char *
|
|
|
|
meta_kms_device_get_driver_name (MetaKmsDevice *device)
|
|
|
|
{
|
|
|
|
return device->driver_name;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *
|
|
|
|
meta_kms_device_get_driver_description (MetaKmsDevice *device)
|
|
|
|
{
|
|
|
|
return device->driver_description;
|
|
|
|
}
|
|
|
|
|
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 09:24:44 +00:00
|
|
|
MetaKmsDeviceFlag
|
|
|
|
meta_kms_device_get_flags (MetaKmsDevice *device)
|
|
|
|
{
|
|
|
|
return device->flags;
|
|
|
|
}
|
|
|
|
|
2019-11-11 17:05:32 +00:00
|
|
|
gboolean
|
|
|
|
meta_kms_device_get_cursor_size (MetaKmsDevice *device,
|
|
|
|
uint64_t *out_cursor_width,
|
|
|
|
uint64_t *out_cursor_height)
|
|
|
|
{
|
|
|
|
if (device->caps.has_cursor_size)
|
|
|
|
{
|
|
|
|
*out_cursor_width = device->caps.cursor_width;
|
|
|
|
*out_cursor_height = device->caps.cursor_height;
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-03-29 09:48:59 +00:00
|
|
|
gboolean
|
|
|
|
meta_kms_device_prefers_shadow_buffer (MetaKmsDevice *device)
|
|
|
|
{
|
|
|
|
return device->caps.prefers_shadow_buffer;
|
|
|
|
}
|
|
|
|
|
2021-03-29 09:56:49 +00:00
|
|
|
gboolean
|
|
|
|
meta_kms_device_uses_monotonic_clock (MetaKmsDevice *device)
|
|
|
|
{
|
|
|
|
return device->caps.uses_monotonic_clock;
|
|
|
|
}
|
|
|
|
|
2019-03-08 15:23:15 +00:00
|
|
|
GList *
|
|
|
|
meta_kms_device_get_connectors (MetaKmsDevice *device)
|
|
|
|
{
|
|
|
|
return device->connectors;
|
|
|
|
}
|
|
|
|
|
2020-08-04 17:03:17 +00:00
|
|
|
MetaKmsCrtc *
|
|
|
|
meta_kms_device_find_crtc_in_impl (MetaKmsDevice *device,
|
|
|
|
uint32_t crtc_id)
|
|
|
|
{
|
|
|
|
MetaKmsImplDevice *impl_device = meta_kms_device_get_impl_device (device);
|
|
|
|
GList *l;
|
|
|
|
|
|
|
|
meta_assert_in_kms_impl (device->kms);
|
|
|
|
meta_assert_is_waiting_for_kms_impl_task (device->kms);
|
|
|
|
|
|
|
|
for (l = meta_kms_impl_device_peek_crtcs (impl_device); l; l = l->next)
|
|
|
|
{
|
|
|
|
MetaKmsCrtc *crtc = META_KMS_CRTC (l->data);
|
|
|
|
|
|
|
|
if (meta_kms_crtc_get_id (crtc) == crtc_id)
|
|
|
|
return crtc;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
MetaKmsConnector *
|
|
|
|
meta_kms_device_find_connector_in_impl (MetaKmsDevice *device,
|
|
|
|
uint32_t connector_id)
|
|
|
|
{
|
|
|
|
MetaKmsImplDevice *impl_device = meta_kms_device_get_impl_device (device);
|
|
|
|
GList *l;
|
|
|
|
|
|
|
|
meta_assert_in_kms_impl (device->kms);
|
|
|
|
meta_assert_is_waiting_for_kms_impl_task (device->kms);
|
|
|
|
|
|
|
|
for (l = meta_kms_impl_device_peek_connectors (impl_device); l; l = l->next)
|
|
|
|
{
|
|
|
|
MetaKmsConnector *connector = META_KMS_CONNECTOR (l->data);
|
|
|
|
|
|
|
|
if (meta_kms_connector_get_id (connector) == connector_id)
|
|
|
|
return connector;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2019-01-29 17:33:00 +00:00
|
|
|
GList *
|
|
|
|
meta_kms_device_get_crtcs (MetaKmsDevice *device)
|
|
|
|
{
|
|
|
|
return device->crtcs;
|
|
|
|
}
|
|
|
|
|
2020-10-09 23:41:52 +00:00
|
|
|
GList *
|
2019-03-09 17:23:28 +00:00
|
|
|
meta_kms_device_get_planes (MetaKmsDevice *device)
|
|
|
|
{
|
|
|
|
return device->planes;
|
|
|
|
}
|
|
|
|
|
2019-11-08 10:31:29 +00:00
|
|
|
static MetaKmsPlane *
|
|
|
|
get_plane_with_type_for (MetaKmsDevice *device,
|
|
|
|
MetaKmsCrtc *crtc,
|
|
|
|
MetaKmsPlaneType type)
|
2019-03-09 17:23:28 +00:00
|
|
|
{
|
|
|
|
GList *l;
|
|
|
|
|
|
|
|
for (l = meta_kms_device_get_planes (device); l; l = l->next)
|
|
|
|
{
|
|
|
|
MetaKmsPlane *plane = l->data;
|
|
|
|
|
2019-11-08 10:31:29 +00:00
|
|
|
if (meta_kms_plane_get_plane_type (plane) != type)
|
2019-03-09 17:23:28 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
if (meta_kms_plane_is_usable_with (plane, crtc))
|
|
|
|
return plane;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2019-11-08 10:31:29 +00:00
|
|
|
MetaKmsPlane *
|
|
|
|
meta_kms_device_get_primary_plane_for (MetaKmsDevice *device,
|
|
|
|
MetaKmsCrtc *crtc)
|
|
|
|
{
|
|
|
|
return get_plane_with_type_for (device, crtc, META_KMS_PLANE_TYPE_PRIMARY);
|
|
|
|
}
|
|
|
|
|
|
|
|
MetaKmsPlane *
|
|
|
|
meta_kms_device_get_cursor_plane_for (MetaKmsDevice *device,
|
|
|
|
MetaKmsCrtc *crtc)
|
|
|
|
{
|
|
|
|
return get_plane_with_type_for (device, crtc, META_KMS_PLANE_TYPE_CURSOR);
|
|
|
|
}
|
|
|
|
|
2020-07-02 09:54:56 +00:00
|
|
|
GList *
|
|
|
|
meta_kms_device_get_fallback_modes (MetaKmsDevice *device)
|
|
|
|
{
|
|
|
|
return device->fallback_modes;
|
|
|
|
}
|
|
|
|
|
2021-06-28 08:11:31 +00:00
|
|
|
static gpointer
|
|
|
|
disable_device_in_impl (MetaKmsImpl *impl,
|
|
|
|
gpointer user_data,
|
|
|
|
GError **error)
|
|
|
|
{
|
|
|
|
MetaKmsImplDevice *impl_device = user_data;
|
|
|
|
|
|
|
|
meta_kms_impl_device_disable (impl_device);
|
|
|
|
|
|
|
|
return GINT_TO_POINTER (TRUE);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
meta_kms_device_disable (MetaKmsDevice *device)
|
|
|
|
{
|
|
|
|
meta_assert_not_in_kms_impl (device->kms);
|
|
|
|
|
|
|
|
meta_kms_run_impl_task_sync (device->kms, disable_device_in_impl,
|
|
|
|
device->impl_device,
|
|
|
|
NULL);
|
|
|
|
}
|
|
|
|
|
2022-03-17 09:22:05 +00:00
|
|
|
MetaKmsResourceChanges
|
2020-08-04 17:28:04 +00:00
|
|
|
meta_kms_device_update_states_in_impl (MetaKmsDevice *device,
|
|
|
|
uint32_t crtc_id,
|
|
|
|
uint32_t connector_id)
|
2019-08-22 12:26:54 +00:00
|
|
|
{
|
|
|
|
MetaKmsImplDevice *impl_device = meta_kms_device_get_impl_device (device);
|
2022-03-17 09:22:05 +00:00
|
|
|
MetaKmsResourceChanges changes;
|
2019-08-22 12:26:54 +00:00
|
|
|
|
|
|
|
meta_assert_in_kms_impl (device->kms);
|
2019-10-04 09:54:29 +00:00
|
|
|
meta_assert_is_waiting_for_kms_impl_task (device->kms);
|
2019-08-22 12:26:54 +00:00
|
|
|
|
2020-08-04 17:28:04 +00:00
|
|
|
changes = meta_kms_impl_device_update_states (impl_device, crtc_id,
|
|
|
|
connector_id);
|
2020-07-31 19:37:17 +00:00
|
|
|
|
2022-03-17 09:22:05 +00:00
|
|
|
if (changes == META_KMS_RESOURCE_CHANGE_NONE)
|
2020-07-31 19:37:17 +00:00
|
|
|
return changes;
|
2019-08-22 12:26:54 +00:00
|
|
|
|
2019-10-04 09:54:29 +00:00
|
|
|
g_list_free (device->crtcs);
|
|
|
|
device->crtcs = meta_kms_impl_device_copy_crtcs (impl_device);
|
2019-08-22 12:26:54 +00:00
|
|
|
|
2019-10-04 09:54:29 +00:00
|
|
|
g_list_free (device->connectors);
|
|
|
|
device->connectors = meta_kms_impl_device_copy_connectors (impl_device);
|
2019-08-22 12:26:54 +00:00
|
|
|
|
2019-10-04 09:54:29 +00:00
|
|
|
g_list_free (device->planes);
|
|
|
|
device->planes = meta_kms_impl_device_copy_planes (impl_device);
|
2020-07-31 19:37:17 +00:00
|
|
|
|
|
|
|
return changes;
|
2019-10-04 09:54:29 +00:00
|
|
|
}
|
2019-08-22 12:26:54 +00:00
|
|
|
|
2021-06-24 10:30:00 +00:00
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
MetaKmsUpdate *update;
|
|
|
|
MetaKmsUpdateFlag flags;
|
|
|
|
} PostUpdateData;
|
|
|
|
|
|
|
|
static gpointer
|
|
|
|
process_update_in_impl (MetaKmsImpl *impl,
|
|
|
|
gpointer user_data,
|
|
|
|
GError **error)
|
2019-10-04 09:54:29 +00:00
|
|
|
{
|
2021-06-24 10:30:00 +00:00
|
|
|
PostUpdateData *data = user_data;
|
|
|
|
MetaKmsUpdate *update = data->update;
|
|
|
|
MetaKmsDevice *device = meta_kms_update_get_device (update);
|
2019-10-04 09:54:29 +00:00
|
|
|
MetaKmsImplDevice *impl_device = meta_kms_device_get_impl_device (device);
|
|
|
|
|
2021-06-24 10:30:00 +00:00
|
|
|
return meta_kms_impl_device_process_update (impl_device, update, data->flags);
|
|
|
|
}
|
2019-10-04 09:54:29 +00:00
|
|
|
|
2021-06-24 10:30:00 +00:00
|
|
|
MetaKmsFeedback *
|
|
|
|
meta_kms_device_process_update_sync (MetaKmsDevice *device,
|
|
|
|
MetaKmsUpdate *update,
|
|
|
|
MetaKmsUpdateFlag flags)
|
|
|
|
{
|
|
|
|
MetaKms *kms = META_KMS (meta_kms_device_get_kms (device));
|
|
|
|
PostUpdateData data;
|
|
|
|
|
|
|
|
data = (PostUpdateData) {
|
|
|
|
.update = update,
|
|
|
|
.flags = flags,
|
|
|
|
};
|
|
|
|
return meta_kms_run_impl_task_sync (kms, process_update_in_impl,
|
|
|
|
&data, NULL);
|
2019-08-22 12:26:54 +00:00
|
|
|
}
|
|
|
|
|
2020-02-21 11:06:28 +00:00
|
|
|
void
|
|
|
|
meta_kms_device_add_fake_plane_in_impl (MetaKmsDevice *device,
|
|
|
|
MetaKmsPlaneType plane_type,
|
|
|
|
MetaKmsCrtc *crtc)
|
|
|
|
{
|
|
|
|
MetaKmsImplDevice *impl_device = device->impl_device;
|
|
|
|
MetaKmsPlane *plane;
|
|
|
|
|
|
|
|
meta_assert_in_kms_impl (device->kms);
|
|
|
|
|
|
|
|
plane = meta_kms_impl_device_add_fake_plane (impl_device,
|
|
|
|
plane_type,
|
|
|
|
crtc);
|
|
|
|
device->planes = g_list_append (device->planes, plane);
|
|
|
|
}
|
|
|
|
|
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 09:24:44 +00:00
|
|
|
typedef struct _CreateImplDeviceData
|
|
|
|
{
|
|
|
|
MetaKmsDevice *device;
|
2020-09-29 14:43:04 +00:00
|
|
|
const char *path;
|
kms: Add way to run without mode setting
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 13:54:45 +00:00
|
|
|
MetaKmsDeviceFlag flags;
|
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 09:24:44 +00:00
|
|
|
|
|
|
|
MetaKmsImplDevice *out_impl_device;
|
2019-01-29 17:33:00 +00:00
|
|
|
GList *out_crtcs;
|
2019-03-08 15:23:15 +00:00
|
|
|
GList *out_connectors;
|
kms: Add plane representation
A plane is one of three possible: primary, overlay and cursor. Each
plane can have various properties, such as possible rotations, formats
etc. Each plane can also be used with a set of CRTCs.
A primary plane is the "backdrop" of a CRTC, i.e. the primary output for
the composited frame that covers the whole CRTC. In general, mutter
composites to a stage view frame onto a framebuffer that is then put on
the primary plane.
An overlay plane is a rectangular area that can be displayed on top of
the primary plane. Eventually it will be used to place non-fullscreen
surfaces, potentially avoiding stage redraws.
A cursor plane is a plane placed on top of all the other planes, usually
used to put the mouse cursor sprite.
Initially, we only fetch the rotation properties, and we so far
blacklist all rotations except ones that ends up with the same
dimensions as with no rotations. This is because non-180° rotations
doesn't work yet due to incorrect buffer modifiers. To make it possible
to use non-180° rotations, changes necessary include among other things
finding compatible modifiers using atomic modesetting. Until then,
simply blacklist the ones we know doesn't work.
https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-31 17:48:19 +00:00
|
|
|
GList *out_planes;
|
2019-11-11 17:05:32 +00:00
|
|
|
MetaKmsDeviceCaps out_caps;
|
2020-07-02 09:54:56 +00:00
|
|
|
GList *out_fallback_modes;
|
2020-06-17 15:49:12 +00:00
|
|
|
char *out_driver_name;
|
|
|
|
char *out_driver_description;
|
kms: Add way to run without mode setting
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 13:54:45 +00:00
|
|
|
char *out_path;
|
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 09:24:44 +00:00
|
|
|
} CreateImplDeviceData;
|
|
|
|
|
2021-04-06 10:14:24 +00:00
|
|
|
static const char *
|
|
|
|
impl_device_type_to_string (GType type)
|
2020-10-09 23:25:06 +00:00
|
|
|
{
|
2021-04-06 10:14:24 +00:00
|
|
|
if (type == META_TYPE_KMS_IMPL_DEVICE_ATOMIC)
|
|
|
|
return "atomic modesetting";
|
|
|
|
else if (type == META_TYPE_KMS_IMPL_DEVICE_SIMPLE)
|
|
|
|
return "legacy modesetting";
|
|
|
|
else if (type == META_TYPE_KMS_IMPL_DEVICE_DUMMY)
|
|
|
|
return "no modesetting";
|
|
|
|
g_assert_not_reached();
|
2020-09-29 14:39:12 +00:00
|
|
|
}
|
|
|
|
|
2020-07-16 20:17:04 +00:00
|
|
|
static MetaKmsImplDevice *
|
kms: Add way to run without mode setting
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 13:54:45 +00:00
|
|
|
meta_create_kms_impl_device (MetaKmsDevice *device,
|
|
|
|
MetaKmsImpl *impl,
|
|
|
|
const char *path,
|
|
|
|
MetaKmsDeviceFlag flags,
|
|
|
|
GError **error)
|
2020-07-16 20:17:04 +00:00
|
|
|
{
|
|
|
|
meta_assert_in_kms_impl (meta_kms_impl_get_kms (impl));
|
|
|
|
|
kms: Add way to run without mode setting
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 13:54:45 +00:00
|
|
|
if (flags & META_KMS_DEVICE_FLAG_NO_MODE_SETTING)
|
|
|
|
{
|
2021-04-06 10:14:24 +00:00
|
|
|
return g_initable_new (META_TYPE_KMS_IMPL_DEVICE_DUMMY,
|
|
|
|
NULL, error,
|
|
|
|
"device", device,
|
|
|
|
"impl", impl,
|
|
|
|
"path", path,
|
|
|
|
"flags", flags,
|
|
|
|
NULL);
|
2020-10-09 23:25:06 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2021-04-06 10:14:24 +00:00
|
|
|
GType impl_device_types[] = {
|
|
|
|
META_TYPE_KMS_IMPL_DEVICE_ATOMIC,
|
|
|
|
META_TYPE_KMS_IMPL_DEVICE_SIMPLE,
|
|
|
|
};
|
|
|
|
int i;
|
2021-01-18 17:30:02 +00:00
|
|
|
|
2021-04-06 10:14:24 +00:00
|
|
|
for (i = 0; i < G_N_ELEMENTS (impl_device_types); i++)
|
2020-10-09 23:25:06 +00:00
|
|
|
{
|
2021-04-06 10:14:24 +00:00
|
|
|
MetaKmsImplDevice *impl_device;
|
|
|
|
g_autoptr (GError) local_error = NULL;
|
|
|
|
|
|
|
|
impl_device = g_initable_new (impl_device_types[i],
|
|
|
|
NULL, &local_error,
|
|
|
|
"device", device,
|
|
|
|
"impl", impl,
|
|
|
|
"path", path,
|
|
|
|
"flags", flags,
|
|
|
|
NULL);
|
|
|
|
if (impl_device)
|
|
|
|
return impl_device;
|
|
|
|
|
|
|
|
if (local_error->domain != META_KMS_ERROR)
|
|
|
|
{
|
|
|
|
g_warning ("Failed to open %s backend: %s",
|
|
|
|
impl_device_type_to_string (impl_device_types[i]),
|
|
|
|
local_error->message);
|
|
|
|
}
|
2020-10-09 23:25:06 +00:00
|
|
|
}
|
kms: Add way to run without mode setting
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 13:54:45 +00:00
|
|
|
|
2021-07-09 08:26:11 +00:00
|
|
|
g_set_error (error, G_IO_ERROR, G_IO_ERROR_FAILED,
|
|
|
|
"No suitable mode setting backend found");
|
|
|
|
|
2021-04-06 10:14:24 +00:00
|
|
|
return NULL;
|
kms: Add way to run without mode setting
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 13:54:45 +00:00
|
|
|
}
|
2020-07-16 20:17:04 +00:00
|
|
|
}
|
|
|
|
|
2019-11-08 22:47:48 +00:00
|
|
|
static gpointer
|
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 09:24:44 +00:00
|
|
|
create_impl_device_in_impl (MetaKmsImpl *impl,
|
|
|
|
gpointer user_data,
|
|
|
|
GError **error)
|
|
|
|
{
|
|
|
|
CreateImplDeviceData *data = user_data;
|
|
|
|
MetaKmsImplDevice *impl_device;
|
|
|
|
|
2020-07-16 20:17:04 +00:00
|
|
|
impl_device = meta_create_kms_impl_device (data->device,
|
|
|
|
impl,
|
2020-09-29 14:43:04 +00:00
|
|
|
data->path,
|
kms: Add way to run without mode setting
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 13:54:45 +00:00
|
|
|
data->flags,
|
2020-07-16 20:17:04 +00:00
|
|
|
error);
|
2019-07-01 08:49:03 +00:00
|
|
|
if (!impl_device)
|
|
|
|
return FALSE;
|
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 09:24:44 +00:00
|
|
|
|
2020-07-16 21:29:31 +00:00
|
|
|
meta_kms_impl_add_impl_device (impl, impl_device);
|
|
|
|
|
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 09:24:44 +00:00
|
|
|
data->out_impl_device = impl_device;
|
2019-01-29 17:33:00 +00:00
|
|
|
data->out_crtcs = meta_kms_impl_device_copy_crtcs (impl_device);
|
2019-03-08 15:23:15 +00:00
|
|
|
data->out_connectors = meta_kms_impl_device_copy_connectors (impl_device);
|
kms: Add plane representation
A plane is one of three possible: primary, overlay and cursor. Each
plane can have various properties, such as possible rotations, formats
etc. Each plane can also be used with a set of CRTCs.
A primary plane is the "backdrop" of a CRTC, i.e. the primary output for
the composited frame that covers the whole CRTC. In general, mutter
composites to a stage view frame onto a framebuffer that is then put on
the primary plane.
An overlay plane is a rectangular area that can be displayed on top of
the primary plane. Eventually it will be used to place non-fullscreen
surfaces, potentially avoiding stage redraws.
A cursor plane is a plane placed on top of all the other planes, usually
used to put the mouse cursor sprite.
Initially, we only fetch the rotation properties, and we so far
blacklist all rotations except ones that ends up with the same
dimensions as with no rotations. This is because non-180° rotations
doesn't work yet due to incorrect buffer modifiers. To make it possible
to use non-180° rotations, changes necessary include among other things
finding compatible modifiers using atomic modesetting. Until then,
simply blacklist the ones we know doesn't work.
https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-31 17:48:19 +00:00
|
|
|
data->out_planes = meta_kms_impl_device_copy_planes (impl_device);
|
2019-11-11 17:05:32 +00:00
|
|
|
data->out_caps = *meta_kms_impl_device_get_caps (impl_device);
|
2020-07-02 09:54:56 +00:00
|
|
|
data->out_fallback_modes =
|
|
|
|
meta_kms_impl_device_copy_fallback_modes (impl_device);
|
2020-06-17 15:49:12 +00:00
|
|
|
data->out_driver_name =
|
|
|
|
g_strdup (meta_kms_impl_device_get_driver_name (impl_device));
|
|
|
|
data->out_driver_description =
|
|
|
|
g_strdup (meta_kms_impl_device_get_driver_description (impl_device));
|
kms: Add way to run without mode setting
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 13:54:45 +00:00
|
|
|
data->out_path = g_strdup (meta_kms_impl_device_get_path (impl_device));
|
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 09:24:44 +00:00
|
|
|
|
2019-11-08 22:47:48 +00:00
|
|
|
return GINT_TO_POINTER (TRUE);
|
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 09:24:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
MetaKmsDevice *
|
|
|
|
meta_kms_device_new (MetaKms *kms,
|
|
|
|
const char *path,
|
|
|
|
MetaKmsDeviceFlag flags,
|
|
|
|
GError **error)
|
|
|
|
{
|
|
|
|
MetaKmsDevice *device;
|
|
|
|
CreateImplDeviceData data;
|
|
|
|
|
|
|
|
device = g_object_new (META_TYPE_KMS_DEVICE, NULL);
|
2019-09-16 16:34:39 +00:00
|
|
|
device->kms = 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 09:24:44 +00:00
|
|
|
|
|
|
|
data = (CreateImplDeviceData) {
|
|
|
|
.device = device,
|
2020-09-29 14:43:04 +00:00
|
|
|
.path = path,
|
kms: Add way to run without mode setting
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 13:54:45 +00:00
|
|
|
.flags = flags,
|
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 09:24:44 +00:00
|
|
|
};
|
|
|
|
if (!meta_kms_run_impl_task_sync (kms, create_impl_device_in_impl, &data,
|
|
|
|
error))
|
|
|
|
{
|
|
|
|
g_object_unref (device);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
device->impl_device = data.out_impl_device;
|
|
|
|
device->flags = flags;
|
|
|
|
device->path = g_strdup (path);
|
2019-01-29 17:33:00 +00:00
|
|
|
device->crtcs = data.out_crtcs;
|
2019-03-08 15:23:15 +00:00
|
|
|
device->connectors = data.out_connectors;
|
kms: Add plane representation
A plane is one of three possible: primary, overlay and cursor. Each
plane can have various properties, such as possible rotations, formats
etc. Each plane can also be used with a set of CRTCs.
A primary plane is the "backdrop" of a CRTC, i.e. the primary output for
the composited frame that covers the whole CRTC. In general, mutter
composites to a stage view frame onto a framebuffer that is then put on
the primary plane.
An overlay plane is a rectangular area that can be displayed on top of
the primary plane. Eventually it will be used to place non-fullscreen
surfaces, potentially avoiding stage redraws.
A cursor plane is a plane placed on top of all the other planes, usually
used to put the mouse cursor sprite.
Initially, we only fetch the rotation properties, and we so far
blacklist all rotations except ones that ends up with the same
dimensions as with no rotations. This is because non-180° rotations
doesn't work yet due to incorrect buffer modifiers. To make it possible
to use non-180° rotations, changes necessary include among other things
finding compatible modifiers using atomic modesetting. Until then,
simply blacklist the ones we know doesn't work.
https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-31 17:48:19 +00:00
|
|
|
device->planes = data.out_planes;
|
2019-11-11 17:05:32 +00:00
|
|
|
device->caps = data.out_caps;
|
2020-07-02 09:54:56 +00:00
|
|
|
device->fallback_modes = data.out_fallback_modes;
|
2020-06-17 15:49:12 +00:00
|
|
|
device->driver_name = data.out_driver_name;
|
|
|
|
device->driver_description = data.out_driver_description;
|
kms: Add way to run without mode setting
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
2021-01-19 13:54:45 +00:00
|
|
|
free (device->path);
|
|
|
|
device->path = data.out_path;
|
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 09:24:44 +00:00
|
|
|
|
2022-04-05 09:06:21 +00:00
|
|
|
if (!device->caps.addfb2_modifiers)
|
|
|
|
device->flags |= META_KMS_DEVICE_FLAG_DISABLE_MODIFIERS;
|
|
|
|
|
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 09:24:44 +00:00
|
|
|
return device;
|
|
|
|
}
|
|
|
|
|
2019-11-08 22:47:48 +00:00
|
|
|
static gpointer
|
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 09:24:44 +00:00
|
|
|
free_impl_device_in_impl (MetaKmsImpl *impl,
|
|
|
|
gpointer user_data,
|
|
|
|
GError **error)
|
|
|
|
{
|
2021-03-31 16:34:45 +00:00
|
|
|
MetaKmsImplDevice *impl_device = user_data;
|
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 09:24:44 +00:00
|
|
|
|
|
|
|
g_object_unref (impl_device);
|
|
|
|
|
2019-11-08 22:47:48 +00:00
|
|
|
return GINT_TO_POINTER (TRUE);
|
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 09:24:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
meta_kms_device_finalize (GObject *object)
|
|
|
|
{
|
|
|
|
MetaKmsDevice *device = META_KMS_DEVICE (object);
|
|
|
|
|
2019-09-16 16:41:46 +00:00
|
|
|
g_free (device->path);
|
2019-01-29 17:33:00 +00:00
|
|
|
g_list_free (device->crtcs);
|
2019-03-08 15:23:15 +00:00
|
|
|
g_list_free (device->connectors);
|
kms: Add plane representation
A plane is one of three possible: primary, overlay and cursor. Each
plane can have various properties, such as possible rotations, formats
etc. Each plane can also be used with a set of CRTCs.
A primary plane is the "backdrop" of a CRTC, i.e. the primary output for
the composited frame that covers the whole CRTC. In general, mutter
composites to a stage view frame onto a framebuffer that is then put on
the primary plane.
An overlay plane is a rectangular area that can be displayed on top of
the primary plane. Eventually it will be used to place non-fullscreen
surfaces, potentially avoiding stage redraws.
A cursor plane is a plane placed on top of all the other planes, usually
used to put the mouse cursor sprite.
Initially, we only fetch the rotation properties, and we so far
blacklist all rotations except ones that ends up with the same
dimensions as with no rotations. This is because non-180° rotations
doesn't work yet due to incorrect buffer modifiers. To make it possible
to use non-180° rotations, changes necessary include among other things
finding compatible modifiers using atomic modesetting. Until then,
simply blacklist the ones we know doesn't work.
https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-31 17:48:19 +00:00
|
|
|
g_list_free (device->planes);
|
2019-01-29 17:33:00 +00:00
|
|
|
|
2019-09-16 16:34:39 +00:00
|
|
|
if (device->impl_device)
|
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 09:24:44 +00:00
|
|
|
{
|
2021-03-31 16:34:45 +00:00
|
|
|
meta_kms_run_impl_task_sync (device->kms, free_impl_device_in_impl,
|
|
|
|
device->impl_device,
|
|
|
|
NULL);
|
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 09:24:44 +00:00
|
|
|
}
|
2021-03-31 16:34:45 +00: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 09:24:44 +00:00
|
|
|
G_OBJECT_CLASS (meta_kms_device_parent_class)->finalize (object);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
meta_kms_device_init (MetaKmsDevice *device)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
meta_kms_device_class_init (MetaKmsDeviceClass *klass)
|
|
|
|
{
|
|
|
|
GObjectClass *object_class = G_OBJECT_CLASS (klass);
|
|
|
|
|
|
|
|
object_class->finalize = meta_kms_device_finalize;
|
|
|
|
}
|