Commit Graph

23234 Commits

Author SHA1 Message Date
Jonas Ådahl
8a7876ded5 wayland: Don't cancel the pointer grab on compositor grabs
We shouldn't cancel the pointer grab when there is a compositor grab,
since that'd break things like drag-n-drop via the overview and
alt-tabs.

The original reason for cancelling the pointer grab on compositor grabs
was to avoid a re-entry when a compositor grab was activated while
there was an active pointer constraint grab. The re-entry would happen
when the compositor grab cleared the pointer focus. Clearing the focus
would trigger the pointer constraint to be deactivated, which would end
its grab. Ending the grab would reset the grab to the default one, which
could focus the same surface again, triggering the constraint to
re-enable before it finished disabling.

This is now avoided because the default grab handler is now aware of
compositor grabs, and won't override the cleared pointer focus until
the compositor grab ends.

https://bugzilla.gnome.org/show_bug.cgi?id=772914
2016-10-19 15:45:33 +08:00
Jonas Ådahl
b50da46f43 wayland/pointer: Don't set focus while during compositor grab
Teach the default grab about compositor grabs (i.e.
display->event_route) so that it can avoid setting a pointer focus when
after the compositor grab actively unset the pointer focus.

https://bugzilla.gnome.org/show_bug.cgi?id=772914
2016-10-19 15:45:33 +08:00
Jonas Ådahl
8b0e9706ca constraints: Use ConstraintInfo window size when placing
The frame rect will at this point not be set for Wayland popups, since
the popup is placed and constrained before the actual buffer will be
attached. To still be able to calculate a proper monitor to be used for
constraining, use the ConstraintInfo::current dimensions instead, since
they will have the expected size. This should not cause any issues with
present paths since when a window is otherwise placed, it usually
doesn't change monitor calculation result.

This fixes opening a popup menu that would be positioned on the left
edge of a not-left-most monitor, for example a 'File' menu on a window
maximized on a second monitor.

https://bugzilla.gnome.org/show_bug.cgi?id=773141
2016-10-19 15:14:23 +08:00
Rui Matos
1d4a5a7520 MetaOnscreenNative: fix mirror mode with stage views
Using the view's MetaMonitorInfo to find all the crtcs which should be
configured to display a given onscreen doesn't work unfortunately. The
association runs only the other way around, i.e. we need to go through
each crtc and find the ones corresponding to our monitor info.

https://bugzilla.gnome.org/show_bug.cgi?id=773115
2016-10-18 14:11:10 +02:00
Rui Matos
8290e1f09a MetaRendererNative: don't call drmModeGetResources()
There's no need to call this and we were leaking the returned memory.

https://bugzilla.gnome.org/show_bug.cgi?id=773116
2016-10-18 14:10:58 +02:00
Rui Matos
89672fad04 MetaMonitorManageKms: plug a GArray leak
https://bugzilla.gnome.org/show_bug.cgi?id=773116
2016-10-18 14:10:55 +02:00
Hannie Dumoleyn
1cb9cfe11d Updated Dutch translation Master 3.24 2016-10-17 18:26:41 +02:00
Rui Matos
280e297afe MetaIdleMonitorNative: initialize last event timestamp
If this isn't initialized and an idle watch gets instanced before
meta_idle_monitor_native_reset_idletime() gets called, that idle watch
would get triggered as soon as we hit the main loop.

This was causing gnome-session to go into idle mode at session start
thus making gnome-shell lock the screen.

In the past this bug was being masked by either logind emiting
session active signals or a stray input event making it through at
startup.

https://bugzilla.gnome.org/show_bug.cgi?id=772839
2016-10-17 13:47:20 +02:00
Rui Matos
fc8de3d0c8 clutter/stage: Fix framebuffer capture origin offset (again)
Commit 5fbb479301 was wrong too. What we
really want to do here is getting view relative coordinates given the
view's and the rectangle's global coordinates so we need to subtract
the view's origin from the rectangle's.

