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