We were using the connector_id for the winsys_id, but different
devices could have connectors with the same id. Since we use
winsys_id to uniquely identify outputs, use both the connector
id and the device id to avoid having outputs with the same id.
Python is not guaranteed to be installed in /usr/bin. This is especially
true for *BSD systems which don't consider Python as an integral part of
their systems.
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
drmModePageFlip() is guaranteed to fail for the invalid FB id 0.
Therefore it never makes sense to call this function with such argument.
Disabling a CRTC must be done with SetCrtc instead, for example.
Trying to flip to FB 0 not only fails, but it also causes Mutter to
never try page flip on this output again, using drmModeSetCrtc()
instead.
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