https://bugzilla.gnome.org/show_bug.cgi?id=771502
2016-10-17 13:47:20 +02:00
Rui Matos
3e2555667f MetaWaylandDataSourcePrimary: use the correct parent GType
https://bugzilla.gnome.org/show_bug.cgi?id=771019
2016-10-17 13:47:20 +02:00
Kjartan Maraas
1ecadb6e57 Updated Norwegian bokmål translation. 2016-10-15 17:12:17 +02:00
Carlos Garnacho
2abee91dbc wayland: Cancel touches on meta_wayland_touch_disable()
When disabling the device/capability, we can't rely on cancelled events
being emitted timely, because the capability will be already disabled by
then, all touches must be cancelled immediately then.

https://bugzilla.gnome.org/show_bug.cgi?id=772929
2016-10-14 18:22:42 +02:00
Jonas Ådahl
68645df3a3 wayland/xdg-shell: Scale positioner coordinates
When the monitor is scaled (i.e. HiDPI scaling) the placement coordinates
ere still in unscaled xdg_surface window geometry coordinate space when
used to place the window. Fix this by scaling the coordinates by the
monitor scale of the parent toplevel window before using them.

https://bugzilla.gnome.org/show_bug.cgi?id=771841
2016-10-13 13:57:54 +08:00
Sjoerd Simons
d2f79afc1a wayland/xdg-shell: update popup window monitor early
As meta_window_place_with_placement_rule will trigger a configure event
being sent ensure that the popup is placed on the correct monitor first
to ensure the right scale factor is applied.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

https://bugzilla.gnome.org/show_bug.cgi?id=771841
2016-10-13 13:57:54 +08:00
Sjoerd Simons
8a6fa726d3 wayland/xdg-popup: Force monitor of the top-level
Directly set the monitor of the toplevel window for the popup to avoid
the change not being applied due to later constraints calculation.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

https://bugzilla.gnome.org/show_bug.cgi?id=771841
2016-10-13 13:57:54 +08:00
Jonas Ådahl
a3d7ae6214 wayland/xdg-shell: Scale configure relative popup coordinate
The parent local popup coordinate needs to be scaled according to the
monitor scale it is assigned.

https://bugzilla.gnome.org/show_bug.cgi?id=771841
2016-10-13 13:57:54 +08:00
Jonas Ådahl
c0c132a320 wayland/xdg-popup: Always use monitor of toplevel
Always use the monitor of the toplevel surface's window, so that the
popup menu and the parent will always have the same scale. This fixes
the dimensions sent in the xdg_popup configure event.

https://bugzilla.gnome.org/show_bug.cgi?id=771841
2016-10-13 13:57:54 +08:00
Jonas Ådahl
0dfb5d3ef7 wayland/touch: Use surface relative coordinate helper
Use the global to surface local coordinate converter helper, as that
will currently convert coordinates for Xwayland client more correctly.

https://bugzilla.gnome.org/show_bug.cgi?id=768039
2016-10-13 13:57:54 +08:00
Jonas Ådahl
6480a7ee4a wayland/pointer-constraints: Don't include window frame in region
When Xwayland confines, the surface dimensions will include the server
side window manager decorations. We don't want the decorations to be
included in the constraint region so intersect the calculated input
region with the parts of the buffer rect that is not part of the window
frame.

https://bugzilla.gnome.org/show_bug.cgi?id=771859
2016-10-13 12:59:41 +08:00
Jonas Ådahl
6cc8450f8e wayland/pointer-constraints: Unify requirements for enablement
Put the conditions for enabling a pointer constraint in a helper
function, and use that in both maybe_enable() and maybe_remove(). The
constraint region checking is still only done in maybe_enable()
however.

This changes the conditions for maybe disabling the constraint on focus
change and other trigger points, namely it makes constraints by Xwayland
not disable when they shouldn't due to the constraining window being an
override-redirect window.

https://bugzilla.gnome.org/show_bug.cgi?id=771859
2016-10-13 12:59:41 +08:00
Jonas Ådahl
7ae4b28bda wayland/pointer-constraints: Disable or remove when grab is cancelled
When the grab is cancelled, for example because of an Alt-tab, VT
switch etc, disable or remove (depending on the constraint type) the
constraint. This avoids a re-entry issue when the focus is returned and
the focus listener tries to re-enable a disabled constraint.

