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
The modifier event was only added in v3 of the client; sending it to
older clients (e.g. GStreamer waylandsink) causes them to disconnect
immediately.
Send the older 'format' event to all clients, and only send the newer
'modifier' event to resource versions 3 or above.
https://bugzilla.gnome.org/show_bug.cgi?id=788558
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.
To keep feature parity with the Wayland backend, and
to improve the overall tiling experience with GTK apps,
add the _GTK_EDGE_CONSTRAINTS X11 atom and update it
when necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
Following up the previous patch, this patch makes the
Wayland backend send the edge constraints through a
custom protocol extension internal to GTK.
As it mature, we can think of upstreaming the protocol
to Wayland itself.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
GTK has the ability to handle client-decorated windows
in such a way that the behavior of these windows must
match the behavior of the current window manager.
In Mutter, windows can be tiled horizontally (and, in
the future, vertically as well), which comes with a few
requirements that the toolkit must supply. Tiled windows
have their borders' behavior changed depending on the
tiled position, and the toolkit must be aware of this
information in order to properly match the window manager
behavior.
In order to provide toolkits with more precise and general
data regarding resizable and constrained edges, this patch
makes MetaWindow track its own edge constraints.
This will later be used by the backends to send information
to the toolkit.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
When computing a potential match for a tiled window, there is a
chance we face the case where 2 windows really complement each
other's tile mode (i.e. left and right) but they have different
sizes, and their borders don't really touch each other.
In that case, the current code would mistakenly assume they're
tile matches, and would resize them with either a hole or an
overlapping area between windows. This is clearly a misbehavior
that is a consequence of the previous assumptions pre-resizable
tiles.
This patch adapts the tile match algorithm to also consider the
touching edges when computing the matching tile, unless:
* the window is not currently tiled (for example when computing
the tile preview)
* the window is currently resized in tandem with an existing
tile match
https://bugzilla.gnome.org/show_bug.cgi?id=645153
bar
When a pair of tiled windows are grouped together, they
are treated as parts of a whole and interacting with one
affects the other.
Following the idea that sibling tiled windows are treated
as part of the same group, they should also be raised and
lowered together.
It is still possible to break tiled windows grouping by
simply untiling the window with the keyboard or by grabbing
and resizing or moving the window with the cursor.
This patch makes sibling tiled windows be lowered and raised
in tandem. For future reference, this behavior is documented
in [1].
[1] https://wiki.gnome.org/GeorgesNeto/MinutesOfFeaneron/Tilinghttps://bugzilla.gnome.org/show_bug.cgi?id=645153
There is a variable in meta_window_edge_resistance_for_resize
that isn't really helpful: it just assumes TRUE, and is passed
to apply_edge_resistance_to_each_side.
This patch removes that useless variable and simply pass TRUE
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=645153
When windows are tiled, it improves the interaction with
them when they have a set of snapping edges relative to
the monitor. For example, when there's a document editor
and a PDF file opened, I might want to rescale the former
to 2/3 of the screen and the latter to 1/3.
These snapping sections are not really tied to any other
window, and only depend on the current work area of the
window. Thus, it is not necessary to adapt the current
snapping edge detection algorithm.
This patch adds the necessary code in edge-resistance.c
to special-case tiled windows and allow them to cover
1/4, 1/3 and 1/2 (horizontally) of the screen. These
values are hardcoded.
https://bugzilla.gnome.org/show_bug.cgi?id=645153
After the introduction of the possibility to resize tiled windows,
it is a sensible decision to make windows aware of their tiling
match. A tiling match is another window that is tiled in such a
way that is the complement of the current window.
The newly introduced behavior attepts to make tiling as smooth as
possible, with the following rules:
* Windows now compute their tile match when tiling and, if there's
a match, they automatically complement the sibling's width.
* Resizing a window with a sibling automatically resizes the sibling
too to be the complement of the window's width.
* It is not possible to resize below windows' minimum widths.
https://bugzilla.gnome.org/show_bug.cgi?id=645153
Now that tiled windows are resizable, the user may grow a tiled
windows until it covers the entire work area. As this makes the
window state mostly indistinguishable from maximization, avoid
subtle differences by properly maximizing the window in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=645153
Currently tiled windows are not resizable and their size is fixed
to half the screen width. Adjust the code to work with fractions
other than half, and allow users to adjust the split by dragging
the window edge that is not constrained by a monitor edge.
Follow-up patches will improve on that by resizing neighboring
tiled windows by a shared edge, and making the functionality
available to client-side decorated windows implementing the
new edge constraints protocol.
Now that the preview tile mode has been split from the window's
tile_mode property, it is much more natural to pass the requested
tile_mode to the tile() function instead of setting it externally
and calling the function to apply the state.
The existing semantics of the tile_mode property are terribly confusing,
as it depends on some other property whether it represents the requested
or current mode. Clear this up by just using separate variables for the
two. As it is unlikely that we will ever support more than one tile
preview, we can track the requested mode globally instead of adding
another per-window variable.
https://bugzilla.gnome.org/show_bug.cgi?id=645153
update_num_workspaces() is a no-op when the number of workspaces
did not actually change. That is fine, except that we still want
to initialize the _NET_NUMBER_OF_DESKTOPS hint on startup to not
break components like nautilus-desktop that rely on it.
https://bugzilla.gnome.org/show_bug.cgi?id=760651
Automatic maximization is done when a window is almost the size of the
work area of a monitor. This makes no sense to try when there is no
monitor available, so skip trying to do this when headless.
https://bugzilla.gnome.org/show_bug.cgi?id=787637
When we are headless, treat this as if the window is always not monitor
sized. This might cause windows to temporarly become redirected while
being headless, but this is harmless as when a new monitor is
connected, we'll recalculate weather it should be redirected or not.
https://bugzilla.gnome.org/show_bug.cgi?id=787637
Check that configurations where monitors are disabled are properly
used. Also test that old configurations with explicitly disabled
outputs are migrated properly.
https://bugzilla.gnome.org/show_bug.cgi?id=787629
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
When dynamic workspaces are used, we pick up an existing NUMBER_OF_DESKTOP
hint in meta_screen_init_workspaces() to properly restore workspaces
on restart. Unconditionally setting that hint to 1 *before* reading it
breaks that, and we end up shifting all windows to the first workspace.
This reverts commit 8532b10290.
https://bugzilla.gnome.org/show_bug.cgi?id=760651
Also adds a soft assert to meta_window_is_on_primary_monitor() to make
it easier to spot when callers might want to handle headless
in a certain way.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
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
For now we abuse of meta_window_get_flatpak_id not to break the APIs,
so that it's working seamlessly in gnone shell too.
Rename flatpak_id to sandboxed_app_id internally to get prepared to the future
API.
https://bugzilla.gnome.org/show_bug.cgi?id=788217
If a non-latin based keyboard layout is active, for example Cyrillic,
keybindings won't work unless we resolve the bound keysyms on a
secondary latin based layout. So, to make keybindings work on non-latin
based layouts, detect if a keymap doesn't have all of the basic latin
letters (a-z) and resolve from an additional US layout as well.
https://bugzilla.gnome.org/show_bug.cgi?id=787016
Add the infrastructure to resolve keybinding symbols from multiple
layouts. It is still unused, but will be, when the primary layout does
not have the required latin keysyms in it.
https://bugzilla.gnome.org/show_bug.cgi?id=787016
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
Make sure to call set_number_of_spaces_hint in meta_screen_new.
_NET_NUMBER_OF_DESKTOPS is required by nautilus-desktop to correctly
get the desktop workarea.
https://bugzilla.gnome.org/show_bug.cgi?id=760651
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
We would free the shortcut inhibit data only when the client destroys
its request, which is not the case when the clients itself is
destroyed, leading to a leak of the shortcut inhibit data.
Free the data on resource destruction instead, and simply destroy the
resource on destroy request.
https://bugzilla.gnome.org/show_bug.cgi?id=787568
On Wayland, the grab()/ungrab() in gtk+/gdk are wired to the shortcut
inhibitor mechanism, which in turn shows the dialog, which can take
focus away from the client window when the dialog is shown.
If the client issues an ungrab() when the keyboard focus is lost, we
would hide the dialog, causing the keyboard focus to be returned to the
client surface, which in turn would issue a new grab(), so forth and so
on, causing a continuous show/hide of the shortcut inhibitor dialog.
To avoid this issue, keep the dialog around even if the shortcut inhibit
is canceled by the client, so that the user is forced to make a choice
that we can reuse on the next request without showing the dialog again.
Instead of hiding the dialog when the shortcut inhibitor is destroyed by
the client, we simply mark the request as canceled and do not apply the
user's choice.
https://bugzilla.gnome.org/show_bug.cgi?id=787568
The brightness is about the vignette. Add a 'vignette_' prefix in order
to give more context. Keep the property name as it is, doing so we don't
break any plugin (e.g., gnome-shell).
https://bugzilla.gnome.org/show_bug.cgi?id=786618
Add the word 'vignette' in order to give some context on what the
snippets do. This will be useful later when we land other snippets
for the gradient effect.
https://bugzilla.gnome.org/show_bug.cgi?id=786618
The reverted commit seems to cause
https://bugzilla.gnome.org/show_bug.cgi?id=787240 for some reason. Lets
be safe and revert it for now, as the code freeze is just around the
corner.
This partly (it doesn't reintroduce a whitespace issue) reverts commit
dbc63430d8.
When cleaning up the display name string management, the display name
string retrieved from libwayland-server was also passed to free() on
clean up. This is invalid as the display name string ownership is not
transferred to us. Fix this by strdup:ing the string before saving it.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
Give clients (such as Xwayland) a chance to bind the wl_output global
before we continue, otherwise there is an significant risk that mutter
won't see the bind request until after the next hot plug which might
have destroyed the global object.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
This avoids updating state (such as position, size etc) when going
headless. Eventually, when non-headless, things will be updated again,
and not until then will we be able to update to a valid state.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
In order to give the clients the best chance to bind the wl_output
before we later remove it (for example on fast hot plugs or in the test
suite), flush the client sockets after creating the global.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
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
If there are no active logical monitors, don't try to dereference a
NULL one to get a preferred output winsys id. Instead just set an
invalid one.
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
