X11 client windows now hook a X11-specific MetaWaylandDragDestFuncs
that converts these into Xdnd* messages, and an additional selection
bridge has been added to take care of XdndSelection, and the data
transfers done through it.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
This will be useful in order to interact with drag dest surfaces in
its windowing-specific ways, although everything defaults to the
wayland vfuncs.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
This piece of code hooks in both wl_data_device and the relevant X
selection events, an X11 Window is set up so it can act as the clipboard
owner when any wayland client owns the selection, reacting to
SelectionRequest events, and returning the data from the wayland client
FD to any X11 requestor through X properties.
In the opposite direction, SelectionNotify messages are received,
which results in the property contents being converted then written
into the wayland requestor's FD.
This code also takes care of the handling incremental transfers through
the INCR property type, reading/writing data chunk by chunk.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
Expose it partly (in internal headers anyway), and pass a vtable for the
data source functions, the wayland vfuncs just delegate operations on the
wl_data_source resource. The resource has been also made optional, although
it'll be present on all data sources from wayland clients.
The ownership/lifetime of the DnD data source has also changed a bit,
belonging now to the MetaWaylandDataDevice like the selection one does, as
we can't guarantee how long it will be needed after the grab is finished,
it will be left inert and replaced the next time DnD is started at worst.
This allows the creation of custom/proxy data sources, which will turn out
useful for X11 selection interoperation.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
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.
