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 12:48:19 -05:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2013-2019 Red Hat
|
|
|
|
* Copyright (C) 2018 DisplayLink (UK) Ltd.
|
|
|
|
*
|
|
|
|
* 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"
|
|
|
|
|
2019-10-31 05:38:19 -04:00
|
|
|
#include "backends/native/meta-kms-plane-private.h"
|
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 12:48:19 -05:00
|
|
|
|
2019-06-28 12:21:52 -04:00
|
|
|
#include <drm_fourcc.h>
|
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 12:48:19 -05:00
|
|
|
#include <stdio.h>
|
|
|
|
|
|
|
|
#include "backends/meta-monitor-transform.h"
|
|
|
|
#include "backends/native/meta-kms-crtc.h"
|
|
|
|
#include "backends/native/meta-kms-impl-device.h"
|
backend/native: Add and use transactional KMS API
This commit introduces, and makes use of, a transactional API used for
setting up KMS state, later to be applied, potentially atomically. From
an API point of view, so is always the case, but in the current
implementation, it still uses legacy drmMode* API to apply the state
non-atomically.
The API consists of various buliding blocks:
* MetaKmsUpdate - a set of configuration changes, the higher level
handle for handing over configuration to the impl backend. It's used to
set mode, assign framebuffers to planes, queue page flips and set
connector properties.
* MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane.
Currently used to map a framebuffer to the primary plane of a CRTC. In
the legacy KMS implementation, the plane assignment is used to derive
the framebuffer used for mode setting and page flipping.
This also means various high level changes:
State, excluding configuring the cursor plane and creating/destroying
DRM framebuffer handles, are applied in the end of a clutter frame, in
one go. From an API point of view, this is done atomically, but as
mentioned, only the non-atomic implementation exists so far.
From MetaRendererNative's point of view, a page flip now initially
always succeeds; the handling of EBUSY errors are done asynchronously in
the MetaKmsImpl backend (still by retrying at refresh rate, but
postponing flip callbacks instead of manipulating the frame clock).
Handling of falling back to mode setting instead of page flipping is
notified after the fact by a more precise page flip feedback API.
EGLStream based page flipping relies on the impl backend not being
atomic, as the page flipping is done in the EGLStream backend (e.g.
nvidia driver). It uses a 'custom' page flip queueing method, keeping
the EGLStream logic inside meta-renderer-native.c.
Page flip handling is moved to meta-kms-impl-device.c from
meta-gpu-kms.c. It goes via an extra idle callback before reaching
meta-renderer-native.c to make sure callbacks are invoked outside of the
impl context.
While dummy power save page flipping is kept in meta-renderer-native.c, the
EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the
frame clock, actual page flip callbacks are postponed until all EBUSY retries
have either succeeded or failed due to some other error than EBUSY. This
effectively inhibits new frames to be drawn, meaning we won't stall waiting on
the file descriptor for pending page flips.
https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-04-04 16:36:41 -04:00
|
|
|
#include "backends/native/meta-kms-update-private.h"
|
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 12:48:19 -05:00
|
|
|
|
|
|
|
struct _MetaKmsPlane
|
|
|
|
{
|
|
|
|
GObject parent;
|
|
|
|
|
|
|
|
MetaKmsPlaneType type;
|
2020-02-21 06:06:28 -05:00
|
|
|
gboolean is_fake;
|
|
|
|
|
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 12:48:19 -05:00
|
|
|
uint32_t id;
|
|
|
|
|
|
|
|
uint32_t possible_crtcs;
|
|
|
|
|
|
|
|
uint32_t rotation_prop_id;
|
|
|
|
uint32_t rotation_map[META_MONITOR_N_TRANSFORMS];
|
|
|
|
uint32_t all_hw_transforms;
|
|
|
|
|
2019-03-09 12:23:28 -05:00
|
|
|
/*
|
|
|
|
* primary plane's supported formats and maybe modifiers
|
|
|
|
* key: GUINT_TO_POINTER (format)
|
|
|
|
* value: owned GArray* (uint64_t modifier), or NULL
|
|
|
|
*/
|
|
|
|
GHashTable *formats_modifiers;
|
|
|
|
|
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 12:48:19 -05:00
|
|
|
MetaKmsDevice *device;
|
|
|
|
};
|
|
|
|
|
|
|
|
G_DEFINE_TYPE (MetaKmsPlane, meta_kms_plane, G_TYPE_OBJECT)
|
|
|
|
|
backend/native: Add and use transactional KMS API
This commit introduces, and makes use of, a transactional API used for
setting up KMS state, later to be applied, potentially atomically. From
an API point of view, so is always the case, but in the current
implementation, it still uses legacy drmMode* API to apply the state
non-atomically.
The API consists of various buliding blocks:
* MetaKmsUpdate - a set of configuration changes, the higher level
handle for handing over configuration to the impl backend. It's used to
set mode, assign framebuffers to planes, queue page flips and set
connector properties.
* MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane.
Currently used to map a framebuffer to the primary plane of a CRTC. In
the legacy KMS implementation, the plane assignment is used to derive
the framebuffer used for mode setting and page flipping.
This also means various high level changes:
State, excluding configuring the cursor plane and creating/destroying
DRM framebuffer handles, are applied in the end of a clutter frame, in
one go. From an API point of view, this is done atomically, but as
mentioned, only the non-atomic implementation exists so far.
From MetaRendererNative's point of view, a page flip now initially
always succeeds; the handling of EBUSY errors are done asynchronously in
the MetaKmsImpl backend (still by retrying at refresh rate, but
postponing flip callbacks instead of manipulating the frame clock).
Handling of falling back to mode setting instead of page flipping is
notified after the fact by a more precise page flip feedback API.
EGLStream based page flipping relies on the impl backend not being
atomic, as the page flipping is done in the EGLStream backend (e.g.
nvidia driver). It uses a 'custom' page flip queueing method, keeping
the EGLStream logic inside meta-renderer-native.c.
Page flip handling is moved to meta-kms-impl-device.c from
meta-gpu-kms.c. It goes via an extra idle callback before reaching
meta-renderer-native.c to make sure callbacks are invoked outside of the
impl context.
While dummy power save page flipping is kept in meta-renderer-native.c, the
EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the
frame clock, actual page flip callbacks are postponed until all EBUSY retries
have either succeeded or failed due to some other error than EBUSY. This
effectively inhibits new frames to be drawn, meaning we won't stall waiting on
the file descriptor for pending page flips.
https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-04-04 16:36:41 -04:00
|
|
|
MetaKmsDevice *
|
|
|
|
meta_kms_plane_get_device (MetaKmsPlane *plane)
|
|
|
|
{
|
|
|
|
return plane->device;
|
|
|
|
}
|
|
|
|
|
2019-03-09 12:23:28 -05:00
|
|
|
uint32_t
|
|
|
|
meta_kms_plane_get_id (MetaKmsPlane *plane)
|
|
|
|
{
|
2020-02-21 06:06:28 -05:00
|
|
|
g_return_val_if_fail (!plane->is_fake, 0);
|
|
|
|
|
2019-03-09 12:23:28 -05:00
|
|
|
return plane->id;
|
|
|
|
}
|
|
|
|
|
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 12:48:19 -05:00
|
|
|
MetaKmsPlaneType
|
|
|
|
meta_kms_plane_get_plane_type (MetaKmsPlane *plane)
|
|
|
|
{
|
|
|
|
return plane->type;
|
|
|
|
}
|
|
|
|
|
backend/native: Add and use transactional KMS API
This commit introduces, and makes use of, a transactional API used for
setting up KMS state, later to be applied, potentially atomically. From
an API point of view, so is always the case, but in the current
implementation, it still uses legacy drmMode* API to apply the state
non-atomically.
The API consists of various buliding blocks:
* MetaKmsUpdate - a set of configuration changes, the higher level
handle for handing over configuration to the impl backend. It's used to
set mode, assign framebuffers to planes, queue page flips and set
connector properties.
* MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane.
Currently used to map a framebuffer to the primary plane of a CRTC. In
the legacy KMS implementation, the plane assignment is used to derive
the framebuffer used for mode setting and page flipping.
This also means various high level changes:
State, excluding configuring the cursor plane and creating/destroying
DRM framebuffer handles, are applied in the end of a clutter frame, in
one go. From an API point of view, this is done atomically, but as
mentioned, only the non-atomic implementation exists so far.
From MetaRendererNative's point of view, a page flip now initially
always succeeds; the handling of EBUSY errors are done asynchronously in
the MetaKmsImpl backend (still by retrying at refresh rate, but
postponing flip callbacks instead of manipulating the frame clock).
Handling of falling back to mode setting instead of page flipping is
notified after the fact by a more precise page flip feedback API.
EGLStream based page flipping relies on the impl backend not being
atomic, as the page flipping is done in the EGLStream backend (e.g.
nvidia driver). It uses a 'custom' page flip queueing method, keeping
the EGLStream logic inside meta-renderer-native.c.
Page flip handling is moved to meta-kms-impl-device.c from
meta-gpu-kms.c. It goes via an extra idle callback before reaching
meta-renderer-native.c to make sure callbacks are invoked outside of the
impl context.
While dummy power save page flipping is kept in meta-renderer-native.c, the
EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the
frame clock, actual page flip callbacks are postponed until all EBUSY retries
have either succeeded or failed due to some other error than EBUSY. This
effectively inhibits new frames to be drawn, meaning we won't stall waiting on
the file descriptor for pending page flips.
https://gitlab.gnome.org/GNOME/mutter/issues/548
https://gitlab.gnome.org/GNOME/mutter/merge_requests/525
2019-04-04 16:36:41 -04:00
|
|
|
void
|
|
|
|
meta_kms_plane_update_set_rotation (MetaKmsPlane *plane,
|
|
|
|
MetaKmsPlaneAssignment *plane_assignment,
|
|
|
|
MetaMonitorTransform transform)
|
|
|
|
{
|
|
|
|
g_return_if_fail (meta_kms_plane_is_transform_handled (plane, transform));
|
|
|
|
|
|
|
|
meta_kms_plane_assignment_set_plane_property (plane_assignment,
|
|
|
|
plane->rotation_prop_id,
|
|
|
|
plane->rotation_map[transform]);
|
|
|
|
}
|
|
|
|
|
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 12:48:19 -05:00
|
|
|
gboolean
|
|
|
|
meta_kms_plane_is_transform_handled (MetaKmsPlane *plane,
|
|
|
|
MetaMonitorTransform transform)
|
|
|
|
{
|
|
|
|
switch (transform)
|
|
|
|
{
|
|
|
|
case META_MONITOR_TRANSFORM_NORMAL:
|
|
|
|
case META_MONITOR_TRANSFORM_180:
|
|
|
|
case META_MONITOR_TRANSFORM_FLIPPED:
|
|
|
|
case META_MONITOR_TRANSFORM_FLIPPED_180:
|
|
|
|
break;
|
|
|
|
case META_MONITOR_TRANSFORM_90:
|
|
|
|
case META_MONITOR_TRANSFORM_270:
|
|
|
|
case META_MONITOR_TRANSFORM_FLIPPED_90:
|
|
|
|
case META_MONITOR_TRANSFORM_FLIPPED_270:
|
|
|
|
/*
|
|
|
|
* Blacklist these transforms as testing shows that they don't work
|
|
|
|
* anyway, e.g. due to the wrong buffer modifiers. They might as well be
|
|
|
|
* less optimal due to the complexity dealing with rotation at scan-out,
|
|
|
|
* potentially resulting in higher power consumption.
|
|
|
|
*/
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
return plane->all_hw_transforms & (1 << transform);
|
|
|
|
}
|
|
|
|
|
2019-03-09 12:23:28 -05:00
|
|
|
GArray *
|
|
|
|
meta_kms_plane_get_modifiers_for_format (MetaKmsPlane *plane,
|
|
|
|
uint32_t format)
|
|
|
|
{
|
|
|
|
return g_hash_table_lookup (plane->formats_modifiers,
|
|
|
|
GUINT_TO_POINTER (format));
|
|
|
|
}
|
|
|
|
|
|
|
|
GArray *
|
|
|
|
meta_kms_plane_copy_drm_format_list (MetaKmsPlane *plane)
|
|
|
|
{
|
|
|
|
GArray *formats;
|
|
|
|
GHashTableIter it;
|
|
|
|
gpointer key;
|
|
|
|
unsigned int n_formats_modifiers;
|
|
|
|
|
|
|
|
n_formats_modifiers = g_hash_table_size (plane->formats_modifiers);
|
|
|
|
formats = g_array_sized_new (FALSE, FALSE,
|
|
|
|
sizeof (uint32_t),
|
|
|
|
n_formats_modifiers);
|
|
|
|
g_hash_table_iter_init (&it, plane->formats_modifiers);
|
|
|
|
while (g_hash_table_iter_next (&it, &key, NULL))
|
|
|
|
{
|
|
|
|
uint32_t drm_format = GPOINTER_TO_UINT (key);
|
|
|
|
|
|
|
|
g_array_append_val (formats, drm_format);
|
|
|
|
}
|
|
|
|
|
|
|
|
return formats;
|
|
|
|
}
|
|
|
|
|
|
|
|
gboolean
|
|
|
|
meta_kms_plane_is_format_supported (MetaKmsPlane *plane,
|
|
|
|
uint32_t drm_format)
|
|
|
|
{
|
|
|
|
return g_hash_table_lookup_extended (plane->formats_modifiers,
|
|
|
|
GUINT_TO_POINTER (drm_format),
|
|
|
|
NULL, NULL);
|
|
|
|
}
|
|
|
|
|
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 12:48:19 -05:00
|
|
|
gboolean
|
|
|
|
meta_kms_plane_is_usable_with (MetaKmsPlane *plane,
|
|
|
|
MetaKmsCrtc *crtc)
|
|
|
|
{
|
|
|
|
return !!(plane->possible_crtcs & (1 << meta_kms_crtc_get_idx (crtc)));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
parse_rotations (MetaKmsPlane *plane,
|
|
|
|
MetaKmsImplDevice *impl_device,
|
|
|
|
drmModePropertyPtr prop)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < prop->count_enums; i++)
|
|
|
|
{
|
|
|
|
MetaMonitorTransform transform = -1;
|
|
|
|
|
|
|
|
if (strcmp (prop->enums[i].name, "rotate-0") == 0)
|
|
|
|
transform = META_MONITOR_TRANSFORM_NORMAL;
|
|
|
|
else if (strcmp (prop->enums[i].name, "rotate-90") == 0)
|
|
|
|
transform = META_MONITOR_TRANSFORM_90;
|
|
|
|
else if (strcmp (prop->enums[i].name, "rotate-180") == 0)
|
|
|
|
transform = META_MONITOR_TRANSFORM_180;
|
|
|
|
else if (strcmp (prop->enums[i].name, "rotate-270") == 0)
|
|
|
|
transform = META_MONITOR_TRANSFORM_270;
|
|
|
|
|
|
|
|
if (transform != -1)
|
|
|
|
{
|
|
|
|
plane->all_hw_transforms |= 1 << transform;
|
|
|
|
plane->rotation_map[transform] = 1 << prop->enums[i].value;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
init_rotations (MetaKmsPlane *plane,
|
|
|
|
MetaKmsImplDevice *impl_device,
|
|
|
|
drmModeObjectProperties *drm_plane_props)
|
|
|
|
{
|
|
|
|
drmModePropertyPtr prop;
|
|
|
|
int idx;
|
|
|
|
|
|
|
|
prop = meta_kms_impl_device_find_property (impl_device, drm_plane_props,
|
|
|
|
"rotation", &idx);
|
|
|
|
if (prop)
|
|
|
|
{
|
|
|
|
plane->rotation_prop_id = drm_plane_props->props[idx];
|
|
|
|
parse_rotations (plane, impl_device, prop);
|
|
|
|
drmModeFreeProperty (prop);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-03-09 12:23:28 -05:00
|
|
|
static inline uint32_t *
|
|
|
|
drm_formats_ptr (struct drm_format_modifier_blob *blob)
|
|
|
|
{
|
|
|
|
return (uint32_t *) (((char *) blob) + blob->formats_offset);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct drm_format_modifier *
|
|
|
|
drm_modifiers_ptr (struct drm_format_modifier_blob *blob)
|
|
|
|
{
|
|
|
|
return (struct drm_format_modifier *) (((char *) blob) +
|
|
|
|
blob->modifiers_offset);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
free_modifier_array (GArray *array)
|
|
|
|
{
|
|
|
|
if (!array)
|
|
|
|
return;
|
|
|
|
|
|
|
|
g_array_free (array, TRUE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
parse_formats (MetaKmsPlane *plane,
|
|
|
|
MetaKmsImplDevice *impl_device,
|
|
|
|
uint32_t blob_id)
|
|
|
|
{
|
|
|
|
int fd;
|
|
|
|
drmModePropertyBlobPtr blob;
|
|
|
|
struct drm_format_modifier_blob *blob_fmt;
|
|
|
|
uint32_t *formats;
|
|
|
|
struct drm_format_modifier *drm_modifiers;
|
|
|
|
unsigned int fmt_i, mod_i;
|
|
|
|
|
|
|
|
g_return_if_fail (g_hash_table_size (plane->formats_modifiers) == 0);
|
|
|
|
|
|
|
|
if (blob_id == 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
fd = meta_kms_impl_device_get_fd (impl_device);
|
|
|
|
blob = drmModeGetPropertyBlob (fd, blob_id);
|
|
|
|
if (!blob)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (blob->length < sizeof (struct drm_format_modifier_blob))
|
|
|
|
{
|
|
|
|
drmModeFreePropertyBlob (blob);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
blob_fmt = blob->data;
|
|
|
|
|
|
|
|
formats = drm_formats_ptr (blob_fmt);
|
|
|
|
drm_modifiers = drm_modifiers_ptr (blob_fmt);
|
|
|
|
|
|
|
|
for (fmt_i = 0; fmt_i < blob_fmt->count_formats; fmt_i++)
|
|
|
|
{
|
|
|
|
GArray *modifiers = g_array_new (FALSE, FALSE, sizeof (uint64_t));
|
|
|
|
|
|
|
|
for (mod_i = 0; mod_i < blob_fmt->count_modifiers; mod_i++)
|
|
|
|
{
|
|
|
|
struct drm_format_modifier *drm_modifier = &drm_modifiers[mod_i];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The modifier advertisement blob is partitioned into groups of
|
|
|
|
* 64 formats.
|
|
|
|
*/
|
|
|
|
if (fmt_i < drm_modifier->offset || fmt_i > drm_modifier->offset + 63)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!(drm_modifier->formats & (1 << (fmt_i - drm_modifier->offset))))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
g_array_append_val (modifiers, drm_modifier->modifier);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (modifiers->len == 0)
|
|
|
|
{
|
|
|
|
free_modifier_array (modifiers);
|
|
|
|
modifiers = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
g_hash_table_insert (plane->formats_modifiers,
|
|
|
|
GUINT_TO_POINTER (formats[fmt_i]),
|
|
|
|
modifiers);
|
|
|
|
}
|
|
|
|
|
|
|
|
drmModeFreePropertyBlob (blob);
|
|
|
|
}
|
|
|
|
|
2019-06-28 09:04:44 -04:00
|
|
|
static void
|
|
|
|
set_formats_from_array (MetaKmsPlane *plane,
|
|
|
|
const uint32_t *formats,
|
|
|
|
size_t n_formats)
|
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
for (i = 0; i < n_formats; i++)
|
|
|
|
{
|
|
|
|
g_hash_table_insert (plane->formats_modifiers,
|
|
|
|
GUINT_TO_POINTER (formats[i]), NULL);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In case the DRM driver does not expose a format list for the
|
|
|
|
* primary plane (does not support universal planes nor
|
|
|
|
* IN_FORMATS property), hardcode something that is probably supported.
|
|
|
|
*/
|
|
|
|
static const uint32_t drm_default_formats[] =
|
|
|
|
{
|
|
|
|
/* The format everything should always support by convention */
|
|
|
|
DRM_FORMAT_XRGB8888,
|
|
|
|
#if G_BYTE_ORDER == G_LITTLE_ENDIAN
|
|
|
|
/* OpenGL GL_RGBA, GL_UNSIGNED_BYTE format, hopefully supported */
|
|
|
|
DRM_FORMAT_XBGR8888
|
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
2019-03-09 12:23:28 -05:00
|
|
|
static void
|
|
|
|
init_formats (MetaKmsPlane *plane,
|
|
|
|
MetaKmsImplDevice *impl_device,
|
2019-06-28 09:04:44 -04:00
|
|
|
drmModePlane *drm_plane,
|
2019-03-09 12:23:28 -05:00
|
|
|
drmModeObjectProperties *drm_plane_props)
|
|
|
|
{
|
|
|
|
drmModePropertyPtr prop;
|
|
|
|
int idx;
|
|
|
|
|
|
|
|
prop = meta_kms_impl_device_find_property (impl_device, drm_plane_props,
|
|
|
|
"IN_FORMATS", &idx);
|
|
|
|
if (prop)
|
|
|
|
{
|
|
|
|
uint32_t blob_id;
|
|
|
|
|
|
|
|
blob_id = drm_plane_props->prop_values[idx];
|
|
|
|
parse_formats (plane, impl_device, blob_id);
|
|
|
|
drmModeFreeProperty (prop);
|
|
|
|
}
|
2019-06-28 09:04:44 -04:00
|
|
|
|
|
|
|
if (g_hash_table_size (plane->formats_modifiers) == 0)
|
|
|
|
{
|
|
|
|
set_formats_from_array (plane,
|
|
|
|
drm_plane->formats,
|
|
|
|
drm_plane->count_formats);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* final formats fallback to something hardcoded */
|
|
|
|
if (g_hash_table_size (plane->formats_modifiers) == 0)
|
|
|
|
{
|
|
|
|
set_formats_from_array (plane,
|
|
|
|
drm_default_formats,
|
|
|
|
G_N_ELEMENTS (drm_default_formats));
|
|
|
|
}
|
2019-03-09 12:23:28 -05:00
|
|
|
}
|
|
|
|
|
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 12:48:19 -05:00
|
|
|
MetaKmsPlane *
|
|
|
|
meta_kms_plane_new (MetaKmsPlaneType type,
|
|
|
|
MetaKmsImplDevice *impl_device,
|
|
|
|
drmModePlane *drm_plane,
|
|
|
|
drmModeObjectProperties *drm_plane_props)
|
|
|
|
{
|
|
|
|
MetaKmsPlane *plane;
|
|
|
|
|
|
|
|
plane = g_object_new (META_TYPE_KMS_PLANE, NULL);
|
|
|
|
plane->type = type;
|
|
|
|
plane->id = drm_plane->plane_id;
|
|
|
|
plane->possible_crtcs = drm_plane->possible_crtcs;
|
|
|
|
plane->device = meta_kms_impl_device_get_device (impl_device);
|
|
|
|
|
|
|
|
init_rotations (plane, impl_device, drm_plane_props);
|
2019-06-28 09:04:44 -04:00
|
|
|
init_formats (plane, impl_device, drm_plane, drm_plane_props);
|
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 12:48:19 -05:00
|
|
|
|
|
|
|
return plane;
|
|
|
|
}
|
|
|
|
|
2020-02-21 06:06:28 -05:00
|
|
|
MetaKmsPlane *
|
|
|
|
meta_kms_plane_new_fake (MetaKmsPlaneType type,
|
|
|
|
MetaKmsCrtc *crtc)
|
|
|
|
{
|
|
|
|
MetaKmsPlane *plane;
|
|
|
|
|
|
|
|
static const uint32_t fake_plane_drm_formats[] =
|
|
|
|
{
|
|
|
|
DRM_FORMAT_XRGB8888,
|
|
|
|
DRM_FORMAT_ARGB8888,
|
|
|
|
#if G_BYTE_ORDER == G_LITTLE_ENDIAN
|
|
|
|
/* OpenGL GL_RGBA, GL_UNSIGNED_BYTE format, hopefully supported */
|
|
|
|
DRM_FORMAT_XBGR8888,
|
|
|
|
DRM_FORMAT_ABGR8888
|
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
|
|
|
plane = g_object_new (META_TYPE_KMS_PLANE, NULL);
|
|
|
|
plane->type = type;
|
|
|
|
plane->is_fake = TRUE;
|
|
|
|
plane->possible_crtcs = 1 << meta_kms_crtc_get_idx (crtc);
|
|
|
|
plane->device = meta_kms_crtc_get_device (crtc);
|
|
|
|
|
|
|
|
set_formats_from_array (plane,
|
|
|
|
fake_plane_drm_formats,
|
|
|
|
G_N_ELEMENTS (fake_plane_drm_formats));
|
|
|
|
|
|
|
|
return plane;
|
|
|
|
}
|
|
|
|
|
2019-03-09 12:23:28 -05:00
|
|
|
static void
|
|
|
|
meta_kms_plane_finalize (GObject *object)
|
|
|
|
{
|
|
|
|
MetaKmsPlane *plane = META_KMS_PLANE (object);
|
|
|
|
|
|
|
|
g_hash_table_destroy (plane->formats_modifiers);
|
|
|
|
|
|
|
|
G_OBJECT_CLASS (meta_kms_plane_parent_class)->finalize (object);
|
|
|
|
}
|
|
|
|
|
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 12:48:19 -05:00
|
|
|
static void
|
|
|
|
meta_kms_plane_init (MetaKmsPlane *plane)
|
|
|
|
{
|
2020-02-21 06:06:28 -05:00
|
|
|
plane->formats_modifiers =
|
|
|
|
g_hash_table_new_full (g_direct_hash,
|
|
|
|
g_direct_equal,
|
|
|
|
NULL,
|
|
|
|
(GDestroyNotify) free_modifier_array);
|
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 12:48:19 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
meta_kms_plane_class_init (MetaKmsPlaneClass *klass)
|
|
|
|
{
|
2019-03-09 12:23:28 -05:00
|
|
|
GObjectClass *object_class = G_OBJECT_CLASS (klass);
|
|
|
|
|
|
|
|
object_class->finalize = meta_kms_plane_finalize;
|
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 12:48:19 -05:00
|
|
|
}
|