sungmg/mutter-performance-source
1
0
Fork 0
Code Activity
mutter-performance-source/src/backends/native/meta-cursor-renderer-native.c

1209 lines
38 KiB
C
Raw Normal View History

backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
/*
* Copyright (C) 2014 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.
*
* Written by:
* Jasper St. Pierre <jstpierre@mecheye.net>
*/
#include "config.h"
#include "meta-cursor-renderer-native.h"
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
#include <string.h>
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
#include <gbm.h>
Support for hardware cursor sizes other than 64x64 on wayland Use the new DRM capabilities to figure out the correct cursor size, and make sure that matches instead of hardcoding 64x64. This fixes incorrect rendering on some newer AMD cards that support 256x256 cursors. Based heavily on a patch by: Alvaro Fernando García <alvarofernandogarcia@gmail.com>
2014-09-24 21:40:09 +00:00
#include <xf86drm.h>
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
#include <errno.h>
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
#include <meta/util.h>
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
#include <meta/meta-backend.h>
Move cogl KMS winsys into the native backend Move the KMS interaction from cogl into mutter, where most of the other KMS interaction already takes place. This also removes dead code which were only excercised when non-mutter callers used the cogl KMS backend. The cogl KMS API was updated to pass via MetaRendererNative instead of via the different cogl objects. https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-09 11:51:29 +00:00
#include "backends/meta-backend-private.h"
cursor-renderer: Centralize hw cursor realization paths Use a common entry point into the cursor renderer implementations HW cursor realization paths for all cursor sprite types. This is in preparation for realizing at more strategic times. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 12:34:02 +00:00
#include "backends/meta-cursor-sprite-xcursor.h"
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
#include "backends/meta-logical-monitor.h"
#include "backends/meta-monitor.h"
Move cogl KMS winsys into the native backend Move the KMS interaction from cogl into mutter, where most of the other KMS interaction already takes place. This also removes dead code which were only excercised when non-mutter callers used the cogl KMS backend. The cogl KMS API was updated to pass via MetaRendererNative instead of via the different cogl objects. https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-09 11:51:29 +00:00
#include "backends/meta-monitor-manager-private.h"
Make MetaOutput a GObject Turn MetaOutput into a GObject and move it to a separate file. This changes the storage format, resulting in changing the API for accessing MetaOutputs from using an array, to using a GList. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-03-24 09:35:51 +00:00
#include "backends/meta-output.h"
Move cogl KMS winsys into the native backend Move the KMS interaction from cogl into mutter, where most of the other KMS interaction already takes place. This also removes dead code which were only excercised when non-mutter callers used the cogl KMS backend. The cogl KMS API was updated to pass via MetaRendererNative instead of via the different cogl objects. https://bugzilla.gnome.org/show_bug.cgi?id=768976
2016-05-09 11:51:29 +00:00
#include "backends/native/meta-renderer-native.h"
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
#include "core/boxes-private.h"
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
#include "meta/boxes.h"
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
cursor-renderer/native: Fetch instead of pass wl_buffer when realizing This is the next step in centralizing the cursor sprite hw sprite realization paths. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 10:27:02 +00:00
#ifdef HAVE_WAYLAND
#include "wayland/meta-cursor-sprite-wayland.h"
#include "wayland/meta-wayland-buffer.h"
#endif
Support for hardware cursor sizes other than 64x64 on wayland Use the new DRM capabilities to figure out the correct cursor size, and make sure that matches instead of hardcoding 64x64. This fixes incorrect rendering on some newer AMD cards that support 256x256 cursors. Based heavily on a patch by: Alvaro Fernando García <alvarofernandogarcia@gmail.com>
2014-09-24 21:40:09 +00:00
#ifndef DRM_CAP_CURSOR_WIDTH
#define DRM_CAP_CURSOR_WIDTH 0x8
#endif
#ifndef DRM_CAP_CURSOR_HEIGHT
#define DRM_CAP_CURSOR_HEIGHT 0x9
#endif
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
/* When animating a cursor, we usually call drmModeSetCursor2 once per frame.
* Though, testing shows that we need to triple buffer the cursor buffer in
* order to avoid glitches when animating the cursor, at least when running on
* Intel. The reason for this might be (but is not confirmed to be) due to
* the user space gbm_bo cache, making us reuse and overwrite the kernel side
* buffer content before it was scanned out. To avoid this, we keep a user space
* reference to each buffer we set until at least one frame after it was drawn.
* In effect, this means we three active cursor gbm_bo's: one that that just has
* been set, one that was previously set and may or may not have been scanned
* out, and one pending that will be replaced if the cursor sprite changes.
*/
#define HW_CURSOR_BUFFER_COUNT 3
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
static GQuark quark_cursor_sprite = 0;
cursor-renderer-native: Cleanup type declaration Use G_DECLARE_FINAL_TYPE instead of the old macros. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-07 08:06:22 +00:00
struct _MetaCursorRendererNative
{
MetaCursorRenderer parent;
};
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
struct _MetaCursorRendererNativePrivate
{
native/cursor-renderer: Cleanup construction Pass the backend to a new factory function, and keep a pointer to the monitor manager, which is accessed elsewhere in the same file instead of fetching the singleton. The HW cursor initialization part is also made more obvious, without depending on seemingly irrelevant clutter features. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-07 08:12:07 +00:00
MetaMonitorManager *monitor_manager;
MetaCursorRendererNative: Always force set hw cursor the first time The initial state of the hardware cursor is not known, so always force update it the first time we update the cursor. Do this by changing the 'force' flag of update_hw_cursor() to an 'invalidated' hw cursor state. https://bugzilla.gnome.org/show_bug.cgi?id=771056
2017-01-10 08:01:46 +00:00
gboolean hw_state_invalidated;
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
gboolean has_hw_cursor;
Rename MetaCursorReference to MetaCursorSprite It isn't really a reference to a MetaCursor enum, but a reference counted cursor sprite, and enum value. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-10 03:23:00 +00:00
MetaCursorSprite *last_cursor;
backends: Trigger animated cursor animations on the native backend We will need to update the timeout on either cursor changes, or right when ticking to the next cursor frame. https://bugzilla.gnome.org/show_bug.cgi?id=752342
2015-07-13 18:38:08 +00:00
guint animation_timeout_id;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
};
typedef struct _MetaCursorRendererNativePrivate MetaCursorRendererNativePrivate;
backends: Trigger animated cursor animations on the native backend We will need to update the timeout on either cursor changes, or right when ticking to the next cursor frame. https://bugzilla.gnome.org/show_bug.cgi?id=752342
2015-07-13 18:38:08 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
typedef struct _MetaCursorRendererNativeGpuData
{
gboolean hw_cursor_broken;
Support for hardware cursor sizes other than 64x64 on wayland Use the new DRM capabilities to figure out the correct cursor size, and make sure that matches instead of hardcoding 64x64. This fixes incorrect rendering on some newer AMD cards that support 256x256 cursors. Based heavily on a patch by: Alvaro Fernando García <alvarofernandogarcia@gmail.com>
2014-09-24 21:40:09 +00:00
uint64_t cursor_width;
uint64_t cursor_height;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
} MetaCursorRendererNativeGpuData;
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
typedef enum _MetaCursorGbmBoState
{
META_CURSOR_GBM_BO_STATE_NONE,
META_CURSOR_GBM_BO_STATE_SET,
META_CURSOR_GBM_BO_STATE_INVALIDATED,
} MetaCursorGbmBoState;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
typedef struct _MetaCursorNativeGpuState
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
{
guint active_bo;
MetaCursorGbmBoState pending_bo_state;
struct gbm_bo *bos[HW_CURSOR_BUFFER_COUNT];
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
} MetaCursorNativeGpuState;
typedef struct _MetaCursorNativePrivate
{
GHashTable *gpu_states;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
} MetaCursorNativePrivate;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
static GQuark quark_cursor_renderer_native_gpu_data = 0;
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
G_DEFINE_TYPE_WITH_PRIVATE (MetaCursorRendererNative, meta_cursor_renderer_native, META_TYPE_CURSOR_RENDERER);
cursor-renderer/native: Let the backend realize cursor sprite itself It knows better when it's needed. For now, just do it just as before, before drawing. Eventually, we can conditionalize where to realize depending on the cursor sprite position. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 14:56:53 +00:00
static void
realize_cursor_sprite (MetaCursorRenderer *renderer,
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
MetaCursorSprite *cursor_sprite,
GList *gpus);
cursor-renderer/native: Let the backend realize cursor sprite itself It knows better when it's needed. For now, just do it just as before, before drawing. Eventually, we can conditionalize where to realize depending on the cursor sprite position. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 14:56:53 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
static MetaCursorNativeGpuState *
get_cursor_gpu_state (MetaCursorNativePrivate *cursor_priv,
MetaGpuKms *gpu_kms);
static MetaCursorNativeGpuState *
ensure_cursor_gpu_state (MetaCursorNativePrivate *cursor_priv,
MetaGpuKms *gpu_kms);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
static MetaCursorNativePrivate *
ensure_cursor_priv (MetaCursorSprite *cursor_sprite);
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
static MetaCursorNativePrivate *
get_cursor_priv (MetaCursorSprite *cursor_sprite);
static MetaCursorRendererNativeGpuData *
meta_cursor_renderer_native_gpu_data_from_gpu (MetaGpuKms *gpu_kms)
{
return g_object_get_qdata (G_OBJECT (gpu_kms),
quark_cursor_renderer_native_gpu_data);
}
static MetaCursorRendererNativeGpuData *
meta_create_cursor_renderer_native_gpu_data (MetaGpuKms *gpu_kms)
{
MetaCursorRendererNativeGpuData *cursor_renderer_gpu_data;
cursor_renderer_gpu_data = g_new0 (MetaCursorRendererNativeGpuData, 1);
g_object_set_qdata_full (G_OBJECT (gpu_kms),
quark_cursor_renderer_native_gpu_data,
cursor_renderer_gpu_data,
g_free);
return cursor_renderer_gpu_data;
}
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
static void
meta_cursor_renderer_native_finalize (GObject *object)
{
MetaCursorRendererNative *renderer = META_CURSOR_RENDERER_NATIVE (object);
cursor-renderer/native: Various whitespace fixes https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 12:31:44 +00:00
MetaCursorRendererNativePrivate *priv =
meta_cursor_renderer_native_get_instance_private (renderer);
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
backends: Trigger animated cursor animations on the native backend We will need to update the timeout on either cursor changes, or right when ticking to the next cursor frame. https://bugzilla.gnome.org/show_bug.cgi?id=752342
2015-07-13 18:38:08 +00:00
if (priv->animation_timeout_id)
g_source_remove (priv->animation_timeout_id);
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
G_OBJECT_CLASS (meta_cursor_renderer_native_parent_class)->finalize (object);
}
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
static guint
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
get_pending_cursor_sprite_gbm_bo_index (MetaCursorNativeGpuState *cursor_gpu_state)
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
{
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
return (cursor_gpu_state->active_bo + 1) % HW_CURSOR_BUFFER_COUNT;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
}
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
static struct gbm_bo *
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
get_pending_cursor_sprite_gbm_bo (MetaCursorNativeGpuState *cursor_gpu_state)
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
{
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
guint pending_bo;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
pending_bo = get_pending_cursor_sprite_gbm_bo_index (cursor_gpu_state);
return cursor_gpu_state->bos[pending_bo];
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
}
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
static struct gbm_bo *
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
get_active_cursor_sprite_gbm_bo (MetaCursorNativeGpuState *cursor_gpu_state)
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
{
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
return cursor_gpu_state->bos[cursor_gpu_state->active_bo];
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
}
static void
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
set_pending_cursor_sprite_gbm_bo (MetaCursorSprite *cursor_sprite,
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
MetaGpuKms *gpu_kms,
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
struct gbm_bo *bo)
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
{
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
MetaCursorNativePrivate *cursor_priv;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
MetaCursorNativeGpuState *cursor_gpu_state;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
guint pending_bo;
cursor_priv = ensure_cursor_priv (cursor_sprite);
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_gpu_state = ensure_cursor_gpu_state (cursor_priv, gpu_kms);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
pending_bo = get_pending_cursor_sprite_gbm_bo_index (cursor_gpu_state);
cursor_gpu_state->bos[pending_bo] = bo;
cursor_gpu_state->pending_bo_state = META_CURSOR_GBM_BO_STATE_SET;
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
}
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
static void
set_crtc_cursor (MetaCursorRendererNative *native,
monitor-manager: Rename MetaCRTC(Info) to MetaCrtc(Info) Change to follow the naming convention used everywhere else. This means changing CRTC to Crtc even though it is an abbreviation. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2016-12-08 04:15:28 +00:00
MetaCrtc *crtc,
MetaCursorRendererNative: Always force set hw cursor the first time The initial state of the hardware cursor is not known, so always force update it the first time we update the cursor. Do this by changing the 'force' flag of update_hw_cursor() to an 'invalidated' hw cursor state. https://bugzilla.gnome.org/show_bug.cgi?id=771056
2017-01-10 08:01:46 +00:00
MetaCursorSprite *cursor_sprite)
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
{
cursor-renderer/native: Various whitespace fixes https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 12:31:44 +00:00
MetaCursorRendererNativePrivate *priv =
meta_cursor_renderer_native_get_instance_private (native);
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
MetaCursorRendererNativeGpuData *cursor_renderer_gpu_data;
MetaGpuKms *gpu_kms;
int kms_fd;
gpu_kms = META_GPU_KMS (meta_crtc_get_gpu (crtc));
cursor_renderer_gpu_data =
meta_cursor_renderer_native_gpu_data_from_gpu (gpu_kms);
kms_fd = meta_gpu_kms_get_fd (gpu_kms);
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
Rename MetaCursorReference to MetaCursorSprite It isn't really a reference to a MetaCursor enum, but a reference counted cursor sprite, and enum value. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-10 03:23:00 +00:00
if (cursor_sprite)
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
{
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
MetaCursorNativePrivate *cursor_priv;
MetaCursorNativeGpuState *cursor_gpu_state;
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
struct gbm_bo *bo;
union gbm_bo_handle handle;
int hot_x, hot_y;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_priv = get_cursor_priv (cursor_sprite);
cursor_gpu_state = get_cursor_gpu_state (cursor_priv, gpu_kms);
if (cursor_gpu_state->pending_bo_state == META_CURSOR_GBM_BO_STATE_SET)
bo = get_pending_cursor_sprite_gbm_bo (cursor_gpu_state);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
else
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
bo = get_active_cursor_sprite_gbm_bo (cursor_gpu_state);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
MetaCursorRendererNative: Always force set hw cursor the first time The initial state of the hardware cursor is not known, so always force update it the first time we update the cursor. Do this by changing the 'force' flag of update_hw_cursor() to an 'invalidated' hw cursor state. https://bugzilla.gnome.org/show_bug.cgi?id=771056
2017-01-10 08:01:46 +00:00
if (!priv->hw_state_invalidated && bo == crtc->cursor_renderer_private)
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
return;
crtc->cursor_renderer_private = bo;
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
handle = gbm_bo_get_handle (bo);
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
meta_cursor_sprite_get_hotspot (cursor_sprite, &hot_x, &hot_y);
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
if (drmModeSetCursor2 (kms_fd, crtc->crtc_id, handle.u32,
cursor_renderer_gpu_data->cursor_width,
cursor_renderer_gpu_data->cursor_height,
cursor-renderer-native: fallback to texture cursor In some cases the hardware cursor is invisible when Mutter is launched from the TTY, due to drmModeSetCursor2 failing without a fallback being set. This patch captures the return value of drmModeSetCursor2 and in case of an error, enables the texture based fallback. It adds a `broken` state, that is checked in should_have_hw_cursor() and meta_cursor_renderer_native_realize_cursor_from_*() to avoid copying every cursor into a gbm buffer when we know it will fail every single time. https://bugzilla.gnome.org/show_bug.cgi?id=770020
2017-03-24 21:12:54 +00:00
hot_x, hot_y) < 0)
{
cursor-rendere-native: Don't declare HW cursors broken on EACCES Don't permanently fall back to OpenGL based cursor rendering when setting the HW cursor fails with EACCES as that may happen on VT switching and other things temporarily revoking fd access. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-24 03:44:57 +00:00
if (errno != EACCES)
{
g_warning ("drmModeSetCursor2 failed with (%s), "
"drawing cursor with OpenGL from now on",
strerror (errno));
priv->has_hw_cursor = FALSE;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_renderer_gpu_data->hw_cursor_broken = TRUE;
cursor-rendere-native: Don't declare HW cursors broken on EACCES Don't permanently fall back to OpenGL based cursor rendering when setting the HW cursor fails with EACCES as that may happen on VT switching and other things temporarily revoking fd access. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-24 03:44:57 +00:00
}
cursor-renderer-native: fallback to texture cursor In some cases the hardware cursor is invisible when Mutter is launched from the TTY, due to drmModeSetCursor2 failing without a fallback being set. This patch captures the return value of drmModeSetCursor2 and in case of an error, enables the texture based fallback. It adds a `broken` state, that is checked in should_have_hw_cursor() and meta_cursor_renderer_native_realize_cursor_from_*() to avoid copying every cursor into a gbm buffer when we know it will fail every single time. https://bugzilla.gnome.org/show_bug.cgi?id=770020
2017-03-24 21:12:54 +00:00
}
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
if (cursor_gpu_state->pending_bo_state == META_CURSOR_GBM_BO_STATE_SET)
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
{
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_gpu_state->active_bo =
(cursor_gpu_state->active_bo + 1) % HW_CURSOR_BUFFER_COUNT;
cursor_gpu_state->pending_bo_state = META_CURSOR_GBM_BO_STATE_NONE;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
}
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
}
else
{
MetaCursorRendererNative: Always force set hw cursor the first time The initial state of the hardware cursor is not known, so always force update it the first time we update the cursor. Do this by changing the 'force' flag of update_hw_cursor() to an 'invalidated' hw cursor state. https://bugzilla.gnome.org/show_bug.cgi?id=771056
2017-01-10 08:01:46 +00:00
if (priv->hw_state_invalidated || crtc->cursor_renderer_private != NULL)
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
{
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
drmModeSetCursor2 (kms_fd, crtc->crtc_id, 0, 0, 0, 0, 0);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
crtc->cursor_renderer_private = NULL;
}
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
}
}
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
typedef struct
{
MetaCursorRendererNative *in_cursor_renderer_native;
MetaLogicalMonitor *in_logical_monitor;
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
ClutterRect in_local_cursor_rect;
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
MetaCursorSprite *in_cursor_sprite;
gboolean out_painted;
} UpdateCrtcCursorData;
static gboolean
update_monitor_crtc_cursor (MetaMonitor *monitor,
MetaMonitorMode *monitor_mode,
MetaMonitorCrtcMode *monitor_crtc_mode,
gpointer user_data,
GError **error)
{
UpdateCrtcCursorData *data = user_data;
MetaCursorRendererNative *cursor_renderer_native =
data->in_cursor_renderer_native;
MetaCursorRendererNativePrivate *priv =
meta_cursor_renderer_native_get_instance_private (cursor_renderer_native);
cursor-renderer-native: take rotation into account Rotating an output would show duplicate cursors when the pointer is located over an area which would be within the output if not rotated. Make sure to swap the width/height of the output when rotated. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/85
2018-03-26 13:56:04 +00:00
MetaMonitorTransform transform;
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
ClutterRect scaled_crtc_rect;
logical-monitor: Make scale a float To support fractional scaling, the logical monitor scale must be stored as a float. No other functional changes is part of this commit. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-05-25 08:12:51 +00:00
float scale;
monitor: Don't keep CRTC position in MetaMonitorCrtcMode The CRTC position depends on the transform and how the transform is implemented. The function calculating the positions still doesn't support anything but the non-transformed case; this commit is in preparation of adding support for transforms. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-17 09:21:10 +00:00
int crtc_x, crtc_y;
cursor-renderer-native: take rotation into account Rotating an output would show duplicate cursors when the pointer is located over an area which would be within the output if not rotated. Make sure to swap the width/height of the output when rotated. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/85
2018-03-26 13:56:04 +00:00
int crtc_width, crtc_height;
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
if (meta_is_stage_views_scaled ())
scale = meta_logical_monitor_get_scale (data->in_logical_monitor);
else
logical-monitor: Make scale a float To support fractional scaling, the logical monitor scale must be stored as a float. No other functional changes is part of this commit. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-05-25 08:12:51 +00:00
scale = 1.0;
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
monitor: Don't keep CRTC position in MetaMonitorCrtcMode The CRTC position depends on the transform and how the transform is implemented. The function calculating the positions still doesn't support anything but the non-transformed case; this commit is in preparation of adding support for transforms. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-17 09:21:10 +00:00
meta_monitor_calculate_crtc_pos (monitor, monitor_mode,
monitor_crtc_mode->output,
monitor-config-manager: Support logical monitor transforms Add support for rotated monitors. This is done per logical monitor, as every monitor assigned to a logical monitor must be transformed in the same way. This includes being transformed on the same level; e.g. if the backend does not support transforming any monitor of a logical monitor natively, then all monitors will be transformed using the offscreen intermediate framebuffer. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-21 06:17:18 +00:00
META_MONITOR_TRANSFORM_NORMAL,
monitor: Don't keep CRTC position in MetaMonitorCrtcMode The CRTC position depends on the transform and how the transform is implemented. The function calculating the positions still doesn't support anything but the non-transformed case; this commit is in preparation of adding support for transforms. https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-03-17 09:21:10 +00:00
&crtc_x, &crtc_y);
cursor-renderer-native: take rotation into account Rotating an output would show duplicate cursors when the pointer is located over an area which would be within the output if not rotated. Make sure to swap the width/height of the output when rotated. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/85
2018-03-26 13:56:04 +00:00
transform = meta_logical_monitor_get_transform (data->in_logical_monitor);
if (meta_monitor_transform_is_rotated (transform))
{
crtc_width = monitor_crtc_mode->crtc_mode->height;
crtc_height = monitor_crtc_mode->crtc_mode->width;
}
else
{
crtc_width = monitor_crtc_mode->crtc_mode->width;
crtc_height = monitor_crtc_mode->crtc_mode->height;
}
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
scaled_crtc_rect = (ClutterRect) {
.origin = {
.x = crtc_x / scale,
.y = crtc_y / scale
},
.size = {
cursor-renderer-native: take rotation into account Rotating an output would show duplicate cursors when the pointer is located over an area which would be within the output if not rotated. Make sure to swap the width/height of the output when rotated. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/85
2018-03-26 13:56:04 +00:00
.width = crtc_width / scale,
.height = crtc_height / scale
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
},
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
};
if (priv->has_hw_cursor &&
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
clutter_rect_intersection (&scaled_crtc_rect,
&data->in_local_cursor_rect,
NULL))
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
{
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
MetaGpuKms *gpu_kms;
int kms_fd;
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
float crtc_cursor_x, crtc_cursor_y;
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
set_crtc_cursor (data->in_cursor_renderer_native,
monitor_crtc_mode->output->crtc,
data->in_cursor_sprite);
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
gpu_kms = META_GPU_KMS (meta_monitor_get_gpu (monitor));
kms_fd = meta_gpu_kms_get_fd (gpu_kms);
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
crtc_cursor_x = (data->in_local_cursor_rect.origin.x -
scaled_crtc_rect.origin.x) * scale;
crtc_cursor_y = (data->in_local_cursor_rect.origin.y -
scaled_crtc_rect.origin.y) * scale;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
drmModeMoveCursor (kms_fd,
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
monitor_crtc_mode->output->crtc->crtc_id,
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
roundf (crtc_cursor_x),
roundf (crtc_cursor_y));
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
data->out_painted = data->out_painted || TRUE;
}
else
{
set_crtc_cursor (data->in_cursor_renderer_native,
monitor_crtc_mode->output->crtc, NULL);
}
return TRUE;
}
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
static void
update_hw_cursor (MetaCursorRendererNative *native,
MetaCursorRendererNative: Always force set hw cursor the first time The initial state of the hardware cursor is not known, so always force update it the first time we update the cursor. Do this by changing the 'force' flag of update_hw_cursor() to an 'invalidated' hw cursor state. https://bugzilla.gnome.org/show_bug.cgi?id=771056
2017-01-10 08:01:46 +00:00
MetaCursorSprite *cursor_sprite)
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
{
cursor-renderer/native: Various whitespace fixes https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 12:31:44 +00:00
MetaCursorRendererNativePrivate *priv =
meta_cursor_renderer_native_get_instance_private (native);
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
MetaCursorRenderer *renderer = META_CURSOR_RENDERER (native);
native/cursor-renderer: Cleanup construction Pass the backend to a new factory function, and keep a pointer to the monitor manager, which is accessed elsewhere in the same file instead of fetching the singleton. The HW cursor initialization part is also made more obvious, without depending on seemingly irrelevant clutter features. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-07 08:12:07 +00:00
MetaMonitorManager *monitor_manager = priv->monitor_manager;
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
GList *logical_monitors;
GList *l;
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
ClutterRect rect;
cursor-renderer: Add a cursor painted signal This signal allows interested parties to be notified of a new cursor frame being painted regardless of whether it's being painted by the backend directly or if it's a software rendered cursor frame handled by clutter. https://bugzilla.gnome.org/show_bug.cgi?id=749913
2016-01-10 16:28:54 +00:00
gboolean painted = FALSE;
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
if (cursor_sprite)
rect = meta_cursor_renderer_calculate_rect (renderer, cursor_sprite);
else
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
rect = (ClutterRect) { 0 };
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
logical_monitors =
meta_monitor_manager_get_logical_monitors (monitor_manager);
for (l = logical_monitors; l; l = l->next)
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
{
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
MetaLogicalMonitor *logical_monitor = l->data;
UpdateCrtcCursorData data;
GList *monitors;
GList *k;
data = (UpdateCrtcCursorData) {
.in_cursor_renderer_native = native,
.in_logical_monitor = logical_monitor,
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
.in_local_cursor_rect = (ClutterRect) {
.origin = {
.x = rect.origin.x - logical_monitor->rect.x,
.y = rect.origin.y - logical_monitor->rect.y
},
.size = rect.size
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
},
.in_cursor_sprite = cursor_sprite
};
monitors = meta_logical_monitor_get_monitors (logical_monitor);
for (k = monitors; k; k = k->next)
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
{
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
MetaMonitor *monitor = k->data;
MetaMonitorMode *monitor_mode;
monitor_mode = meta_monitor_get_current_mode (monitor);
meta_monitor_mode_foreach_crtc (monitor, monitor_mode,
update_monitor_crtc_cursor,
&data,
NULL);
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
}
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
painted = painted || data.out_painted;
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
}
cursor-renderer: Add a cursor painted signal This signal allows interested parties to be notified of a new cursor frame being painted regardless of whether it's being painted by the backend directly or if it's a software rendered cursor frame handled by clutter. https://bugzilla.gnome.org/show_bug.cgi?id=749913
2016-01-10 16:28:54 +00:00
MetaCursorRendererNative: Always force set hw cursor the first time The initial state of the hardware cursor is not known, so always force update it the first time we update the cursor. Do this by changing the 'force' flag of update_hw_cursor() to an 'invalidated' hw cursor state. https://bugzilla.gnome.org/show_bug.cgi?id=771056
2017-01-10 08:01:46 +00:00
priv->hw_state_invalidated = FALSE;
cursor-renderer: Add a cursor painted signal This signal allows interested parties to be notified of a new cursor frame being painted regardless of whether it's being painted by the backend directly or if it's a software rendered cursor frame handled by clutter. https://bugzilla.gnome.org/show_bug.cgi?id=749913
2016-01-10 16:28:54 +00:00
if (painted)
meta_cursor_renderer_emit_painted (renderer, cursor_sprite);
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
}
static gboolean
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
has_valid_cursor_sprite_gbm_bo (MetaCursorSprite *cursor_sprite,
MetaGpuKms *gpu_kms)
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
{
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
MetaCursorNativePrivate *cursor_priv;
MetaCursorNativeGpuState *cursor_gpu_state;
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_priv = get_cursor_priv (cursor_sprite);
cursor-renderer-native: Avoid a crash if we fail to allocate a gbm bo https://bugzilla.gnome.org/show_bug.cgi?id=758613
2016-01-08 15:09:10 +00:00
if (!cursor_priv)
return FALSE;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_gpu_state = get_cursor_gpu_state (cursor_priv, gpu_kms);
if (!cursor_gpu_state)
return FALSE;
switch (cursor_gpu_state->pending_bo_state)
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
{
case META_CURSOR_GBM_BO_STATE_NONE:
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
return get_active_cursor_sprite_gbm_bo (cursor_gpu_state) != NULL;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
case META_CURSOR_GBM_BO_STATE_SET:
return TRUE;
case META_CURSOR_GBM_BO_STATE_INVALIDATED:
return FALSE;
}
g_assert_not_reached ();
return FALSE;
}
native: Implement DRM-based crtc rotation We can know the rotation modes supported by the driver, so export these as our supported modes, and ensure these modes are honored on the CRTC primary plane upon apply_configuration(). It is worth noting however that not all hardware will be capable of supporting all rotation modes (in fact, most of them won't). A driver independent solution should be in place to back up the rotation modes unsupported by the drivers, so this is still a partial solution. The cursor renderer has also been changed to default to software-based rendering anytime the cursor enters a rotated CRTC. Another solution would be actually rotating the DRM cursor planes, but then it requires applying rotation on these per-CRTC, and actually transforming the pointer position by the output matrix. This brings marginal gains, so we use the "sw" rendered cursor, which will be transformed together with the primary plane. https://bugzilla.gnome.org/show_bug.cgi?id=745079
2015-12-18 11:16:59 +00:00
static gboolean
cursor-renderer-native: Don't use HW cursor on transformed logical monitor The HW cursor plane can't do any transformations, and as we still don't pre-transform any buffer before uploading to the cursor plane, we must disable the HW cursor when a logical monitor is transformed. This worked previously because the transform of a MetaCrtc did not correspond to the transform of a CRTC, but the transform of the logical monitor the CRTC was assigned to. https://bugzilla.gnome.org/show_bug.cgi?id=786023
2017-08-11 07:02:43 +00:00
cursor_over_transformed_logical_monitor (MetaCursorRenderer *renderer,
MetaCursorSprite *cursor_sprite)
native: Implement DRM-based crtc rotation We can know the rotation modes supported by the driver, so export these as our supported modes, and ensure these modes are honored on the CRTC primary plane upon apply_configuration(). It is worth noting however that not all hardware will be capable of supporting all rotation modes (in fact, most of them won't). A driver independent solution should be in place to back up the rotation modes unsupported by the drivers, so this is still a partial solution. The cursor renderer has also been changed to default to software-based rendering anytime the cursor enters a rotated CRTC. Another solution would be actually rotating the DRM cursor planes, but then it requires applying rotation on these per-CRTC, and actually transforming the pointer position by the output matrix. This brings marginal gains, so we use the "sw" rendered cursor, which will be transformed together with the primary plane. https://bugzilla.gnome.org/show_bug.cgi?id=745079
2015-12-18 11:16:59 +00:00
{
native/cursor-renderer: Cleanup construction Pass the backend to a new factory function, and keep a pointer to the monitor manager, which is accessed elsewhere in the same file instead of fetching the singleton. The HW cursor initialization part is also made more obvious, without depending on seemingly irrelevant clutter features. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-07 08:12:07 +00:00
MetaCursorRendererNative *cursor_renderer_native =
META_CURSOR_RENDERER_NATIVE (renderer);
MetaCursorRendererNativePrivate *priv =
meta_cursor_renderer_native_get_instance_private (cursor_renderer_native);
MetaMonitorManager *monitor_manager = priv->monitor_manager;
cursor-renderer-native: Don't use HW cursor on transformed logical monitor The HW cursor plane can't do any transformations, and as we still don't pre-transform any buffer before uploading to the cursor plane, we must disable the HW cursor when a logical monitor is transformed. This worked previously because the transform of a MetaCrtc did not correspond to the transform of a CRTC, but the transform of the logical monitor the CRTC was assigned to. https://bugzilla.gnome.org/show_bug.cgi?id=786023
2017-08-11 07:02:43 +00:00
GList *logical_monitors;
GList *l;
ClutterRect cursor_rect;
native: Implement DRM-based crtc rotation We can know the rotation modes supported by the driver, so export these as our supported modes, and ensure these modes are honored on the CRTC primary plane upon apply_configuration(). It is worth noting however that not all hardware will be capable of supporting all rotation modes (in fact, most of them won't). A driver independent solution should be in place to back up the rotation modes unsupported by the drivers, so this is still a partial solution. The cursor renderer has also been changed to default to software-based rendering anytime the cursor enters a rotated CRTC. Another solution would be actually rotating the DRM cursor planes, but then it requires applying rotation on these per-CRTC, and actually transforming the pointer position by the output matrix. This brings marginal gains, so we use the "sw" rendered cursor, which will be transformed together with the primary plane. https://bugzilla.gnome.org/show_bug.cgi?id=745079
2015-12-18 11:16:59 +00:00
cursor-renderer-native: Don't use HW cursor on transformed logical monitor The HW cursor plane can't do any transformations, and as we still don't pre-transform any buffer before uploading to the cursor plane, we must disable the HW cursor when a logical monitor is transformed. This worked previously because the transform of a MetaCrtc did not correspond to the transform of a CRTC, but the transform of the logical monitor the CRTC was assigned to. https://bugzilla.gnome.org/show_bug.cgi?id=786023
2017-08-11 07:02:43 +00:00
cursor_rect = meta_cursor_renderer_calculate_rect (renderer, cursor_sprite);
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor-renderer-native: Don't use HW cursor on transformed logical monitor The HW cursor plane can't do any transformations, and as we still don't pre-transform any buffer before uploading to the cursor plane, we must disable the HW cursor when a logical monitor is transformed. This worked previously because the transform of a MetaCrtc did not correspond to the transform of a CRTC, but the transform of the logical monitor the CRTC was assigned to. https://bugzilla.gnome.org/show_bug.cgi?id=786023
2017-08-11 07:02:43 +00:00
logical_monitors =
meta_monitor_manager_get_logical_monitors (monitor_manager);
for (l = logical_monitors; l; l = l->next)
native: Implement DRM-based crtc rotation We can know the rotation modes supported by the driver, so export these as our supported modes, and ensure these modes are honored on the CRTC primary plane upon apply_configuration(). It is worth noting however that not all hardware will be capable of supporting all rotation modes (in fact, most of them won't). A driver independent solution should be in place to back up the rotation modes unsupported by the drivers, so this is still a partial solution. The cursor renderer has also been changed to default to software-based rendering anytime the cursor enters a rotated CRTC. Another solution would be actually rotating the DRM cursor planes, but then it requires applying rotation on these per-CRTC, and actually transforming the pointer position by the output matrix. This brings marginal gains, so we use the "sw" rendered cursor, which will be transformed together with the primary plane. https://bugzilla.gnome.org/show_bug.cgi?id=745079
2015-12-18 11:16:59 +00:00
{
cursor-renderer-native: Don't use HW cursor on transformed logical monitor The HW cursor plane can't do any transformations, and as we still don't pre-transform any buffer before uploading to the cursor plane, we must disable the HW cursor when a logical monitor is transformed. This worked previously because the transform of a MetaCrtc did not correspond to the transform of a CRTC, but the transform of the logical monitor the CRTC was assigned to. https://bugzilla.gnome.org/show_bug.cgi?id=786023
2017-08-11 07:02:43 +00:00
MetaLogicalMonitor *logical_monitor = l->data;
MetaRectangle logical_monitor_layout;
ClutterRect logical_monitor_rect;
MetaMonitorTransform transform;
cursor-renderer-native: Take panel-orientation into account Even if the logical_monitor config does not have an active transform, we might still be doing a transform under the hood to compensate for panel-orientation. Check for this and fall back to the sw cursor if this is the case. https://bugzilla.gnome.org/show_bug.cgi?id=782294
2017-10-06 12:48:32 +00:00
GList *monitors, *l_mon;
cursor-renderer-native: Don't use HW cursor on transformed logical monitor The HW cursor plane can't do any transformations, and as we still don't pre-transform any buffer before uploading to the cursor plane, we must disable the HW cursor when a logical monitor is transformed. This worked previously because the transform of a MetaCrtc did not correspond to the transform of a CRTC, but the transform of the logical monitor the CRTC was assigned to. https://bugzilla.gnome.org/show_bug.cgi?id=786023
2017-08-11 07:02:43 +00:00
logical_monitor_layout =
meta_logical_monitor_get_layout (logical_monitor);
logical_monitor_rect =
meta_rectangle_to_clutter_rect (&logical_monitor_layout);
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
cursor-renderer-native: Don't use HW cursor on transformed logical monitor The HW cursor plane can't do any transformations, and as we still don't pre-transform any buffer before uploading to the cursor plane, we must disable the HW cursor when a logical monitor is transformed. This worked previously because the transform of a MetaCrtc did not correspond to the transform of a CRTC, but the transform of the logical monitor the CRTC was assigned to. https://bugzilla.gnome.org/show_bug.cgi?id=786023
2017-08-11 07:02:43 +00:00
if (!clutter_rect_intersection (&cursor_rect, &logical_monitor_rect,
NULL))
native: Implement DRM-based crtc rotation We can know the rotation modes supported by the driver, so export these as our supported modes, and ensure these modes are honored on the CRTC primary plane upon apply_configuration(). It is worth noting however that not all hardware will be capable of supporting all rotation modes (in fact, most of them won't). A driver independent solution should be in place to back up the rotation modes unsupported by the drivers, so this is still a partial solution. The cursor renderer has also been changed to default to software-based rendering anytime the cursor enters a rotated CRTC. Another solution would be actually rotating the DRM cursor planes, but then it requires applying rotation on these per-CRTC, and actually transforming the pointer position by the output matrix. This brings marginal gains, so we use the "sw" rendered cursor, which will be transformed together with the primary plane. https://bugzilla.gnome.org/show_bug.cgi?id=745079
2015-12-18 11:16:59 +00:00
continue;
cursor-renderer-native: Take panel-orientation into account Even if the logical_monitor config does not have an active transform, we might still be doing a transform under the hood to compensate for panel-orientation. Check for this and fall back to the sw cursor if this is the case. https://bugzilla.gnome.org/show_bug.cgi?id=782294
2017-10-06 12:48:32 +00:00
monitors = meta_logical_monitor_get_monitors (logical_monitor);
for (l_mon = monitors; l_mon; l_mon = l_mon->next)
{
MetaMonitor *monitor = l_mon->data;
transform = meta_logical_monitor_get_transform (logical_monitor);
/* Get transform corrected for LCD panel-orientation. */
transform = meta_monitor_logical_to_crtc_transform (monitor, transform);
if (transform != META_MONITOR_TRANSFORM_NORMAL)
return TRUE;
}
native: Implement DRM-based crtc rotation We can know the rotation modes supported by the driver, so export these as our supported modes, and ensure these modes are honored on the CRTC primary plane upon apply_configuration(). It is worth noting however that not all hardware will be capable of supporting all rotation modes (in fact, most of them won't). A driver independent solution should be in place to back up the rotation modes unsupported by the drivers, so this is still a partial solution. The cursor renderer has also been changed to default to software-based rendering anytime the cursor enters a rotated CRTC. Another solution would be actually rotating the DRM cursor planes, but then it requires applying rotation on these per-CRTC, and actually transforming the pointer position by the output matrix. This brings marginal gains, so we use the "sw" rendered cursor, which will be transformed together with the primary plane. https://bugzilla.gnome.org/show_bug.cgi?id=745079
2015-12-18 11:16:59 +00:00
}
return FALSE;
}
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
static float
calculate_cursor_crtc_sprite_scale (MetaCursorSprite *cursor_sprite,
MetaLogicalMonitor *logical_monitor)
{
return (meta_logical_monitor_get_scale (logical_monitor) *
meta_cursor_sprite_get_texture_scale (cursor_sprite));
}
static gboolean
can_draw_cursor_unscaled (MetaCursorRenderer *renderer,
MetaCursorSprite *cursor_sprite)
{
native/cursor-renderer: Cleanup construction Pass the backend to a new factory function, and keep a pointer to the monitor manager, which is accessed elsewhere in the same file instead of fetching the singleton. The HW cursor initialization part is also made more obvious, without depending on seemingly irrelevant clutter features. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-07 08:12:07 +00:00
MetaCursorRendererNative *cursor_renderer_native =
META_CURSOR_RENDERER_NATIVE (renderer);
MetaCursorRendererNativePrivate *priv =
meta_cursor_renderer_native_get_instance_private (cursor_renderer_native);
MetaMonitorManager *monitor_manager = priv->monitor_manager;
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
ClutterRect cursor_rect;
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
GList *logical_monitors;
GList *l;
gboolean has_visible_crtc_sprite = FALSE;
if (!meta_is_stage_views_scaled ())
return meta_cursor_sprite_get_texture_scale (cursor_sprite) == 1.0;
logical_monitors =
meta_monitor_manager_get_logical_monitors (monitor_manager);
if (!logical_monitors)
return FALSE;
cursor_rect = meta_cursor_renderer_calculate_rect (renderer, cursor_sprite);
for (l = logical_monitors; l; l = l->next)
{
MetaLogicalMonitor *logical_monitor = l->data;
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
ClutterRect logical_monitor_rect =
meta_rectangle_to_clutter_rect (&logical_monitor->rect);
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
cursor-renderer: Track cursor position using floats To be able to render the pointer cursor sprite at sub-(logical)-pixel positions, track the pointer position using floats instead of ints. This also requires users of the cursor sprite rect to deal with floating points, when e.g. finding the logical monitor etc. https://bugzilla.gnome.org/show_bug.cgi?id=765011
2017-06-08 14:13:16 +00:00
if (!clutter_rect_intersection (&cursor_rect,
&logical_monitor_rect,
NULL))
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
continue;
if (calculate_cursor_crtc_sprite_scale (cursor_sprite,
logical_monitor) != 1.0)
return FALSE;
has_visible_crtc_sprite = TRUE;
}
return has_visible_crtc_sprite;
}
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
static gboolean
should_have_hw_cursor (MetaCursorRenderer *renderer,
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
MetaCursorSprite *cursor_sprite,
GList *gpus)
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
{
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
GList *l;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
CoglTexture *texture;
if (!cursor_sprite)
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
return FALSE;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
for (l = gpus; l; l = l->next)
{
MetaGpuKms *gpu_kms = l->data;
MetaCursorRendererNativeGpuData *cursor_renderer_gpu_data;
cursor_renderer_gpu_data =
meta_cursor_renderer_native_gpu_data_from_gpu (gpu_kms);
if (!cursor_renderer_gpu_data)
return FALSE;
if (cursor_renderer_gpu_data->hw_cursor_broken)
return FALSE;
if (!has_valid_cursor_sprite_gbm_bo (cursor_sprite, gpu_kms))
return FALSE;
}
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
cursor-renderer-native: Don't use HW cursor on transformed logical monitor The HW cursor plane can't do any transformations, and as we still don't pre-transform any buffer before uploading to the cursor plane, we must disable the HW cursor when a logical monitor is transformed. This worked previously because the transform of a MetaCrtc did not correspond to the transform of a CRTC, but the transform of the logical monitor the CRTC was assigned to. https://bugzilla.gnome.org/show_bug.cgi?id=786023
2017-08-11 07:02:43 +00:00
if (cursor_over_transformed_logical_monitor (renderer, cursor_sprite))
native: Implement DRM-based crtc rotation We can know the rotation modes supported by the driver, so export these as our supported modes, and ensure these modes are honored on the CRTC primary plane upon apply_configuration(). It is worth noting however that not all hardware will be capable of supporting all rotation modes (in fact, most of them won't). A driver independent solution should be in place to back up the rotation modes unsupported by the drivers, so this is still a partial solution. The cursor renderer has also been changed to default to software-based rendering anytime the cursor enters a rotated CRTC. Another solution would be actually rotating the DRM cursor planes, but then it requires applying rotation on these per-CRTC, and actually transforming the pointer position by the output matrix. This brings marginal gains, so we use the "sw" rendered cursor, which will be transformed together with the primary plane. https://bugzilla.gnome.org/show_bug.cgi?id=745079
2015-12-18 11:16:59 +00:00
return FALSE;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
texture = meta_cursor_sprite_get_cogl_texture (cursor_sprite);
if (!texture)
return FALSE;
Add support for scaled logical monitor framebuffers This commit adds support for rendering onto enlarged per logical monitor framebuffers, using the scaled clutter stage views, for HiDPI enabled logical monitors. This works by scaling the mode of the monitors in a logical monitors by the scale, no longer relying on scaling the window actors and window geometry for making windows have the correct size on HiDPI monitors. It is disabled by default, as in automatically created configurations will still use the old mode. This is partly because Xwayland clients will not yet work good enough to make it feasible. To enable, add the 'scale-monitor-framebuffer' keyword to the org.gnome.mutter.experimental-features gsettings array. It is still possible to specify the mode via the new D-Bus API, which has been adapted. The adaptations to the D-Bus API means the caller need to be aware of how to position logical monitors on the stage grid. This depends on the 'layout-mode' property that is used (see the DisplayConfig D-Bus documentation). https://bugzilla.gnome.org/show_bug.cgi?id=777732
2017-02-24 10:10:52 +00:00
if (!can_draw_cursor_unscaled (renderer, cursor_sprite))
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
return FALSE;
return TRUE;
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
}
backends: Trigger animated cursor animations on the native backend We will need to update the timeout on either cursor changes, or right when ticking to the next cursor frame. https://bugzilla.gnome.org/show_bug.cgi?id=752342
2015-07-13 18:38:08 +00:00
static gboolean
meta_cursor_renderer_native_update_animation (MetaCursorRendererNative *native)
{
cursor-renderer/native: Various whitespace fixes https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 12:31:44 +00:00
MetaCursorRendererNativePrivate *priv =
meta_cursor_renderer_native_get_instance_private (native);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
MetaCursorRenderer *renderer = META_CURSOR_RENDERER (native);
MetaCursorSprite *cursor_sprite = meta_cursor_renderer_get_cursor (renderer);
backends: Trigger animated cursor animations on the native backend We will need to update the timeout on either cursor changes, or right when ticking to the next cursor frame. https://bugzilla.gnome.org/show_bug.cgi?id=752342
2015-07-13 18:38:08 +00:00
priv->animation_timeout_id = 0;
Rename MetaCursorReference to MetaCursorSprite It isn't really a reference to a MetaCursor enum, but a reference counted cursor sprite, and enum value. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-10 03:23:00 +00:00
meta_cursor_sprite_tick_frame (cursor_sprite);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
meta_cursor_renderer_force_update (renderer);
backends: Trigger animated cursor animations on the native backend We will need to update the timeout on either cursor changes, or right when ticking to the next cursor frame. https://bugzilla.gnome.org/show_bug.cgi?id=752342
2015-07-13 18:38:08 +00:00
return G_SOURCE_REMOVE;
}
static void
cursor-renderer/native: Rename frame scheduling helper function The function conditionally schedules a cursor animation frame, so rename it to make that clearer. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 14:43:30 +00:00
maybe_schedule_cursor_sprite_animation_frame (MetaCursorRendererNative *native,
MetaCursorSprite *cursor_sprite)
backends: Trigger animated cursor animations on the native backend We will need to update the timeout on either cursor changes, or right when ticking to the next cursor frame. https://bugzilla.gnome.org/show_bug.cgi?id=752342
2015-07-13 18:38:08 +00:00
{
cursor-renderer/native: Various whitespace fixes https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 12:31:44 +00:00
MetaCursorRendererNativePrivate *priv =
meta_cursor_renderer_native_get_instance_private (native);
backends: Trigger animated cursor animations on the native backend We will need to update the timeout on either cursor changes, or right when ticking to the next cursor frame. https://bugzilla.gnome.org/show_bug.cgi?id=752342
2015-07-13 18:38:08 +00:00
gboolean cursor_change;
guint delay;
Rename MetaCursorReference to MetaCursorSprite It isn't really a reference to a MetaCursor enum, but a reference counted cursor sprite, and enum value. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-10 03:23:00 +00:00
cursor_change = cursor_sprite != priv->last_cursor;
priv->last_cursor = cursor_sprite;
backends: Trigger animated cursor animations on the native backend We will need to update the timeout on either cursor changes, or right when ticking to the next cursor frame. https://bugzilla.gnome.org/show_bug.cgi?id=752342
2015-07-13 18:38:08 +00:00
if (!cursor_change && priv->animation_timeout_id)
return;
if (priv->animation_timeout_id)
{
g_source_remove (priv->animation_timeout_id);
priv->animation_timeout_id = 0;
}
Rename MetaCursorReference to MetaCursorSprite It isn't really a reference to a MetaCursor enum, but a reference counted cursor sprite, and enum value. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-10 03:23:00 +00:00
if (cursor_sprite && meta_cursor_sprite_is_animated (cursor_sprite))
backends: Trigger animated cursor animations on the native backend We will need to update the timeout on either cursor changes, or right when ticking to the next cursor frame. https://bugzilla.gnome.org/show_bug.cgi?id=752342
2015-07-13 18:38:08 +00:00
{
Rename MetaCursorReference to MetaCursorSprite It isn't really a reference to a MetaCursor enum, but a reference counted cursor sprite, and enum value. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-10 03:23:00 +00:00
delay = meta_cursor_sprite_get_current_frame_time (cursor_sprite);
backends: Trigger animated cursor animations on the native backend We will need to update the timeout on either cursor changes, or right when ticking to the next cursor frame. https://bugzilla.gnome.org/show_bug.cgi?id=752342
2015-07-13 18:38:08 +00:00
if (delay == 0)
return;
priv->animation_timeout_id =
g_timeout_add (delay,
(GSourceFunc) meta_cursor_renderer_native_update_animation,
native);
g_source_set_name_by_id (priv->animation_timeout_id,
"[mutter] meta_cursor_renderer_native_update_animation");
}
}
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
static GList *
calculate_cursor_sprite_gpus (MetaCursorRenderer *renderer,
MetaCursorSprite *cursor_sprite)
{
MetaCursorRendererNative *native = META_CURSOR_RENDERER_NATIVE (renderer);
MetaCursorRendererNativePrivate *priv =
meta_cursor_renderer_native_get_instance_private (native);
MetaMonitorManager *monitor_manager = priv->monitor_manager;
GList *gpus = NULL;
GList *logical_monitors;
GList *l;
ClutterRect cursor_rect;
cursor_rect = meta_cursor_renderer_calculate_rect (renderer, cursor_sprite);
logical_monitors =
meta_monitor_manager_get_logical_monitors (monitor_manager);
for (l = logical_monitors; l; l = l->next)
{
MetaLogicalMonitor *logical_monitor = l->data;
MetaRectangle logical_monitor_layout;
ClutterRect logical_monitor_rect;
GList *monitors, *l_mon;
logical_monitor_layout =
meta_logical_monitor_get_layout (logical_monitor);
logical_monitor_rect =
meta_rectangle_to_clutter_rect (&logical_monitor_layout);
if (!clutter_rect_intersection (&cursor_rect, &logical_monitor_rect,
NULL))
continue;
monitors = meta_logical_monitor_get_monitors (logical_monitor);
for (l_mon = monitors; l_mon; l_mon = l_mon->next)
{
MetaMonitor *monitor = l_mon->data;
MetaGpu *gpu;
gpu = meta_monitor_get_gpu (monitor);
if (!g_list_find (gpus, gpu))
gpus = g_list_prepend (gpus, gpu);
}
}
return gpus;
}
cursor: Correct switching between fallback and backend cursors When switching from the stage cursor to the native cursor, we forgot to repaint the stage to get rid of the old cursor. Fix this by having the abstract cursor renderer class track whether we're using the backend, rather than doing chain-up shenanigans.
2014-05-17 15:22:05 +00:00
static gboolean
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
meta_cursor_renderer_native_update_cursor (MetaCursorRenderer *renderer,
MetaCursorSprite *cursor_sprite)
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
{
MetaCursorRendererNative *native = META_CURSOR_RENDERER_NATIVE (renderer);
cursor-renderer/native: Various whitespace fixes https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 12:31:44 +00:00
MetaCursorRendererNativePrivate *priv =
meta_cursor_renderer_native_get_instance_private (native);
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
g_autoptr (GList) gpus = NULL;
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
if (cursor_sprite)
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
{
meta_cursor_sprite_realize_texture (cursor_sprite);
gpus = calculate_cursor_sprite_gpus (renderer, cursor_sprite);
realize_cursor_sprite (renderer, cursor_sprite, gpus);
}
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
cursor-renderer/native: Rename frame scheduling helper function The function conditionally schedules a cursor animation frame, so rename it to make that clearer. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 14:43:30 +00:00
maybe_schedule_cursor_sprite_animation_frame (native, cursor_sprite);
backends: Trigger animated cursor animations on the native backend We will need to update the timeout on either cursor changes, or right when ticking to the next cursor frame. https://bugzilla.gnome.org/show_bug.cgi?id=752342
2015-07-13 18:38:08 +00:00
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
priv->has_hw_cursor = should_have_hw_cursor (renderer, cursor_sprite, gpus);
MetaCursorRendererNative: Always force set hw cursor the first time The initial state of the hardware cursor is not known, so always force update it the first time we update the cursor. Do this by changing the 'force' flag of update_hw_cursor() to an 'invalidated' hw cursor state. https://bugzilla.gnome.org/show_bug.cgi?id=771056
2017-01-10 08:01:46 +00:00
update_hw_cursor (native, cursor_sprite);
cursor-renderer/native: Don't trigger redraw when cursor hidden When a cursor is hidden, the native backend will properly hide the HW cursor sprite as well, but it would communicate this as if the cursor was not handled by the backend, while in fact it still was. This caused the generic cursor rendering layer to queue a redraw. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-11 11:23:39 +00:00
return (priv->has_hw_cursor ||
!cursor_sprite ||
!meta_cursor_sprite_get_cogl_texture (cursor_sprite));
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
}
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
static void
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_gpu_state_free (MetaCursorNativeGpuState *cursor_gpu_state)
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
{
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
int i;
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
for (i = 0; i < HW_CURSOR_BUFFER_COUNT; i++)
g_clear_pointer (&cursor_gpu_state->bos[i], (GDestroyNotify) gbm_bo_destroy);
g_free (cursor_gpu_state);
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
}
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
static MetaCursorNativeGpuState *
get_cursor_gpu_state (MetaCursorNativePrivate *cursor_priv,
MetaGpuKms *gpu_kms)
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
{
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
return g_hash_table_lookup (cursor_priv->gpu_states, gpu_kms);
}
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
static MetaCursorNativeGpuState *
ensure_cursor_gpu_state (MetaCursorNativePrivate *cursor_priv,
MetaGpuKms *gpu_kms)
{
MetaCursorNativeGpuState *cursor_gpu_state;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_gpu_state = get_cursor_gpu_state (cursor_priv, gpu_kms);
if (cursor_gpu_state)
return cursor_gpu_state;
cursor_gpu_state = g_new0 (MetaCursorNativeGpuState, 1);
g_hash_table_insert (cursor_priv->gpu_states, gpu_kms, cursor_gpu_state);
return cursor_gpu_state;
}
cursor-renderer/native: Let the backend realize cursor sprite itself It knows better when it's needed. For now, just do it just as before, before drawing. Eventually, we can conditionalize where to realize depending on the cursor sprite position. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 14:56:53 +00:00
static void
on_cursor_sprite_texture_changed (MetaCursorSprite *cursor_sprite)
{
MetaCursorNativePrivate *cursor_priv = get_cursor_priv (cursor_sprite);
GHashTableIter iter;
MetaCursorNativeGpuState *cursor_gpu_state;
g_hash_table_iter_init (&iter, cursor_priv->gpu_states);
while (g_hash_table_iter_next (&iter, NULL, (gpointer *) &cursor_gpu_state))
{
guint pending_bo;
pending_bo = get_pending_cursor_sprite_gbm_bo_index (cursor_gpu_state);
g_clear_pointer (&cursor_gpu_state->bos[pending_bo],
(GDestroyNotify) gbm_bo_destroy);
cursor_gpu_state->pending_bo_state = META_CURSOR_GBM_BO_STATE_INVALIDATED;
}
}
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
static void
cursor_priv_free (MetaCursorNativePrivate *cursor_priv)
{
g_hash_table_destroy (cursor_priv->gpu_states);
}
static MetaCursorNativePrivate *
get_cursor_priv (MetaCursorSprite *cursor_sprite)
{
return g_object_get_qdata (G_OBJECT (cursor_sprite), quark_cursor_sprite);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
}
static MetaCursorNativePrivate *
ensure_cursor_priv (MetaCursorSprite *cursor_sprite)
{
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
MetaCursorNativePrivate *cursor_priv;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_priv = get_cursor_priv (cursor_sprite);
if (cursor_priv)
return cursor_priv;
cursor_priv = g_new0 (MetaCursorNativePrivate, 1);
cursor_priv->gpu_states =
g_hash_table_new_full (g_direct_hash,
g_direct_equal,
NULL,
(GDestroyNotify) cursor_gpu_state_free);
g_object_set_qdata_full (G_OBJECT (cursor_sprite),
quark_cursor_sprite,
cursor_priv,
(GDestroyNotify) cursor_priv_free);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
cursor-renderer/native: Let the backend realize cursor sprite itself It knows better when it's needed. For now, just do it just as before, before drawing. Eventually, we can conditionalize where to realize depending on the cursor sprite position. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 14:56:53 +00:00
g_signal_connect (cursor_sprite, "texture-changed",
G_CALLBACK (on_cursor_sprite_texture_changed), NULL);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
return cursor_priv;
}
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
static void
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
load_cursor_sprite_gbm_buffer_for_gpu (MetaCursorRendererNative *native,
MetaGpuKms *gpu_kms,
MetaCursorSprite *cursor_sprite,
uint8_t *pixels,
uint width,
uint height,
int rowstride,
uint32_t gbm_format)
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
{
uint64_t cursor_width, cursor_height;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
MetaCursorRendererNativeGpuData *cursor_renderer_gpu_data;
struct gbm_device *gbm_device;
cursor_renderer_gpu_data =
meta_cursor_renderer_native_gpu_data_from_gpu (gpu_kms);
if (!cursor_renderer_gpu_data)
return;
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_width = (uint64_t) cursor_renderer_gpu_data->cursor_width;
cursor_height = (uint64_t) cursor_renderer_gpu_data->cursor_height;
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
if (width > cursor_width || height > cursor_height)
{
meta_warning ("Invalid theme cursor size (must be at most %ux%u)\n",
(unsigned int)cursor_width, (unsigned int)cursor_height);
return;
}
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
gbm_device = meta_gbm_device_from_gpu (gpu_kms);
if (gbm_device_is_format_supported (gbm_device, gbm_format,
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
GBM_BO_USE_CURSOR | GBM_BO_USE_WRITE))
{
struct gbm_bo *bo;
uint8_t buf[4 * cursor_width * cursor_height];
uint i;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
bo = gbm_bo_create (gbm_device, cursor_width, cursor_height,
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
gbm_format, GBM_BO_USE_CURSOR | GBM_BO_USE_WRITE);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
if (!bo)
{
meta_warning ("Failed to allocate HW cursor buffer\n");
return;
}
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
memset (buf, 0, sizeof(buf));
for (i = 0; i < height; i++)
memcpy (buf + i * 4 * cursor_width, pixels + i * rowstride, width * 4);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
if (gbm_bo_write (bo, buf, cursor_width * cursor_height * 4) != 0)
{
meta_warning ("Failed to write cursors buffer data: %s",
g_strerror (errno));
gbm_bo_destroy (bo);
return;
}
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
set_pending_cursor_sprite_gbm_bo (cursor_sprite, gpu_kms, bo);
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
}
else
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
{
meta_warning ("HW cursor for format %d not supported\n", gbm_format);
}
}
cursor-renderer/native: Let the backend realize cursor sprite itself It knows better when it's needed. For now, just do it just as before, before drawing. Eventually, we can conditionalize where to realize depending on the cursor sprite position. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 14:56:53 +00:00
static gboolean
is_cursor_hw_state_valid (MetaCursorSprite *cursor_sprite,
MetaGpuKms *gpu_kms)
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
{
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
MetaCursorNativePrivate *cursor_priv;
MetaCursorNativeGpuState *cursor_gpu_state;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_priv = get_cursor_priv (cursor_sprite);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
if (!cursor_priv)
cursor-renderer/native: Let the backend realize cursor sprite itself It knows better when it's needed. For now, just do it just as before, before drawing. Eventually, we can conditionalize where to realize depending on the cursor sprite position. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 14:56:53 +00:00
return FALSE;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_gpu_state = get_cursor_gpu_state (cursor_priv, gpu_kms);
if (!cursor_gpu_state)
cursor-renderer/native: Let the backend realize cursor sprite itself It knows better when it's needed. For now, just do it just as before, before drawing. Eventually, we can conditionalize where to realize depending on the cursor sprite position. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 14:56:53 +00:00
return FALSE;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor-renderer/native: Let the backend realize cursor sprite itself It knows better when it's needed. For now, just do it just as before, before drawing. Eventually, we can conditionalize where to realize depending on the cursor sprite position. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 14:56:53 +00:00
switch (cursor_gpu_state->pending_bo_state)
{
case META_CURSOR_GBM_BO_STATE_SET:
case META_CURSOR_GBM_BO_STATE_NONE:
return TRUE;
case META_CURSOR_GBM_BO_STATE_INVALIDATED:
return FALSE;
}
g_assert_not_reached ();
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
}
#ifdef HAVE_WAYLAND
static void
cursor-renderer/native: Fetch instead of pass wl_buffer when realizing This is the next step in centralizing the cursor sprite hw sprite realization paths. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 10:27:02 +00:00
realize_cursor_sprite_from_wl_buffer_for_gpu (MetaCursorRenderer *renderer,
MetaGpuKms *gpu_kms,
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
MetaCursorSpriteWayland *sprite_wayland)
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
{
MetaCursorRendererNative *native = META_CURSOR_RENDERER_NATIVE (renderer);
cursor-renderer/native: Fetch instead of pass wl_buffer when realizing This is the next step in centralizing the cursor sprite hw sprite realization paths. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 10:27:02 +00:00
MetaCursorSprite *cursor_sprite = META_CURSOR_SPRITE (sprite_wayland);
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
MetaCursorRendererNativeGpuData *cursor_renderer_gpu_data;
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
uint32_t gbm_format;
uint64_t cursor_width, cursor_height;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
CoglTexture *texture;
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
uint width, height;
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
MetaWaylandBuffer *buffer;
struct wl_resource *buffer_resource;
struct wl_shm_buffer *shm_buffer;
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_renderer_gpu_data =
meta_cursor_renderer_native_gpu_data_from_gpu (gpu_kms);
if (!cursor_renderer_gpu_data || cursor_renderer_gpu_data->hw_cursor_broken)
MetaCursorRendererNative: Fall back to texture when there is no gbm For when there is no gbm available, for example when using EGLDevice/EGLStream's, just fall back to the OpenGL texture based cursor rendering path. https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-09-27 05:39:45 +00:00
return;
cursor-renderer/native: Let the backend realize cursor sprite itself It knows better when it's needed. For now, just do it just as before, before drawing. Eventually, we can conditionalize where to realize depending on the cursor sprite position. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 14:56:53 +00:00
if (is_cursor_hw_state_valid (cursor_sprite, gpu_kms))
return;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
texture = meta_cursor_sprite_get_cogl_texture (cursor_sprite);
width = cogl_texture_get_width (texture);
height = cogl_texture_get_height (texture);
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
buffer = meta_cursor_sprite_wayland_get_buffer (sprite_wayland);
if (!buffer)
return;
buffer_resource = meta_wayland_buffer_get_resource (buffer);
if (!buffer_resource)
return;
shm_buffer = wl_shm_buffer_get (buffer_resource);
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
if (shm_buffer)
{
int rowstride = wl_shm_buffer_get_stride (shm_buffer);
uint8_t *buffer_data;
wl_shm_buffer_begin_access (shm_buffer);
switch (wl_shm_buffer_get_format (shm_buffer))
{
#if G_BYTE_ORDER == G_BIG_ENDIAN
case WL_SHM_FORMAT_ARGB8888:
gbm_format = GBM_FORMAT_ARGB8888;
break;
case WL_SHM_FORMAT_XRGB8888:
gbm_format = GBM_FORMAT_XRGB8888;
break;
#else
case WL_SHM_FORMAT_ARGB8888:
gbm_format = GBM_FORMAT_ARGB8888;
break;
case WL_SHM_FORMAT_XRGB8888:
gbm_format = GBM_FORMAT_XRGB8888;
break;
#endif
default:
g_warn_if_reached ();
gbm_format = GBM_FORMAT_ARGB8888;
}
buffer_data = wl_shm_buffer_get_data (shm_buffer);
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
load_cursor_sprite_gbm_buffer_for_gpu (native,
gpu_kms,
cursor_sprite,
buffer_data,
width, height, rowstride,
gbm_format);
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
wl_shm_buffer_end_access (shm_buffer);
}
else
{
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
struct gbm_device *gbm_device;
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
struct gbm_bo *bo;
/* HW cursors have a predefined size (at least 64x64), which usually is
* bigger than cursor theme size, so themed cursors must be padded with
* transparent pixels to fill the overlay. This is trivial if we have CPU
* access to the data, but it's not possible if the buffer is in GPU
* memory (and possibly tiled too), so if we don't get the right size, we
* fallback to GL. */
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_width = (uint64_t) cursor_renderer_gpu_data->cursor_width;
cursor_height = (uint64_t) cursor_renderer_gpu_data->cursor_height;
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
if (width != cursor_width || height != cursor_height)
{
meta_warning ("Invalid cursor size (must be 64x64), falling back to software (GL) cursors\n");
return;
}
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
gbm_device = meta_gbm_device_from_gpu (gpu_kms);
bo = gbm_bo_import (gbm_device,
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
GBM_BO_IMPORT_WL_BUFFER,
buffer,
GBM_BO_USE_CURSOR);
if (!bo)
{
meta_warning ("Importing HW cursor from wl_buffer failed\n");
return;
}
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
set_pending_cursor_sprite_gbm_bo (cursor_sprite, gpu_kms, bo);
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
}
}
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
#endif
static void
cursor-renderer/native: Shorten some helper function names Purely a cosmetic change, making a couple of unnecessarily long function name shorter. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 10:23:49 +00:00
realize_cursor_sprite_from_xcursor_for_gpu (MetaCursorRenderer *renderer,
MetaGpuKms *gpu_kms,
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
MetaCursorSpriteXcursor *sprite_xcursor)
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
{
MetaCursorRendererNative *native = META_CURSOR_RENDERER_NATIVE (renderer);
MetaCursorRendererNativeGpuData *cursor_renderer_gpu_data;
cursor-renderer: Fetch instead of pass Xcursor image when realizing The end goal here is to being able to realize at any point in time through a single API, so start by moving state into the cursor sprite implementation. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-04-30 10:55:08 +00:00
MetaCursorSprite *cursor_sprite = META_CURSOR_SPRITE (sprite_xcursor);
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
XcursorImage *xc_image;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_renderer_gpu_data =
meta_cursor_renderer_native_gpu_data_from_gpu (gpu_kms);
if (!cursor_renderer_gpu_data || cursor_renderer_gpu_data->hw_cursor_broken)
MetaCursorRendererNative: Fall back to texture when there is no gbm For when there is no gbm available, for example when using EGLDevice/EGLStream's, just fall back to the OpenGL texture based cursor rendering path. https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-09-27 05:39:45 +00:00
return;
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
cursor-renderer/native: Let the backend realize cursor sprite itself It knows better when it's needed. For now, just do it just as before, before drawing. Eventually, we can conditionalize where to realize depending on the cursor sprite position. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 14:56:53 +00:00
if (is_cursor_hw_state_valid (cursor_sprite, gpu_kms))
return;
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
xc_image = meta_cursor_sprite_xcursor_get_current_image (sprite_xcursor);
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
load_cursor_sprite_gbm_buffer_for_gpu (native,
gpu_kms,
cursor_sprite,
(uint8_t *) xc_image->pixels,
xc_image->width,
xc_image->height,
xc_image->width * 4,
GBM_FORMAT_ARGB8888);
}
static void
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
realize_cursor_sprite_for_gpu (MetaCursorRenderer *renderer,
MetaGpuKms *gpu_kms,
MetaCursorSprite *cursor_sprite)
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
{
cursor-renderer: Centralize hw cursor realization paths Use a common entry point into the cursor renderer implementations HW cursor realization paths for all cursor sprite types. This is in preparation for realizing at more strategic times. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 12:34:02 +00:00
if (META_IS_CURSOR_SPRITE_XCURSOR (cursor_sprite))
{
MetaCursorSpriteXcursor *sprite_xcursor =
META_CURSOR_SPRITE_XCURSOR (cursor_sprite);
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
realize_cursor_sprite_from_xcursor_for_gpu (renderer,
gpu_kms,
sprite_xcursor);
cursor-renderer: Centralize hw cursor realization paths Use a common entry point into the cursor renderer implementations HW cursor realization paths for all cursor sprite types. This is in preparation for realizing at more strategic times. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 12:34:02 +00:00
}
#ifdef HAVE_WAYLAND
else if (META_IS_CURSOR_SPRITE_WAYLAND (cursor_sprite))
{
MetaCursorSpriteWayland *sprite_wayland =
META_CURSOR_SPRITE_WAYLAND (cursor_sprite);
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
realize_cursor_sprite_from_wl_buffer_for_gpu (renderer,
gpu_kms,
sprite_wayland);
cursor-renderer: Centralize hw cursor realization paths Use a common entry point into the cursor renderer implementations HW cursor realization paths for all cursor sprite types. This is in preparation for realizing at more strategic times. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 12:34:02 +00:00
}
#endif
}
cursor-render/native: Realize hw cursor lazilly Where to realize a hardware cursor depends on where on the screen it will be displayed. For example it only needs buffers for the cursor plane on a certain GPU if it overlaps with a monitor that is connected said GPU. Previously, we were too eager with uploading the cursor plane buffers, which in effect resulted in the secondary GPU always being woken up when changing the cursor, even though the cursor plane would actually never be set unless the pointer cursor was moved to a monitor connected to the secondary GPU. These wake-ups caused noticable stuttering; thus by uploading the buffers more lazilly, the stuttering is avoided. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 18:32:43 +00:00
static void
realize_cursor_sprite (MetaCursorRenderer *renderer,
MetaCursorSprite *cursor_sprite,
GList *gpus)
{
GList *l;
for (l = gpus; l; l = l->next)
{
MetaGpuKms *gpu_kms = l->data;
realize_cursor_sprite_for_gpu (renderer, gpu_kms, cursor_sprite);
}
}
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
static void
meta_cursor_renderer_native_class_init (MetaCursorRendererNativeClass *klass)
{
MetaCursorRendererClass *renderer_class = META_CURSOR_RENDERER_CLASS (klass);
GObjectClass *object_class = G_OBJECT_CLASS (klass);
object_class->finalize = meta_cursor_renderer_native_finalize;
renderer_class->update_cursor = meta_cursor_renderer_native_update_cursor;
MetaCursorSprite: Put renderer specific code in the renderer There were lots of code handling the native renderer specific cases; move these parts to the renderer. Note that this causes the X11 case to always generate the texture which is a waste of memory, but his regression will be fixed in a following commit. The lazy loading of the texture was removed because it was eventually always loaded anyway indirectly by the renderer to calculate the current rect. https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-03-11 03:16:58 +00:00
quark_cursor_sprite = g_quark_from_static_string ("-meta-cursor-native");
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
quark_cursor_renderer_native_gpu_data =
g_quark_from_static_string ("-meta-cursor-renderer-native-gpu-data");
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
}
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
static void
force_update_hw_cursor (MetaCursorRendererNative *native)
{
MetaCursorRenderer *renderer = META_CURSOR_RENDERER (native);
MetaCursorRendererNative: Always force set hw cursor the first time The initial state of the hardware cursor is not known, so always force update it the first time we update the cursor. Do this by changing the 'force' flag of update_hw_cursor() to an 'invalidated' hw cursor state. https://bugzilla.gnome.org/show_bug.cgi?id=771056
2017-01-10 08:01:46 +00:00
MetaCursorRendererNativePrivate *priv =
meta_cursor_renderer_native_get_instance_private (native);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
MetaCursorRendererNative: Always force set hw cursor the first time The initial state of the hardware cursor is not known, so always force update it the first time we update the cursor. Do this by changing the 'force' flag of update_hw_cursor() to an 'invalidated' hw cursor state. https://bugzilla.gnome.org/show_bug.cgi?id=771056
2017-01-10 08:01:46 +00:00
priv->hw_state_invalidated = TRUE;
cursor-renderer/native: Update hw state via generic update path When force-updating the HW state we might end up with a situation where the HW cursor is no longer usable. If this would happen, we'd before this commit not trigger the fallback paths using a GL texture. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-09 16:50:37 +00:00
meta_cursor_renderer_force_update (renderer);
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
}
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
static void
on_monitors_changed (MetaMonitorManager *monitors,
MetaCursorRendererNative *native)
{
Support scaling of cursor sprites given what output they are on This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
2015-07-17 15:16:39 +00:00
force_update_hw_cursor (native);
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
}
static void
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
init_hw_cursor_support (MetaCursorRendererNative *cursor_renderer_native)
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
{
native/cursor-renderer: Cleanup construction Pass the backend to a new factory function, and keep a pointer to the monitor manager, which is accessed elsewhere in the same file instead of fetching the singleton. The HW cursor initialization part is also made more obvious, without depending on seemingly irrelevant clutter features. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-07 08:12:07 +00:00
MetaCursorRendererNativePrivate *priv =
meta_cursor_renderer_native_get_instance_private (cursor_renderer_native);
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
GList *gpus;
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
GList *l;
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
gpus = meta_monitor_manager_get_gpus (priv->monitor_manager);
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
for (l = gpus; l; l = l->next)
{
MetaGpuKms *gpu_kms = l->data;
MetaCursorRendererNativeGpuData *cursor_renderer_gpu_data;
int kms_fd;
struct gbm_device *gbm_device;
uint64_t width, height;
gbm_device = meta_gbm_device_from_gpu (gpu_kms);
if (!gbm_device)
continue;
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
cursor_renderer_gpu_data =
meta_create_cursor_renderer_native_gpu_data (gpu_kms);
MetaCursorRendererNative: Always force set hw cursor the first time The initial state of the hardware cursor is not known, so always force update it the first time we update the cursor. Do this by changing the 'force' flag of update_hw_cursor() to an 'invalidated' hw cursor state. https://bugzilla.gnome.org/show_bug.cgi?id=771056
2017-01-10 08:01:46 +00:00
cursor-renderer-native: Support HW cursors on multiple GPUs On hybrid GPU systems, hardware cursors needs to be realized on all the GPUs, as scanout cursor planes cannot be shared. Do this by moving gbm buffer and drm buffer ID management to a per GPU struct, realizing a cursor on each GPU when previously only realized on the primary GPU. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-25 02:31:25 +00:00
kms_fd = meta_gpu_kms_get_fd (gpu_kms);
if (drmGetCap (kms_fd, DRM_CAP_CURSOR_WIDTH, &width) == 0 &&
drmGetCap (kms_fd, DRM_CAP_CURSOR_HEIGHT, &height) == 0)
{
cursor_renderer_gpu_data->cursor_width = width;
cursor_renderer_gpu_data->cursor_height = height;
}
else
{
cursor_renderer_gpu_data->cursor_width = 64;
cursor_renderer_gpu_data->cursor_height = 64;
}
native/cursor-renderer: Cleanup construction Pass the backend to a new factory function, and keep a pointer to the monitor manager, which is accessed elsewhere in the same file instead of fetching the singleton. The HW cursor initialization part is also made more obvious, without depending on seemingly irrelevant clutter features. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-07 08:12:07 +00:00
}
}
MetaCursorRendererNative *
meta_cursor_renderer_native_new (MetaBackend *backend)
{
MetaMonitorManager *monitor_manager =
meta_backend_get_monitor_manager (backend);
MetaCursorRendererNative *cursor_renderer_native;
MetaCursorRendererNativePrivate *priv;
cursor_renderer_native =
g_object_new (META_TYPE_CURSOR_RENDERER_NATIVE, NULL);
priv =
meta_cursor_renderer_native_get_instance_private (cursor_renderer_native);
backends: add 'monitors-updated-internal' signal to only update internal state Adding an internal signal and use it to update the internal state before emitting "monitors-changed" which will be repeated by the screen to the world. https://bugzilla.gnome.org/show_bug.cgi?id=788860
2017-10-13 00:14:40 +00:00
g_signal_connect_object (monitor_manager, "monitors-changed-internal",
native/cursor-renderer: Cleanup construction Pass the backend to a new factory function, and keep a pointer to the monitor manager, which is accessed elsewhere in the same file instead of fetching the singleton. The HW cursor initialization part is also made more obvious, without depending on seemingly irrelevant clutter features. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-07 08:12:07 +00:00
G_CALLBACK (on_monitors_changed),
cursor_renderer_native, 0);
priv->monitor_manager = monitor_manager;
priv->hw_state_invalidated = TRUE;
backends: Split out CRTC/output management to MetaGpu In order to eventually support multilpe GPUs with their own connectors, split out related meta data management (i.e. outputs, CRTCs and CRTC modes) into a new MetaGpu GObject. The Xrandr backend always assumes there is always only a single "GPU" as the GPU is abstracted by the X server; only the native backend (aside from the test backend) will eventually see more than one GPU. The Xrandr backend still moves some management to MetaGpuXrandr, in order to behave more similarly to the KMS counterparts. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-10 10:19:32 +00:00
init_hw_cursor_support (cursor_renderer_native);
native/cursor-renderer: Cleanup construction Pass the backend to a new factory function, and keep a pointer to the monitor manager, which is accessed elsewhere in the same file instead of fetching the singleton. The HW cursor initialization part is also made more obvious, without depending on seemingly irrelevant clutter features. https://bugzilla.gnome.org/show_bug.cgi?id=785381
2017-07-07 08:12:07 +00:00
return cursor_renderer_native;
}
static void
meta_cursor_renderer_native_init (MetaCursorRendererNative *native)
{
backends: Add a native cursor renderer
2014-04-22 19:15:11 +00:00
}
Copy permalink