Don't update the stack until after setting the window->transient_for
field. Updating before will cause the stack transient-for constraint to
be missing until the next time constraints are applied.
https://bugzilla.gnome.org/show_bug.cgi?id=755606
The test runner sends a "show" command to the test clients and assumes
this was enough work done by the client to enable the compositor to map
the window. Now that we wait to show a Wayland window until the first
buffer is attached (see bug 750552), we need to make sure that we attach
a buffer before assuming that we have the final stacking order.
So, to in order to continue relying on "show" to be enough to actually
show a window, let the test client wait until it has drawn the first
frame.
This makes the tests using Wayland clients test non-flaky.
https://bugzilla.gnome.org/show_bug.cgi?id=754711
When managing a non-OR window we're required by the ICCCM to behave as
if we received a ConfigureRequest which means that we must generate a
synthetic ConfigureNotify even if the window isn't moved or resized
from its current (initial) geometry.
During MetaWindow's x11/wayland split a slight behavior change for x11
windows crept in. Before the code split, MetaWindow->rect was
initialized with the X window's geometry, but now we're not
initializing MetaWindowX11Private->client_rect which causes the checks
for whether it's necessary to move/resize the window in
meta_window_x11_move_resize_internal() to tell us that we do need to
move/resize which means we do an XConfigureWindow() call and don't
send the sythetic ConfigureNotify. But since the X window isn't really
moving, the XConfigureWindow() call doesn't cause the X server to
generate a ConfigureNotify which breaks some clients such as Java's
AWT.
We can fix this by setting MetaWindowX11Privatew->client_rect for both
OR and non-OR windows. We can set buffer_rect for non-OR windows as
well to simplify the code since it will be assigned the correct value
in meta_window_x11_move_resize_internal() .
https://bugzilla.gnome.org/show_bug.cgi?id=759492
During xwayland initialization we run main loop and dispatch wayland
events, so that xwayland can initialize. If some client during this
phase connects and creates surface, mutter crashes because
it is not initialized yet. If we bind wayland socket after xwayland
is initialized and main loop is not running anymore, no client can
connect to mutter during initialization and that is what we want.
https://bugzilla.gnome.org/show_bug.cgi?id=751845
GDesktopTouchpadScrollMethod was used instead of GDesktopTouchpadClickMethod
which became visible now that the former has been removed from
gsettings-desktop-schemas.
https://bugzilla.gnome.org/show_bug.cgi?id=759304
When the touchpad is two-finger scrolling capable, always enable it.
When the touchpad only supports edge scrolling (usually older devices, and
usually smaller devices), allow disabling the edge scrolling.
This requires a newer gsettings-desktop-schemas as the scroll-method key
was removed, and the edge-scroll-enabled key added.
https://bugzilla.gnome.org/show_bug.cgi?id=759304
Wine removes the minimize func from its Motif hints on full-screen
windows, because, as the Win32 API literally says, the minimize button
is indeed not visible on full-screen windows.
Given that this code was added to prevent minimizing a panel by
accident, I don't necessarily think that it's relevant anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=758186
Unsetting it in meta_display_handle_event() will make the pointer
emulation checks fail on TOUCH_END event handlers across clutter
actors, the sequence should still be considered as pointer emulating
at that time.
As we don't have a way to hook this post clutter event handling,
instead unset/reset it lazily on the next pointer emulating TOUCH_BEGIN
event, the checks would already fail on other sequences, even if the
pointer emulating touch ended earlier. The only extra thing we need
to take care about is sequence collision, at which point it's safe to
just unset the stored sequence if its new incarnation isn't flagged/
deemed as pointer emulating.
https://bugzilla.gnome.org/show_bug.cgi?id=756754
The max potential number of logical monitors (i.e. MetaMonitorInfos)
is the number of CRTCs, not the number of outputs.
In cases where we have more enabled CRTCs than connected outputs we
would end up appending more MetaMonitorInfos to the GArray than the
size it was initialized with which means the array would get
re-allocated rendering invalid some MetaCRTC->logical_monitor pointers
assigned previously and thus ending in crashes later on.
https://bugzilla.gnome.org/show_bug.cgi?id=751638
Use the xdg_shell XML file installed by wayland-protocols instead of
our own copy. This protocol has yet to go through any unstable naming,
but since we had an outdated (though wire compatible) version, some
minor changes were needed.
https://bugzilla.gnome.org/show_bug.cgi?id=758633
Remove our own copy of the pointer gestures protocol, and us the one
installed by wayland-protocols. This also means the new fixed unstable
naming conventions are used for the new version of the protocol, which
is reflected in the change. No functional changes were made, it is only
a rename.
https://bugzilla.gnome.org/show_bug.cgi?id=758633
When running as a native compositor, we can just do that. However, the
previous code must stay for whenever it's run as a X11 client.
Additionally, the fallback switch{} that transforms clutter 1-indexed
buttons into input.h event codes had to be adapted to the change introduced
in clutter commit 83b738c0e, where the 4-7 button range is kept clear for
compatibility with the X11 backend.
https://bugzilla.gnome.org/show_bug.cgi?id=758239
On the wire, Wayland specifies the refresh rate in milliHz. Mutter sends
the refresh rate in Hz, which confuses clients, e.g. weston-info:
interface: 'wl_output', version: 2, name: 4
mode:
width: 2560 px, height: 1440 px, refresh: 0 Hz,
flags: current preferred
interface: 'wl_output', version: 2, name: 5
mode:
width: 3200 px, height: 1800 px, refresh: 0 Hz,
flags: current preferred
and xrandr:
XWAYLAND0 connected 2560x1440+3200+0 600mm x 340mm
2560x1440@0.1Hz 0.05*+
XWAYLAND1 connected 3200x1800+0+0 290mm x 170mm
3200x1800@0.1Hz 0.03*+
Export the refresh rate in the correct units. For improved precision,
perform the KMS intermediate calculations in milliHz as well, and
account for interlaced/doublescan modes.
This is also consistent with what GTK+ expects:
timings->refresh_interval = 16667; /* default to 1/60th of a second */
/* We pick a random output out of the outputs that the window touches
* The rate here is in milli-hertz */
int refresh_rate = _gdk_wayland_screen_get_output_refresh_rate (wayland_display->screen,
impl->outputs->data);
if (refresh_rate != 0)
timings->refresh_interval = G_GINT64_CONSTANT(1000000000) / refresh_rate;
Where the 'refresh_rate' given is exactly what's come off the wire.
1000000000/60000 comes out as 16667, whereas divided by 60 is ...
substantially less.
https://bugzilla.gnome.org/show_bug.cgi?id=758653
If a client only ever sets the hint on window creation we'd never pick
the value. Also, include override redirect windows since the hint is
relevant to them too.
https://bugzilla.gnome.org/show_bug.cgi?id=758544
When managing window, we queue showing the window.
Under wayland, if we commit surface quickly enough,
the showing is unqueued and commit procedure takes care
of mapping and placing the window. In the oposite case,
queue is processed before client sets all we need and
then we have wrong size of window, which leads to broken placement.
Therefore force placement in queue only if the window should already
be mapped. If it is not mapped, we don't care where it is anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=751887
On Odroid U2 (exynos4412) the drm device is not bound to pci.
Open the detection to platform device of the drm subsystem, exclusive of
control devices.
https://bugzilla.gnome.org/show_bug.cgi?id=754911
Failing to initialize Clutter isn't something it's useful to report
into automatic bug tracking systems or get a backtrace for - in fact,
the most common case is that DISPLAY is unset or points to a
non-existent X server. So simply exit rather than calling g_error().
https://bugzilla.gnome.org/show_bug.cgi?id=757311
g_error() is the wrong thing to do when, for example, we can't find the
DRM device, since Mutter should just fail to start rather than reporting
a bug into automatic bug tracking systems. Rather than trying to decipher
which errors are "expected" and which not, just make all failure paths
in meta_launcher_new() return a GError out to the caller - which we make
exit(1).
https://bugzilla.gnome.org/show_bug.cgi?id=757311
The qxl kms driver has a bug where the cursor gets hidden
implicitly after a drmModeSetCrtc call.
This commit works around the bug by forcing a drmModeSetCursor2
call after the drmModeSetCrtc calls.
This is pretty hacky and won't ever go upstream.
https://bugzilla.gnome.org/show_bug.cgi?id=746078
The default theme started to use them in GTK+ commit 371f50, so
we need to update the style contexts to keep matching the style
of client-side decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=757101
Ubuntu ships a patch in the X server that makes the group switch
keybindings only work on key release, i.e. the X server internal group
locking happens on key release which means that mutter gets the
XKB_KEY_ISO_Next_Group key press event, does its XLockGroup() call
with a new index and then, on key release, the X server moves the
index further again.
We can work around this without affecting our behavior in unpatched X
servers by doing a XLockGroup() every time we're notified of the
locked group changing if it doesn't match what we requested.
https://bugzilla.gnome.org/show_bug.cgi?id=756543
In a HiDPI environment, all gtk+ apps will report a 2 x 2 size
increment to avoid odd size. But that does not mean they are
resizing in cells like terminals, so they resize popup should
not be shown.
Ideally, we should ignore <= scale x scale increments, but in
practice scale is 1 or 2, and even in a lo-dpi setting a 2 x 2
increment makes little sense so let's keep the patch simple.
https://bugzilla.gnome.org/show_bug.cgi?id=746420
Right now we just check the pointer serial, so the popup will be
immediately dismissed if the client passes a serial corresponding to
another input device.
Abstract this a bit further and add a meta_wayland_seat_can_popup() call
that will check the serial all input devices. This makes it possible to
trigger menus through touch or keyboard devices.
https://bugzilla.gnome.org/show_bug.cgi?id=756296
We might get modes in XRROutputInfos that aren't in the
XRRScreenResources we get earlier. This always seems to be transient,
i.e. when it happens, the X server will usually send us a follow up
RRScreenChangeNotify where we then get a "stable" view of the world
again.
In any case, when these glitches happen, we end up with NULL pointers
in the MetaOutput->modes array which makes us crash later on. This
patch ensures that doesn't happen.
https://bugzilla.gnome.org/show_bug.cgi?id=756660
If we immediately dismiss the popup, we still need to set the
surface->xdg_popup pointer field in order for the destructor to
properly clean up the state. Not doing this may cause a crash if the
xdg_popup resource that was immediately dismissed is destoryed after
wl_surface during client destruction.
https://bugzilla.gnome.org/show_bug.cgi?id=756675
We have been ignoring those buttons since 3.16 after they had been
broken in the default theme for a couple of versions. As nobody
appears to miss them, it's time to remove them for good.
We use a single style context to draw titlebar buttons, updating
its state according to each button's prelight state as necessary.
This assumes that the original state is neither ACTIVE nor PRELIGHT,
which means we need to reset the state after drawing to avoid
propagating the state of the last-drawn button.
Displaying all Wayland windows with the XID of 0x0 makes it hard
to figure out what is going on ... use the recently-added
window->stamp to show Wayland windows as W1/W2/W3...
Some windows, like Chromium and Steam, are technically CSD in that they
don't want a system titlebar and draw their own, but we should still
provide them with a shadow.
Both Window and XSyncCounter are XIDs which on 64 bit X clients are 8
bytes wide. But the values on the wire are 32 bit so, for these types,
we always copy 4 bytes into results->prop. As such copying them out
with a cast such as *(Window *) means that we are actually reading 8
bytes which depending on whether the higher addressed 4 bytes are zero
means that sometimes this works while others it gives us a bogus
value.
https://bugzilla.gnome.org/show_bug.cgi?id=756074
We don't have any way of knowing what the intended size of a XWayland
cursor is supposed to be, so lets do what we do with regular XWayland
surfaces and don't scale them. The result is that cursor sprites of
HiDPI aware X11 clients will show correctly, but non-aware clients may
have tiny cursor sprites.
https://bugzilla.gnome.org/show_bug.cgi?id=755099
Each keyboard focus change ends up calling the MetaWaylandDataDevice
counterpart, we don't need though to notify the current selection
again. In order to fix this, keep track of the current client, and
only emit the relevant signals when the focus switches to another
client.
The situations where wl_data_device.selection were emitted during
focus changes between surfaces of the same client was inocuous most
of the times, although it's prone to inducing confusing behavior
on context menu clipboard actions, as the closing menu triggers a
focus change, which triggers a whole new wl_data_offer being created
and given on wl_data_device.selection, at a time where there's already
ongoing requests on the previous data offer.
https://bugzilla.gnome.org/show_bug.cgi?id=754357
If the transfer is cancelled, the X11SelectionData will be cleared from
the MetaSelectionBridge, although x11_data_write_cb() was invariably
expecting it to be non-NULL.
If the write was cancelled, all the actions done in x11_data_write_cb()
are moot, so just return early. If there's other errors happening
(eg. "connection closed" if the target client happens to crash), we
should still attempt at clearing the data anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=754357
When committing a toplevel surface we might no longer have a MetaWindow
associated with it. The reason may vary but some are: a popup was
dismissed, the client attached and committed a NULL buffer to a
wl_surface with the wl_shell_surface role, the client committed a
buffer to a wl_surface which previously had an toplevel window role
which extension object was destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=755490
If the drag dest surface suddenly disappears, we may find ourselves
processing an XdndPosition message that was sent before the X11 drag
source had an opportunity to find out.
In that case mutter does know, so double check before processing the
messages.
We try to translate the atom with its corresponding mimetype both back
and forth, which actually breaks if the X11 client chose to announce the
mimetype atom. To do the translation properly, keep track on whether the
source announced the UTF8_STRING atom, and reply back with this only if
that happened.
If the wayland surface isn't available yet when we process the
WL_SURFACE_ID ClientMessage, we schedule a later function to try the
association again after we get a chance to process wayland requests.
This works fine except on cases where the MetaWindow already had a
previous surface attached (i.e. when the xwindow is reparented) since
we only break the existing association on the later function which
means that when processing the old surface's destruction we destroy
the MetaWindow and cancel the pending later function leaving us
without a MetaWindow and an invisible surface.
Fix this by detaching the old surface as soon as possible so that the
MetaWindow survives.
https://bugzilla.gnome.org/show_bug.cgi?id=743339
The saved rect is used to restore a saved window size. We need to
update this when the window is moved to a monitor with different scale,
so that if we unmaximize a window which was moved to a different
monitor while maximized (for example when unplugged) will restore to
the correct size.
https://bugzilla.gnome.org/show_bug.cgi?id=755097
When a window is moved across monitors with different scales, its
rectangle is scaled accordingly. We also need to scale the
unconstrained_rect rectangle, so that moving a window via
meta_window_move_resize() which uses the unconstrained_rect.
https://bugzilla.gnome.org/show_bug.cgi?id=755097
Calling queue_redraw() in _force_update() is not needed because
update_cursor() will do this when needed, i.e. when switching between
hardware cursor and texture cursor, or when drawing with texture cursor.
There is also no need to force _native_force_update() because
update_cursor() will cover this as well when needed. When not changing
cursor but only the gbm_bo, the "dirty" boolean on the gbm_bo will
trigger a redraw.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
This commits refactors cursor handling code and plugs in logic so that
cursor sprites changes appearance as it moves across the screen.
Renderers are adapted to handle the necessary functionality.
The logic for changing the cursor sprite appearance is done outside of
MetaCursorSprite, and actually where depends on what type of cursor it
is. In mutter we now have two types of cursors that may have their
appearance changed:
- Themed cursors (aka root cursors)
- wl_surface cursors
Themed cursors are created by MetaScreen and when created, when
applicable(*), it will extend the cursor via connecting to a signal
which is emitted everytime the cursor is moved. The signal handler will
calculate the expected scale given the monitor it is on and reload the
theme in a correct size when needed.
wl_surface cursors are created when a wl_surface is assigned the
"cursor" role, i.e. when a client calls wl_pointer.set_cursor. A
cursor role object is created which is connected to the cursor object
by the position signal, and will set a correct texture scale given what
monitor the cursor is on and what scale the wl_surface's active buffer
is in. It will also push new buffers to the same to the cursor object
when new ones are committed to the surface.
This commit also makes texture loading lazy, since the renderer doesn't
calculate a rectangle when the cursor position changes.
The native backend is refactored to be triple-buffered; see the comment
in meta-cursor-renderer-native.c for further explanations.
* when we are running as a Wayland compositor
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Use a specialized cursor renderer when running as a nested Wayand
compositor. This new renderer sets an empty X11 cursor and draws the
cursor as part of the stage using the generic cursor renderer drawing
path.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Make a surface roles into objects with vfuncs for things where there
before was a big switch statement. The declaration and definition
boilerplate is hidden behind C macros.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
If a surface doesn't have a role, the compositor will not know how, if
or when it will be painted. By adding it to the compositor frame
callback list, the compositor will respond to the client that the
surface has been drawn already which might not be true.
Instead, queue the frame callback in a list that is then processed when
the surface gets a role assigned. The compositor may then, given the
role the surface got, queue the frame callback accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
Being a "XWayland window" should be considered equivalent to a role,
even though it is not part of any protocol anywhere. The commit doesn't
have any functional difference, but just makes it clear that an
wl_surface managed by XWayland have the same type of special casing as
surface roles as defined by the Wayland protocol.
As the semantics are more explicit given the role is defined, a comment
explaining why the semantics need to be how they are was added.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
If a queued event is being processed after the surface is
destroyed, trying to access the window associated with the surface
will lead to a segmentation fault.
This patch avoids the crash by first checking if the surface is not null.
https://bugzilla.gnome.org/show_bug.cgi?id=754715
This fixes build error caused by commit 614d6bd. We can simply remove
the usage of meta-wayland.c functions in non-wayland build because
META_BACKEND_X11_MODE_NESTED is only used in wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=753948
Use a better name, use GNOME conventions for error handling, open code the
client error reporting and send the error to the correct resource.
wl_subcompositor doesn't have a role error yet, so continue use some
other error. The only effect of this is error received in the client will
be a bit confusing, it will still be disconnected.
https://bugzilla.gnome.org/show_bug.cgi?id=754215
Older GCC only allows "for (int i" in explicit c99 mode - there's probably
no reason that we can't enable that, but avoiding the construct for
a fast fix.
If the user Alt-Tabs out of the window, we will be left thinking
the Alt key is still pressed since we don't see a release for it.
Solve this and other related issues for the nested X11 compositor
by selecting for KeymapStateMask which causes a KeymapNotify event
to be sent after each FocusIn, and when we get these events, update
the internal XKB state and send any necessary modifiers events to
clients.
https://bugzilla.gnome.org/show_bug.cgi?id=753948
Some backgrounds don't fully fill the screen. For those backgrounds
it's important to paint a color behind them to fill in the gaps.
This commit checks whether or not the background image textures take
up the entire monitor, and in the event they don't, draws a color
behind them (such as it would do if the background were
translucent).
https://bugzilla.gnome.org/show_bug.cgi?id=754476
meta_background_get_texture only draws the bottom image texture
if
1) the blend factor leaves the top image translucent
or
2) the top image is translucent from alpha
The latter case doesn't actually matter since we're using REPLACE
on the top image texture.
This commit drops the unnecessary check for the second case and
applies demorgans law to the conditional for clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=754476
There were lots of code handling the native renderer specific cases;
move these parts to the renderer. Note that this causes the X11 case to
always generate the texture which is a waste of memory, but his
regression will be fixed in a following commit.
The lazy loading of the texture was removed because it was eventually
always loaded anyway indirectly by the renderer to calculate the
current rect.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
There is nothing special about the private API which only consists of
getters for renderer specific backing buffer. Lets them to the regular
.h file and treat them as part of the normal API.
https://bugzilla.gnome.org/show_bug.cgi?id=744932
When a client binds an incompatible version, we should terminate it.
This check should only be there for the unstable version, as once it is
declared stable and renamed, future versions will be backward compatible.
https://bugzilla.gnome.org/show_bug.cgi?id=753855
Before, it used to be in the screen, but now,
meta_cursor_reference_from_theme can never fail. Move it to where we
load the images from the cursor name.
meta_wayland_pointer_get_client_pointer() may be called when the
MetaWaylandPointer as been already shut down, so the hash table will be
NULL at that moment.
Since mutter has two X connections and does damage handling on the
frontend while fence triggering is done on the backend, we have a race
between XDamageSubtract() and XSyncFenceTrigger() causing missed
redraws in the GL_EXT_X11_sync_object path.
If the fence trigger gets processed first by the server, any client
drawing that happens between that and the damage subtract being
processed and is completely contained in the last damage event box
that mutter got, won't be included in the current frame nor will it
cause a new damage event.
A simple fix for this would be XSync()ing on the frontend connection
after doing all the damage subtracts but that would add a round trip
on every frame again which defeats the asynchronous design of X
fences.
Instead, if we move fence handling to the frontend we automatically
get the right ordering between damage subtracts and fence triggers.
https://bugzilla.gnome.org/show_bug.cgi?id=728464
The global wl_pointer_gestures object is now created, effectively
bridging pinch/swipe gestures with clients, so they're now
accessible to clients implementing the protocol.
Instead of moving around all the bound pointer resources for a client
when changing focus, keep all the resources bound by a client in a per
client struct, and track the focus by having a pointer to the current
active pointer client struct instance.
This will simplify having wl_pointer extensinos sharing the pointer
focus of the wl_pointer by only having to add them to the pointer
client.
https://bugzilla.gnome.org/show_bug.cgi?id=744104
While we shouldn't normally receive crossing events for any windows
except the stage when running nested, we do in case we hold a pointer
grab - just ignore those events instead of taking down the user's
session.
The spec says:
"A server should avoid signalling the frame callbacks if the surface is not
visible in any way, e.g. the surface is off-screen, or completely obscured
by other opaque surfaces."
We actually do have the information to do that but we are always calling
the frame callbacks in after_stage_paint. So fix that to only call when
when the surface gets drawn on screen.
https://bugzilla.gnome.org/show_bug.cgi?id=739163
The compositor maintains a ring of shared fences with the X server in order to
properly synchronize rendering between the X server and the compositor's GPU
channel. When all of the fences have been used, the compositor needs to reset
one so that it can be reused. It does this by first waiting on the CPU for the
fence to become triggered, and then sending a request to the X server to reset
the fence.
If the compositor's GPU channel is busy processing other work (e.g. the desktop
switcher animation), then the X server may process the reset request before the
GPU has consumed the fence. This causes the GPU channel to hang.
Fix the problem by having the compositor's GPU channel trigger its own fence
after waiting for the X server's fence. Wait for that fence on the CPU before
sending the reset request to the X server. This ensures that the GPU has
consumed the X11 fence before the server resets it.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=728464
If GL advertises this extension we'll use it to synchronize X with GL
rendering instead of relying on the XSync() behavior with open source
drivers.
Some driver bugs were uncovered while working on this so if we have
had to reboot the ring a few times, something is probably wrong and
we're likely to just make things worse by continuing to try. Let's
err on the side of caution, disable ourselves and fallback to the
XSync() path in the compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=728464
If we can't put up a popup because grabbing the pointer fails we
immediately dismiss the popup but the client might have made requests
already, in particular it might have commited the surface and in that
case we should ignore it.
https://bugzilla.gnome.org/show_bug.cgi?id=753237
When a client sets an input region or a opaque region to NULL, it
should still be considered a change to the corresponding region on the
actor. This patch makes sure this state is properly forwarded.
https://bugzilla.gnome.org/show_bug.cgi?id=753222
This was introduced in commit c6793d477a
to prevent window self-maximisation. It turns out that that bug seems
to have been fixed meanwhile in a different way since the reproducer
in https://bugzilla.gnome.org/show_bug.cgi?id=461927#c37 now works
fine with this special handling removed.
In fact, failing to set window->fullscreen immediately when loading
the initial set of X properties causes us to create a UI frame for a
window that sets _NET_WM_STATE_FULLSCREEN.
This, in turn, might cause the fullscreen constrain code to fail if
the window also sets min_width/min_height size hints to be the monitor
size since the UI frame size added to those makes the rectangle too
big to fit the monitor. If the window doesn't set these hints, we
fullscreen it but the window will get sized such that the UI frame is
taken into account while it really shouldn't (see the reproducer
above).
https://bugzilla.gnome.org/show_bug.cgi?id=753020
Since commit 14b0a83f64 we store the
main window monitor instead of computing it every time. This means
that we must now ensure that it's updated before trying to use it
which we do from meta_screen_resize_func() or else we'll crash on an
assertion later on when removing a monitor:
assertion failed: (which_monitor < workspace->screen->n_monitor_infos)
https://bugzilla.gnome.org/show_bug.cgi?id=752674
Some monitors return a bunch of bytes on their display descriptor
which aren't valid utf8 and thus we fail to serialize them later on
for the DisplayConfig DBus API.
Let's fall back to the stringified product code and serial number in
that case.
https://bugzilla.gnome.org/show_bug.cgi?id=752673
There's a chance the icon will be animated, so store the XcursorImages
instead of the individual XcursorImage, and handle that as a nimages=1
special case.
API to "tick" a cursor animation, and retrieve current frame timing
information has been added.
https://bugzilla.gnome.org/show_bug.cgi?id=752342
They otherwise fall through paths that enable bypass_clutter, this
is necessary so they can be picked by captured-event handlers
along the actor hierarchy.
https://bugzilla.gnome.org/show_bug.cgi?id=752248
When placing a popup and the legacy transient wl_shell_surface surfaces,
take the current scale of the window into account. This commit doesn't
fix relative positioning in case a window scale would change, but since
the use case for relative positioning is mostly popups, which would be
dismissed before the parent window would be moved, it should not be that
much of a problem.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
