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
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
