backends/native: Add basic KMS abstraction building blocks
The intention with KMS abstraction is to hide away accessing the drm
functions behind an API that allows us to have different kind of KMS
implementations, including legacy non-atomic and atomic. The intention
is also that the code interacting with the drm device should be able to
be run in a different thread than the main thread. This means that we
need to make sure that all drm*() API usage must only occur from within
tasks that eventually can be run in the dedicated thread.
The idea here is that MetaKms provides a outward facing API other places
of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is
an internal implementation that only gets interacted with via "tasks"
posted via the MetaKms object. These tasks will in the future
potentially be run on the dedicated KMS thread. Initially, we don't
create any new threads.
Likewise, MetaKmsDevice is a outward facing representation of a KMS
device, while MetaKmsImplDevice is the corresponding implementation,
which only runs from within the MetaKmsImpl tasks.
This commit only moves opening and closing the device to this new API,
while leaking the fd outside of the impl enclosure, effectively making
the isolation for drm*() calls pointless. This, however, is necessary to
allow gradual porting of drm interaction, and eventually the file
descriptor in MetaGpuKms will be removed. For now, it's harmless, since
everything still run in the main thread.
https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 04:24:44 -05:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2018 Red Hat
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License as
|
|
|
|
* published by the Free Software Foundation; either version 2 of the
|
|
|
|
* License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
|
|
|
|
* 02111-1307, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
|
|
|
|
#include "backends/native/meta-kms-private.h"
|
|
|
|
|
2019-03-08 13:19:18 -05:00
|
|
|
#include "backends/native/meta-backend-native.h"
|
|
|
|
#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 04:24:44 -05:00
|
|
|
#include "backends/native/meta-kms-impl.h"
|
|
|
|
#include "backends/native/meta-kms-impl-simple.h"
|
2019-03-08 13:19:18 -05:00
|
|
|
#include "backends/native/meta-udev.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
|
|
|
|
2019-03-10 08:36:34 -04:00
|
|
|
typedef struct _MetaKmsCallbackData
|
|
|
|
{
|
|
|
|
MetaKmsCallback callback;
|
|
|
|
gpointer user_data;
|
|
|
|
GDestroyNotify user_data_destroy;
|
|
|
|
} MetaKmsCallbackData;
|
|
|
|
|
2019-03-10 08:40:30 -04:00
|
|
|
typedef struct _MetaKmsSimpleImplSource
|
|
|
|
{
|
|
|
|
GSource source;
|
|
|
|
MetaKms *kms;
|
|
|
|
} MetaKmsSimpleImplSource;
|
|
|
|
|
2019-03-10 08:48:18 -04:00
|
|
|
typedef struct _MetaKmsFdImplSource
|
|
|
|
{
|
|
|
|
GSource source;
|
|
|
|
|
|
|
|
gpointer fd_tag;
|
|
|
|
MetaKms *kms;
|
|
|
|
|
|
|
|
MetaKmsImplTaskFunc dispatch;
|
|
|
|
gpointer user_data;
|
|
|
|
} MetaKmsFdImplSource;
|
|
|
|
|
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
|
|
|
struct _MetaKms
|
|
|
|
{
|
|
|
|
GObject parent;
|
|
|
|
|
|
|
|
MetaBackend *backend;
|
|
|
|
|
2019-03-08 13:19:18 -05:00
|
|
|
guint hotplug_handler_id;
|
|
|
|
|
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
|
|
|
MetaKmsImpl *impl;
|
|
|
|
gboolean in_impl_task;
|
|
|
|
|
|
|
|
GList *devices;
|
2019-03-10 08:36:34 -04:00
|
|
|
|
|
|
|
GList *pending_callbacks;
|
|
|
|
guint callback_source_id;
|
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
|
|
|
};
|
|
|
|
|
|
|
|
G_DEFINE_TYPE (MetaKms, meta_kms, G_TYPE_OBJECT)
|
|
|
|
|
2019-03-10 08:36:34 -04:00
|
|
|
static void
|
|
|
|
meta_kms_callback_data_free (MetaKmsCallbackData *callback_data)
|
|
|
|
{
|
|
|
|
if (callback_data->user_data_destroy)
|
|
|
|
callback_data->user_data_destroy (callback_data->user_data);
|
|
|
|
g_slice_free (MetaKmsCallbackData, callback_data);
|
|
|
|
}
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
callback_idle (gpointer user_data)
|
|
|
|
{
|
|
|
|
MetaKms *kms = user_data;
|
|
|
|
GList *l;
|
|
|
|
|
|
|
|
for (l = kms->pending_callbacks; l; l = l->next)
|
|
|
|
{
|
|
|
|
MetaKmsCallbackData *callback_data = l->data;
|
|
|
|
|
|
|
|
callback_data->callback (kms, callback_data->user_data);
|
|
|
|
meta_kms_callback_data_free (callback_data);
|
|
|
|
}
|
|
|
|
|
|
|
|
g_list_free (kms->pending_callbacks);
|
|
|
|
kms->pending_callbacks = NULL;
|
|
|
|
|
|
|
|
kms->callback_source_id = 0;
|
|
|
|
return G_SOURCE_REMOVE;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
meta_kms_queue_callback (MetaKms *kms,
|
|
|
|
MetaKmsCallback callback,
|
|
|
|
gpointer user_data,
|
|
|
|
GDestroyNotify user_data_destroy)
|
|
|
|
{
|
|
|
|
MetaKmsCallbackData *callback_data;
|
|
|
|
|
|
|
|
callback_data = g_slice_new0 (MetaKmsCallbackData);
|
|
|
|
*callback_data = (MetaKmsCallbackData) {
|
|
|
|
.callback = callback,
|
|
|
|
.user_data = user_data,
|
|
|
|
.user_data_destroy = user_data_destroy,
|
|
|
|
};
|
|
|
|
kms->pending_callbacks = g_list_append (kms->pending_callbacks,
|
|
|
|
callback_data);
|
|
|
|
if (!kms->callback_source_id)
|
|
|
|
kms->callback_source_id = g_idle_add (callback_idle, 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
|
|
|
gboolean
|
|
|
|
meta_kms_run_impl_task_sync (MetaKms *kms,
|
|
|
|
MetaKmsImplTaskFunc func,
|
|
|
|
gpointer user_data,
|
|
|
|
GError **error)
|
|
|
|
{
|
|
|
|
gboolean ret;
|
|
|
|
|
|
|
|
kms->in_impl_task = TRUE;
|
|
|
|
ret = func (kms->impl, user_data, error);
|
|
|
|
kms->in_impl_task = FALSE;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-03-10 08:40:30 -04:00
|
|
|
static gboolean
|
|
|
|
simple_impl_source_dispatch (GSource *source,
|
|
|
|
GSourceFunc callback,
|
|
|
|
gpointer user_data)
|
|
|
|
{
|
|
|
|
MetaKmsSimpleImplSource *simple_impl_source =
|
|
|
|
(MetaKmsSimpleImplSource *) source;
|
|
|
|
MetaKms *kms = simple_impl_source->kms;
|
|
|
|
gboolean ret;
|
|
|
|
|
|
|
|
kms->in_impl_task = TRUE;
|
|
|
|
ret = callback (user_data);
|
|
|
|
kms->in_impl_task = FALSE;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GSourceFuncs simple_impl_source_funcs = {
|
|
|
|
.dispatch = simple_impl_source_dispatch,
|
|
|
|
};
|
|
|
|
|
|
|
|
GSource *
|
|
|
|
meta_kms_add_source_in_impl (MetaKms *kms,
|
|
|
|
GSourceFunc func,
|
|
|
|
gpointer user_data)
|
|
|
|
{
|
|
|
|
GSource *source;
|
|
|
|
MetaKmsSimpleImplSource *simple_impl_source;
|
|
|
|
|
|
|
|
meta_assert_in_kms_impl (kms);
|
|
|
|
|
|
|
|
source = g_source_new (&simple_impl_source_funcs,
|
|
|
|
sizeof (MetaKmsSimpleImplSource));
|
|
|
|
simple_impl_source = (MetaKmsSimpleImplSource *) source;
|
|
|
|
simple_impl_source->kms = kms;
|
|
|
|
|
|
|
|
g_source_set_callback (source, func, user_data, NULL);
|
|
|
|
g_source_attach (source, g_main_context_get_thread_default ());
|
|
|
|
|
|
|
|
return source;
|
|
|
|
}
|
|
|
|
|
2019-03-10 08:48:18 -04:00
|
|
|
static gboolean
|
|
|
|
meta_kms_fd_impl_source_check (GSource *source)
|
|
|
|
{
|
|
|
|
MetaKmsFdImplSource *fd_impl_source = (MetaKmsFdImplSource *) source;
|
|
|
|
|
|
|
|
return g_source_query_unix_fd (source, fd_impl_source->fd_tag) & G_IO_IN;
|
|
|
|
}
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
meta_kms_fd_impl_source_dispatch (GSource *source,
|
|
|
|
GSourceFunc callback,
|
|
|
|
gpointer user_data)
|
|
|
|
{
|
|
|
|
MetaKmsFdImplSource *fd_impl_source = (MetaKmsFdImplSource *) source;
|
|
|
|
MetaKms *kms = fd_impl_source->kms;
|
|
|
|
gboolean ret;
|
|
|
|
GError *error = NULL;
|
|
|
|
|
|
|
|
kms->in_impl_task = TRUE;
|
|
|
|
ret = fd_impl_source->dispatch (kms->impl,
|
|
|
|
fd_impl_source->user_data,
|
|
|
|
&error);
|
|
|
|
kms->in_impl_task = FALSE;
|
|
|
|
|
|
|
|
if (!ret)
|
|
|
|
{
|
|
|
|
g_warning ("Failed to dispatch fd source: %s", error->message);
|
|
|
|
g_error_free (error);
|
|
|
|
}
|
|
|
|
|
|
|
|
return G_SOURCE_CONTINUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static GSourceFuncs fd_impl_source_funcs = {
|
|
|
|
NULL,
|
|
|
|
meta_kms_fd_impl_source_check,
|
|
|
|
meta_kms_fd_impl_source_dispatch
|
|
|
|
};
|
|
|
|
|
|
|
|
GSource *
|
|
|
|
meta_kms_register_fd_in_impl (MetaKms *kms,
|
|
|
|
int fd,
|
|
|
|
MetaKmsImplTaskFunc dispatch,
|
|
|
|
gpointer user_data)
|
|
|
|
{
|
|
|
|
GSource *source;
|
|
|
|
MetaKmsFdImplSource *fd_impl_source;
|
|
|
|
|
|
|
|
meta_assert_in_kms_impl (kms);
|
|
|
|
|
|
|
|
source = g_source_new (&fd_impl_source_funcs, sizeof (MetaKmsFdImplSource));
|
|
|
|
fd_impl_source = (MetaKmsFdImplSource *) source;
|
|
|
|
fd_impl_source->dispatch = dispatch;
|
|
|
|
fd_impl_source->user_data = user_data;
|
|
|
|
fd_impl_source->kms = kms;
|
|
|
|
fd_impl_source->fd_tag = g_source_add_unix_fd (source, fd,
|
|
|
|
G_IO_IN | G_IO_ERR);
|
|
|
|
|
|
|
|
g_source_attach (source, g_main_context_get_thread_default ());
|
|
|
|
|
|
|
|
return source;
|
|
|
|
}
|
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
return kms->in_impl_task;
|
|
|
|
}
|
|
|
|
|
2019-03-08 13:19:18 -05:00
|
|
|
static gboolean
|
|
|
|
update_states_in_impl (MetaKmsImpl *impl,
|
|
|
|
gpointer user_data,
|
|
|
|
GError **error)
|
|
|
|
{
|
|
|
|
MetaKms *kms = user_data;
|
|
|
|
GList *l;
|
|
|
|
|
|
|
|
for (l = kms->devices; l; l = l->next)
|
|
|
|
{
|
|
|
|
MetaKmsDevice *device = l->data;
|
|
|
|
MetaKmsImplDevice *impl_device = meta_kms_device_get_impl_device (device);
|
|
|
|
|
|
|
|
meta_kms_impl_device_update_states (impl_device);
|
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
meta_kms_update_states_sync (MetaKms *kms,
|
|
|
|
GError **error)
|
|
|
|
{
|
|
|
|
return meta_kms_run_impl_task_sync (kms,
|
|
|
|
update_states_in_impl,
|
|
|
|
kms,
|
|
|
|
error);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
on_udev_hotplug (MetaUdev *udev,
|
|
|
|
MetaKms *kms)
|
|
|
|
{
|
|
|
|
g_autoptr (GError) error = NULL;
|
|
|
|
|
|
|
|
if (!meta_kms_update_states_sync (kms, &error))
|
|
|
|
g_warning ("Updating KMS state failed: %s", error->message);
|
|
|
|
}
|
|
|
|
|
backends/native: Add basic KMS abstraction building blocks
The intention with KMS abstraction is to hide away accessing the drm
functions behind an API that allows us to have different kind of KMS
implementations, including legacy non-atomic and atomic. The intention
is also that the code interacting with the drm device should be able to
be run in a different thread than the main thread. This means that we
need to make sure that all drm*() API usage must only occur from within
tasks that eventually can be run in the dedicated thread.
The idea here is that MetaKms provides a outward facing API other places
of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is
an internal implementation that only gets interacted with via "tasks"
posted via the MetaKms object. These tasks will in the future
potentially be run on the dedicated KMS thread. Initially, we don't
create any new threads.
Likewise, MetaKmsDevice is a outward facing representation of a KMS
device, while MetaKmsImplDevice is the corresponding implementation,
which only runs from within the MetaKmsImpl tasks.
This commit only moves opening and closing the device to this new API,
while leaking the fd outside of the impl enclosure, effectively making
the isolation for drm*() calls pointless. This, however, is necessary to
allow gradual porting of drm interaction, and eventually the file
descriptor in MetaGpuKms will be removed. For now, it's harmless, since
everything still run in the main thread.
https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-01-29 04:24:44 -05:00
|
|
|
MetaBackend *
|
|
|
|
meta_kms_get_backend (MetaKms *kms)
|
|
|
|
{
|
|
|
|
return kms->backend;
|
|
|
|
}
|
|
|
|
|
|
|
|
MetaKmsDevice *
|
|
|
|
meta_kms_create_device (MetaKms *kms,
|
|
|
|
const char *path,
|
|
|
|
MetaKmsDeviceFlag flags,
|
|
|
|
GError **error)
|
|
|
|
{
|
|
|
|
MetaKmsDevice *device;
|
|
|
|
|
|
|
|
device = meta_kms_device_new (kms, path, flags, error);
|
|
|
|
if (!device)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
kms->devices = g_list_append (kms->devices, device);
|
|
|
|
|
|
|
|
return device;
|
|
|
|
}
|
|
|
|
|
|
|
|
MetaKms *
|
|
|
|
meta_kms_new (MetaBackend *backend,
|
|
|
|
GError **error)
|
|
|
|
{
|
2019-03-08 13:19:18 -05:00
|
|
|
MetaBackendNative *backend_native = META_BACKEND_NATIVE (backend);
|
|
|
|
MetaUdev *udev = meta_backend_native_get_udev (backend_native);
|
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
|
|
|
MetaKms *kms;
|
|
|
|
|
|
|
|
kms = g_object_new (META_TYPE_KMS, NULL);
|
|
|
|
kms->backend = backend;
|
|
|
|
kms->impl = META_KMS_IMPL (meta_kms_impl_simple_new (kms, error));
|
|
|
|
if (!kms->impl)
|
|
|
|
{
|
|
|
|
g_object_unref (kms);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2019-03-08 13:19:18 -05:00
|
|
|
kms->hotplug_handler_id =
|
|
|
|
g_signal_connect (udev, "hotplug", G_CALLBACK (on_udev_hotplug), 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
|
|
|
return kms;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
meta_kms_finalize (GObject *object)
|
|
|
|
{
|
|
|
|
MetaKms *kms = META_KMS (object);
|
2019-03-08 13:19:18 -05:00
|
|
|
MetaBackendNative *backend_native = META_BACKEND_NATIVE (kms->backend);
|
|
|
|
MetaUdev *udev = meta_backend_native_get_udev (backend_native);
|
2019-03-10 08:36:34 -04:00
|
|
|
GList *l;
|
|
|
|
|
|
|
|
for (l = kms->pending_callbacks; l; l = l->next)
|
|
|
|
meta_kms_callback_data_free (l->data);
|
|
|
|
g_list_free (kms->pending_callbacks);
|
|
|
|
|
|
|
|
g_clear_handle_id (&kms->callback_source_id, g_source_remove);
|
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
|
|
|
|
|
|
|
g_list_free_full (kms->devices, g_object_unref);
|
|
|
|
|
2019-03-08 13:19:18 -05:00
|
|
|
if (kms->hotplug_handler_id)
|
|
|
|
g_signal_handler_disconnect (udev, kms->hotplug_handler_id);
|
|
|
|
|
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
|
|
|
G_OBJECT_CLASS (meta_kms_parent_class)->finalize (object);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
meta_kms_init (MetaKms *kms)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
meta_kms_class_init (MetaKmsClass *klass)
|
|
|
|
{
|
|
|
|
GObjectClass *object_class = G_OBJECT_CLASS (klass);
|
|
|
|
|
|
|
|
object_class->finalize = meta_kms_finalize;
|
|
|
|
}
|