There was a race in setting next_fb_id when a secondary GPU was using
the CPU copy path. Losing this race caused the attempt to
drmModePageFlip () to FB ID 0 which is invalid and always fails. Failing
to flip causes Mutter to fall back to drmModeSetCrtc () permanently.
In meta_onscreen_native_swap_buffers_with_damage ():
- update_secondary_gpu_state_pre_swap_buffers ()
- copy_shared_framebuffer_cpu () but only on the CPU copy path
- secondary_gpu_state->gbm.next_fb_id is set
- wait_for_pending_flips ()
- Waits for any remaining page flip events and executes and destroys
the related page flip closures.
- on_crtc_flipped ()
- meta_onscreen_native_swap_drm_fb ()
- swap_secondary_drm_fb ()
- secondary_gpu_state->gbm.next_fb_id = 0;
- meta_onscreen_native_flip_crtcs ()
- meta_onscreen_native_flip_crtc ()
- meta_gpu_kms_flip_crtc () gets called with fb_id = 0
This race was observed lost when running 'mutter --wayland' on a machine
with two outputs on Intel and one output on DisplayLink USB dock, and
wiggling around a weston-terminal window between the Intel and
DisplayLink outputs. It took from a second to a minute to trigger. For
testing with DisplayLink outputs Mutter also needed a patch to take the
DisplayLink output into use, as it would have otherwise been ignored
being a platform device rather than a PCI device.
Fix this race by first waiting for pending flips and only then
proceeding with the swap operations. This should be safe, because the
pending flips could have completed already before entering
meta_onscreen_native_swap_buffers_with_damage ().
meta_renderer_native_gles3_read_pixels() was assuming that the target
buffer stride == width * 4. This is not generally true. When a DRM
driver allocates a dumb buffer, it is free to choose a stride so that
the buffer can actually work on the hardware.
Record the driver chosen stride in MetaDumbBuffer, and use it in the CPU
copy path. This should fix any possible stride issues in
meta_renderer_native_gles3_read_pixels().
Track the allocated dumb buffer size in MetaDumbBuffer. Assert that the
size is as expected in copy_shared_framebuffer_cpu().
This is just to ensure that Cogl and the real size match. The size from
Cogl was used in the copy, so getting that wrong might have written
beyond the allocation.
This is a safety measure and has not been observed to happen yet.
If drmModeAddFB2() does not work, the fallback to drmModeAddFB() can
only handle a single specific format. Make sure the requested format is
that one format, and fail the operation otherwise.
This should at least makes the failure mode obvious on such old systems
where the kernel does not support AddFB2, rather than producing wrong
colors.
Previously, trackballs were detected based on the presence of the
substring "trackball" in the device name. This had the downside of
missing devices, such as the Kensington Expert Mouse, which don't have
"trackball" in their names.
Rather than depending on the device name, use the ID_INPUT_TRACKBALL
property from udev to determine whether or not to treat a device as a
trackball.
This adds a new function, `is_trackball_device`, to MetaInputEvents, and
eliminates the `meta_input_device_is_trackball` function.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/258
The "backends: Move MetaOutput::crtc field into private struct"
accidentally changed the view transform calculation code to assume that
"MetaCrtc::transform" corresponds to the transform of the CRTC; so is
not the case yet; one must calculate the transform from the logical
monitor, and check whether it is supported by the CRTC using
meta_monitor_manager_is_transform_handled(). This commit restores the
old behaviour that doesn't use MetaCrtc::transform when calculating the
view transform.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/216
We need a way for mutter to exit if no available GPUs are going to work.
For example if gdm starts gnome-shell and we're using a DRM driver that
doesn't work with KMS then we should exit so that GDM can try with Xorg,
rather than operating in headless mode.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/223
Commit c0d9b08ef9 replaced the old GBM API calls
with the multi-plane GBM API. However, the call to gbm_bo_get_handle_for_plane
fails for some DRI drivers (in particular i915). Due to missing error checks,
the subsequent call to drmModeAddFB[2] fails and the screen output locks up.
This commit adds the missing error checks and falls back to the old GBM API
(non-planar) if necessary.
v5: test success of gbm_bo_get_handle_for_plane instead of errno
This commit adopts solution proposed by Daniel van Vugt to check the return
value of gbm_bo_get_handle_for_plane on plane 0 and fall back to old
non-planar method if the call fails. This removes the errno check (for
ENOSYS) that could abort if mesa ever sets a different value.
Related to: https://gitlab.gnome.org/GNOME/mutter/issues/127
The function is intentionally provided as macro to not require a
cast. Recently the macro was improved to check that the passed in
pointer matches the free function, so the cast to GDestroyNotify
is now even harmful.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
If drmModeSetCrtc() is called with no fb, mode or connectors for some
CRTC it may still fail, and we should handle that gracefully instead of
assuming it failed to set a non-disabled state.
Closes https://gitlab.gnome.org/GNOME/mutter/issues/70
Commit 712ec30cd9 added the logic to only
choose EGL configs that match the GBM_FORMAT_XRGB8888 pixel format.
However, there won't be any EGL config satisfying such criteria for
non-GBM backends, such as EGLDevice.
This change will let us choose the first EGL config for the EGLDevice
backend, while still forcing GBM_FORMAT_XRGB8888 configs for the GBM
one.
Related to: https://gitlab.gnome.org/GNOME/mutter/issues/2
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
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
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
It is already handled by the monitor-updated-internal signal handler in
meta-cursor-renderer-native.c, which will always be called indirectly
by resuming the monitor manager.
While at it, remove a useless comment.
https://gitlab.gnome.org/GNOME/mutter/issues/77
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
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
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
drmModeAddFB2 allows userspace to specify a real format enum on
non-ancient kernels, as an improvement over the legacy drmModeAddFB
which derives format from a fixed depth/bpp mapping.
As an optimisation, Weston used to decide at the first failure of
drmModeAddFB2 that the ioctl was unavailable: as non-existent DRM
ioctls return -EINVAL rather than -ENOSYS or similar, bad parameters are
not distinguishable from the ioctl not being present.
Mutter has also implemented the same optimisation for dumb framebuffers,
which potentially papers over errors for the gain of avoiding one ioctl
which will rapidly fail on ancient kernels. Remove the optimisation and
always use AddFB2 where possible.
Closes: #14
When using the EGLStream backend, the MetaRendererNative passed a
GClosure to KMS when using EGLStreams, but KMS flip callback event
handler in meta-gpu-kms.c expected a closure wrapped in a closure
container, meaning it'd instead crash when using EGLStreams. Make the
flip handler get what it expects also when using EGLStreams by wrapping
the flip closure in the container before handing it over to EGL.
https://bugzilla.gnome.org/show_bug.cgi?id=790316
While MetaStage, MetaWindowGroup and MetaDBusDisplayConfigSkeleton don't
appear explicitly in the public API, their gtypes are still exposed via
meta_get_stage_for_screen(), meta_get_*window_group_for_screen() and
MetaMonitorManager's parent type. Newer versions of gjs will warn about
undefined properties if it encounters a gtype without introspection
information, so expose those types to shut up the warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
Before we just set it to "none", but this was not enough since various
calls will depend on not just the context being active, but the main
rendering surface.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/21
This is a small mistake spotted while working on a solution
for #77. When a GPU fails to initialize, we're adding them
anyway, which might have pretty bad consequences when trying
to use these NULL GPUs.
Issue: #77
Make it re-enable:able by a hidden "experimental feature". To enable, add
"kms-modifiers" to the org.gnome.mutter.experimental-features GSettings entry.
And use the old "native" backend for both X11 and Wayland. This will
allow us to share fixes between implementations without having to delve
into the XSync X11 extension code.
https://bugzilla.gnome.org/show_bug.cgi?id=705942
If we attempt GBM surface allocation with a set of modifiers but the
allocation fails, fall back to non-modifier allocations. This fixes
startup on Pineview-based Atom systems, where KMS provides us a set of
modifiers but the GBM implementation doesn't support modifier use.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/84
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
Rendering the next frame (which mostly happens as part of the flush done
in swap buffers) is a task that the GPU can complete independently of
the CPU having to wait for previous page flips. So reverse their order
to get the GPU started earlier, with the aim of greater GPU-CPU
parallelism.
We just arbitrarily chose the first EGL config matching the passed
attributes, but we then assumed we always got GBM_FORMAT_XRGB8888. That
was not a correct assumption. Instead, make sure we always pick the
format we expect.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/2
When the buffer modifier is DRM_FORMAT_MOD_LINEAR, we can use the
old code path. That means not specifying any modifier parameter.
It was an issue when the primary GPU was creating a linear GBM surface
and that a secondary GPU (not supporting modifiers) was trying to
import it. It was failing because the driver could not use the
import_modifiers extension even though it could in theory easily
import the buffer.
https://gitlab.gnome.org/GNOME/mutter/issues/18
We were retrieving the supported KMS modifiers for all GPUs even
though what we really need to intersect between these sets of
modifiers:
1) KMS supported modifiers for primary GPU if the GPU is used for
scanout;
2) EGL supported modifiers for secondary GPUs (different than the
primary GPU used for rendering);
3) GBM supported modifiers when creating the surface (already
taken care of by gbm_surface_create_with_modifiers());
https://gitlab.gnome.org/GNOME/mutter/issues/18
There seems to be a kernel race when one disconnects an external
monitor connected to a DisplayPort via a USB-C adapter. The race
results in a connector being reported as connected, but without any
modes supported.
This had the side effect that we tried to set a preferred mode to
the first listed mode, but as no modes were available, we instead tried
to dereference the first element of a NULL array, causing a
segmentation fault.
Mitigate this by skipping adding output if no supported modes are
advertised and the output doesn't support scaling, while moving the
fallback path for calculating a preferred output mode to after possibly
adding the common modes, to avoid the unvolentary NULL dereference.
https://bugzilla.gnome.org/show_bug.cgi?id=789501
The tertiary-button-action (see bug 790028) is a place for g-c-c to store
the action which should be performed when a stylus' third button is pressed.
Pressing this button is signaled as a BTN_STYLUS3 event from the kernel or
X11 button 8.
https://bugzilla.gnome.org/show_bug.cgi?id=790033
Now that we have the list of supported modifiers from the monitor
manager (via the CRTCs to the primary planes), we can use this to inform
EGL it can use those modifiers to allocate the GBM surface with. Doing
so allows us to use tiling and compression for our scanout surfaces.
This requires the Mesa commit in:
Mesa 10.3 (08264e5dad4df448e7718e782ad9077902089a07) or
Mesa 10.2.7 (55d28925e6109a4afd61f109e845a8a51bd17652).
Otherwise Mesa closes the fd behind our back and re-importing will fail.
See FDO bug #76188 for details.
https://bugzilla.gnome.org/show_bug.cgi?id=785779
Newer versions of GBM support buffer modifiers, including multi-plane
buffers. Use this new API to explicitly pull the information from GBM,
and feed it to drmModeAddFB2WithModifiers.
https://bugzilla.gnome.org/show_bug.cgi?id=785779
The KMS IN_FORMATS blob property contains a structure defining which
format/modifier combinations are supported for each plane. Use this to
extract a list of acceptable modifiers to use for the primary plane for
XRGB8888, so we can ask EGL to allocate tiled/compressed buffers for
scanout when available.
https://bugzilla.gnome.org/show_bug.cgi?id=785779
Just like we swap the x and y resolution of the monitor modes when
the panel-orientation requires 90 or 270 degree rotation to compensate,
we should do the same for the width and height in mm of the monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=782294
If a monitor's max resolution is a portrait resolution, then assume it is
a native portrait monitor and add portrait versions of the common modes.
https://bugzilla.gnome.org/show_bug.cgi?id=782294
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
Some x86 clamshell design devices use portrait tablet LCD panels while
they should use a landscape panel, resoluting in a 90 degree rotated
picture.
Newer kernels detect this and rotate the fb console in software to
compensate. These kernels also export their knowledge of the LCD panel
orientation vs the casing in a "panel orientation" drm_connector property.
This commit adds support to mutter for reading the "panel orientation"
and transparently (from a mutter consumer's pov) fixing this by applying
a (hidden) rotation transform to compensate for the panel orientation.
Related: https://bugs.freedesktop.org/show_bug.cgi?id=94894https://bugzilla.gnome.org/show_bug.cgi?id=782294
Proprietary drivers such as ARM Mali export EGL_KHR_platform_gbm instead
of EGL_MESA_platform_gbm. As such, GBM platform check should be done for
both MESA and non-MESA drivers.
https://bugzilla.gnome.org/show_bug.cgi?id=780668
The DRM properties container must be destroyed with
drmModeFreeObjectProperties, and the connectors must be freed on every
caller. Also make it sure that gbm_device structs are destroyed with the
MetaRendererNativeGpuData that owns them.
https://bugzilla.gnome.org/show_bug.cgi?id=789984
On some architectures, including both GLES3/gl3.h GL/gl.h will cause
compilation issues due to incompatible type definitions. To avoid
running into that issue while building on other architectures, make
sure we haven't included GL/gl.h by accident.
https://bugzilla.gnome.org/show_bug.cgi?id=788695
The org.gnome.desktop.peripherals.trackball.scroll-wheel-emulation-button
setting contains buttons X11-style. Work out the BTN evcode that applies
to it when applying the setting on the libinput device.
https://bugzilla.gnome.org/show_bug.cgi?id=787804
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
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
A hybrid GPU system is a system where more than one GPU is connected to
connectors. A common configuration is having a integrated GPU (iGPU)
connected to a laptop panel, and a dedicated GPU (dGPU) connected to
one or more external connector (such as HDMI).
This commit adds support for rendering the compositor stage using the
iGPU, then copying the framebuffer content onto a secondary framebuffer
that will be page flipped on the CRTC of the dGPU.
This can work in two different ways: GPU accelerated using Open GL ES
3, or CPU unaccelerated.
When supported, GPU accelerated copying works by exporting the iGPU
onscreen framebuffer as a DMA-BUF, importing it as a texture on a
separate dGPU EGL context, then using glBlitFramebuffer(), blitting it
onto a framebuffer on the dGPU that can then be page flipped on the dGPU
CRTC.
When GPU acceleration is not available, copying works by creating two
dumb buffers, and each frame glReadPixels() from the iGPU EGL render
context directly into the dumb buffer. The dumb buffer is then page
flipped on the dGPU CRTC.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
First find the primary GPU and open it. Then go through all other
discovered GPUs with connectors and add those too. MetaRendererNative
still fails to initialize when multiple added GPUs and
MetaCursorRendererNative still always falls back on OpenGL based cursor
rendering when there are multiple GPUs.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
When creating a renderer with a custom winsys (which is always how
mutter uses cogl) make it possible to pass a user data with the winsys.
Still unused.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Make dumb buffer creation/destruction reusable by introducing a
MetaDumbBuffer type (private to meta-renderer-native.c). This will
later be used for software based fallback paths for copying render GPU
buffers onto secondary GPUs.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
On a CRTC that doesn't report any transforms at all, setting the normal
transform will fail. Avoid failing by checking if any transforms are
supported before applying it, and early out if no transforms are
supported.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Get rid of some technical dept by removing the support in the native
backend for drawing the the whole stage to one large framebuffer.
Previously the only way to disable stage views was to set the
MUTTER_STAGE_VIEWS environment variable to 0; doing that now will cause
the native backend to fail to initialize.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
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
When drmHandleEvent() returns an error and errno is set to EAGAIN,
instead of ending up in a busy loop, poll() the fd until there is
anything to read.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
The prefix, if any, of a variable name often contains information about
the namespace (such as clutter_backend is the ClutterBackend, while
backend is a MetaBackend). Clean up some more inconsistencies in
meta-renderer-native.c where various variable names were egl_ prefixed
but in fact was Cogl types.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
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
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
Move finding, opening and managment of the KMS file descriptor to
MetaMonitorManagerKms. This means that the monitor manager creation can
now fail, both if more than one GPU with connectors is discovered, or
if finding or opening the primary GPU fails.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
The monitor manager instance was created and setup in one step; at
construction. This is problematic if, in the future, the monitor manager
creation can fail, as the monitor manager is created quite late.
To make it possible to in the future fail creating a monitor manager,
create the instance very early when initiating the backend, then on
post init backend setup, "setup" the monitor manager state, i.e. read
the current state and setup the stage.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
The error was printed, then dropped, eventually resulting in another
generic error being printed. Lets just propogate the error all the way
up instead.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Move code dealing with MetaCrtcKms and related functionality to its
own file. Eventually, MetaCrtcKms should become a GObject based on
MetaCrtc, and this commit is in preparation for that.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Instead of passing it around or fetching the singleton, keep a pointer
to the monitor manager that owns the CRTC. This will eventually be
replaced with a per GPU/graphics card object.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Move code dealing with MetaOutputKms and related functionality to its
own file. Eventually, MetaOutputKms should become a GObject based on
MetaOutput, and this commit is in preparation for that.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Instead of passing it around or fetching the singleton, keep a pointer
to the monitor manager that owns the output. This will eventually be
replaced with a per GPU/graphics card object.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Convert MetaCrtcMode from a plain struct to a GObject. This changes the
storage format, and also the API, as the API was dependent on the
storage format.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Turn MetaCrtc into a GObject and move it to a separate file. This
changes the storage format, resulting in changing the API for accessing
MetaCrtcs from using an array, to using a GList.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
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
The reverted commit seems to cause
https://bugzilla.gnome.org/show_bug.cgi?id=787240 for some reason. Lets
be safe and revert it for now, as the code freeze is just around the
corner.
This partly (it doesn't reintroduce a whitespace issue) reverts commit
dbc63430d8.
When headless, we don't have any logical monitors to derive a screen
size from, but we can't set it to empty as that will cause issues with
the clutter stage, UI widget layout and other things. To avoid such
issues, just fall back to a 640 x 480 screen size when headless.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
Due to rounding issues, we can't assume a floating point calculation
will end up on an integer, even if we got the factor from the reverse
calculation. Thus, to avoid casting away values like N.999... to N,
when they should really be N+1, round the resulting floating point
calculation before casting it to int.
This fixes an issue where using the scale ~1.739 on a 1920x1080 mode
resulted in error when setting the mode, as the calculated size of the
framebuffer was only 1919x1080.
https://bugzilla.gnome.org/show_bug.cgi?id=786918
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
Add API to get the layout group (layout index) currently active. In the
native backend this is done by fetching the state directly from the
evdev backend; on X11 this works by listening for XkbStateNotify
events, caching the layout group value.
https://bugzilla.gnome.org/show_bug.cgi?id=786408
The zero-initialized winsys id was incorrectly used as the key to find
the old output to base active/primary state from, which would never
succeed unless the winsys id happened to be 0. Fix this by using the
winsys id that will be used, i.e. the connector id.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The problem is that libinput offers the possibility to not enabled
dragging when tap-to-click is enabled but mutter doesn't. For people who
have a sensitive touchpad and who like tap-to-click option, dragging is
launched even when you don't want it : for example, when you select a
folder, most of the time the folder is dragging whereas just selected or
when you want to select some lines of a text file, several lines are
moved as a cut-paste which is not expected and erase datas.
To fix it, you need to have the possibility to desactivate the drag
option when you use tap-to-click in mutter. Because it's already a
specification of libinput, it remains to add it to mutter.
Implementation with X11 is added too.
https://bugzilla.gnome.org/show_bug.cgi?id=775755
When suspending (i.e. VT switching away, the GDM gnome-shell instance
gets hidden, or changing user), destroy the onscreen and offscreen
monitor framebuffers. When resuming, the stage views and framebuffers
will be recreated anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=786299
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
We manually scaled pointer motions when they travel over a scaled
monitor. When a stage view of a monitor is also scaled, in practice this
meant we scaled twice. Avoid this by only manually scaling the pointer
motion when stage views are not scaled.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
This changes the API to pass supported scales per mode instead of
providing a global list. This allows for more flexible scaling
scenarious, where a scale compatible with one mode can still be made
available even though another mode is incompatible.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
When the logical layout mode is used, allow configuring the scaling to
be non-integer. Supported scales are so far hard coded to include at
most 1, 1.5 and 2, and scales that doesn't result in non-fractional
logical monitor sizes are discarded.
Wayland outputs are set to have scale ceil(actual_scale) meaning well
behaving Wayland clients will provide buffers with buffer scale 2, thus
being scaled down to the fractional scale.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
To support fractional scaling, change the stage view scale to be a
float instead of an int. Also change the places where it is retrieved
and used when scaling things.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
The caller in clutter really expects an error if fd==-1, so make
sure we set one here. Otherwise we get a nice crash in addition to
the failure to open the /sys file. Also, retry on EINTR.
https://bugzilla.gnome.org/show_bug.cgi?id=784881
With GLVND, whenever we have both Mesa's and NVIDIA's drives installed
in the system, initializing the GBM backend will always succeed,
regardless of what GPU you have on your system.
This is due to GBM's software rendering fallback.
It seems better to initialize the EGLDevice backend first, which will
fail to find a device match when given a non-NVIDIA GPU.
https://bugzilla.gnome.org/show_bug.cgi?id=784272
It is possible to interpret the ammount of padding provided to the
*_set_tablet_area functions in two different and incompatible ways. The X11
backend effectively treats them as being input-centric (i.e., the padding
defines the size of the "dead zone" on the tablet) while the native backend
has an output-centric viewpoint (i.e., the padding defines the size of the
"dead zone" on the display) viewpoint. This difference in opinion causes the
cursor offset to change when switching between Xorg and a Wayland sessions.
The calibration utility within g-c-c does its calculations with an input-
centric viewpoint, so this patch modifies the native backend to work
correctly with these values. To change viewpoints, we can simply invert
the scale and negate the offset. It should be noted that this function
also forgot to apply scaling to the offsets (as required by the matrix
transform done by libinput) which would have further compounded the
cursor offset issue under Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=784009
This commit makes it possible to configure logical monitor scale also
when running on top of an X11 server using Xrandr. An extra property
'requires-globla-scale' is added to the D-Bus API is added to instruct
a configuration application to only allow setting a global logical
monitor scale.
This is needed to let gsd-xsettings use the configured state to set a
XSettings state that respects the explicit monitor configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The scale calculation doesn't really have anything to do with KMS, and
eventually we'll want to have mutter calculate the monitor scale for
non-KMS backends too, so move the scale calculation to MetaMonitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Introduce MetaSettings and add the settings managed by MetaBackend into
the new object. These settings include: experimental-features and UI
scaling factor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Disable-while-typing disables the touchpad while the user is typing.
This patch introduces the necessary backend code to implement the
org.gnome.desktop.peripherals.touchpad.disable-while-typing setting of
gsettings-desktop-schemas which was implemented in commit
4c5b1c1df399d6afaaccb237e299ccd1d5d29ddd and released as part of 3.24.
This is known as dwt in libinput.
This patch has been tested on X11 and Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=764852
Let the backend implementations create their own input settings
backend, as is done with other backend specific special purpose
backends. Also use the macro for declaring the GType.
https://bugzilla.gnome.org/show_bug.cgi?id=782152
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
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
Keep track of the logical monitor transform. When a logical monitor is
transformed, all of its monitors are also transformed in the same way.
A logical monitor can either be transformed on the CRTC level, or using
an offscreen intermediate buffer. In both cases will the logical
monitor be transformed, but only in the latter will the view be
transformed.
MetaCrtcs::transform currently does not represent whether the CRTC is
configured to be transformed or not; only when the backend can handle
it does it correctly correspond to the actual CRTC configuration. This
is intended to change with MetaMonitorConfigManager.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Instead of using a environment variable, add a new 'experimental
feature' gsetting keyword "monitor-config-manager" that enables the use
of the new MetaMonitorConfigManager. This commit also makes it possible
to switch between the two systems without restarting mutter.
The D-Bus API is disabled when the experimental feature is not enabled,
and clients trying to access it will get a access-denied error in
response. A new property 'IsExperimentalApiEnabled' is added to let the
D-Bus client know whether it is possible to use the experimental API or
not.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
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
Make the concept of maximum screen size optional, as it is not
necessarily a thing on all systems (e.g. when using the native backend
and stage views).
The meta_monitor_monitor_get_limits() function is replaced by a
meta_monitor_manager_get_max_screen_size() which fails when no screen
limit is available. Callers and other users of the previous max screen
size fields are updated to deal with the fact that the limit is
optional.
The new D-Bus API is changed to move it to the properties bag, where
its absence means there is no applicable limit.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a new D-Bus API that uses the state from GetCurrentState to
configure high level monitors, instead of low level CRTCs and
connectors. So far persistent configuration is not implemented, as
writing to the configuration store is still not supported.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Let the backends decide whether to just rebuild a derived state, or use
the NULL config to rebuild an empty logical state.
This also changes the expected screen size values of the no-outputs
test; as this case is actually handled now.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Replace the 'scale' of an output with a vfunc on the MetaMonitorManager
class that takes a monitor and a monitor mode which calculates the
scale. On X11 this always returns 1, on KMS, the old formula is used.
On the dummy and test backends, the already configured values are
returned.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
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
Quick motions can come across as too fast (or slow) if it crosses outputs
with different scales. If this happens, rebuild the motion delta applying
the scale that applies to each logical monitor the pointer is crossing.
https://bugzilla.gnome.org/show_bug.cgi?id=778119
To allow for more natural pointer movements from relative pointer
devices (e.g. mouse, touchpad, tablet tool in relative mode, etc), scale
the relative motion from libinput with the scale of the monitor. In
effect, this means that the pointer movement is twice as fast (physical
movement vs numbers of pixels passed) as before, but it also means that
the same physical movement crosses the distance in a GUI no matter if
it is on a HiDPI monitor or not.
https://bugzilla.gnome.org/show_bug.cgi?id=778119
The code calculating the output scale involves calculations around pixel
and mm sizes, however we do compare post-transformation pixel sizes to
untransformed mm sizes, which breaks the DPI calculations. Fix this by
transforming back pixel sizes back to untransformed.
While we're at it, actually compare the output height to HIDPI_MIN_HEIGHT
instead of its width, it seems right according to the #define name and
comment.
https://bugzilla.gnome.org/show_bug.cgi?id=777687
The mitigation to avoid missing EDID blob was incorrect; the reason it
sometimes failed to read was a race between different applications all
trying to read the EDID at the same time. E.g. gnome-shell as GDM would
at the same time as the session gnome-shell try to read the EDID of the
same connector at the same time, triggering a race in the kernel,
making the blob reading ioctl occationally fail with ENOENT.
Remove this mitigation, as it didn't really mitigate anything; the race
could just as well happen when doing the actual read later.
https://bugzilla.gnome.org/show_bug.cgi?id=779837
When mutter is paused (i.e. not the DRM master), stop listening on
hotplug events. Instead read the current state and set modes when
resumed.
This avoids a race condition in the drm API which currently only
manages to properly deal with one application querying the EDID state
at the same time when there are multiple mutter instances running at
the same time (e.g. gnome-shell driving gdm at the same time as
gnome-shell as the session instance).
https://bugzilla.gnome.org/show_bug.cgi?id=779837
A MetaOutput is a connector, not exactly a monitor or a region on the
stage; for example tiled monitors are split up into multiple outputs,
and for what is used in input settings, that makes no sense. Change
this to use logical monitors instead of outputs.
https://bugzilla.gnome.org/show_bug.cgi?id=779745
When no output was specified, the screen limit was used to calculate the
aspect ratio. The screen limit, however, is either just an arbitrary
number if no screen limit is applicable, or a hardware graphics buffer
limit, which has nothing to do with anything actually displayed. Change
it to use the screen size instead, to get something that makes more
sense when no output is found.
https://bugzilla.gnome.org/show_bug.cgi?id=779745
Expose via a new API whether the transform on a logical monitor is
handled by the backend. This was previously only exposed only in the
native backend. This will be used to emulate not supporting transforms
in the backend in the nested backend.
https://bugzilla.gnome.org/show_bug.cgi?id=779745
Whenever an EGLOutput consumer is temporary unable to handle
eglStreamConsumerAcquire() operations (e.g. during a VT-switch),
an EGL_RESOURCE_BUSY_EXT error is generated.
This change adds the appropriate error handling to flip_egl_stream() in
order to recover from such errors.
https://bugzilla.gnome.org/show_bug.cgi?id=779112
Using ClutterInputDeviceEvdev::output-aspect-ratio. This only applies
to devices which are not calibratable, so again we need to implement
this at the toolkit level.
https://bugzilla.gnome.org/show_bug.cgi?id=774115
We couldn't properly merge output-mapping matrix and calibration into
one. Now that libinput calibration matrix is free to use, we can
actually implement tablet calibration with it.
https://bugzilla.gnome.org/show_bug.cgi?id=774115
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
Clutter assumed seat0 which is most usually, but not always correct.
Add an evdev-backend specific function to allow passing the seat
that will be used for ClutterDeviceManager construction, which we
already obtain in MetaLauncher.
https://bugzilla.gnome.org/show_bug.cgi?id=778092
Handle headless setup gracefully by having no logical monitors. This
commit only makes the monitor management code deal with it; other areas
may still not be able to handle it.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The new monitor configuration system (MetaMonitorConfigManager) aims to
replace the current MetaMonitorConfig. The main difference between the
two is that MetaMonitorConfigManager works with higher level input
(MetaMonitor, MetaMonitorMode) instead of directly looking at the CRTC
and connector state. It still produces CRTC and connector configuration
later applied by the respective backends.
Other difference the new system aims to introduce is that the
configuration system doesn't manipulate the monitor manager state; that
responsibility is left for the monitor manager to handle (it only
manages configuration and creates CRTC/connector assignments, it
doesn't apply anything).
The new configuration system allows backends to not rely on deriving the
current configuration from the CRTC/connector state, as this may no longer be
possible (i.e. when using KMS and multiple framebuffers).
The MetaMonitorConfigManager system is so far disabled by default, as
it does not yet have all the features of the old system, but eventually
it will replace MetaMonitorConfig which will at that point be removed.
This will make it possible to remove old hacks introduced due to
limitations in the old system.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Sometimes we hit a race on hot-plug where we try to read the KMS
resources and the EDID blob is not yet ready. This would normally
result in a ENOENT when retrieving the blob. Handle this by retrying
after 50 milliseconds after a hot-plug event. Do this up to 10 times,
and after that give up trying to get the EDID blob and continue with
best effort.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The function meta_monitor_manager_read_current_config() was renamed to
meta_monitor_manager_read_current_state() as it does not read any
configuration, but reads the current state as described by the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The MetaMonitorMode referred to the mode of a CRTC, and with the future
introduction of a MetaMonitor, theh old name would be confusing.
Instead call it what it is.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Instead of storing the logical monitors in an array and having users
either look up them in the array given an index or iterate using
indices, put it in a GList, and use GList iterators when iterating and
alternative API where array indices were previously used.
This allows for more liberty regarding the type of the logical monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Change meta_monitor_manager_get_logical_monitor_at() to use floats,
replace users of meta_monitor_manager_get_monitor_at_point() to use the
API that returns a logical monitor and remove the now unused function.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The method used for getting the current logical monitor (the monitor
where the pointer cursor is currently at) depends on the backend type,
so move that logic to the corresponding backends.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Let the backend initialize the cursor tracker, and change all call
sites to get the cursor tracker from the backend instead of from the
screen. It wasn't associated with the screen anyway, so the API was
missleading.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In preparation for further refactorizations, rename the MetaMonitorInfo
struct to MetaLogicalMonitor. Eventually, part of MetaLogicalMonitor
will be split into a MetaMonitor type.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
We need to do swap notifications asynchronously from flip events since
these might be processed during swap buffers if we are waiting for the
previous frame's flip to continue with the current.
This means that we might have more than one swap notification queued
to be delivered when the idle handler runs. In that case we must
deliver all notifications for which we've already seen a flip event.
Failing to do so means that if a new frame, that only swaps buffers on
such a swap notification backlogged Onscreen, is started, when later
we get its flip event, we'd notify only an old frame which would hit
this MetaStageNative's frame_cb() early exit:
if (global_frame_counter <= presented_frame_counter)
return;
and we'd never finish the new frame and thus clutter's master clock
would be waiting forever stuck.
https://bugzilla.gnome.org/show_bug.cgi?id=774557
When flush-swap-notify is already queued, we might end up trying to
requeue it, for example when handling flip callbacks inside
swap-buffers. Actually queuing it there is harmless, since old frames
will be discarded anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=774923
We might still end up in swap-buffer without the previous flip callback
having been invoked. This can happen if there are two monitors, and we
manage to draw before having all monitor flip callbacks invoked.
https://bugzilla.gnome.org/show_bug.cgi?id=774923
This commit adds for a new type of buffer being attached to a Wayland
surface: buffers from an EGLStream. These buffers behave very
differently from regular Wayland buffers; instead of each buffer
reperesenting an actual frame, the same buffer is attached over and
over again, and EGL API is used to switch the content of the OpenGL
texture associated with the buffer attached. It more or less
side-tracks the Wayland buffer handling.
It is implemented by creating a MetaWaylandEglStream object, dealing
with the EGLStream state. The lifetime of the MetaWaylandEglStream is
tied to the texture object (CoglTexture), which is referenced-counted
and owned by both the actors and the MetaWaylandBuffer.
When the buffer is reattached and committed, the EGLStream is triggered
to switch the content of the associated texture to the new content.
This means that one cannot keep old texture content around without
copying, so any feature relying on that will effectively be broken.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
This commit adds support for using a EGLDevice and EGLStreams for
rendering on top of KMS instead of gbm. It is disabled by default; to
enable it pass --enable-egl-device to configure.
By default gbm is first tried, and if it fails, the EGLDevice path is
tried. If both fails, mutter will terminate just as before.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
There is no way to pass any backend specific parameters to a
CoglFramebuffer until after it has been allocated by
cogl_framebuffer_allocate() (since this is where the winsys/platform
fields are initialized). This can make it hard to actually allocate
anything, if the platform depends on some backend specific data.
A proper solution would be to refactor the onscreens and framebuffers to
use a GObject based type system instead of the home baked Cogl one, but
that'll be left for another day. For now, allocate in two steps, one to
allocate the backend specific parts (MetaOnscreenNative), and one to
allocate the actual onscreen framebuffer (via
meta_onscreen_native_allocate()).
So far there is nothing that forces this separation, but in the future
there will, for example EGLDevice's need to know about the CRTC in
order to create the EGLSurface.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
A swap-buffers should never be issued when we are waiting for a flipped
callback, so instead of trying to handle a situation that sholud never
happen, warn instead.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
When a swap failed with EACCES (possibly due to VT switching), don't
mark the framebuffer as 'in use', so that it'll be cleaned up properly
and not set as current.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
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
Drivers may be bad at guessing what is passed to eglGetDisplay, ending
up return non-functioning EGLDisplay's. Using eglGetPlatformDisplay
avoids this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Lets use a pbuffer surface as a dummy surface instead of a gbm based
one, so that we don't need to rely on the availability of gbm to create
a dummy surface when there is no need for it.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Separate gbm initialization from general renderer initialization. Do
this even though no other initialization is done for now; later there
will will be other types of rendering mode, initialized in their own
functions.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
In another step getting rid of the duplications introduced by Cogl,
use the equivalent GLib types where Cogl types previously used. While
CoglBool is not a typedef to gboolean, they are both typedefs to int,
and we already use GLib's TRUE/FALSE to set them.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Initialize the GError pointer used when creating the renderer. If an
error occurs, the error is expected to be NULL, otherwise it'll
misinterpreted as already set.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
Stylus configuration (stylus buttons, pressure) was handled
at the very high level, doing the button and pressure translations
right before sending these to wayland clients.
However, it makes more sense to store these settings into the
ClutterInputDeviceTool itself, and have clutter apply the config
at the lower level so 1) the settings actually apply desktop-wide,
not just in clients and 2) X11 and wayland may share similar
configuration paths. The settings are now just applied whenever
the tool enters proximity, in reaction to
ClutterDeviceManager::tool-changed.
This commit moves all handling of these two settings to
the clutter level, and removes the wayland-specific paths
https://bugzilla.gnome.org/show_bug.cgi?id=773779
Enabling edge scrolling before disabling two finger would result in
edge scrolling not actually being enabled because two finger is still
enabled at the time and we bail out.
This patch moves this logic to common code for both the native and X
backends and fixes it by ensuring that both settings are never set at
the same time and still re-checking if edge scrolling should be
enabled after two finger scrolling gets disabled.
We also simplify the code by not checking for supported/available
settings since the underlying devices will just reject those values
and there isn't anything we can do about it here. It's the UI's job to
only show supported/available settings to users.
https://bugzilla.gnome.org/show_bug.cgi?id=771744
Checking for supported methods isn't needed since libinput will just
error out and do nothing itself if a requested method isn't supported
and, in fact, this logic was preventing the enum values 0 from being
set.
https://bugzilla.gnome.org/show_bug.cgi?id=771744
commit e2bfaf0751 does this:
g_hash_table_insert (cards,
g_udev_device_get_name (parent_device),
g_steal_pointer (&parent_device));
The problem is the g_steal_pointer call may happen before the
g_udev_device_get_name call leading to a crash.
This commit does the get_name call on an earlier line
https://bugzilla.gnome.org/show_bug.cgi?id=771442
Right now we accept any character device that matches the glob card*.
That's fine, but we can be a little more specific by checking that
the devtype is what we expect.
This commit does that.
https://bugzilla.gnome.org/show_bug.cgi?id=771442
Despite g_udev_client_new taking a list of subsystems, it doesn't
implicitly filter results to those subsystems.
This commit explicitly adds a subsystem match to make sure sound cards
don't end up in the resulting list of video cards.
https://bugzilla.gnome.org/show_bug.cgi?id=771442
Using the view's MetaMonitorInfo to find all the crtcs which should be
configured to display a given onscreen doesn't work unfortunately. The
association runs only the other way around, i.e. we need to go through
each crtc and find the ones corresponding to our monitor info.
https://bugzilla.gnome.org/show_bug.cgi?id=773115
If this isn't initialized and an idle watch gets instanced before
meta_idle_monitor_native_reset_idletime() gets called, that idle watch
would get triggered as soon as we hit the main loop.
This was causing gnome-session to go into idle mode at session start
thus making gnome-shell lock the screen.
In the past this bug was being masked by either logind emiting
session active signals or a stray input event making it through at
startup.
https://bugzilla.gnome.org/show_bug.cgi?id=772839
This isn't technically needed and, in fact, makes us default to
interlaced modes in some cases which isn't desirable.
Note that X doesn't account for these flags either for its mode
refresh rates.
https://bugzilla.gnome.org/show_bug.cgi?id=772176
As the m format specifier doesn't consume any arguments, the number
of varargs currently doesn't match the number of specifiers; the
failed transform may be relevant, so include it in the message
instead of removing the excess argument.
Some output devices only advertise their preferred mode even though
they're able to display others too. This means we can include some
common modes in each output's supported list.
This is particularly important for mirroring, since we can only mirror
outputs which are using the same resolution.
https://bugzilla.gnome.org/show_bug.cgi?id=744544
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
Switch to the output naming logic used by the X server's modesetting
driver which, in particular, uses drmModeConnector's connector_type_id
instead of connector_id.
The kernel generates new connector_id's every time there are changes
which means we can't identify the same monitor on the same connector
after an hardware hotplug. Switching to connector_type_id fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=770338
We can only honor this properly in the MUTTER_STAGE_VIEWS=1 case. When using
the legacy view, software implemented transforms are only exposed if there is
only one output, as we can only transform the entire stage there.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
The texture is only created if the view is transformed at the software level,
otherwise the texture is NULL, and rendering happens on the onscreen.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
The offscreen is given through the ::back-buffer property, the ClutterStageView
will set up the the CoglPipeline used to render it back to the "onscreen"
framebuffer.
The pipeline can be altered through the setup_pipeline() vfunc, so ClutterStageView
implementations can alter the default behavior of blitting from offscreen to
onscreen with no transformations.
All getters of "the framebuffer" that were expecting to get an onscreen have
been updated to call the right clutter_stage_view_get_onscreen() function.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
The call to _cogl_framebuffer_winsys_update_size() results in no-op here,
as the framebuffer has already the right size when rebuilding the views.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
Those will need a separate treatment from the modes that we eventually
support through "software", so split those into a separate enum so we
can can do the right thing when applying the configuration.
Also, add a helper function that returns the transform that the software
fallbacks should perform, which should be "normal" if the rotation is
already handled via hw.
The function applying the configuration has been modified to always set
a HW rotation mode (even if normal), when we come to support SW rotation
modes, we'll be relying on a normal transformation, so it will be
necessary to have mixed HW/SW managed transforms.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
The scale will have been set to 1 no matter what when initializing the
MetaOutput since it at the time didn't have an CRTC assigned to it.
Now, when we assign the CRTC to the output, we need to update the scale.
https://bugzilla.gnome.org/show_bug.cgi?id=769505
Support changing the mouse and trackball acceleration profile. This
makes it possible to for example disable pointer acceleration by
choosing the 'flat' profile.
This adds an optional dependency on gudev. Gudev is used by the X11
backend to detect whether a device is a mouse or not. Without gudev
support, the accel profile settings has have effect for mouse devices.
Trackball still uses the "strstr" approach, since udev doesn't support
tagging devices as trackball devices yet.
https://bugzilla.gnome.org/show_bug.cgi?id=769179
Add support for setting edge-scrolling separately from two-finger
scrolling. We now have 2 separate boolean settings for those, with the
Mouse panel in gnome-control-center allowing to set only one of those at
a time, but nothing precludes both being set in the configuration.
We need to handle:
- two-finger-scrolling-enabled and edge-scrolling-enabled settings both
being set.
- those 2 settings being change out-of-order
- two-finger-scrolling being set on a device that doesn't support it
- edge-scrolling-enabled on a device that doesn't support it
And the combinations of one touchpad supporting just one of edge
scrolling and two-finger scrolling and another vice-versa.
https://bugzilla.gnome.org/show_bug.cgi?id=768245
They are already effectively interchangeable so this should reduce
pointless casts.
Just like in GDK though, we need to keep the old definition for
instrospection to be able to include the struct's fields.
By creating a pending gbm/EGL surface pair, only setting it on
swap-buffers, we would draw onto a buffer on the old surface, then swap
the buffer from the new surface, causing the first frame after a
hot-plug always having no content.
This was in the past not very noticable since some non-deterministic but
frequent side effect in gnome-shell caused hot-plugging to always render
two new frames, but after "Introduce regional stage rendering", this
side effect did not occur as often, thus making it more visible.
This commit updates the current gbm/EGL surface pair before painting a
frame, so that when the frame is painted, the surface with the correct
size is used and the buffer from correct surface is swapped.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
CoglFrameInfo is a frame info container associated with a single
onscreen framebuffer. The clutter stage will eventually support drawing
a stage frame with multiple onscreen framebuffers, thus needs its own
frame info container.
This patch introduces a new stage signal 'presented' and a accompaning
ClutterFrameInfo and adapts the stage windows and past onscreen frame
callbacks users to use the signal and new info container.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Call a CoglContext "cogl_context", CoglDisplay "cogl_display" and
CoglRenderer "cogl_renderer" so that they won't be confused with
ClutterContext, MetaDisplay and MetaRenderer etc.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Make the cogl vfunc functions have names that are globally
discoverable. Calling the same function in every backend the same name
causes code navigation tools to not function properly. Rename the
affected functions to closer correspond to the style mutter uses.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
In preperation for having allowing drawing onto multiple onscreen
framebuffers, move the onscreen framebuffer handling to the
corresponding winsys dependent backends.
Currently the onscreen framebuffer is still accessed, but, as can seen
by the usage of "legacy" in the accessor name, it should be considered
the legacy method. Eventually only the X11 Compositing Manager backend
will make use of the legacy single onscreen framebuffer API.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Split the stage window implementations into three separate objects: one
for X11 as a compositing manager, one for X11 running as a nested
Wayland compositor, and one for running with the native backend.
The new stage window implementations are only thin shells; this is in
preparation for making the stage windows behave more differently.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
The stage resizing was placed in the generic backend, which was only
run on certain configurations (when running nested or using the native
backend). This commits makes the resizing more explicit thus more
obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
This commit completes the move of monitor logic to the monitor
mangager. The renderer now only deals with framebuffers, asking the
monitor manager to do the crtc flip tracking.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Let MetaMonitorManagerKms manage KMS modes. This lets us pass less
state to MetaRendererNative. Instead let MetaMonitorManager tell the
monitor manager when it should set the mode and with what framebuffer.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Absorb the CoglRendererKMS struct into MetaRendererNative. The gbm
device initialization is moved earlier so that the renderer fails to
initialize if the gbm device creation failed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
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
Instead of passing around the KMS file descriptor via clutter to cogl,
just make our own clutter backend create the cogl renderer and set the
KSM fd.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
MetaRenderer is meant to be the object responsible for rendering the
scene graph. It will contain the logic related to the cogl winsys
backend, the clutter backend, and the clutter stage window.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Introduce two new clutter backends: MetaClutterBackendX11 and
MetaClutterBackendNative. They are so far only wrap ClutterBackendX11
and ClutterBackendEglNative respectively, but the aim is to move things
from the original clutter backends when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Sadly, GLib's autoptr cleanup macros cannot be detected by the C
pre-processor, because they generate a function. This means that we are
forced to bump up the dependency on GLib 2.49, in order to build against
a newer version of gdbus-codegen.
Starting from GLib 2.49, the gdbus-codegen tool automatically generates
the auto cleanup symbols for the GDBus proxy and skeleton interfaces.
Since we don't depend on a specific version of GLib we need to
conditionally generate the auto cleanup symbols in case an older version
of gdbus-codegen is used when building Mutter.
This commit unbreaks the build under GNOME Continuous, which has been
failing with:
usr/include/glib-2.0/glib/gmacros.h:415:43: error: redefinition of 'glib_autoptr_cleanup_Login1Session'
#define _GLIB_AUTOPTR_FUNC_NAME(TypeName) glib_autoptr_cleanup_##TypeName
^
[...]
/usr/include/glib-2.0/glib/gmacros.h:415:43: note: previous definition of 'glib_autoptr_cleanup_Login1Session' was here
./meta-dbus-login1.h:82:1: note: in expansion of macro 'G_DEFINE_AUTOPTR_CLEANUP_FUNC'
G_DEFINE_AUTOPTR_CLEANUP_FUNC (Login1Session, g_object_unref)
^
If we rely on getting back an input event with the warped pointer
coordinates, we might draw a frame with the old coordinates if we warp
during the paint phase. Avoid that by moving the cursor immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
The wp_pointer_constraints protocol is a protocol which enables clients
to manipulate the behavior of the pointer cursor associated with a seat.
Currently available constraints are locking the pointer to a static
position, and confining the pointer to a given region.
Currently locking is fully implemented, and confining is implemented for
rectangular confinement regions.
What else is lacking is less troublesome semantics for enabling the lock
or confinement; currently the only requirement implemented is that the
window that appears focused is the one that may aquire the lock.
This means that a pointer could be 'stolen' by creating a new window that
receives active focus, or when using focus-follows-mouse, a pointer
passes a window that has requested a lock. This semantics can be changed
and the protocol itself allows any semantics as seems fit.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
In order to reuse some vector math for pointer confinement, move out
those parts to its own file, introducing the types old types
"MetaVector2" and "MetaLine2" outside of meta-barrier-native.c, as well
as introducing MetaBorder which is a line, with a blocking direction.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
Add support for sending relative pointer motion deltas to clients who
request such events by creating wp_relative_pointer objects via
wp_relative_pointer_manager.
This currently implements the unstable version 1 from wayland-protocols.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
Instancing a gbm device without initializing EGL with it means that it
won't be able to import wl_drm buffers. Instead, let's re-use cogl's
gbm device which is already properly initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=761557
This fixes an issue analogous to bug 760330 for the X11 backend,
except on this backend we wouldn't crash accessing free'd memory.
Instead we're leaking watches since we steal them from the hash table
which means that when they're removed in
_meta_idle_monitor_watch_fire() they're no longer there and thus
they're never free'd.
https://bugzilla.gnome.org/show_bug.cgi?id=760476
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
When the touchpad is two-finger scrolling capable, always enable it.
When the touchpad only supports edge scrolling (usually older devices, and
usually smaller devices), allow disabling the edge scrolling.
This requires a newer gsettings-desktop-schemas as the scroll-method key
was removed, and the edge-scroll-enabled key added.
https://bugzilla.gnome.org/show_bug.cgi?id=759304
On the wire, Wayland specifies the refresh rate in milliHz. Mutter sends
the refresh rate in Hz, which confuses clients, e.g. weston-info:
interface: 'wl_output', version: 2, name: 4
mode:
width: 2560 px, height: 1440 px, refresh: 0 Hz,
flags: current preferred
interface: 'wl_output', version: 2, name: 5
mode:
width: 3200 px, height: 1800 px, refresh: 0 Hz,
flags: current preferred
and xrandr:
XWAYLAND0 connected 2560x1440+3200+0 600mm x 340mm
2560x1440@0.1Hz 0.05*+
XWAYLAND1 connected 3200x1800+0+0 290mm x 170mm
3200x1800@0.1Hz 0.03*+
Export the refresh rate in the correct units. For improved precision,
perform the KMS intermediate calculations in milliHz as well, and
account for interlaced/doublescan modes.
This is also consistent with what GTK+ expects:
timings->refresh_interval = 16667; /* default to 1/60th of a second */
/* We pick a random output out of the outputs that the window touches
* The rate here is in milli-hertz */
int refresh_rate = _gdk_wayland_screen_get_output_refresh_rate (wayland_display->screen,
impl->outputs->data);
if (refresh_rate != 0)
timings->refresh_interval = G_GINT64_CONSTANT(1000000000) / refresh_rate;
Where the 'refresh_rate' given is exactly what's come off the wire.
1000000000/60000 comes out as 16667, whereas divided by 60 is ...
substantially less.
https://bugzilla.gnome.org/show_bug.cgi?id=758653
On Odroid U2 (exynos4412) the drm device is not bound to pci.
Open the detection to platform device of the drm subsystem, exclusive of
control devices.
https://bugzilla.gnome.org/show_bug.cgi?id=754911
g_error() is the wrong thing to do when, for example, we can't find the
DRM device, since Mutter should just fail to start rather than reporting
a bug into automatic bug tracking systems. Rather than trying to decipher
which errors are "expected" and which not, just make all failure paths
in meta_launcher_new() return a GError out to the caller - which we make
exit(1).
https://bugzilla.gnome.org/show_bug.cgi?id=757311
The qxl kms driver has a bug where the cursor gets hidden
implicitly after a drmModeSetCrtc call.
This commit works around the bug by forcing a drmModeSetCursor2
call after the drmModeSetCrtc calls.
This is pretty hacky and won't ever go upstream.
https://bugzilla.gnome.org/show_bug.cgi?id=746078
Calling queue_redraw() in _force_update() is not needed because
update_cursor() will do this when needed, i.e. when switching between
hardware cursor and texture cursor, or when drawing with texture cursor.
There is also no need to force _native_force_update() because
update_cursor() will cover this as well when needed. When not changing
cursor but only the gbm_bo, the "dirty" boolean on the gbm_bo will
trigger a redraw.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
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
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
There is nothing special about the private API which only consists of
getters for renderer specific backing buffer. Lets them to the regular
.h file and treat them as part of the normal API.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Instead of selecting the first drm mode as the preferred mode, select the
first drm mode marked as preferred. If there are no modes marked as
preferred, revert to the old behaviour and select the first mode.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
https://bugzilla.gnome.org/show_bug.cgi?id=750363
Read the drm layout properties suggested_X, suggested_Y and
hotplug_mode_update and transfer them to the meta layer.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
https://bugzilla.gnome.org/show_bug.cgi?id=750363
this just adds backend support for retrieving the tile
information from X11 (randr 1.5) and native backends.
It stores the tiling information into the output struct.
This makes gnome-settings-daemon turn on the backlight and
gnome-shell's screen shield animate.
Note that on X sessions, gnome-settings-daemon uses the same upower
property to force an innocuous key event into the X server so that the
idle time gets reset since Xorg doesn't do this itself on lid events.
https://bugzilla.gnome.org/show_bug.cgi?id=749076
This seems nicer/tidier than the current X11 (center on the span of all
monitors) or native (so close to the activities corner it's hard not
to trigger it) platform behaviors.
This code also takes over the native-specific pointer warping that
happens when the pointer was over a removed output.
https://bugzilla.gnome.org/show_bug.cgi?id=746896
This function returns the monitor_info index corresponding to the given
coordinates, or -1 if none is found at that point. The native backend
has been changed in places where it could make use of this function.
https://bugzilla.gnome.org/show_bug.cgi?id=746896
The enums are swapped currently, because for edge scroll is enabled two finger
scroll and similary for two finger scroll is enabled edge scroll, what is
apparently wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=746870
The initial pointer position is set by clutter. At the moment it
is the point 16x16 on the screen. But this point is not always
in the visible area on monitors (the monotors can be arranged in
many different ways).
https://bugzilla.gnome.org/show_bug.cgi?id=745752
Otherwise the pointer might be "lost" outside the visible area. Note
that the constraining code only ensures the pointer doesn't leave the
visible area but if the pointer is already outside because the rug was
pulled under it then it doesn't do anything.
https://bugzilla.gnome.org/show_bug.cgi?id=745121
DRM objects like connectors and encoders might change at any time, in
particular they might become invalid between drmModeGetResources() and
getting the actual objects in which case they'll be NULL. Be defensive
against that.
Note that, if this happens, we should get another udev event soon
which will cause us to update our state.
https://bugzilla.gnome.org/show_bug.cgi?id=745476
This just exposes the type and the singleton getter necessary to make
it available to introspection. We'll expose more functionality as it
becomes needed.
https://bugzilla.gnome.org/show_bug.cgi?id=743745
When running as a dispay server pointer barriers are a server side
feature and requires no client interaction of any sort. This patch
implements pointer barriers that can be used when running as a display
server on the native backend. Running as a display server using the X11
backend is currently not supported.
https://bugzilla.gnome.org/show_bug.cgi?id=706655
EDID parsing has been refactored to a common meta_output_parse_edid()
function, which ensures the extracted information is the same on both KMS
and X11 backend, so it can be used consistently on eg. settings values.
https://bugzilla.gnome.org/show_bug.cgi?id=742882
In recent versions of the QXL driver, it may set "suggested X|Y" connector
properties. These properties are used to indicate the position at which
multiple displays should be aligned. If all outputs have a suggested position,
the displays are arranged according to these positions, otherwise we fall back
to the default configuration.
At the moment, we trust that the driver has chosen sane values for the
suggested position.
meta_monitor_config_match_current() only matches the number of outputs
and if the output connector, vendor, product and serial match.
In the X backend, this means that we can't use it to bypass doing any
work because it won't detect cases where we actually want to update
ourselves like e.g. an output being turned off either by us or by
another X client (e.g. xrandr).
In the native backend, unlike the xrandr backend, we only get called
on real hotplug events and thus should always trigger the common
hotplug code to (possibly) apply a new mode so the check is pointless
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=738630
We need to tell clutter's evdev backend about the desktop's key repeat
settings so that our own key bindings event processing and
gnome-shell's chrome widgets get their fake key events for continuous
key press as they expect.
Note that the wayland frontend filters out these events and thus
wayland clients do not see them as specced.
https://bugzilla.gnome.org/show_bug.cgi?id=728055
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>
We'll need this in the wayland frontend to send a modifiers event to
clients.
Note that on X11 this isn't needed because key events include the
group index encoded in modifier state. If we ever want to make the
wayland frontend work with the X11 backend we'll handle it then.
https://bugzilla.gnome.org/show_bug.cgi?id=736433
This allows creating the stage much earlier than it otherwise would have
been. Our initialization sequence has always been a bit haphazard, with
first the MetaBackend created, then the MetaDisplay, and inside of that,
the MetaScreen and MetaCompositor.
Refactor this out so that the MetaBackend creates the Clutter
stage. Besides the clarity of early initialization, we now have much
easier access to the stage, allowing us to use it for things such as
key focus and beyond.
These methods allow us to set and get xkbcommon keymaps as well as
locking a specific layout in a layout group.
With this, we introduce dependencies on xkeyboard-config, xkbfile,
xkbcommon-x11 and a libX11 new enough to have xcb support.
https://bugzilla.gnome.org/show_bug.cgi?id=734301
The output_id is more of an opaque identifier for the monitor, based on
its underlying ID from the windowing system. Since we also use the term
"output_id" for the output's index, rename our use of the opaque cookie
"output_id" to "winsys_id".
This uses David Herrmann's new logind sessions interface to retrieve
fds for input devices, rather than using a custom setuid helper to do
the management. This vastly simplifies the interface.
This requires systemd v210, at least.
https://bugzilla.gnome.org/show_bug.cgi?id=724604
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.