https://bugzilla.gnome.org/show_bug.cgi?id=771859
2016-10-13 12:59:41 +08:00
Theppitak Karoonboonyanan
bb8e6afae6 Fix typo in Thai translation 2016-10-13 11:22:35 +07:00
Olivier Fourdan
d7f61e48ac wayland: apply size hints after placing the window
Otherwise the window will be shown initially in the wrong position then
moved quickly as soon as it's made visible, which is confusing.

https://bugzilla.gnome.org/show_bug.cgi?id=772729
2016-10-12 10:16:13 +02:00
Jonas Ådahl
9de6de5802 MetaWaylandPopup: Dismiss popup when grab is cancelled
Dismiss the popup when the grab is cancelled, so that if the grab is
ended for whatever reason (such as VT switching or the last pointer
being disconnected), it doesn't try to end the grab when it isn't
active.

This fixes a crash when VT switching back and forth while a popup grab
is active.

https://bugzilla.gnome.org/show_bug.cgi?id=771858
2016-10-12 10:08:59 +08:00
Jonas Ådahl
6e7057426e wayland/pointer: Add way to cancel current grab
Previously a grab could suddenly end without the grabber knowing
anything about it. Some grabs assume they won't suddenly end without
notice, and can use then new 'cancel' vfunc to be notified.

Currently a grab is cancelled when a new one is started (i.e. in
meta_wayland_pointer_grab_start()), when a non-popup compositor wide
event route is initiated, and when the seat looses the pointer
capability.

https://bugzilla.gnome.org/show_bug.cgi?id=771858
2016-10-12 10:08:59 +08:00
Jonas Ådahl
5306d36522 wayland/touch: Use helper for getting the next event serial
https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:54 +08:00
Jonas Ådahl
7990182f56 wayland/pointer: Use grab helper that doesn't focus when disabling
Instead of using meta_wayland_pointer_end_grab() which focuses the new
grab, add a new helper mean to be used to reset the grab state without
changing the pointer focus. When using this function, the call site is
supposed to explicitly manage focus.

https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:54 +08:00
Jonas Ådahl
93a6be08a5 wayland/pointer: Naming and coding style fixes
Some very long lines that stood out were shortened, and an old naming
convention from weston was removed.

https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:54 +08:00
Jonas Ådahl
d5d5084151 wayland/pointer: Check pointer presence at set focus call site
Make the caller of focus setting check whether there is a pointer to
update the focus state of. It makes it more obvious what to expect, as
the call would be a no-op in when no pointer is present.

Grabbing is still allowed without the presence of a pointer because it
is used by popups even on touch-only systems.

https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:54 +08:00
Jonas Ådahl
d3cff9a962 wayland/pointer: Use helper for getting the next event serial
Use the MetaWaylandInputDevice helper for serial retrieval.

https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:54 +08:00
Jonas Ådahl
133bbdfefa wayland/keyboard: Check keyboard presence at set focus call site
Make the caller of focus setting and grab starting check whether there
is a keyboard to update the focus state or start grabbing. It makes it
more obvious what to expect, as the call would be a no-op in when no
keyboard is present.

https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:54 +08:00
Jonas Ådahl
a8c3470cf2 wayland/seat: Use seat capability checking helper
https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:54 +08:00
Jonas Ådahl
578e527869 wayland/keyboard: Cleanup resource list management
Initialize on init(), unlink and reinitialize the list headers on
disable() so that any delayed resource destruction doesn't affect future
state.

https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:54 +08:00
Jonas Ådahl
312f215fc3 wayland/keyboard: Cleanup grab state managing
Initialize on init() and just end grab on disable().

https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:54 +08:00
Jonas Ådahl
d639c28e3b wayland/keyboard: Cleanup xkb state managing
Initialize and cleanup properly in a _init()/_destroy() function pair.

https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:54 +08:00
Jonas Ådahl
c3f7259cbb wayland/keyboard: Initialize static state in GObject init func
https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:54 +08:00
Jonas Ådahl
56e8f98c13 wayland/keyboard: Naming and coding style fixes
Some very long lines that stood out were shortened, and an old naming
convention from weston was removed.

https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:54 +08:00
Jonas Ådahl
c2217373df wayland/keyboard: Scope variable correctly
https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:54 +08:00
Jonas Ådahl
4a3781d7db wayland/keyboard: Stop using temporary wl_list 'l'
The variable name 'l' usually refers to a GList iterator, but here it's
just a short hand for a specific list. Stop using this shorthand, since
it just makes it harder to read what list is used.

