Going from fullscreen to unfullscreen involves a frame border size, so
in order to properly interpret the saved rect size, we need to make sure
that the frame borders are fully up to date.
When we're unredirected, we don't have a pixmap, and thus our allocation
becomes 0x0. So when events come in, they pass right through our actor,
going to the one underneath in the stack.
Fix this by having a fallback size on the shaped texture actor when
we're unredirected, causing it to always have a valid allocation.
This fixes clicking on stuff in sloppy / mouse mode focus.
In commit cc5def1, buttons were changed from GdkRectangles to
MetaButtonSpace units, but the corresponding memset hack was not.
This means that the clickable portion of the unshade rectangle
was always set to uninitalized memory. The effects of this were
random, but in cases where the moon is aligned just right, the
rectangle would graze over the borders, and so it would take priority
over other borders and show a pointer cursor instead of a resize
cursor.
Since we're using xcb now, not Xlib, it doesn't have the stupid silly
thing where it copies all 32-bit data to 64-bit data to match the
long-y-ness of it.
It seems the largest possible value is to be passed, so actually pass
that instead. Note that even though the name of the xcb_get_property
parameter is called 'long_length' its actually a uint32_t.
https://bugzilla.gnome.org/show_bug.cgi?id=751136
If a client unsets a selection (calls set_selection with the offer
NULL), this should cause the compositor not to continue sending the
previously set offer.
https://bugzilla.gnome.org/show_bug.cgi?id=750007
If we're running as a nested compositor, we must not attempt to
passive grab on the root window, and we should be setting the
touch event mask on the stage window.
https://bugzilla.gnome.org/show_bug.cgi?id=751036
The "calc showing" operation is queued in a few places alongside MetaWindow
creation, we should be ignoring these until there is a buffer to show.
https://bugzilla.gnome.org/show_bug.cgi?id=750552
Mutter generates a motion event for every button and scroll events,
which confuses Xwayland apps that rely on XMotionEvents for various
purposes, e.g. it fools rxvt jumpy mouse detection code.
Remove the call to notify_motion() from the button and scroll event
handlers to avoid these spurious motion events.
https://bugzilla.gnome.org/show_bug.cgi?id=748705
This way, we won't be hit with BadValue errors if we set it to a value
outside the X device's range. This can happen for touchpads without
two-finger scrolling, for instance.
According to the xdg-shell protocol specification the (x, y) coordinates
passed when creating a popup surface is relative to top left corner of
the parent surface, but prior to this patch, if the parent surface was
a xdg_surface, it'd position it relative to top left corner of the
window geometry of that xdg_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=749716
Instead of selecting the first drm mode as the preferred mode, select the
first drm mode marked as preferred. If there are no modes marked as
preferred, revert to the old behaviour and select the first mode.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
https://bugzilla.gnome.org/show_bug.cgi?id=750363
Read the drm layout properties suggested_X, suggested_Y and
hotplug_mode_update and transfer them to the meta layer.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
https://bugzilla.gnome.org/show_bug.cgi?id=750363
The monitors info structure is created from the tiled outputs
and this is used as the central storage for info about a monitor
as opposed to the output state.
It appears at least the EDID mm w/h is for the whole monitor and
not per tile.
this just adds backend support for retrieving the tile
information from X11 (randr 1.5) and native backends.
It stores the tiling information into the output struct.
When DnD is started from an X11 client, mutter now sets up an special
grab that 1) Ensures the drag source keeps receiving events, and 2)
Moves an internal X Window over wayland clients as soon as the pointer
enters over these.
That window will act as the X-side peer for the currently focused
wayland client, and will transform XdndEnter/Position/Leave/Drop
messages into wayland actions. If DnD happens between X11 clients,
the window will be moved away and unmapped, to let these operate as
usual.
https://bugzilla.gnome.org/show_bug.cgi?id=738312
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
window->is_alive isn't initialized explicitly so it defaults to FALSE
meaning that if the first ping fails we'd short circuit and not show
the delete dialog as we should.
We could initialize the variable to TRUE but in fact we don't even
need the variable at all since our dialog management is enough to
manage all the state we need, i.e. we're only interested in knowing
whether we're already displaying a delete dialog.
This does change our behavior here since previously we wouldn't
display the dialog again if the next ping failed after the dialog is
dismissed but this was arguably a bug too since in that case there
wouldn't be a way to kill the window after waiting for a while and the
window kept being unresponsive.
https://bugzilla.gnome.org/show_bug.cgi?id=749711
