Keep the active position state in its original coordinate space, and
synchronize the surface actor with it when it changes and when
synchronizing the rest of the surface state, in case the surface scale
had changed.
https://bugzilla.gnome.org/show_bug.cgi?id=745655
We can get this operation in some cases, for example when
we're trying to resize window that cannot be resized.
This can occur with maximized windows that have a border
(without border we couldn't resize them by mouse in maximized state).
In this case we reached abort() beacuse we did not handle this op.
https://bugzilla.gnome.org/show_bug.cgi?id=751884
Previously a MetaWaylandOutput could be removed from the current outputs
table (by being unplugged for example). This would result in the global
object being removed and the MetaWaylandOutput instance freed, but the
wl_resource destructor would still try to remove itself from the list of
resources. Trying to do this, it'd try to access its user data pointer
which would point to the freed MetaWaylandOutput instance, and as a
result crash when trying to manipulate the freed data.
https://bugzilla.gnome.org/show_bug.cgi?id=744453
Whenever a MetaSurfaceActor is painted, update the list of what outputs
the surface is being drawed upon. Since we do this on paint, we
effectively avoids this whenever the surface is not drawn, for example
being minimized, on a non-active workspace, or simply outside of the
damage region of a frame.
DND icons and cursors are not affected by this patch, since they are not
drawn as MetaSurfaceActors. If a MetaSurfaceActor or a parent is cloned,
then we'll check the position of the original actor again when the clone is
drawn, which is slightly expensive, but harmless. If the MetaShapedTexture
instead is cloned, as GNOME Shell does in many cases, then these clones
will not cause duplicate position checks.
https://bugzilla.gnome.org/show_bug.cgi?id=744453
We may access it during painting even if it has been freed. For now,
manually unset it during the MetaWaylandSurface cleanup; in the future
make MetaWaylandSurface a GObject and make the surface pointer a weak
reference.
https://bugzilla.gnome.org/show_bug.cgi?id=744453
Lets use the role when doing role specific commit actions. The
conditions effectively do that anyway, and this way we will get a
compiler warning here whenever we add a new role, as well as we avoid
having different variants of role-determination checks in different
places.
https://bugzilla.gnome.org/show_bug.cgi?id=744453
Enable a user to test and debug multi output configurations on Wayland
without having the available hardware by enabling some basic
configuration of the dummy monitor manager.
Currently available configuration options are:
MUTTER_DEBUG_NUM_DUMMY_MONITORS - to set the number of monitors
MUTTER_DEBUG_DUMMY_MONITOR_SCALES - to configure the monitor scales
See src/backends/meta-monitor-manager-dummy.c for detailed description
of the available configuration parameters.
https://bugzilla.gnome.org/show_bug.cgi?id=747089
Before submitting a new scroll mode, click method or sendevents mode check if
the value is supported by the device. This avoids BadValue errors when setting
two-finger scrolling on single-finger touchpad devices since we can't easily
handle BadValue (see 9747277b)
https://bugzilla.gnome.org/show_bug.cgi?id=750816
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The elementary guys would like this as an API, and I don't see any
reason to refuse -- this is quite nice shadow painting code :)
For some reason, gobject-introspection can't seem to cope with
MetaWindowShape. I'll look into it a bit later, but for now, mark
the function it has trouble with as (skip).
It seems that when translated, paint_offset and actor_offset will always
be the same, so our translation of the clip group won't work. For now,
until I figure out what's going on here, just use the painting offset,
since that what seems to make sense to me.
I didn't write this code, though, so I don't know why the actor's
allocation was involved in this computation at all.
I tested briefly with clones (magnifier, manual cloning through the
looking glass) and couldn't find any other artifacts, so I'm going to do
this for now.
A much less hacky version of maximize / unmaximize is reimplemented
in terms of this, but it could also eventually be used for fullscreen /
unfullscreen, and tile / untile.
The comment explains it better, but Clutter tries to be smart and
repaint actors when their allocations change. Since the window group's
allocation changes when windows move around, this means that moving a
window will always cause a full-stage repaint, which is super slow.
Hack around this for now.
While nothing will completely fix X11's artifacts, this tends to look a
bit better, *especially* with mask textures that have black at the
edges (which are most of them).
It's also faster for GPUs to manage.
The only time we ever execute this code is when we're minimizing or
hiding a window, in which case we should respect stacking order.
This fixes weird "bugs" where windows from the same app magically pop up
over other windows.
We should not be setting random output properties like this.
Use the function we just introduced to only set the underscan flag when
it's actually supported.
So that clients such as the control center can decide to hide an
underscanning checkbutton when the output does not support it.
Support in the KMS / native backend to come later...
This is an extremely niche feature, and conflicts with the rest of our
interface being consistent about not allowing resizing while tiled or
maximized.
A window may be hidden even if not minimized itself, for instance
when an ancestor is minimized. As meta_window_focus() will refuse
to actually focus the window in that case, don't pick it in the first
place.
https://bugzilla.gnome.org/show_bug.cgi?id=751715
Firstly, this patch makes MetawaylandDataSource a GObject. This is in
order to easier track its lifetime without adding destroy signals etc. It
also makes the vfunc table GObject class functions instead while at it,
as well as moves protocol specific part of the source into their own
implementations.
An important part of this patch is the change of ownership. Prior to this
patch, MetaWaylandDataDevice would kind of own the source, but for
Wayland sources it would remove it if the corresponding wl_resource was
destroyed. For XWayland clients it would own it completely, and only
remove it if the source was replaced.
This patch changes so that the protocol implementation owns the source.
For Wayland sources, the wl_resource owns the source, and the
MetaWaylandDataDevice sets a weak reference (so in other words, no
semantical changes really). For XWayland sources, the source is owned by
the selection bridge, and not removed until replaced or if the client
goes away.
Given the changes in ownership, data offers may now properly track the
lifetime of a source it represents. Prior to this patch, if an offer with
an XWayland source would loose its source, it wouldn't get notified and
have an invalid pointer it would potentally crash on. For Wayland
sources, an offer would have a weak reference and clean itself up if the
source went away. This patch changes so the behavior is consistent,
meaning a weak reference is added to the source GObject so that the offer
can behave correctly both for Wayland sources and XWayland sources.
https://bugzilla.gnome.org/show_bug.cgi?id=750680
When a possible drag dest client crashes during DnD, it may happen
we receive first the destroy notification for the data_device, and
later the notification for the focus surface. When this happens we
unset the drag_focus_data_device first, and later on
meta_wayland_drag_grab_set_focus(grab, NULL) we assume it still
exists when sending the leave event, leading to mutter crashing
right after.
So, as we don't receive any ordering guarantees about resource
destruction, just prepare the meta_wayland_drag_grab_set_focus()
paths for this.
It seems that fglrx sometimes gives us absolute junk when requesting the
outputs, and if we don't trap errors, we'll just crash when trying to
configure a junk output. Use xcb so errors simply get ignored.
For enter / leave events, which we use in the UI code, we need to make
sure that these coordinates are root-relative as well, otherwise the
cursor when entering frames might be incorrect.
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
This makes gnome-settings-daemon turn on the backlight and
gnome-shell's screen shield animate.
Note that on X sessions, gnome-settings-daemon uses the same upower
property to force an innocuous key event into the X server so that the
idle time gets reset since Xorg doesn't do this itself on lid events.
https://bugzilla.gnome.org/show_bug.cgi?id=749076
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
We'll need to get the value of some properties. Fail if the number of
items returned is less than we expect and warn if it exceeds it so
that we can easily find out if items are added to a property later and
fix it.
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.
When running as an X11 compositor we do this for every event we see on
the X event stream. As a wayland compositor we don't go through that
code path but since we see all events we can easily do this on motion
events.
In fact, we don't even need this caching when we're a wayland
compositor since we can always find where the pointer is without a
round trip but we're sharing the current monitor logic with the X
path so let's keep it as is for now.
https://bugzilla.gnome.org/show_bug.cgi?id=748478