https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:53 +08:00
Jonas Ådahl
911a838c3a wayland/keyboard: Simplify getting the serial serial
Use the MetaWaylandInputDevice helper for getting the next event serial
number.

https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:53 +08:00
Jonas Ådahl
c6106f90d4 wayland/input-device: Add next serial helper
Add a helper function for getting the next input device serial number.
Will be used by keyboard, pointer and touch devices.

https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-11 22:51:50 +08:00
Landry MINOZA
ed52e17886 delete: Swap wait/force-quit actions
The order doesn't only affect the visual layout, but also which action
cancels the dialog (and therefore responds to Escape). It is completely
surprising that this triggers a destructive action like force-quit, so
swap the actions to wait when the dialog is cancelled.

https://bugzilla.gnome.org/show_bug.cgi?id=737109
2016-10-11 00:54:25 +02:00
Florian Müllner
f63bb024fa Bump version to 3.22.1
Update NEWS.
2016-10-11 00:34:34 +02:00
Florian Müllner
bccff5bdd8 window: Expose Flatpak application ID
GNOME Shell's window matching currently fails frequently with Flatpak
applications, as one of the primary hints used to link windows with
.desktop files - the WM_CLASS - no longer matches when flatpak renames
the exported .desktop file. Luckily, Flatpak provides us with a fail-safe
way to map from the PID to the corresponding application ID, so expose an
appropriate method that allows GNOME Shell to reliably match windows to
the corresponding Flatpak app.

https://bugzilla.gnome.org/show_bug.cgi?id=772614
2016-10-10 23:35:02 +02:00
Florian Müllner
e9944350d3 delete: Share some code between X11 and wayland
In order to kill a window, on both X11 and wayland we first try to
kill(3) the corresponding process, so we can add the newly added
get_client_pid() method to share that code.

https://bugzilla.gnome.org/show_bug.cgi?id=772613
2016-10-10 23:35:02 +02:00
Florian Müllner
1fab6e69b7 window: Add get_client_pid() method
It is often useful to identify the client process that created
a particular window, however the existing meta_window_get_pid()
method relies on _NET_WM_PID, which is only available on X11 and
depends on applications to set it correctly (which may not even
be possible when the app runs in its own PID namespace as Flatpak
apps do). So add a get_client_pid() method that uses windowing
system facilities to resolve the PID associated with a particular
window.

https://bugzilla.gnome.org/show_bug.cgi?id=772613
2016-10-10 23:35:01 +02:00
Jonas Ådahl
f89162ee73 wayland/pointer: Unset pointer focus when disabled
Previously the focus was reset implicitly by a memset() on the whole
MetaWaylandPointer struct. When MetaWaylandPointer was turned into a
GObject, this was not possible any more, and the focus was not updated
properly.

https://bugzilla.gnome.org/show_bug.cgi?id=771646
2016-10-10 23:35:01 +02:00
Rui Matos
5261638bfd meta-monitor-config: Look at an output's modes directly when assigning
Going through the global mode pool and then checking if the mode is
available for a given output is pointless work since we can look at
the output's available modes directly.

This implicitly changes how we choose the default mode since, instead
of relying on the sort order of the global modes array, we now rely on
the sort order of the output modes array. Still not ideal, but at
least it makes more sense since the global array is essentially
unsorted.

https://bugzilla.gnome.org/show_bug.cgi?id=772176
2016-10-10 22:37:13 +02:00
Rui Matos
04b75c45f8 MetaMonitorManagerKms: stop taking drmModeModeInfo.vrefresh directly
As in the previous commit, this value already has mode flags baked in
and we can always get the value we need by computing it ourselves.

https://bugzilla.gnome.org/show_bug.cgi?id=772176
2016-10-10 22:37:11 +02:00
Rui Matos
a50950cf8f MetaMonitorManagerKms: stop accounting for mode flags in refresh rates
This isn't technically needed and, in fact, makes us default to
interlaced modes in some cases which isn't desirable.

Note that X doesn't account for these flags either for its mode
refresh rates.

https://bugzilla.gnome.org/show_bug.cgi?id=772176
2016-10-10 22:36:47 +02:00