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
Various code assumed PipeWire function calls would never fail. Some can
actually fail for real reasons, and some currently can only fail due to
OOM situations, but we should still not assume that will always be the
case.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/102
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
When deriving the global scale directly from the current hardware state
(as done when using the X11 backend) we are inspecting the logical
state they had prior to the most recent hot plug. That means that a
primary monitor might have been disabled, and a new primary monitor may
not have been assigned yet.
Stop assuming a primary monitor has an active mode before having
reconstructed the logical state by finding some active monitor if the
old primary monitor was disabled. This avoids a crash when trying to
derive the global scale from a disabled monitor.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/130
As a follow up to the patch from a95cbd0a, we need to make sure
that the pointer is out of the way as well when monitors changed,
since that's the event that will prevail in some cases. Besides,
this is also consistent with what the code before a95cbd0a was,
which initialized the pointer position in the same way both in
this case and in the real_post_init() function.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/157
Centering the pointer at startup causes undesired behaviour if
it ends up hovering over reactive elements, that might react
to that positioning, causing confusion. This is the case of
the login dialog when a list of different users is shown, as
centering the pointer at startup in that case will get the
user in the center of the screen pre-selected, which is not
the expected behaviour (i.e. pre-selecting the first one).
Fix this by simply moving the pointer out of the way, close
to the bottom-right corner, during initialization.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/157
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.
The ResetIdletime API can be used instead of an "XTest" binary to
programmatically reset the idle time, as if the user pressed a button on
a keyboard.
This is necessary since we stopped using the XSync extension to monitor
idletimes, as it didn't consider inhibitors as busy, and mutter's
clutter code ignores "Core Events" as generated by XTest.
This patch will require minimal changes to gnome-settings-daemon's power
test suite so that "key press" idletime resets are triggered through
this D-Bus interface rather than through XTest and a roundtrip through
the X server.
https://bugzilla.gnome.org/show_bug.cgi?id=705942
Take idle inhibitions into account for when to fire idle watches as
requested by OS components.
This should stop gnome-session and gnome-settings-daemon considering
the session idle when they have been inhibited for longer than their
timeout, for example to avoid the screensaver activating, or the
computer suspending after watching a film.
https://bugzilla.gnome.org/show_bug.cgi?id=705942
Now that we've removed the X11 specific backend of the idle monitor,
add back a cut-down version of it for the explicit purpose of being
told about idle time resets when XTest events are used.
XTest events are usually used by test suites and remote display software
to inject events into an X11 session. We should consider somebody moving
the mouse remotely to be just as "active" as somebody moving it locally.
https://bugzilla.gnome.org/show_bug.cgi?id=705942
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
Output ID is set equal to 'i' later in the loop. But 'i' was never
incremented, so all outputs were getting the same ID (equal to
the number of CRTCs, because 'i' was reused from the previous loop).
(cherry picked from commit 23c3f8bb18)
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.
When using two monitors size by side with different scales, once the
cursor moves from one output to another one, its size changes based on
the scale of the given output.
Changing the size of the cursor can cause the cursor area to change
output again if the hotspot is not exactly at the top left corner of the
area, causing the texture of the cursor to change, which will trigger
another output change, so on and so forth causing continuous surface
enter/leave event which flood the clients and eventually kill them.
Change the logic to use only the actual cursor position to determine if
its on the given logical monitor, so that it remains immune to scale
changes induced by output scale differences.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/83
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
In order to let applications gracefully handle version mismatches, add
a version property to the APIs. Also add a warning on the APIs that
these are not meant for public consumption.
If the coordinates was for a stream not at the stage position (0, 0),
they'd be incorrect. Fix this by correctly translating the coordinates
according to the stream position.
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
So the changes can be instantly applied while the tool is in proximity.
Before we would just do it on proximity-in, which doesn't provide a
good look&feel while modifying the tool settings in g-c-c.
https://gitlab.gnome.org/GNOME/mutter/issues/38Closes: #38
The property has been 32 bits since around 2011 and has not changed, mutter
expects it to be 8 bits. The mismatch causes change_property to never
actually change the property.
https://gitlab.gnome.org/GNOME/mutter/issues/26Closes: #26
This was done by the clutter X11 backend before prior to introducing
MetaRenderer, but during that work, enabling of said extension was lost.
Let's turn it on again.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
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
Opening and closing the device may result into XI2 grabs being cut short,
resulting into pad buttons being rendered ineffective, and other possible
misbehaviors. This is an XInput flaw that fell in the gap between XI1 and
XI2, and has no easy fix. It pays us for mixing both versions, I guess...
Work this around by keeping the XI1 XDevice attached to the
ClutterInputDevice, this way it will live long enough that this is not
a concern.
Investigation of this bug was mostly carried by Peter Hutterer, I'm just
the executing hand.
https://gitlab.gnome.org/GNOME/mutter/issues/7Closes: #7
A comparison in translate_device_event() does not account for the fact
that X's clock wraps about every 49.7 days. When triggered, this causes
an unresponsive GUI.
Replace simple less-than comparison with XSERVER_TIME_IS_BEFORE macro,
which accounts for the wrapping of X's clock.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/12
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
Using 800x600 as minimum logical size is very 4:3 thinking, while a lot of
modern devices are 16:9. The specific reason for this commit is to allow
1.5 scaling at mini-laptops (clamshell devices) with e.g. a 5.5"
1280x720 screen. Given that this device has a keyboard, one obviously
is not holding it very close to ones eyes and at 220 dpi that means the text
is too small at scale 1.0. For one real world example of such a device see:
https://en.wikipedia.org/wiki/GPD_Winhttps://bugzilla.gnome.org/show_bug.cgi?id=792765
The device orientation coming out of iio-sensor-proxy defines upright/normal
as the direction in which the picture is displayed on the LCD panel without
any rotation. This is necessary for accelerometer rotation to work properly
in desktop environments which are not aware of panel-orientation issues.
This means that we need to correct the logical-monitor-config / user-visible
rotation for the panel-orientation when we get rotation info from
iio-sensor-proxy.
https://bugzilla.gnome.org/show_bug.cgi?id=782294
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
If a LCD panel has a non normal orientation (mounted upside-down or 90
degrees rotated) then the kernel will report touchscreen coordinates with
the origin matching the native (e.g. upside down) coordinates of the panel.
Since we transparently rotate the image on the panel to correct for the
non normal panel-orientation, we must apply the same transform to input
coordinates to keep the aligned.
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
We only counted configured monitors and whether the config was
applicable (could be assigned), howeverwe didn't include disabled
monitors when comparing. This could caused incorrect configurations to
be applied when trying to use the previous configuration.
One scenario where this happened was one a system with one laptop
screen and one external monitor that was hot plugged some point after
start up. When the laptop lid was closed, the 'previous configuration'
being the configuration where only the laptop panel was enabled, passed
'is-complete' check as the number of configured monitors were correct,
and the configuration was applicable.
Avoid this issue by simply comparing the configuration key of the
previous configuration and the configuration key of the current state.
This correctly identifies a laptop panel with the lid closed as
inaccessible, thus doesn't incorrectly revert to the previous
configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=788915
When deriving the list of disabled monitors when creating new monitors
configs, don't include the laptop panel if the lid is currently closed,
as we consider the laptop panel nonexistent when the laptop lid is
closed when it comes to configuration.
The laptop panel connector(s) will either way be appropriately disabled
anyway, as the field listing disabled monitors in the configuration do
not affect actual CRTC/connector assignments.
https://bugzilla.gnome.org/show_bug.cgi?id=788915
Commit b1a0bf891 broke the previous logic that we would only fallback
to the root cursor if 1) windows are not interactable or 2) no window
cursor is currently set (i.e. not hovering over any window). Now it
will set up the root cursor if it's NULL, which breaks clients
explicitly setting an invisible cursor. This commit restaurates the
previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=754806
This function is supposedly not failable, so just move the theme_dirty
flag clearing to the beginning of the function. Protects against cases
where requesting a cursor image may result in it being loaded and set
as a texture, which emits ::texture-changed, which may end up requesting
the cursor image again.
https://bugzilla.gnome.org/show_bug.cgi?id=754806
As wayland implements the cursor role, it consists of a persistent
MetaCursorSprite that gets the backing texture changed. This is
inconvenient for the places using MetaCursorTracker to track cursor
changes, as they actually track MetaCursorSprites.
This signal will be used to trigger emission of
MetaCursorTracker::cursor-changed, which will make users able to
update accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=754806
Just like X11/XFixes behaves, the current cursor is not affected
by its visibility, so it can be queried while invisible (possibly
to be replaced).
For this, keep an extra effective_cursor pointer that will be
either equal to displayed_cursor (maybe a bit of a misnomer now)
or NULL if the cursor is invisible. The MetaCursorRenderer
management is tied to the former, and the ::cursor-changed signal
emission to the latter.
https://bugzilla.gnome.org/show_bug.cgi?id=754806
We must emit ::dnd-leave to pair the ::dnd-enter that shall be
emitted whenever the plugin grab begins, otherwise we leave
listeners unable to clean up if the plugin begins and ends a
grab while there is an ongoing DnD operation.
https://bugzilla.gnome.org/show_bug.cgi?id=784545
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
Bluetooth mouse usually goes in sleep state after a timeout, when that
happen the mouse is disconnected and on_device_removed function is
called. Before the patch if a touch device is available the
on_device_removed function hide the cursor. The issue is that the cursor
does not reappear once the bluetooth mouse is reconnected because
MetaBackend::current_device_id is not invalidated when on_device_removed
was called.
The patch set MetaBackend::current_device_id to 0 if the current device
is removed. This will make update_last_device to be triggered as soon as
another input device is used or the bluetooth mouse reconnect, as
consequence that the cursor reappear. The id 0 is never given to devices
and can safely used as undefine id.
https://bugzilla.gnome.org/show_bug.cgi?id=761067
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
Check that if there are multiple modes with the same ID (resolution,
refresh rate and handled flags) we correctly add the preferred mode to
the list of monitor modes.
https://bugzilla.gnome.org/show_bug.cgi?id=789153
When generating MetaMonitorMode's, prefer CRTC modes that has the same
set of flags as the preferred mode. This not only is probably a better
set of configurable modes, but it'll guarantee that the preferred mode
is added.
This fixes a crash when the preferred mode was not the first mode with
the same resolution, refresh rate and set of handled modes.
https://bugzilla.gnome.org/show_bug.cgi?id=789153
Under X11 we can only ever have the same scale configured on all
monitors. In order to use e.g. scale 2 when there is a HiDPI monitor
connected, we must not disallow it because there is a monitor that does
not support scale 2. Thus we must show the same scale for every monitor
and monitor mode, even though it might result in a bad experience.
Do this by iterating through all the monitors adding all supported
scales by the preferred mode, combining all the supported scales. This
supported scales list is then used for all monitor and modes no matter
what.
https://bugzilla.gnome.org/show_bug.cgi?id=788901
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
Don't use MAX(logical monitor scales) to determine the UI scaling
factor, just use the primary logical monitor. That's where the shell UI
will most likely be.
https://bugzilla.gnome.org/show_bug.cgi?id=788820
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
Add helper functions and macros for managing and drawing OpenGL ES 3.
It will be used for blitting framebuffers between multiple GPUs in
hybrid GPU systems.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Eventually, we'll render buffers without using Cogl, and for this we
need to be able to do things like creating, destroying and changing the
context, as well as swapping buffers.
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 Xrandr MetaCrtcs and related functionality to its
own file. Eventually, MetaCrtcCrtc should be introduced, based on
MetaCrtc, and this commit is in preparation for that.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
Move code dealing with X11 MetaOutputs and related functionality to its
own file. Eventually, a MetaOutputXrandr should be introduced, based on
MetaOutput, and this commit is in preparation for that.
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
Add meta_logical_monitor_foreach_crtc() helper to iterate over all the
active CRTCs driving the monitors associated with the specified logical
monitor.
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
If a configuration key matched a current system state, but no monitor
mode was found (for example because of an incorrect refresh rate),
discard it while logging a warning.
https://bugzilla.gnome.org/show_bug.cgi?id=787668
People that relied on xsetwacom to configure their tablets used to get
away with this by disabling the wacom g-s-d plugin prior to running
their scripts. This is not possible anymore with mutter managing device
configuration.
Given that X11 shall not go away soon and there's a core of stubbornly
accustomed users, provide a MUTTER_DISABLE_WACOM_CONFIGURATION envvar
to provide *some* way to do this.
When saving and restoring monitor configurations, we must take disabled
monitors into account, as otherwise one cannot store/restore a
configuration where one or more monitors are explicitly disabled. Make
this possible by adding a <disabled> element to the <configure> element
which lists the monitors that are explicitly disabled. These ones are
included when generating the configuration key, meaning they'll be
picked up correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=787629
The XIQueryDevice function used by device_query_area can return a NULL
pointer and set n_devices to a negative number in some cases. We add
additional checks to prevent a segfault.
https://bugzilla.gnome.org/show_bug.cgi?id=787649
When rotating 90/270 degrees we need to swap width and height. This fixes
the screen going black and the following errors showing in the journal:
gnome-shell[1097]: Failed to set CRTC mode 800x1280: No space left on device
gnome-shell[1097]: Failed to flip: Device or resource busy
gnome-shell[1097]: Failed to set CRTC mode 800x1280: No space left on device
gnome-shell[1097]: Failed to set CRTC mode 800x1280: No space left on device
When rotating a tablet with accelerometer 90/270 degrees.
https://bugzilla.gnome.org/show_bug.cgi?id=787836
We currently have a hard coded limit on logical monitor sizes, meant
for filtering out monitor scales that would result in awkward desktop
sizes. This has the side effect of also disqualifying scale 1 for
resolutions that themself are lower than the mentioned limit. To avoid
listing no supported scales, always add the fallback scale 1 if no
other was added.
https://bugzilla.gnome.org/show_bug.cgi?id=787477
When we update state, we might not have set the current config yet (for
example if the Xrandr assignment didn't change), so pass the monitors
config we should derive from instead of fetching it from the monitor
config manager.
https://bugzilla.gnome.org/show_bug.cgi?id=787477
We currently only save synchronously when running the test suite, but
should still not leak the generated config buffer. We also created the
cancellable but never used it if we saved synchronously, so lets stop
doing that too.
https://bugzilla.gnome.org/show_bug.cgi?id=787477
The cancellable should only be cleared if we weren't cancelled, as if
we were cancelled, the path cancelling have already cleared the
cancellable.
https://bugzilla.gnome.org/show_bug.cgi?id=787477
We cleaned up an unused monitor config list, but what we should do is
clear up the logical monitor config list. This commit does that, as
well as removes the unused monitor config list.
We have not enough control over the sources of the refresh rate
float variable to make == comparisons reliable, add some room
when comparing these.
https://bugzilla.gnome.org/show_bug.cgi?id=787668
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.
The foreach CRTC monitor mode helper incorrectly iterated over outputs
without CRTC when non-tiled modes were set on tiled monitors. This was
not expected by callers, so fix the helper to only iterate over active
outputs (that has or should have a CRTC).
The test cases uses the incorrect behaviour of the foreach CRTC helper
to check that the disabled outputs mode are set to NULL, so add a
foreach output helper and change the tests to use that instead.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
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
When a screen cast session is stand-alone, i.e. not created given a
remote desktop session managing it, allow calling the Start/Stop
methods to start and stop it.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
As of commit 5f5ef3de2cdc816dab82cb7eb5d7171bee0ad2c5 in pipewire the
stream creator can find out the node ID of the stream it created.
So instead of using a special purpose entry to the info property box to
let the application discover stream by monitoring added nodes searching
for the given special purpose entry, just pass the node directly.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
When the PipeWire context or stream ends up in an error state, signal
that the source has closed. This then triggers the stream and finally
the session to be closed too.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
This commit adds basic screen casting and remote desktoping
functionalty. This works by exposing two D-Bus API services:
org.gnome.Mutter.ScreenCast and org.gnome.Mutter.RemoteDesktop.
The remote desktop API is used to create remote desktop sessions. For
each session, a D-Bus object is created, and an application can manage
the session by sending messages to the session object. A remote desktop
session the user to emit input events using the D-Bus methods on the
session object. To get framebuffer content, the application should
create an associated screen cast session.
The screen cast API is used to create screen cast sessions. One can so
far either create stand-alone screen cast sessions, or a screen cast
session associated with a remote desktop session. A remote desktop
associated screen cast session is managed by the remote desktop session.
So far only remote desktop managed screen cast sessions are implemented.
Each screen cast session may have one or more streams. A screen cast
stream is a stream of buffers of some part of the compositor content.
So far API exists for creating streams of monitors and windows, but
only monitor streams are implemented.
When a screen cast session is started, the one PipeWire stream is
created for each screen cast stream created for the session. When this
has happened, a PipeWireStreamAdded signal is emitted on the stream
object, passing a unique identifier. The application may use this
identifier to find the associated stream being advertised by the
PipeWire daemon.
The remote desktop and screen cast functionality must be explicitly be
enabled at ./configure time by passing --enable-remote-desktop to
./configure. Doing this will build both screen cast and remote desktop
support.
To actually enable the screen casting and remote desktop, the user must
enable the experimental feature. See
org.gnome.mutter.experimental-features.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
When monitors changed, previous monitor instances are defunct, and any
reference holder should drop its reference. Sometimes they will want to
continue having a reference to the same monitor, so add this function
to make it possible to find it.
Currently the output and crtc references are invalid, as they are not
yet reference counted, so this can only look at cached fields.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
Trying to unilaterally require eglGetPlatformDisplayEXT causes problems in
scenarios where this method is not available. Besides, this should only be
required on Wayland, so we can stop requiring it always and simply let the
eglGetPlatformDisplay() function error accordingly when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=786619
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
When another D-Bus call that just tries to verify a configuration is
made, don't cancel any active monitor configuration dialog, as doing so
would effectively confirm queried configuration.
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
Don't wait for clutter to initialize for connecting to X11; do it when
constructing the backend instance. This way we can later depend on
having an X11 connection earlier during initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=786408
When opening a laptop lid, one will likely want to restore the
configuration one had prior to closing it, so when ensuring monitor
configuration, first try to see if the previously set configuration is
both complete (all connected monitors are configured) and applicable
(it is a valid configuration) and only try to generate a new from
scratch if that failed.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In order to go back in monitor configurations, save them to a history.
The history is implemented as a max 3 element long queue, where newly
set configurations are pushed to the head, and old are popped from the
tail.
The difference between using a single previous config reference and a
queue is that we can now remember the configuration used prior to a
D-Bus triggered configuration when the user discarded the configuration.
This will later be used to restore a previous configuration when a
laptop lid is opened.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This commit changes the new configuration system to use monitors.xml
instead of monitors-experimental.xml. When starting up and the
monitors.xml file is loaded, if a legacy monitors.xml file is
discovered (it has the version number 1), an attempt is made to migrate
the stored configuration onto the new system.
This is done in two steps:
1) Parsing and translation of the old configuration. This works by
parsing file using the mostly the old parser, but then translating the
resulting configuration structs into the new configuration system. As
the legacy configuration system doesn't carry over some state (such as
tiling and scale used), some things are not available. For tiling, the
migration paths makes an attempt to discover tiled monitors by
comparing EDID data, and guessing what the main tile is. Determination
of the scale of a migrated configuration is postponed until the
configuration is actually applied. This works by flagging the
configuration as 'migrated'.
2) Finishing the migration when applying. When a configuration with the
'migrated' flag is retrieved from the configuration store, the final
step of the migration is taken place. This involves calculating the
preferred scale given the mode configured, while making sure this
doesn't result in any overlapping logical monitor regions etc.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
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 'normal' transform has the value 0, so the g_warn_if_fail()
expression failed. Correct it so that it doesn't complain when no
transform is checked.
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
This will allows us to support the XF86Display key present on some
laptops, directly in mutter. This is also known, in evdev, as
KEY_SWITCHVIDEOMODE.
The common usage for this key is to alternate between a few well known
multi-monitor configurations though these aren't officially
standardized. As an example, Lenovo documents it as:
"Switches the display output location between the computer display
and an external monitor."
On this patch, we're just introducing the configurations that have been
implemented in g-s-d until now, which go a bit beyond the above
description.
https://bugzilla.gnome.org/show_bug.cgi?id=781906
Instead of letting MetaMonitor derive the logical monitor size, then
using the main monitor for the position, just let MetaMonitor derive
the whole layout including the position. This means it can deal with
tiled monitors better, for example when the main output (the output
always active when the monitor is active) is not the origin output (the
output with tile position (0, 0)).
https://bugzilla.gnome.org/show_bug.cgi?id=781723
Just like we do for buttons, with a few twists. These have 2 directions
mappable to different keycombos, and are affected by the current mode
in their group.
https://bugzilla.gnome.org/show_bug.cgi?id=782033
This basically moves g-s-d's orientation plugin into mutter so that
eventually g-s-d doesn't need to build monitor configurations by
itself anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=781906
When verifying if a configuration is applicable, don't set it as
current when applying succeeded, or else reverting to a previous
configuration doesn't work after having verified.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
Differentiate between non-interlaced and interlaced modes. This is done
by appending an "i" after the resolution part of the mode ID, and
adding a 'is-interlaced' (b) property to the mode properties.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
To be more flexible without having to change any D-Bus type signatures
in the future, replace the 'uint' flags value (currently determining
whether a mode is current and/or preferred) with a variant lookup table.
The keys 'is-current' (b) and 'is-preferred' (b) replace the existing
flags.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
To be able to add more modes types that happen to have the same
resolution and refresh rate, change the API to specify modes using an
ID string. The ID string is temporary, and only works for associating a
mode for the monitor instance that it was part of.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
When calculating sizes given some size and a fractional logical monitor
scale with precision loss, round the result of the floating point
calculation to the closest integer, as otherwise we might end up with
result smaller by 1 if there was a loss of precision when calculating
the scale.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
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
When passing scales over D-Bus, we'll loose some precision. To set the
correct scale, use the configured scale and look up the one actually
supported by the monitor mode, and use that. To match the supported one
with the configured one, the difference must be within rounding error
range.
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
When using logical sized monitors we are allowed to use fractional scaling
but only if the resulting scaled logical monitor size is in integer form.
So, in order to get this, we allow to scale the monitor to up to
8 fractional values per integer, doing some computation in order to
fetch the nearest values which are closer to the scaling factors we can
permit.
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
Previously gnome-shell listened on the Xft Xsettings via GTK+s
GtkSettings to get the font DPI setting. The Xsetting might not
be what we want, and we should not rely on Xsettings when we don't need
to, so lets manage it ourself.
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
Wacom's display tablets typically do not have (0,0) coincident with the top
left corner of the screen. This "outbound" area must be taken into account
when setting the area or else an unexpected offset of the pointer will
occur.
https://bugzilla.gnome.org/show_bug.cgi?id=784009
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
It would only allow to alternate between the logical monitors, we actually
want to return NULL here so it can cycle to the whole span of monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=782032
Instead of checking all MetaMonitors in the monitor manager, we want to
look (as the function name says) in the MetaMonitors contained in the
given logical monitor.
Otherwise, it will return TRUE for every logical monitor, given we are
querying for an existing EDID.
https://bugzilla.gnome.org/show_bug.cgi?id=782032
Due to the pen/eraser device separation in X11, CLUTTER_TABLET_DEVICE does
not apply there, this device type is only used in native/evdev. Checking
for CLUTTER_PEN/ERASER_DEVICE makes the left-handed mode correctly applied
on tablets.
https://bugzilla.gnome.org/show_bug.cgi?id=782027
For devices connected via HDMI (supposedly TVs) we want have a
scale factor of 1 if we are *below* the smallest 4k resolution
width (not equal or above) and do the scaling factor computation
if we are above the limit. This check was apparently wrongly
ported from gnome-settings-daemon.
Based of a patch by Caolan McNamara <caolanm@redhat.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=777347
We will both create and destroy monitors during initialization (when
using the X11 backend), so don't try to access the monitor manager from
the backend, but store a pointer to it instead.
It's stored in MetaMonitor even though only MetaMonitorTiled uses it,
mostly because it makes more sense to store such a pointer there.
https://bugzilla.gnome.org/show_bug.cgi?id=781723
In some circumstances, the origin tile (0, 0) is not the one that
should be used to drive the monitor when using a non-tiled mode. Update
MetaMonitorTiled to support this case. It also seems to be so that the
preferred mode might be some low resolution or bogus mode on these
monitors, so also adapt MetaMonitorTiled to manage to ignore the
preferred mode of a tiled monitor if the preferred mode doesn't use
both tiles.
https://bugzilla.gnome.org/show_bug.cgi?id=781723
Only support suggested monitor positioning if the monitor is non-tiled.
Normally this functionality is used by virtual machines to provide a
hint of how to place the virtual monitors, and they don't tend to use
tiled monitors anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=781723
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
hotplug_mode_update is used (mostly by VMs nowadays, and
VMware has implemented it) to inform that modes list (including
the preferred one) might change after an uevent.
However, when using MetaMonitorConfigManager we should
ignore this value at initialization level, or mutter
won't restore the configured values at startup.
https://bugzilla.gnome.org/show_bug.cgi?id=783073
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
meta_backend_real_post_init() had some open coded initialization with
some unexpected interdependencies. Split these up and move them to their
own functions in order to make meta_backend_real_post_init() a bit more
readable.
https://bugzilla.gnome.org/show_bug.cgi?id=782152
g_hash_table_insert() doesn't replace the key. This was a problem
because the key was owned by the value inserted into the hash table, so
when a value was removed, the key was freed, meaning that the key in
the hash table was no pointing to freed memory. Fix this by using
g_hash_table_replace() instead, which work the same except that it
replaces the key with the one passed. This means that the key of a
value in the hash table is always the key owned by the value.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The guard for handling size differences between keys were broken, it
only checked if the key passed by the second argument ended up being
shorter.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
An inactive monitor will not be assigned to a logical monitor, so don't
try to match against those. This avoids a dereferencing a NULL when the
main output of an inactive monitor doesn't have an assigned CRTC.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Instead of looking at the GTK+ settings, check the logical monitor
state and determine the UI scaling factor given the maximum logical
monitor scale. This is only enabled when the monitor config manager
feature is enabled, as only then can a scale be explicitly configured.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This adds a function to be used by gnome-shell to get the logical
monitor given a connector name. For now, use the same index integer
method to reference a logical monitor, but this should be revisited by
providing a better API later.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The connector returned is the one of the main output. In other words,
for tiled monitors, it is the connector of the (0, 0) tile, and for
non-tiled, it is simply the connector of the output.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The UI scaling depends on whether the framebuffers are scaled. Enable
the caller to determine the what scale its UI should be drawn in, in
relation to the stage coordinate space by calling this function. A new
singal "ui-scaling-factor-changed" is added in order to liston for for
changes.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Window scaling is a clutter feature used to enable automatic scaling of
stage windows when running under as an application in windowing system.
Clutter in mutter does not support running as a stand-alone application
toolkit, so lets remove this unused feature.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
When told to, MetaMonitorConfigStore will save the current
configuration state by replacing the monitors-experimental.xml file
(while backing a backup).
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Derive the logical monitor position not by looking at the main output
(the (0, 0) tile), but the one that is placed on the top-left corner.
This might be the non-main output on certain transformations.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Only the first output of the first monitor of the primary logical
monitor should be made primary. This fixes an issue where the wrong
logical monitor ended up as primary when the logical state was derived.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Make the nested backend emulate how the real backends actually draw,
i.e. by drawing each CRTC separately. This makes it possible to test
different configuration paths that can take place on different
hardware, without having said hardware.
For example, by setting MUTTER_DEBUG_TILED_DUMMY_MONITORS and
MUTTER_DEBUG_NESTED_OFFSCREEN_TRANSFORM to "1", one can test a system
with MST (tiled) monitors where the GPU doesn't support some transform.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add the transform as a logical monitor parameter, both when getting the
current state and applying a new configuration. The transform is defined
to be identical to MetaMonitorTransform.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Adds a <transform> element to <logicalmonitor>. It has two possible sub
elemenst: <rotation> which can be normal, right, left or upside_down,
and <flipped> which can either be true or false.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
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
Always draw the stage to an offscreen framebuffer when using the nested
backend, so that we more emulate things more similarly to how it works
real-world, i.e. it'll work the way whether stage views are enabled or
not.
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
Split up the MetaRendererX11 class into one for when running as a
X11 compositing manager, and one for when running as a nested Wayland
compositor.
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
The logical monitor config array ownership was transferred to the
config object when it was created, but was not unset when the config
verification failed, causing the clean up path for invalid configs to
try to clean up the same list again.
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
This gsetting will allow the adding of keywords to a array, where each
keyword may enable an experimental feauter, if the given mutter version
supports that particular experimental feature. Emphasis is put on the
lack of guarantee that any such keyword has any effect. Currently no
keywords are defined.
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
Logical monitors in a configuration must be adjecent to each other,
meaning there will be at least one pixel long side touching some other
logical monitor.
The exception to this is when there is only one logical monitor, which
cannot be adjecent to any other.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
We don't want to limit ourself to whole integers for configuration, as
that'd mean it wouldn't be able to provide configurations for
fractional scalings. Thus, change scales to be referred to as floats
instead of ints.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a 'is_underscanning' entry to the properties map, if the monitor
supports underscanning. The client should assume a monitor does not
support underscanning if no property was added.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Add a D-Bus method for getting the current monitor and logical monitor
state. Currently does not contain information about transforms or any
limitations (such as limited CRTCs and cloning).
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
Add support to configure the logical monitor scale. With this, it
becomes possible to override the automatically calculated scaling
number per logical monitor.
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
The default (calculated) scale is derived from the output, but
ultimately set via the monitor scale. This will enable config files to
override the scale. Yet to be done is handling when a scale is not
supported by a backend (i.e. the X11 backend).
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
Clutter's evdev input backend has no support for setting double
click timeout set by gnome-settings-daemon. This results in
touchpad click events timing out on wayland, because the
default timeout value wasn't enough.
This patch moves timeout setting to mutter and removes X11
backend specific setting from clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=771576
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
Previously, the size of the logical monitor was derived directly from
the tiling information. This works fine until we add transformations,
or set modes with a dimension different from the resulting resolution
when tiled. Fix this by traversing the assigned CRTC rects, as these
are already transformed by the configuration system.
https://bugzilla.gnome.org/show_bug.cgi?id=779745
By setting the environment variable MUTTER_DEBUG_TILED_DUMMY_MONITORS
to "1", the dummy MetaMonitorManager backend used when running mutter
nested will create tiled monitors instead of single-output/CRTC
monitors. This makes it possible to test tiled monitor configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=779745
Refactor monitor generation by splitting the generation of modes, CRTCs
and outputs into a separate function. A side effect is that each output
will have its own set of possible modes.
https://bugzilla.gnome.org/show_bug.cgi?id=779745
Split up logical monitor cration into derived (when derived from
current underlying configuration) and non-derived (when creating from a
logical monitor configuration). This avoids that type of logic in the
logical monitor creation function.
https://bugzilla.gnome.org/show_bug.cgi?id=779745
Add support for non-tiled monitor modes on tiled monitors. This is done
by adding all the other supported modes, except the modes with the
same resolution as the tile dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=779745
