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 23c3f8bb18db499d196f1024732ef3234b44f59c)
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
