This prevents issues from happening when processing Enter/Leave events
while in another kind of grab op like a Wayland popup or resizing a
window.
This can't ever really happen except outside of a race condition,
with the X server, since we won't ever pass input events to the
X server in any of these cases, but it can't hurt to be more correct
about what the intended operation is.
GTK+ focuses its own windows with RevertToParent, which means that when
a GTK+ CSD window is destroyed, the X server will set the focus back to
the root window. The event stream that we is an UnmapNotify followed by
a FocusOut event. Our own UnmapNotify-handling code unmanages the window
and forcibly changes the focus to the next default window in the stack.
Since UnmapNotify events don't come with timestamps, we query for one,
and set the window focus using that.
But there's *still* a FocusOut event in the stack, with an older
timestamp and serial than our own focusing. We see this, throw it out
since it's older than the most recent focus, but then our own code that
notices the root has been focused kicks in and tries to focus the
default window... using a timestamp older than our most recent focusing.
meta_display_sanity_check_timestamps notices this, and (rightly so)
puts a warning in our face, telling something is awry.
Only let our workarounds kick in when the event is new enough, otherwise
our code will get confused over old events.
This stops the:
Window manager warning: last_focus_time (367917173) is greater than comparison timestamp (367917170). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around...
warning spam when closing a CSD window.
The last_sent size is effectively what size we should send in configure
requests where the size hasn't changed. Thus, if an app commits a new
size, we need to make sure we respect it and don't reconfigure it with
a size it wasn't expecting when the state changes.
This fixes apps being sent a configure event with 0, 0 on startup,
which was confusing Clutter into displaying a 0x0 viewport.
Restacking the frame for a window while unmanaging the window is
harmless, but for undecorated (in particular, client-side-decorated)
windows, this causes problems because the window is typically
destroyed by the client immediately after withredrawing the window.
Skip windows flagged as being unmanaged when assembling the new
stack and when comparing the old order to the new stack.
Add a stacking test for this.
Windows can be freed at some point after they are unmanaged - because
there is an effect in progress, because a language binding is holding
a reference. Therefore, we need to clean up the later to associate
the xwayland and wayland windows deterministically in an "unamanaged"
handler.
https://bugzilla.gnome.org/show_bug.cgi?id=736694
g_idle_add() makes no guarantee about when it will be run - if Mutter
is busy drawing and blocking glXSwapBuffers() it could happen only
minutes later. Use meta_later_add (META_LATER_BEFORE_REDRAW) instead -
this will deterministically be run after the Wayland socket is read
from but before the next frame is painted.
https://bugzilla.gnome.org/show_bug.cgi?id=736694
We shouldn't scale the cursor size in mutter we g-s-d exports
the correct size on hidpi so use gtk-cursor-theme-size.
This way we also catch changes on resolution updates.
https://bugzilla.gnome.org/show_bug.cgi?id=729337
This reverts commit 4fe66ce0a9.
This is wrong ... we should not scale the cursor size but read
the cursor xsettings that gets exported by gsd. Also this won't update on
resolution changes.
https://bugzilla.gnome.org/show_bug.cgi?id=729337
When restacking the last window alone, we would trigger this off-by-one
error. This would throw us off the end of the array, causing lower_below
warnings for nonsensical values.
Since the last window already is lowered below everything else, we
shouldn't need to lower it.
The merge of the commit af46ef3b 'meta_window_new: clean up error handling'
to the wayland branch accidentally added an extra call to meta_error_trap_push(),
meaning that we leaked one level of error traps for each new window.
Fixes warning:
Gdk-WARNING **: XSetErrorHandler() called with a GDK error trap pushed.
https://bugzilla.gnome.org/show_bug.cgi?id=736589
When the screen resizes, we get a configure event for the composite overlay
window - don't pass that to MetaStackTracker, since the COW isn't in the
stack.
Fixes warning:
mutter-WARNING **: STACK_OP_RAISE_ABOVE: window 0x65 not in stack
We have a quite accurate view of the X stack, so there's no good reason to ask
the X server to do restacking that has no effect. (Restackings that have no
effect on either X windows or Wayland windows were generally optimized out in
the synchronization code, but in other cases like moving an X window that is
only beneath Wayland windows to the top of the stack we would make such
requests.)
Removing such requests:
- Is a small efficiency win in itself
- Allows us to immediately go ahead and apply Wayland changes to the verified stack
- Prevents queued Wayland changes piling up waiting for an X event that will never
be received, since the X server will not send confirmation of no-op restacks.
Since such operations may still have an effect on the relative stacking of X
and Wayland windows, we need to continue applying them to the local stack.
https://bugzilla.gnome.org/show_bug.cgi?id=736559
Now that all actual stack shuffle is handled inside stack-tracker.c, we can make
meta_stack_tracker_record_[raise_above/lower_below] internal to that file and
remove the unused meta_stack_tracker_record_lower().
https://bugzilla.gnome.org/show_bug.cgi?id=736559
stack.c:sync_stack_to_xserver had both code for assembling the desired stack, and
code for enforcing the desired stack on the actual stack of X and Wayland windows;
the latter part is properly the domain of stack-tracker.c; moving the code to
apply the stack there both simplifies it and keeps stack.c more manageable.
https://bugzilla.gnome.org/show_bug.cgi?id=736559
There was still code in stack.c to handle skipping override-redirect windows,
but since quite a while ago, meta_stack_add() is not called for OR windows
since they are outside our stacking control. Add an assertion and remove
unnecessary code.
https://bugzilla.gnome.org/show_bug.cgi?id=736559
stack.c kept it's own record of the last stacking it requested, so that
restacking could be done with minimal moves, but we already have a better
view of the stacking order with the stack tracker, so use that instead.
This allows eliminating the special case for the first restack.
https://bugzilla.gnome.org/show_bug.cgi?id=736559
Since MetaStackTracker is the code that knows about the current X stacking order
and the relationship between X windows and Wayland windows, it's cleaner to
encapsulate stack manipulation in MetaStackTracker rather than have the calling
code make the X calls and only call into MetaStackTracker to inform it about
the changes.
https://bugzilla.gnome.org/show_bug.cgi?id=736559
The step where we requery the stacking order from the server than combine
it in an arbitrary fashion with Wayland windows can be eliminated by observing
that we are the final authority for Wayland window stacking - so if we
apply each X event that we receive from the X server to our stack in a
way that leaves the X windows ordered in the same way as on the server,
and apply events that we have stored locally in a way that doesn't affect
the ordering of X windows, than we have a fully correct ordering of windows.
Ordering this in the order of first applying the X event and then applying the
local portion also means that as long as we had an up-to-date view of the X
stack the composite operation will be identical to what was requested.
https://bugzilla.gnome.org/show_bug.cgi?id=736559
Putting X windows and pointers to MetaWindows into a union had a number of
problems:
- It caused awkward initialization and conditionalization
- There was no way to refer to Wayland windows (represented by
MetaWindow *) in the past, which is necessary for the MetaStackTracker
algorithms
- We never even cleaned up old MetaStackWindow so there could be
records in MetaStackWindow pointing to freed MetaWindow.
Replace MetaStackWindow with a 64-bit "stack ID" which is:
- The XID for X Windows
- a "window stamp" for Wayland windows - window stamps are assigned
for all MetaWindow and are unique across the life of the process.
https://bugzilla.gnome.org/show_bug.cgi?id=736559
Add a basic framework for tests of Mutter handling of client behavior;
mutter-test-runner is a Mutter-based compositor that forks off instances
of mutter-test-client and sends commands to them based on scripts.
The scripts also include assertions.
mutter-test-runner always runs in nested-Wayland mode since the separate
copy of Xwayland is helpful in giving a reliably clean X server to
test against.
Initially the commands and assertions are designed to test the stacking
behavior of Mutter, but the framework should be extensible to test other
parts of client behavior like focus.
The tests are installed according to:
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
if --enable-installed-tests is passed to configure. You can run them
uninstalled with:
cd src && make run-tests
(Not in 'make check' to avoid breaking 'make distcheck' if Mutter can't be
run nested.)
https://bugzilla.gnome.org/show_bug.cgi?id=736505
For reasons related to interaction between the GTK+ CSS code and the
frame sync protocol, the dummy GtkWindow that MetaUI creates to track
theme properties has to be mapped and have MetaWindow associated with it.
Add a private function so that the test framework can filter this out.
https://bugzilla.gnome.org/show_bug.cgi?id=736505
Add a private hook for the test framework to get XSyncAlarmEvent events -
this will be used to implement XSyncCounter based synchronization
so that the test framework can deterministically wait until Mutter
has seen actions performed by an X11 client.
https://bugzilla.gnome.org/show_bug.cgi?id=736505
Add private functions for the test framework to use to find out the
wayland and x11 display names, so they can set up the environment for
children.
https://bugzilla.gnome.org/show_bug.cgi?id=736505
We'll need this in the wayland frontend to send a modifiers event to
clients.
Note that on X11 this isn't needed because key events include the
group index encoded in modifier state. If we ever want to make the
wayland frontend work with the X11 backend we'll handle it then.
https://bugzilla.gnome.org/show_bug.cgi?id=736433
According to the documentation, the method returns "whether the X window
that the actor was displaying has been destroyed" - that is very much
true when we delay the actual actor destruction for a destroy animation,
so update the method accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=735927
When a window is destroyed, the corresponding actor may still be
kept around for the destroy effect. But as the actor is removed
from the compositor's stack list immediately, the compositor will
always stack it above "valid" window actors - this is not what we
want, so only update the compositor's list when the actor is
actually destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=735927
Setting the scaling factor immediately after calling clutter_init()
avoids creating the stage at one size, then later resizing it to
a different size.
https://bugzilla.gnome.org/show_bug.cgi?id=736279
In the case of a nested Wayland compositor inside an X session,
Clutter is managing the toplevel window size, so don't call
XResizeWindow on it - this will confuse Clutter and get the size
and the hints out of sync on the toplevel window.
https://bugzilla.gnome.org/show_bug.cgi?id=736279
It's possible for a released pointer to have repick / set_focus on it as
part of sync_input_focus. When the pointer is actually re-init'd, it
will memset 0, which can cause corruption as our destroy listener has
already been added.
Released devices should be idempotent, so just make sure method calls on
them don't have any effect.
We can enter weird states where get_default_window is called during
window unmanagement, before the window has been fully removed from
the stack. Make sure these windows are *never* returned from
get_default_window, as focusing them can cause an assertion fail,
or worse.
If we add device 2, then add device 254, then remove device 254, then
the max device ID will be 253. Scan through all the devices again on
removal to calculate a new max device ID.
Rather than have the DBus code control this, move this into
MetaBackend. This also lets us destroy idle monitors when appropriate,
rather than leaking them forever.
Not having a paint volume causes every single paint to turn into
full-stage redraw, since otherwise culling won't properly work.
Since we don't paint outside of our allocation, just use the simple
default implementation, but also return TRUE inside it.
Make the vignette options properties so they can be animated;
modify the function-call API for meta_background_actor_set_vignette()
to correspond more closely to the 3 properties.
https://bugzilla.gnome.org/show_bug.cgi?id=735637
Without GLSL, we didn't apply the vignetting, which not only made the
background uniform in color, it made it much lighter. Adjust for this
and make the average brightness with the vignette effect the same
with or without GLSL.
https://bugzilla.gnome.org/show_bug.cgi?id=735637
The old requirement that multiple MetaBackgroundActor objects be
layered on top of each to produce blended backgrounds resulted in
extremely inefficient drawing since the entire framebuffer had
to be read and written multiple times.
* Replace the MetaBackground ClutterContent with a plain GObject
that serves to hold the background parameters and prerender
textures to be used to draw the background. It handles
colors, gradients, and blended images, but does not handle
vignetting
* Add vignetting to MetaBackgroundActor directly.
* Add MetaBackgroundImage and MetaBackgroundImageCache to allow
multiple MetaBackground objects to share the same images
By removing the usage of ClutterContent, the following optimizations
were easy to add:
Blending is turned off when the actor is fully opaque
Nearest-neighbour filtering is used when drawing 1:1
The GLSL vignette code is slightly improved to use a vertex shader
snippet for computing the texture coordinate => position in actor
mapping.
https://bugzilla.gnome.org/show_bug.cgi?id=735637
The old check for using NEAREST by checking clutter_actor_is_in_clone_paint()
and meta_actor_is_untransformed (actor) doesn't work properly since
clutter_actor_is_in_clone_paint() does not look at ancestors of the
actor; it only applies to a direct clone of the actor. Using
meta_actor_painting_untransformed() allows us to check exactly what we
care about rather than using tricky approximations.
https://bugzilla.gnome.org/show_bug.cgi?id=735632
The painting_untransformed() function in MetaWindowGroup is useful
elsewhere, in particular if we want to check whether we can avoid
bilinear filtering when painting a texture 1:1.
https://bugzilla.gnome.org/show_bug.cgi?id=735632
Clutter events include the layout index codified into modifier_state,
unlike XI2 device events, which means that we need to mask it out so
that we can match successfully.
A lot of applications assume that the window is fully positioned when it
gets the MapNotify, especially simple applications. Make sure that the
window is only mapped through the calc_showing logic.
meta_surface_actor_is_argb32 assumes that lack of stex means that a window is
ARGB32. When we unredirect a window we detach the texture so we end up without
a texture. Given that should_unredirect returns FALSE when a window is argb32,
we know that this window is indeed not ARGB32.
Returing TRUE in that case causes us to flip between redirected and
unredirected on every paint.
So fix that by returning FALSE in that case.
A wl_surface may have a wl_subsurface interface, but no buffers attached
yet, even though the geometry calculation code for surfaces/subsurfaces
assumes everything has already a buffer.
Just skip subsurfaces that don't have a buffer, those can't be set
a geometry yet, and right now it's crashing accessing the texture from
the NULL surface->buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=735452
When the blended region was empty, meaning we didn't have to paint
anything blended -- the case for an app update -- was drawing the
entire window blended, because of a think-o in the complex and
complicated logic.
Fix this so that we don't draw anything for the blended region when
empty.
O-R windows appear in workspace->windows, which aren't relocatable,
so we can't simply check if the workspace is empty after relocating
all normal windows, since those windows remain.
Make sure that the only windows we have are those that are
on_all_workspaces.
region first
If we're going to render the entire texture blended, then don't bother
painting the unblended stuff, since we're just going to draw on top
anyway.
We indeed call this function if we're not an X11 compositor, but in this
case we're simply calling it to say that we have no cursor overlay. Make
sure not to assert fail in this case.
This makes it so that MetaSurfaceActorWayland is effectively just a
wrapper actor around MetaShapedTexture with some extra scaling. I think
the MetaSurfaceActor subclassing was a bad idea -- we really should have
these abstractions in much higher levels in the stack than the
compositor.
It doesn't make sense to update it in the surface actor. It's also
theoretically wrong to update the buffer's texture on surface commit,
too, because it's buffer state, not surface state, but I don't think
there's any place we use a wl_buffer without a wl_surface.
This is bad behavior, and can also cause us to get in an infinite loop
if an OR window is mapped and unmapped in quick succession. This
sequence causes a MapNotify followed by an UnmapNotify, and when
processing the events, we'll call XMapWindow, XUnmapWindow, which will
put another set of MapNotify, UnmapNotify events in our queue, which we
then process by calling XMapWindow, XUnmapWindow, and so it goes
forever, or at least some scheduler uncorks us by making us call
XMapWindow when the window is already mapped, or XUnmapWindow when the
window is already unmapped.
We can stop this madness by simply making sure never to call neither
XMapWindow or XUnmapWindow on OR windows, which is the correct thing to
do anyway.
This was the original intention, but it was thought to be easier
to mark this as a combination of all directions. It turned out to
instead cause subtle bugs since code that blindly checked & DIR_WEST or
similar turned out to get it wrong when it was UNKNOWN, so just make
it an explicit flag.
This fixes the cursor appearing in the wrong place when starting a
keyboard resize.
We commonly used the generic, undetailed signal 'changed' to track
changes to preferences. Since we crash on unknown preference types,
this can be dangerous if somebody adds a new setting that has a
type we're unfamiliar with, and something else changes it.
Instead of crashing, just fizzle out doing nothing.
In gnome-shell, we have a feature where the user can unmaximize windows
by dragging them from the panel above the window. With accurate
anchoring, this looks really weird as the cursor is now "detached" from
the window. Detect this case and put the cursor in the middle of the
window titlebar instead.
This seems to be more accurate with what we currently see in
GNOME. Without having the app expose this information to us, it might be
a better idea to use the default frame style for this information instead.
The cursor was anchored wrongly when trying to unmaximize windows from
dragging them from the top of the screen because of a few think-o's and
some code that forgot to be updated when we moved to the frame rect
coordinate system.
The cursor is still offset for windows that start dragging from the top
panel. This is technically correct, but looks wrong. We'll fix this in
the next commit.
RandR's QueryOutputProperty request makes the incredible decision of
throwing a BadName if you pass a property that doesn't exist, which
means that trying to check if a property exists is a royal pain when
using Xlib.
XCB's interface is much more friendly about errors and not having global
state and things like that, so use that instead to query our backlight
property.
If the property doesn't exist, a BadName error will be generated. This
is a terrible API, but it's what we're stuck with. Use
RRGetOutputProperty instead.
The initialization sequence before was quite icky, initializing Clutter
in a few different places depending on what was going on.
Put that all back into main.c
Before, we were using the root window coordinates of the client window,
rather than the toplevel frame window. This caused various Java programs
and programs like VirtualBox and WINE to get confused about where their
window actually is, and make bad ConfigureRequests when trying to
position their windows in the future.
Remove the mass of code here by just using window->rect.
This removes our Xwayland dependency in the native path. The direct
grabs are still there for the X11 backend and are a bit disgusting,
but that's OK. We can refactor it out later.
This introduces some pretty lousy hackery because it depends on
https://github.com/xkbcommon/libxkbcommon/pull/10 , and I really
don't want to wait on that to squash this dep.
Now that the internal mutter bindings and gnome-shell stopped using
META_KEY_BINDING_REVERSES, and after moving the 'adding shift reverses
the keybinding action' logic to gnome-control-center, we can remove
META_KEY_BINDING_REVERSES from mutter.
Plugin API is broken as this constant is removed from the exported
headers. ABI is broken as using this flag is now a noop.
https://bugzilla.gnome.org/show_bug.cgi?id=732385
Currently the bindings for {switch,cycle}.* actions are created with the
META_KEY_BINDING_REVERSES flag so that <shift>+binding triggers the
reverse action. However, gnome-control-center does not know about this
kind of implicit bindings, and, for example, cannot warn when the user
tries to setup a conflicting <shift>+xxx binding.
These backward <shift> bindings are being explicitly set in
gsettings-desktop-schemas, so the META_KEY_BINDING_REVERSES annotation
can be removed for them from mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=732385
MetaKeyBinding can be marked as being reversed
(META_KEY_BINDING_IS_REVERSED), but MetaKeyHandlerFunc callbacks
cannot check whether this flag was set or not on the MetaKeyBinding
which triggered the callback.
https://bugzilla.gnome.org/show_bug.cgi?id=732295
The existing workspace management code is quite hairy, with plenty of
logic inline in all of window.c, workspace.c, and screen.c, making it
hard to understand or make changes to, since you might forget to change
several of the other places the code was around.
Rewrite the internal workspace management logic so that it's
centralized and all in window.c. Document the invariants we need to
maintain, and ensure that these invariants are properly kept, with
asserts in various places.
Extensive testing on gnome-shell did not bring up any issues, and this
is a considerable cleanup.
This will be used to replace some of the hooks that are used to call
into window.c, so that the workspace index property is properly kept up
to date.
We can't name the property "index" since it causes conflicts with the
meta_workspace_index method. This should really be called
meta_workspace_get_index, but oh well.
I accidentally broke this in commit a119ea9. The code was considerably
more complicated than it needs to be, so let's replace it with a
g_list_find and nothing more.
Scanning over the hash table of XIDs is a terrible idea. Not only were
we excluding Wayland windows, but we were also looking at alarms and
barriers, too. We were lucky that that only contained GObjects where
our checks would work.
MetaGrabOp is painful and tedious to work with, because it's a
sequential series of values, meaning we have to use a giant unreadable
switch statement to figure out some basic things about the value.
To solve this, modify the encoding for MetaGrabOp and for the specific
window grab operations so that they're a set of bitflags that we can
easily check.
We've long used a switch statement on the grab operation to determine
where events should go. The issue with MetaGrabOp is that it's a mixture
of a few different things, including event routing, state management,
and the behavior to choose during operations.
This leads to poorly defined event routing and hard-to-follow logic,
since it's sometimes unclear what should point where, and our utility
methods for determining grab operations apart can be poorly named.
To fix this, establish the concept of a "event route", which describes
where events should be routed to.
It turns out that Clutter doesn't actually filter NumLock / ScrollLock /
CapsLock from button events due to its terrible event translation code.
Check only the grab mods to check if it's unmodified.
Popups could not set the cursor image, because the cursor tracker would
ignore window cursors if we had a popup active. The correct condition to
check for is already in should_block_wayland. Rename this to the more
sensible name windows_are_interactable, and use it in the cursor tracker.
Since commit 467465c99c we use meta_stage even on x11 which sets
clutter_stage_set_user_resizable to FALSE.
This messes things up because we ought to ignore the properties on the window
but we apperently didn't.
There is no reason why we'd want to manage the stage window.
https://bugzilla.gnome.org/show_bug.cgi?id=734852
Instead of returning a value based on whether or not we handled it, we
have this logic: either we have taken a grab on the window, in which
case we have a grab op and have handled it ourselves, or we did not take
a grab and *need* to replay the event to the window.
Handle this in events.c by checking the grab operation in the same way
that we check the other grab ops.
This is an accidental regression from 7a109a1. If we mark the event as
handled, then we *need* to set grab_op, or do some other sort of
behavior, since we have a grab.
meta_backend_get_keymap is supposed to return a static keymap, not a new
one every time. Cache it internally. We don't update it when the keymap
changes on the server, but we'll do this soon.
Now that we always use XKB, it's very unlikely that we'll get a
MappingNotifier without a subsequence XkbKeymapNotify event. Just
do all the work always.
This will also help us considerably for the future when we'll be
putting the keymap event in the backend.
This allows creating the stage much earlier than it otherwise would have
been. Our initialization sequence has always been a bit haphazard, with
first the MetaBackend created, then the MetaDisplay, and inside of that,
the MetaScreen and MetaCompositor.
Refactor this out so that the MetaBackend creates the Clutter
stage. Besides the clarity of early initialization, we now have much
easier access to the stage, allowing us to use it for things such as
key focus and beyond.
Mutter depends on the X11 windowing backend of Clutter, unless it's used
as a Wayland display server.
This allows Mutter to run without breaking in case Clutter changes the
order with which windowing backends are selected, like it was the case
for bug https://bugzilla.gnome.org/show_bug.cgi?id=734587
The order of selection of the Clutter backends has not been made public,
so it cannot be relied upon since the introduction of the multiple
backends support; since Mutter requires the X11 backend functionality,
it should select the X11 windowing system, in the same way it selects
the EGL backend when compiled and run as a Wayland display server.
If we for some reason have an error trying to allocate the framebuffer,
we'll still mark the tower as revalidated. Move the validation to the
end of the actual revalidation code to solve this.
It's a deprecated API that can surprise us. Namely, when the internal
format passed is COGL_PIXEL_FORMAT_ANY, it will *always* allocate an
RGBA8888 pixel format texture, even if we only passed it a RGB format
or even an A8 format.
cogl_texture_2d_new_with_data is the newer, better API and doesn't have
these warts.
These methods allow us to set and get xkbcommon keymaps as well as
locking a specific layout in a layout group.
With this, we introduce dependencies on xkeyboard-config, xkbfile,
xkbcommon-x11 and a libX11 new enough to have xcb support.
https://bugzilla.gnome.org/show_bug.cgi?id=734301
At this point there shouldn't be any system capable of running mutter
that doesn't have it and we're introducing functionality like setting
the keymap that has an hard requirement on it.
https://bugzilla.gnome.org/show_bug.cgi?id=734301
Since commit a7b7213017, we rely on the standard property
system to initialize the window type (and likewise for the window
role since commit 031154a400). However as property hooks are
never run for properties that are not set, we end up not initializing
the window type correctly for windows with no _NET_WM_WINDOW_TYPE
property (which includes virtually all OR windows, causing them to
show up in pagers and the Shell overview and resulting in frequent
crashes due to breaking reasonable assumptions all over the place).
Introduce a new FORCE_INIT flag to allow forcing hooks to run
even when the corresponding property is unset, and use it for
both _NET_WM_WINDOW_TYPE and _NET_WM_WINDOW_ROLE.
This way the xserver never paints the frame background, even if
the client window is destroyed. This allows us to have clean
destroy window animation.
There is no problem with interactive resizing because applications
are using the XSync protocol, so we're not painting unless the
client has redrawn.
https://bugzilla.gnome.org/show_bug.cgi?id=734054
Connecting to size-changed is wrong -- size-changed tells us when
we *told* the X server or resize the window. For X11, we're sort of
guaranteed that the surface will be updated at some point before the
next frame, but for Xwayland, we can't be sure that the new surface is
attached at this point.
This fixes weird artifacts when resizing apps like xclock.
This was wrong for subsurfaces that extend beyond the parent's shape,
since the paint volume would be wrong in this case. Instead of using the
shape region which can be out of date and wrong, just use the union of
our children's volumes, which is a lot easier to manage.
Refuse to create a touch resource if we don't have the capability
(for misbehaving clients), and don't attempt to use touch data
structures that are not initialized.
This is a terrible hack. We need to figure out a better way to do
interactive resizes.
This fixes weird resizing from the left bugs when using GTK+, which is
really slow at acking configures.
This is an easy way to get into an infinite loop where we're constantly
re-sending stuff to the window. If it worked once, it probably won't
work again.
We assume in meta_window_wayland_move_resize that the next commit that
changes the geometry will always be for our next pending operation, so
if we have a move pending on a resize, the next commit will trigger the
move. This is, of course, fundamentally wrong.
We broke this assumption even more now that we don't fizzle out calls to
meta_window_move_resize_internal and now call it on every commit, which
means that a simple damage and then commit would complete a pending
move.
This was even broken by apps like weston-terminal, which, when clicking
on the maximize button, first redraws the terminal with the maximize
button state back on hover on press, and would only redraw when it got
the configure event with the coordinates.
To track the correct commit to apply the move for, we implement the
ack_configure request and ignore all move/resizes that happen before
that.
Right now, we actually fizzle out the entire move/resize if there's a
future pending configure we're waiting on.
Sometimes we can get a host event without having the display up and
running yet. Just don't pass it to the compositor in that case, since it
won't be possible for it to have any event that matters.
MetaGestureTracker has been separating the "did I handle an event?" and the
"should the event be filtered out?" questions, merge this and make
handle_event() reply to "should the event be only handled by me?".
If a sequence wasn't accepted yet by the gesture tracker, the event will
go through (eg. not handled exclusively by the gesture tracker) and it'll
still be processed by Clutter, triggering gesture actions, and maybe
changing the sequence into other state.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
The grabbing state is now checked for both pointer/touch devices
within the seat, and the grab start coordinates returned by
meta_wayland_seat_get_grab_info().
https://bugzilla.gnome.org/show_bug.cgi?id=733631
On X11 this works because only emulated pointer events are listened for. On
wayland, the single touch behavior must be enforced in touch events, ignoring
every other sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
This function tells the obvious on X11, and implements a similar mechanism
on wayland to determine the "pointer emulating" sequence, or one to stick
with when implementing single-touch behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
Due to the way the MetaGestureTracker processes every touch event, this
will tell as closely to Clutter as possible the current number of touches
happening on the stage.
Even though, this is subject to windowing behavior, on X11, rejected touches
will be soon followed by a XI_TouchEnd event, so the compositor will stop
seeing touch sequences that are still operating on clients. On wayland, touch
sequences are processed by the compositor during all their lifetime, so these
will stay on the MetaGestureTracker with META_SEQUENCE_PENDING_END state, yet
still tracked.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
On wayland, touches are initially both handled by the compositor and sent
to clients, proceeding to cancellation on clients only after the compositor
claims the sequence for itself. Implement the cancellation detail through
MetaGestureTracker::state-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
The capability flags are determined from the device types of the slave devices
that are currently attached. This also happens whenever a device is added or
removed, so the capabilities are kept up to date, and clients know about these.
On VT switch, all slave devices are temporarily removed, so the cascade of
signals will make the seat end up with capabililities=0 while input is suspended.
https://bugzilla.gnome.org/show_bug.cgi?id=733563
Anytime the keymap is changed, either directly, or indirectly through the
keyboard capability being released/initialized, there should be a
notification of the modifiers being changed too.
https://bugzilla.gnome.org/show_bug.cgi?id=733563
Otherwise the focus_surface_listener list element becomes stale, and then
mangled if the devices' data is initialized again, and the memory memset().
https://bugzilla.gnome.org/show_bug.cgi?id=733563
This doesn't match what Weston does. I don't know of any apps that this
fixes (we don't have any apps that even use non-zero dx/dy, I don't
think), but this is part of a cleanup for window geometry.
This reverts commit 3b85e4b2b9.
This breaks touch support; reverting would break wayland
(is what this patch tried to fix; we should find a better solution
that works on both).
The current GNOME Shell Alt-F2 restart looks very messy and also
provides no indication to the user what is going on. We need to
restart the compositor to switch in and out of stereo mode, so
add a framework for doing this more cleanly:
Additions:
meta_restart(): restarts the compositor with a message
MetaDisplay::show-restart-message: signal the embedding
shell to show a message
MetaDisplay::restart: signal the embedding shell to restart
itself.
meta_is_restart(): indicates whether the current instance is a
restart so we can suppress login animations.
A helper program meta-restart-helper holds the composite overlay
window up during the restart to avoid visual artifacts.
https://bugzilla.gnome.org/show_bug.cgi?id=733026
Use connect_after() to accomodate code in GNOME Shell that,
when benchmarking drawing performance, connects to ::after-paint
and calls glFinish(). The timing information from that will be
more accurate if we hold off until that completes before we signal
apps to begin drawing the next frame. If there are no other
connections to ::after-paint, connect() vs. connect_after() doesn't
matter.
https://bugzilla.gnome.org/show_bug.cgi?id=732350
When a Wayland window acks our arrangement and we don't really have
anything to modify, we'll pass a sole flag of META_IS_WAYLAND_RESIZE
to meta_window_move_resize_internal using a garbage rect. The existing
code to calculate the new rectangle couldn't really handle this case,
and so the garbage rectangle accidentally got stored. Revamp the flag
checks to be more clear about it.
This fixes the weird positioning issues that sometimes appear when
resizing weston-terminal among others.
We really can't do this unless the backend X server is the same as the
frontend X server, as we pass a frontend XID to the backend, which is
only the case when we're not a Wayland compositor.
This code was supposed to refresh our default icons when the theme
changed, but it actually was a no-op, since the default icons are cached
in a static variable in MetaUI.
I'm not sure the fact that the fallback icons don't update when the
theme changes is an important enough use case to keep working, but I'm
keeping the skeleton function there in case somebody wants to actually
fix it properly.
These just spam up our logs, and they aren't getting fixed any time
soon for a variety of reasons. Just disable them to ensure that really
important warnings get noticed and fixed.
This is so we won't poke into the MetaDisplay, which is invalid memory,
and crash. This can sometimes work right now because GSlice might not
deallocate the object immediately, but it's still not a fun thing to do.
Now that we have two connections to the X server, the idea of a
ref-counted server grab that might be held across extended portions
of code is very dangerous since we might try to use the backend
connection while the frontend connection is grabbed.
Replace the only usage (which was local) with direct
XGrabServer/XUngrabServer usage and remove the meta_display_grab()
API.
https://bugzilla.gnome.org/show_bug.cgi?id=733068
There's no obvious reason for grabbing the X server when unmanaging
a screen - the only race conditions a server grab solves are those
related to querying and then acting on the results of the query.
Our shutdown sequence is correctly ordered according to the ICCCM -
we first unselect on the root window, and then we destroy the
window owning WM_S<n> so removing the grab should not cause any
problems when we are being replaced with another window manager.
https://bugzilla.gnome.org/show_bug.cgi?id=733068
Properties like _NET_WM_DESKTOP and _NET_WM_STATE are supposed to be
ignored after the initial map of the window, so ignore any
PropertyNotifies for these.
The only case we have is the case where the two X11 connections are the
same. When on Wayland, the XSync is costly and expensive, and we should
minimize it.
