summaryrefslogtreecommitdiff
path: root/src/wayland
Commit message (Collapse)AuthorAgeFilesLines
* gtk-shell: Work around non-working startup notificationsFlorian Müllner2019-01-141-0/+10
| | | | | | | | | | | GNOME Shell relies on the MetaScreen::startup-sequence-changed signal, which is tied to (lib)startup-notification and therefore X11. As a result, when we remove the startup sequence of a wayland client, GNOME Shell will not be notified about this until startup-notification's timeout is hit. As a temporary stop-gap, go through XWayland even for wayland clients, so that the signal is emitted when expected. https://bugzilla.gnome.org/show_bug.cgi?id=768531
* wayland: Don't reset input focus on text commitChangwoo Ryu2018-05-261-2/+0
| | | | | | | | | Preedit text can be active even after text commit. Resetting the input focus will lead to unintended commit of the preedit text. https://gitlab.gnome.org/GNOME/mutter/issues/152 Closes: #152
* wayland: update enter/leave output after effectsOlivier Fourdan2018-05-221-0/+18
| | | | | | | | | | | | Compositor effects change the actor size and position, which can lead to inconsistent output enter/leave notifications, leaving clients' surfaces without any output set. Update output enter/leave notifications after all compositor effects are completed so that we give clients accurate output location. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/104 (cherry picked from commit 17a745bf81c24dae9c081e93ae1593e2bb81efd6)
* wayland: Compare geometries after chaining upGeorges Basile Stavracas Neto2018-05-182-29/+8
| | | | | | | | | | | | | | | | | | After 20176d03, the Wayland backend only synchronizes with the compositor after a geometry was set, and it was different from the current geometry. That commit was mistakenly comparing the geometry before chaining up, which would yield a false negative on the case where the client didn't call set_geometry() before commit(). Fix that by caching the old geometry locally, chain up (and thus apply the new geometry rectangle), then comparing the old and current geometry rectangles. Fixes https://gitlab.gnome.org/GNOME/mutter/issues/150 (cherry picked from commit cf734999fb9e342811896f70f7c1f415462728a7)
* wayland: Use cursor position in logical monitorOlivier Fourdan2018-05-141-4/+5
| | | | | | | | | | | | | | | | | | | When using two monitors size by side with different scales, once the cursor moves from one output to another one, its size changes based on the scale of the given output. Changing the size of the cursor can cause the cursor area to change output again if the hotspot is not exactly at the top left corner of the area, causing the texture of the cursor to change, which will trigger another output change, so on and so forth causing continuous surface enter/leave event which flood the clients and eventually kill them. Change the logic to use only the actual cursor position to determine if its on the given logical monitor, so that it remains immune to scale changes induced by output scale differences. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/83 (cherry picked from commit 67917db45f96befb777e5f331a775ea3c2b53012)
* wayland/xdg-foreign: Fix child surface validation checkJonas Ådahl2018-05-071-4/+2
| | | | | | | | | The role type should be either an xdg-shell toplevel, or a xdg-shell unstable v6 toplevel. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/138 (cherry picked from commit 332d55f7f6b5d646ea9bc2586b2135113c9d3074)
* wayland/xdg-foreign: Send immediate destroy event to correct resourceJonas Ådahl2018-05-071-1/+1
| | | | | | | | The destroyed signal that was emitted if an imported surface was not available when created, for example if the handle was invalid or already unexported, was emitted on the wrong resource. (cherry picked from commit 98d702428857c79770b159137835622e33b84ba9)
* wayland: Check if state and size changed before calling move_resize()Georges Basile Stavracas Neto2018-05-042-2/+34
| | | | | | | | | | | | | | | | | The current implementation of the XdgSurface v6 protocol does not check if the window changed before calling meta_window_wayland_move_resize(). The problem with this approach is that calling this function is a costly operation since we enter the compositor side. In GNOME Shell case, it is in JavaScript, which triggers a GJS trampoline. Calling this function on every mouse movement is naturally as terrible as it could be - and is exactly what happens now. This commit adds the necessary checks to only call move_resize() when the window actually changed, or when it needs to be updated. https://bugzilla.gnome.org/show_bug.cgi?id=780292 Issue: #78
* wayland: Add function to query if window needs move or resizeGeorges Basile Stavracas Neto2018-05-042-0/+8
| | | | | | | | | | | | | | | | | | | | | | | This will be used by the next commit to determine when a window geometry change should be ignored or not. Normally, it would be enough to just check if the position and sizes changed. The position, in this case, is relative to the client buffer, not the global position. But because it is not global, there is one, admitedly unlikely, situation where the window state is updated while the client size and relative positions don't change. One can trigger this by e.g. tiling the window to the half-left of the monitor, then immediately tile it to half-right. In this case, the window didn't change, just it's state, but nonetheless we need to notify the compositor and run the full move/resize routines. When that case happens, though, the MetaWindowWayland is tracking the pending state change or a move. And this is what we need to expose. https://bugzilla.gnome.org/show_bug.cgi?id=780292 Issue: #78
* window: Let implementations finish state changesGeorges Basile Stavracas Neto2018-05-041-6/+18
| | | | | | | | | | | | | | | | | | | | | | | | In the old, synchronous X.org world, we could assume that a state change always meant a synchronizing the window geometry right after. After firing an operation that would change the window state, such as maximizing or tiling the window, With Wayland, however, this is not valid anymore, since Wayland is asynchronous. In this scenario, we call meta_window_move_resize_internal() twice: when the user executes an state-changing operation, and when the server ACKs this operation. This breaks the previous assumptions, and as a consequence, it breaks the GNOME Shell animations in Wayland. The solution is giving the MetaWindow control over the time when the window geometry is synchronized with the compositor. That is done by introducing a new result flag. Wayland asks for a compositor sync after receiving an ACK from the server, while X11 asks for it right away. Fixes #78
* wayland: avoid a crash in is_effectively_synchronized()Olivier Fourdan2018-05-031-1/+4
| | | | | | | | | | | | | | | | | To check if a subsurface is effectively synchronized, we walk the subsurface hierarchy to look for a non-subsurface parent or a subsurface being synchronized. However, when client is closing, the parent surface might already be gone, in which case we end up with a surface being NULL which causes a NULL pointer dereference and a crash. Check if the parent surface is NULL to avoid the crash, and consider it's already synchronized if it is NULL to avoid further updates. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/124 (cherry picked from commit 52fdd24467fa8d6f97bd5f9eb6d5509fa43436c6)
* wayland: Let IM events go throughCarlos Garnacho2018-04-241-2/+4
| | | | | | | | | These paths implicitly relied on the forwarded IM key events having a source_device backed by a real HW device. This assumption is no longer held true since commit b5328c977. Explicitly check the INPUT_METHOD flag so they are handled as they should despite not being "real HW" events.
* xwayland: Don't abort if Xwayland crashesRay Strode2018-04-241-5/+12
| | | | | | | | | | | | | | | | | Right now if Xwayland crashes, we crash, too. On some level that makes sense, since we're supposed to control the lifecycle of Xwayland, and by it crashing we've lost that control. But practically speaking, the knock-on crash adds noise to the logs, bug trackers, and retrace servers that only makes debugging harder. And the crash isn't something mutter can "fix", since it's ultimately from a bug in Xwayland anyway. This commit makes mutter exit instead of crash if Xwayland goes away unexpectedly. (cherry picked from commit 2d80fd02e76bbe17dc52072299dda92ab88c99c0)
* xwayland: use g_autoptr for GError in xserver_diedRay Strode2018-04-241-2/+1
| | | | | | | | | | | Right now we explicitly g_clear_error any error we find, but that makes it tricky to return early from the function, which a subsequent commit will want to to do. This commit switches GError to use g_autoptr so the error clearing happens automatically. (cherry picked from commit bb6585406543688f3df48aea3211726ce52a8f29)
* wayland: Do not reset frame list when merging pending stateCarlos Garnacho2018-04-221-1/+0
| | | | | | | | In the synchronized subsurface case, the destination list may contain other elements from previous wl_surface.commit calls. Resetting the list will leave those dangling frame callbacks that will lead to invalid writes when those get to be destroyed (eg. on client shutdown).
* wayland: Plug surface pending state contents leakCarlos Garnacho2018-04-131-29/+82
| | | | | | | | | | | | | | | | | | | When moving the pending state of an effectively synchronized subsurface so it is applied together with the parent, perform a merge of the source MetaWaylandPendingState into the destination one, instead of simply overwriting the struct. The other approach had 2 kind of leaks, one that would happen everytime a wl_surface.commit happens on a sync subsurface (both surface/buffer damage regions are leaked). The other more unlikely one would apply on the rest of pending state data, happening whenever the compositor gets >1 wl_surface.commit calls on the subsurface before the parent surface gets its own. The function has also been renamed to use the more descriptive "merge" term. Related: gnome-shell#64
* Fix some spelling errorshandsome-feng2018-03-211-1/+1
| | | | https://gitlab.gnome.org/GNOME/mutter/merge_requests/45
* wayland: Add parentheses around logical ANDCarlos Garnacho2018-03-161-2/+2
| | | | As "suggested" by gcc and -Werror. Introduced by commit cb40049ec.
* wayland: Ignore IM/synthetic key events when updating XKB statewip/carlosg/fix-issue-74Carlos Garnacho2018-03-151-0/+8
| | | | | | | | | | This state tracks hardware devices' state, thus shouldn't be triggered by events that were emulated/forwarded by the IM. Those may include modifiers and would result in xkb_state being doubly set, and possibly stuck. https://gitlab.gnome.org/GNOME/mutter/issues/74 Closes: #74
* wayland: Fix wrong condition in xdg_exporter.exportCarlos Garnacho2018-03-121-4/+3
| | | | | | | | | | | Commit d714a94d9 added support for stable xdg-shell surfaces while preserving old unstable zxdg-shell v6 ones, but committed a mistake in checking for both in the xdg_exporter.export error condition paths. We want to check that the surface is neither of both. https://gitlab.gnome.org/GNOME/mutter/issues/63 Closes: #63
* wayland: Define abstract role types as actually abstractJonas Ådahl2018-02-233-9/+9
| | | | | | | They should not be instantiated by themself, only as actual roles. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
* wayland: Add support for stable xdg-shellJonas Ådahl2018-02-238-175/+2388
| | | | | | | | | | | This commit adds support for xdg_shell (the stable version). This was done by first copying the old xdg-shell unstable v6 implementation into a separate .c .h file pair (including various symbol renaming) then porting the old xdg-shell unstable v6 implementation to the new stable version. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
* wayland: Use helper to set shell surface windowJonas Ådahl2018-02-234-5/+25
| | | | | | | The helper deals with updating the surface output state. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
* wayland: Push actor state instead of itself pullingJonas Ådahl2018-02-2311-78/+306
| | | | | | | | | | | | | | | | | Make the Wayland objects push the state relevant to their role to the MetaSurfaceActor instead of MetaSurfaceActorWayland pulling the state from the associated surface. This makes the relationship between the actor and the objects that constructs it more clear; the actor is a drawable that the protocol objects control, not the other way around. This will make it easier to "detach" a surface actor from a surface, which is necessary when unmapping a window while the underlying surface is yet to be destroyed and potentially reused. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
* xwayland: Base Xwayland surface role object on the actor roleJonas Ådahl2018-02-231-3/+12
| | | | | | | | | The Xwayland role uses a MetaSurfaceActorWayland just so lets share logic related to it. As a side effect, wl_surface.enter/leave starts working for Xwayland surfaces. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
* wayland: Restructure surface role building blocks codeJonas Ådahl2018-02-2311-648/+828
| | | | | | | | | | | | | | | | | | | | | This commit moves out non-core wl_surface related code into separate code units, while renaming types to fit a common scheme. The changes done are: * ClutterActor based surface roles built upon MetaWalyandSurfaceRoleActorSurface. This object has been renamed to MetaWaylandActorSurface and related functionality has moved into meta-wayland-actor-surface.c. * The code related to roles backed by a MetaWindow (i.e. built upon MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c * The majority of subsurface related code was moved into into meta-wayland-subsurface.c and the object was renamed MetaWaylandSubsurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
* wayland/surface: Stop using deprecated g_object_newvJonas Ådahl2018-02-231-38/+38
| | | | | | | | Replace it with g_object_new_with_properties. This fixes a warning about using deprecated API. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
* wayland/xdg-shell: Minor cosmetic cleanupsJonas Ådahl2018-02-231-6/+8
| | | | | https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
* wayland/xdg-shell: Standardize xdg_positioner Wayland vfunc namingJonas Ådahl2018-02-231-32/+32
| | | | | | | | Use the convention [interface]_[request] (..) used elsewhere in the file. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
* wayland/xdg-shell: Standardize object class interface vfunc namesJonas Ådahl2018-02-231-52/+53
| | | | | | | | Follow the convention that MetaSomeObject's class vfuncs should be named meta_some_object_said_vfunc. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
* wayland: Shorten MetaWaylandSurfaceRoleShellSurface nameJonas Ådahl2018-02-236-145/+140
| | | | | | | It was annoyingly long, so rename it to MetaWaylandShellSurface. https://gitlab.gnome.org/GNOME/mutter/merge_requests/5 https://bugzilla.gnome.org/show_bug.cgi?id=791938
* wayland: Avoid clutter_input_focus method calls when unfocusedwip/carlosg/text-input-fixesCarlos Garnacho2018-02-121-0/+2
| | | | | | | | If text_input_enable() is called when there no active IM (eg. running plain mutter), some ClutterInputFocus method calls that are not allowed while unfocused will end up called, triggering critical warnings. If there is no IM return early here, all other calls are superfluous then.
* wayland: Handle NULL event node/vendor/product on tablet methodsCarlos Garnacho2018-02-092-4/+15
| | | | | | We currently don't handle NULLs on these correctly, yet they can be so when running nested. Just refrain from sending those wp_tablet(_pad) events in that case.
* wayland: Fix handling of INCR transactionsCarlos Garnacho2018-02-071-2/+2
| | | | | | | | | | The window checks in the XPropertyEvent handler were wrong both ways, so transfers would be left stale after the first chunk was dealt with. https://gitlab.gnome.org/GNOME/mutter/issues/1 Closes: #1
* wayland: Use read_all() when reading wayland selectionsCarlos Garnacho2018-02-071-7/+6
| | | | | | | | | | | Plain input stream read() calls don't provide hard guarantees about the number of bytes read, but the async method callback sort of relies on bytes being less than requested only when reaching the end of the transmitted data. If that happens mid transfer, that doesn't bode well. This is actually the behavior of g_input_stream_read_all(), so switch to using it.
* wayland: Do not fail on stalled .X11-unix entriesOlivier Fourdan2018-02-051-1/+2
| | | | | | | | | | | | | | If for whatever reason, there are stalled files in /tmp/.X11-unix/ the bind() to the abstract socket will succeed but not the bind() to the to the UNIX socket. This causes gnome-shell/mutter to fail because it cannot start Xwayland (while it could actually, by using a different display). In case of failure to bind to the UNIX socket, try the next display instead of failing, to avoid stalled entries in /tmp/.X11-unix. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/13
* wayland: send shortcut inhibit “active” eventOlivier Fourdan2018-02-051-9/+3
| | | | | | | | | | | | | | The shortcut inhibitor protocol states that the “active” event should be sent every time compositor shortcuts are inhibited on behalf of the surface. However, mutter would send that event only if the surface is focused, which might not be the case if focus is on a shell surface. Send the “active” event unconditionally to match the protocol definition. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/10
* wayland: No need to check for keyboardOlivier Fourdan2018-01-311-3/+0
| | | | | | | meta_wayland_compositor_is_shortcuts_inhibited() does not need to check if the provided source is an actual keyboard. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/8
* wayland: Bolt MetaWaylandTextInput in.Carlos Garnacho2018-01-182-0/+9
| | | | | | Offer the text-input interface global, so it can be used by clients. The MetaWaylandSeat will also let MetaWaylandTextInput intercept key events before the keyboard interface handles those.
* wayland: Let IM-processed key events go through MetaWaylandKeyboardCarlos Garnacho2018-01-181-2/+4
| | | | | Those have the "synthetic" flag as set by Clutter guts, but should be processed anyway. Perhaps a "key-repeat" flat would make sense...
* wayland: Implement text input protocolCarlos Garnacho2018-01-184-0/+675
| | | | | | | | | | | | | | | | This is the implementation of the internal text-input protocol that will be used to communicate IMs (to be implemented by gnome-shell) with clients. The text_input protocol has its own focus expressed through enter/leave events, that will typically follow the keyboard's. The client will be able to communicate its current status (eg. focus state, cursor rectangle in surface coordinates, text surrounding the cursor position, ...) and will receive commands from the compositor (eg. preedit text, committing a string, ...). Whenever there is an active input method, the compositor will route key events directly through it. The client will not receive wl_keyboard events if the event is consumed by the IM.
* protocol: Add internal text input protocolCarlos Garnacho2018-01-181-0/+302
| | | | | The text input protocol has been made internal thus far, so mutter ships an internal copy.
* wayland: shortcuts inhibitor requires a windowOlivier Fourdan2018-01-181-1/+3
| | | | | | | | | Issuing a shortcut inhibit request for a surface without a window set will lead to a crash when trying to show the shortcut inhibitor dialog. In such a case, it's safer to deny the request. https://bugzilla.gnome.org/show_bug.cgi?id=792599
* wayland: Add missing breaks on MetaWaylandSeat event handlerCarlos Garnacho2018-01-171-0/+3
| | | | | | The events might fall through if there's no corresponding active pointer/keyboard/touch interface. Barring bugs this should be safe to do, just a bit wasteful.
* wayland: send xdg-output size as size, not positionOlivier Fourdan2018-01-151-3/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=792527
* wayland: update location prior to maximizeOlivier Fourdan2018-01-112-4/+9
| | | | | | | | | | | | | | | When maximizing a window, the previous location is saved so that un-maximize would restore the same original window location. However, if a Wayland client starts with a window maximized, the previous location will be 0x0, so if we have to force placement in xdg_toplevel_set_maximized(), we should update the location as well so that the window is placed on the right monitor when un-maximizing. For that purpose, add a new flag to force the update of the window location, and use that flag from xdg_toplevel_set_maximized(). https://bugzilla.gnome.org/show_bug.cgi?id=783901
* wayland: Do not enforce a size on un-maximizeOlivier Fourdan2018-01-111-2/+11
| | | | | | | When un-maximizing, use a zero size to pass to the client so that it can use the right un-maximized size that fits. https://bugzilla.gnome.org/show_bug.cgi?id=783901
* window: Defer stack placement without a bufferOlivier Fourdan2018-01-111-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | When closing a window and showing a new one, the new one may not be granted input focus until it gets a buffer on Wayland. If another window is chosen to receive focus and raised on top of stack, the newly mapped window is focused but placed underneath that other window. Meaning that for Wayland surfaces, we need to defer adding the window to the stack until we actually get to show it, once we have a buffer attached. Rather that checking the windowing backend prior to decide if a window is stackable or not, introduce a new vfunc is_stackable() which tells if a window should be added to the stack regardless of the underlying windowing system. Also add meta_window_is_in_stack() API rather than checking the stack position directly (replacing the define WINDOW_IN_STACK only available in stack.c) and remove a window from the stack only if it is present in the stack, so that the test in meta_stack_remote() becomes irrelevant. https://bugzilla.gnome.org/show_bug.cgi?id=780820
* wayland: Ensure wl_shell_surfaces are set reactiveDaniel van Vugt2018-01-091-2/+3
| | | | | | | | | | | | | | | Wayland clients using the wl_shell interface were never receiving mouse input. It meant they also couldn't be raised with a click. This was because the call to meta_wayland_surface_set_window for wl_shell surfaces did nothing while surface->window == window already. As such, it never called clutter_actor_set_reactive() and the wl_shell window remained a non-reactive actor. Just make sure surface->window isn't already set before calling meta_wayland_surface_set_window so it can actually do what it's meant to. https://bugzilla.gnome.org/show_bug.cgi?id=790309
* build: Fix build when native backend is disabledTing-Wei Lan2018-01-091-0/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=792281
View Lorry Controller Status