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
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>
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
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.
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 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
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
