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
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
There is copy&pasted code in set_scroll_button, which is apparently
wrong, because it is trying to set scroll method instead of the scroll
button...
https://bugzilla.gnome.org/show_bug.cgi?id=747967
Since 8769b3d55, the checks performed on which update_* function was
called for each device got quite more lax, leading to failed asserts
on code that assumed the previous behavior.
Change update_[mouse|touchpad|trackball]_* to bail out early if the
device received has not the right type, and remove the asserts.
https://bugzilla.gnome.org/show_bug.cgi?id=747886
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 the frame is the window that's redirected, there's no reason for
it to match the root window. There *is*, however, a big incentive to
match the window's visual, since not doing so might trigger automatic
redirection.
On a specific platform, we construct a depth-32 root window, and stick a
depth-24 child window inside it. The frame ends up being created
depth-32, not depth-24, so we get automatic redirection.
since commit 8c16ac47c1b88fc48ad8ea621a75a86e028a2764, 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
This seems nicer/tidier than the current X11 (center on the span of all
monitors) or native (so close to the activities corner it's hard not
to trigger it) platform behaviors.
This code also takes over the native-specific pointer warping that
happens when the pointer was over a removed output.
https://bugzilla.gnome.org/show_bug.cgi?id=746896
This function returns the monitor_info index corresponding to the given
coordinates, or -1 if none is found at that point. The native backend
has been changed in places where it could make use of this function.
https://bugzilla.gnome.org/show_bug.cgi?id=746896
clutter currently never emits activated or deactivated signals on
the stage object when using the EGL backend. Since the stage never
gets activated, accessibility tools, like orca, don't work.
This commit makes mutter take on the responsibility, by tracking
when the stage gains/loses focus, and then synthesizing stage
CLUTTER_STAGE_STATE_ACTIVATED state events.
A limitation of this approach is that clutter's own notion of
the stage activeness won't reflect mutter's notion of the
stage activeness. This isn't a problem, in practice, and can
be addressed in the medium-term after making changes to
clutter.
https://bugzilla.gnome.org/show_bug.cgi?id=746670
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.
The enums are swapped currently, because for edge scroll is enabled two finger
scroll and similary for two finger scroll is enabled edge scroll, what is
apparently wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=746870
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
As we opt out of GTK+/Clutter's HiDPI handling, we need to apply the
window scaling factor manually to decorations, both the geometry and
when drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=744354
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
With all input events being handled through clutter, this only confuses
things, and most nominally, coerces touch events through places we didn't
intend to, like the window frame.
This makes again all touch events only handled in the passive grab on X11,
while the rest stays pointer (emulated) only.
https://bugzilla.gnome.org/show_bug.cgi?id=745335
On startup, the cursor is kept hidden if there's any touchscreen available.
If the device that was last interacted is removed, we check on available
pointing devices though, so we don't possibly hide the pointer if there are
further mice/touchpads/etc.
Devices being added don't update cursor visibility, we wait for the user
interacting with those instead.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
On X11, calling this function on meta_display_handle_events() will not catch
mouse events happening over clients, so poke directly in the backend for
XI_DeviceChanged events, which mutter will get on device switches.
The code has been slightly refactored so we deal with XIEvents at a single
handle_input_event() function.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
This function can be used to trigger changes depending on the device type
that is currently emitting the events. So far, it is used to switch cursor
visibility on/off on touchscreen interaction.
A "last-device-updated" signal has also been added, in order allow hooking
other behavior changes (eg. OSK) when the last device changes.
https://bugzilla.gnome.org/show_bug.cgi?id=712775
Since commit 6e06648f7, we start out with the invisible frame parts
only, and then add the unconstrained rect's height (which consists of
the visible parts of both frame and client window) *unless* the window
is shaded. While we indeed don't want to add the client height in that
case, we need to explicitly include the visible frame parts now.
https://bugzilla.gnome.org/show_bug.cgi?id=746145
There is no good reason to do so, besides a nice way to check whether
a particular button is enabled. However there are legitimate reasons
for overdrawing like box-shadows or outlines, so remove the clip.
The initial pointer position is set by clutter. At the moment it
is the point 16x16 on the screen. But this point is not always
in the visible area on monitors (the monotors can be arranged in
many different ways).
https://bugzilla.gnome.org/show_bug.cgi?id=745752
Otherwise the pointer might be "lost" outside the visible area. Note
that the constraining code only ensures the pointer doesn't leave the
visible area but if the pointer is already outside because the rug was
pulled under it then it doesn't do anything.
https://bugzilla.gnome.org/show_bug.cgi?id=745121
