The corresponding wl_notify field for destroy_data_device_icon()
is drag_grab->drag_icon_listener, otherwise we're fetching a pointer
that's slightly off where we want.
The stop function currently manually constructs the lock
filename from the display number and also calls unlink
on the same, already known lock filename from the manager
struct.
This commit gets rid fo the manual construction in favor
of the saved lock filename.
https://bugzilla.gnome.org/show_bug.cgi?id=748380
The start function has a few exit paths that need to
perform clean up of the lock file.
This commit consolidates those exit paths at the end
using an out label and gotos.
https://bugzilla.gnome.org/show_bug.cgi?id=748380
Add set_modal ond unset_modal to the gtk_surface interface. When a
surface is modal, the compositor can treat it differently from non-modal
dialogs, for example attach it to the parent window if any. There is
currently no changes to input device focus; it is up to the client to
ignore events to the parent surface that is wanted.
This bumps the gtk_shell version to 2.
https://bugzilla.gnome.org/show_bug.cgi?id=745720
When a parent of a subsurface gets it state applied (either by a
wl_surface.commit, wl_subsurface.set_desync or a recursive
wl_surface.commit on a parent surface), the pending position state
of the subsurface should be applied. If the subsurface is in effective
synchronized mode (i.e. if its in explicit synchronized mode or any of
its parent surfaces is a subsurface in explicit synchronized mode), the
cached state should also be applied at this point, including its
subsurface children, recursively.
https://bugzilla.gnome.org/show_bug.cgi?id=743617
Otherwise we'll access freed memory in the handlers.
The wayland keyboard is released when the seat loses the keyboard
capability which happens when leaving the VT so if there are keymap
changes while switched away from the VT we would crash.
https://bugzilla.gnome.org/show_bug.cgi?id=747263
since commit 8c16ac47c1, we started
creating the login screen on display 1024 instead of display 0.
This defeats this logic in try_display:
display++;
/* If display is above 50, then something's wrong. Just
* abort in this case. */
if (display > 50)
In practice it doesn't matter much since we only have one login
screen in most setups, but we should still fix the bug.
This commit introduces a separate counter to keep try of 50 tries,
rather than assuming "display number == number of tries".
https://bugzilla.gnome.org/show_bug.cgi?id=746545
To avoid integer overflow when scaling "infinite" regions (0, 0)
(INT32_MAX, INT32_MAX), intersect with the surface rect before scaling,
instead of intersecting with the buffer rect afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=746510
The original code in Weston that this was ported from returned an errno,
not a boolean, so we were inadvertently returning TRUE here during an
error path. Fix that up.
When a client wants to start initialized it my set the maximized state
before having attached any buffers. Before we'd not notify the client of
the new expected size if the previous size was 0x0 as it would normally
mean we'd resize to 1x1, but since this is not always the case, only
avoid notifying the client if the previous size was 0x0 and the result
is 1x1.
https://bugzilla.gnome.org/show_bug.cgi?id=745303
If the wl_surface resource happens to be destroyed before any other
role resource, the destructor for the latter will attempt to
access/modify random memory.
Fix this by ensuring the associated resources are destroyed on the
wl_surface destructor, this will free all associated memory and
remove the resources ahead of their imminent destruction.
https://bugzilla.gnome.org/show_bug.cgi?id=745734
In 3.16, GDM keeps a login screen running on vt1.
This login screen starts an Xwayland instance.
Since it's the first X server to start, it gets
the prized :0 display number.
This commit works around that problem, for now,
by having GDM's display number start at 1024.
https://bugzilla.gnome.org/show_bug.cgi?id=746295
MetaWaylandFrameCallback has been added a surface field, which is then
checked when destroying the surfaces. This prevents unintended callbacks
to run after a surface has been destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=745163
In order to switch to the correct surface actor scale given the monitor
the surface is on, without relying on the client committing a new state
given some other side effect, sync the surface actor state when the main
monitor associated with the corresponding window changed.
https://bugzilla.gnome.org/show_bug.cgi?id=744933
Since the surface actor knows more about how it draws itself, instead of
pushing texture state (buffer and scale), input region and opaque region
from MetaWaylandSurface after having transformed into what the surface
actor expects, make the surface actor set its own state given what state
the Wayland surface is in.
https://bugzilla.gnome.org/show_bug.cgi?id=744933
Doing this on manage() allows the common MetaWindow initialization to
do the right thing for popups like setting skip_taskbar and
skip_pager.
In particular this avoids gnome-shell's app tracker to create a new
ShellApp instance for every popup.
https://bugzilla.gnome.org/show_bug.cgi?id=745118
Before commit ac448bd42b the pointer,
keyboard, and touch objects were initialized when the seat was created.
Now they're initialized later, when the clutter device manager finds and
loads them.
This commit makes sure we don't try to access those objects if they
aren't initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=744640
The wayland seat event handlers get sent events that
aren't strictly interesting to them (such as events for
hardware devices the seat doesn't support and events for
virtual devices that the seat needs to ignore).
This commit makes sure all uninteresting events get ignored.
If a client creates an xdg_popup given a parent that is a xdg_popup that
is not the most top one in the grab chain, send the
not_the_topmost_popup error.
Also fail a client who destroys a popup that is not the top most one.
https://bugzilla.gnome.org/show_bug.cgi?id=744452
We'll want to expose popup logic outside of meta-wayland-pointer.c and
one day we'll also probably want to add touch support for popups, so
lets move it to its own file. There are no significant semantical
changes, only refactoring.
https://bugzilla.gnome.org/show_bug.cgi?id=744452
This just exposes the type and the singleton getter necessary to make
it available to introspection. We'll expose more functionality as it
becomes needed.
https://bugzilla.gnome.org/show_bug.cgi?id=743745
The commit 97a69cee5a broke the caching of
the surface state when because the frame_callback_list target state was
overwritten after the content had been moved to it.
This commit fixes it by moving the frame list addition after the copy. We
also need to initialize the list since the plain copy put garbage in it.
https://bugzilla.gnome.org/show_bug.cgi?id=743678
Whenever the compositor takes a grab, we're supposed send leave/enter
events to the current surface, which makes sense, as the compositor
has stolen the pointer from the client.
I forget why I added the special case in the first place, but it's
likely a bug that's since been fixed.
This actually fixes a bug: it prevents the need to double-click on
X11 application titlebars when grabbing them.
The input region currently only gets scaled by the surface
scale while ignoring the output scale, which causes input events to not get
delivered correctly for clients on hidpi screens. So take the output scale
into account when doing so.
https://bugzilla.gnome.org/show_bug.cgi?id=739161
This commit is wrong, it assumes that the scale only applies to the one
set by the client but its not. meta_surface_actor_wayland_scale_texture
also handles the output scale. Revert the commit to fix hidpi for wayland
clients like weston-terminal.
This reverts commit 0364ea9140.
https://bugzilla.gnome.org/show_bug.cgi?id=739161
The key event should be interpreted by clients with the modifier state
as it was before the event itself just as in X11 input events.
Achieving this in wayland is a matter of sending the key event first
and the modifiers after (if needed).
This isn't really specified in the wayland protocol but it matches
weston's behavior and should avoid corner cases in clients.
https://bugzilla.gnome.org/show_bug.cgi?id=738238
This reverts commit 33acb5fea0.
The issue here is that the pointer actor does not actually get reset
when the actor's reactivity changes, so we end up with stale picks after
actors are destroyed.
I have a local patch to Clutter for this, but I don't have time to
submit it upstream, so let's just use the ugly code for now.
This reverts commit e496ed50d6.
This was incorrect. wl_surface_destructor actually does the full repick
-- doing it here is dangerous, because the destroy listeners actually
run *before* the destructor, not after, so the surface is still alive.
We never want to send pressed keys to wayland clients on enter. The
protocol says that we should send them, presumably so that clients can
trigger their own key repeat routine in case they are given focus and
a key is physically pressed.
Unfortunately this causes some clients, in particular Xwayland, to
register key events that they really shouldn't handle, e.g. on an
Alt+Tab keybinding, where Alt is released before Tab, clients would
see Tab being pressed on enter followed by a key release event for
Tab, meaning that Tab would be processed by the client when it really
shouldn't.
Since the use case for the pressed keys array on enter seems weak to
us, we'll just fake that there are no pressed keys instead which
should be spec compliant even if it might not be true.
https://bugzilla.gnome.org/show_bug.cgi?id=727178
It only contained a pointer to a wl_resource, which isn't much of
value. Just replace it with the wl_resource instead. Any future private
data should be handled by our future role system.
The actor is updated on DnD grab motion events, properly notified
when dragging finishes, and destroyed if the client/surface disappear
below its feet.
Keeping track of the surface will be necessary in case it is destroyed
during DnD, and the coordinates will be useful when figuring out the
snap back coordinates.
When grabbing with DND, we need to leave the pointer alone and
under the client's control. The code here was a bit messy before about
when it unset the window cursor -- it did it whenever there was no
current surface after repicking, which is a bit wrong, since it will
fire during a drag grab.
Move the check for this to update_cursor_surface, which is our standard
"sync" API for this, and then call update_cursor_surface after we set
the focus.
During a DND grab, pointer->focus_surface is NULL, since the wl_pointer
doesn't have any focused surface (it's in drag mode). In this case, the
drag interface has control of the focus, and when dragging into a NULL
surface, drag_grab_focus won't get called, properly detaching it from
the previous surface.
Let the interface->focus implementation do the fizzling out.
In the future, we should split out wl_pointer's implementation
(pointer->focus_surface) from the Wayland side of the generic pointer
wrapper (pointer->current) and use our event routing system to determine
or similar whether it should go to wl_pointer or wl_data_device.
Some applications, like totem, create keyboard/pointer objects from the
same client, and expect it to work. We made this work a while ago, but
due to an oversight in the code, we increment the serial on button press
for every resource that we need to send events to.
Since operations like move/resize use the grab serial of the devices to
determine whether the operation is exact, we need to make sure the same
serial goes to all devices.
Restructure the code so that all that's in the resource loop is the
sending of the event -- all the calculation that's needed happens
outside.
This fixes moving / resizing the Totem window not working sometimes.
https://bugzilla.gnome.org/show_bug.cgi?id=736840
The fix in d61dde1 regressed the position of popup windows, since the
size was 0x0 when we wanted to do a sole move. Only fizzle out in the
path where we actually *do* resize.
https://bugzilla.gnome.org/show_bug.cgi?id=736812
We only broadcast input to the focus_resource_list, so we need to make
sure it's put in the proper list on startup.
This fixes input not working for windows when they first appear.
Argh. There's always more stuff to fix with keyboard/pointer. Every
single time I think I've fixed it, more stuff pops up.
GTK+ requests get_xdg_surface before attaching a buffer, and since it
might take a long time for GTK+ to get around to attaching a buffer and
committing it, our idle for MOVE_RESIZE will kick in beforehand.
And our idle will try to resize the 0x0 window that currently exists,
constrain it to 1x1, which will send a configure event of 1x1 to the
window while it boots up, causing it to awkwardly resize to the minimum
size of the window.
Make sure that in this case, our idle doesn't cause any problems, and
that we fizzle out any idles like this.
The "proper" way to do this would be to delay the creation of the
MetaWindow until a surface is committed, but that's difficult for a
variety of reasons, and might cause unintended issues with focus.
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.
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
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 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
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.
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
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.
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
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.
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.
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
