summaryrefslogtreecommitdiff
path: root/src/wayland
Commit message (Collapse)AuthorAgeFilesLines
* 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
* wayland: Only send full sequences of touch events to clientsCarlos Garnacho2017-12-211-6/+12
| | | | | | | | | | | | If input happens to be grabbed somewhere along the shell, and ungrabbed while a touch operation is ongoing, the wayland bits will happily start sending wl_touch.update events from an undeterminate point, without clients having ever received wl_touch.down for that id. Consider those touches grabbed for the entirety of their lifetime, if wl_touch.down wasn't received by the client, no other events will. https://bugzilla.gnome.org/show_bug.cgi?id=776220
* wayland/keyboard: preserve layout indexOlivier Fourdan2017-12-201-2/+4
| | | | | | | | | | | | | | | | | On VT switch, the xkb state layout index is lost and reset to the first group, so if the first layout is not the last one being used, the xkb state used in both meta-wayland-keyboard.c and clutter/evdev will be desynchronized with the keyboard source indicator in the gnome-shell UI. Save the effective layout chosen along with the seat so it can be restored when reclaiming devices. Use the saved layout index from the clutter/evdev's seat to restore the layout in meta-wayland-keyboard, so that switching VT doesn't reset the layout and causes further discrepancies with the layout indicator in the gnome-shell UI. https://bugzilla.gnome.org/show_bug.cgi?id=791383
* wayland: Add Xwayland grab keyboard supportOlivier Fourdan2017-12-184-0/+392
| | | | | | | | | | | | | | | | | This protocol is limited to Xwayland only and is not visible/usable by any other client. Mutter uses the following mechanisms to determine if an X11 client should be granted a grab: - is "xwayland-allow-grabs" set? - if set, is the client blacklisted? - otherwise, has the client set the X11 window property _XWAYLAND_MAY_GRAB_KEYBOARD on the window using a client message? - if not, is it a client white-listed either via the default system list or the settings "xwayland-grab-access-rules"? https://bugzilla.gnome.org/show_bug.cgi?id=783342
* xwayland: add _XWAYLAND_MAY_GRAB_KEYBOARD propertyOlivier Fourdan2017-12-182-0/+68
| | | | | | | | | | | | | | | | | | Add a new client message "_XWAYLAND_MAY_GRAB_KEYBOARD" that X11 clients can use to tell mutter this is a well behaving X11 client so it may grant the keyboard grabs when requested. An X11 client wishing to be granted Xwayland grabs by gnome-shell/mutter must send a ClientMessage to the root window with: - message_type set to "_XWAYLAND_MAY_GRAB_KEYBOARD" - window set to the xid of the window on which the grab is to be issued - data.l[0] to a non-zero value Note: Sending this client message when running a plain native X11 environment would have no effect. https://bugzilla.gnome.org/show_bug.cgi?id=783342
* xwayland: Add MetaWindowXwaylandOlivier Fourdan2017-12-182-0/+102
| | | | | | | | MetaWindowXwayland derives from MetaWindowX11 to allow for some Xwayland specific vfunc that wouldn't apply to plain X11 windows, such as shortcut inhibit routines. https://bugzilla.gnome.org/show_bug.cgi?id=783342
* wayland-outputs: Delay wl_output destructionRui Matos2017-12-151-1/+22
| | | | | | | | This tries to avoid wayland clients getting disconnected for binding to a wl_output that we already destroyed which is a known protocol race condition, see https://phabricator.freedesktop.org/T7722 . https://bugzilla.gnome.org/show_bug.cgi?id=789070
* wayland: Add xdg-output supportOlivier Fourdan2017-12-153-5/+194
| | | | | | | | | | | | | | | | | | The xdg-output protocol aims at describing outputs in way which is more in line with the concept of an output on desktop oriented systems. For now it just features the position and logical size which describe the output position and size in the global compositor space. This is however much useful for Xwayland to advertise the output size and position to X11 clients which need this to configure their surfaces in the global compositor space as the compositor may apply a different scale from what is advertised by the output scaling property (to achieve fractional scaling, for example). This was added in wayland-protocols 1.10. https://bugzilla.gnome.org/show_bug.cgi?id=787363
* wayland/xdg-shell: Dismiss a popup on map if parent already dismissedJonas Ådahl2017-11-301-0/+6
| | | | | | | | | | If a parent doesn't have a window, it means it could have been dismissed (for example due to a input serial race), but the more recent popup might win the input serial race and try to map anyway. This would result in a crash later on when trying to process the placement rule, as the parent already has no window. https://bugzilla.gnome.org/show_bug.cgi?id=790358
* wayland/xdg-shell: Check popup parent type when assigningJonas Ådahl2017-11-301-0/+8
| | | | | | | We only allow mapping popups on top of surfaces with a xdg_surface based role. Add a check and fail clients that doesn't follow this rule. https://bugzilla.gnome.org/show_bug.cgi?id=790358
* wayland/xdg-shell: Fix top-most check when grabbingJonas Ådahl2017-11-301-16/+14
| | | | | | | | | | | | | Move the top-most-popup correctness check to the finish_popup_setup() function after checking the serial. If we pass the serial check, we should have reached a state that if there are any popups they should be the one from the same client. Also avoid failing a client that correctly set the top-most popup at map time, but where at the time of processing the top most popup have already been dismissed by the compositor for some arbitrary reason. https://bugzilla.gnome.org/show_bug.cgi?id=790358
* wayland/keyboard: Apply sticky keys masksOlivier Fourdan2017-11-162-0/+71
| | | | | | | | | | | MetaWaylandKeyboard maintains its own xkb_state used to update Wayland clients. Add the necessary hooks to make sure the sticky keys modifier masks set in clutter-evdev are also applied in MetaWaylandKeyboard's xkb_state so that Wayland clients also benefit from sticky keys. https://bugzilla.gnome.org/show_bug.cgi?id=788564
* wayland: Disable AccessX in XwaylandOlivier Fourdan2017-11-161-0/+1
| | | | | | | | Keyboard accessibility features in Wayland are handled in the compositor, we do not want AccessX in Xwayland to interfere with the compositor. https://bugzilla.gnome.org/show_bug.cgi?id=788564
* window/wayland: Handle resizing when headlessJonas Ådahl2017-11-101-2/+6
| | | | | | | | We tried to get the geometry scale, which may depend on the main logical monitor assigned to the window. To avoid dereferencing a NULL logical monitor when headless, instead assume the geometry scale is 1. https://bugzilla.gnome.org/show_bug.cgi?id=788764
* wayland: Plug leakCarlos Garnacho2017-11-071-1/+5
| | | | | | The remote DBus error is leaked. https://bugzilla.gnome.org/show_bug.cgi?id=789984
* wayland/keyboard: Don't transfer layout group when replacing xkb stateJonas Ådahl2017-11-021-5/+6
| | | | | | | | | | | | | The layout group determines what actual keyboard layout in the keymap to use when translating modifier state and key codes to key syms. When changing a keymap to another, the layout groups has no relation to the layout groups in the old keymap, thus there is no reason to transfer it to the new state. This fixes an issue where the xkb state in meta-wayland-keyboard.c got desynchronized with the xkb state in clutter-device-manager-evdev.c. https://bugzilla.gnome.org/show_bug.cgi?id=789300
* wayland/surface: Disconnect actor handlers before unassigning roleJonas Ådahl2017-10-271-9/+10
| | | | | | | | | | | The handlers depend on a role being assigned. Destroying the window causes it to become unmapped, which would sometimes trigger one of the handlers, resulting in an is-assigned assert hitting in one of the handlers. Avoid this by disconnecting the handlers earlier, so that there is no risk that any them being triggered before the role is assigned. https://bugzilla.gnome.org/show_bug.cgi?id=789552
* wayland: Allow Xwayland to leave core dumpsDaniel van Vugt2017-10-262-12/+33
| | | | | | | | | | | | For historical Xorg-reasons, Xwayland would disable its own core dumps by default. This is a problem because Xwayland crashing is the biggest cause of gnome-shell crashes [1][2], and we still have no idea why due to there being no dumps from Xwayland. So enable core dumping from Xwayland. https://bugzilla.gnome.org/show_bug.cgi?id=789086 [1] https://bugs.launchpad.net/bugs/1505409 [2] https://bugs.launchpad.net/bugs/1556601
* wayland: Update pointer confinement on surface actor relocationsCarlos Garnacho2017-10-261-0/+28
| | | | | | | | In the unlikely case that a surface is moved by the compositor while holding a pointer confinement, we also need to update the pointer position when the surface actor gets moved. https://bugzilla.gnome.org/show_bug.cgi?id=782344
* wayland: Trigger wl_output updates on actor position changesCarlos Garnacho2017-10-261-9/+66
| | | | | | | | | | | | | | | Both notify::position on the surface actor and position-changed on MetaWindow are listened to, in order to trigger wl_output updates for wl_surfaces whenever the surfaces move across them. Both signals are necessary in order to cater for toplevel and subsurface relocations (Because it's the parent window actor what changes position in this last case). Also, shuffle signal disconnection, so each signal goes away with the object reference held by MetaWaylandSurface. https://bugzilla.gnome.org/show_bug.cgi?id=782344
* backends: add 'monitors-updated-internal' signal to only update internal stateMarco Trevisan (Treviño)2017-10-131-1/+1
| | | | | | | Adding an internal signal and use it to update the internal state before emitting "monitors-changed" which will be repeated by the screen to the world. https://bugzilla.gnome.org/show_bug.cgi?id=788860
* wayland-dma-buf: Don't send modifiers to old clientsDaniel Stone2017-10-051-1/+8
| | | | | | | | | | | The modifier event was only added in v3 of the client; sending it to older clients (e.g. GStreamer waylandsink) causes them to disconnect immediately. Send the older 'format' event to all clients, and only send the newer 'modifier' event to resource versions 3 or above. https://bugzilla.gnome.org/show_bug.cgi?id=788558
* wayland: Send edge constraintsGeorges Basile Stavracas Neto2017-10-033-10/+119
| | | | | | | | | | | Following up the previous patch, this patch makes the Wayland backend send the edge constraints through a custom protocol extension internal to GTK. As it mature, we can think of upstreaming the protocol to Wayland itself. https://bugzilla.gnome.org/show_bug.cgi?id=751857
* wayland/surface: Send buffer release events immediatelyJonas Ådahl2017-09-281-1/+1
| | | | | | | | | Just queuing the buffer release event is prone to starvation, so send the release immediately. See https://lists.freedesktop.org/archives/wayland-devel/2017-September/035147.html for more detailed explanation. https://bugzilla.gnome.org/show_bug.cgi?id=788197
* wayland: do not leak shortcut inhibit dataOlivier Fourdan2017-09-141-3/+8
| | | | | | | | | | | We would free the shortcut inhibit data only when the client destroys its request, which is not the case when the clients itself is destroyed, leading to a leak of the shortcut inhibit data. Free the data on resource destruction instead, and simply destroy the resource on destroy request. https://bugzilla.gnome.org/show_bug.cgi?id=787568
* wayland: Keep the inhibit shortcut dialogOlivier Fourdan2017-09-143-6/+13
| | | | | | | | | | | | | | | | | | | | | On Wayland, the grab()/ungrab() in gtk+/gdk are wired to the shortcut inhibitor mechanism, which in turn shows the dialog, which can take focus away from the client window when the dialog is shown. If the client issues an ungrab() when the keyboard focus is lost, we would hide the dialog, causing the keyboard focus to be returned to the client surface, which in turn would issue a new grab(), so forth and so on, causing a continuous show/hide of the shortcut inhibitor dialog. To avoid this issue, keep the dialog around even if the shortcut inhibit is canceled by the client, so that the user is forced to make a choice that we can reuse on the next request without showing the dialog again. Instead of hiding the dialog when the shortcut inhibitor is destroyed by the client, we simply mark the request as canceled and do not apply the user's choice. https://bugzilla.gnome.org/show_bug.cgi?id=787568
* wayland/inhibit-shortcuts-dialog: Use g_new0 instead of g_newJonas Ådahl2017-09-141-1/+1
| | | | | | | The code assumed the newly allocated blocked was initialized to 0, but it wasn't since g_new was used. Fix that by using g_new0. https://bugzilla.gnome.org/show_bug.cgi?id=787570
* wayland: Don't free non-transferred string when cleaning upJonas Ådahl2017-09-041-3/+6
| | | | | | | | | When cleaning up the display name string management, the display name string retrieved from libwayland-server was also passed to free() on clean up. This is invalid as the display name string ownership is not transferred to us. Fix this by strdup:ing the string before saving it. https://bugzilla.gnome.org/show_bug.cgi?id=730551
* window: Handle being headless betterJonas Ådahl2017-08-301-3/+7
| | | | | | | | This avoids updating state (such as position, size etc) when going headless. Eventually, when non-headless, things will be updated again, and not until then will we be able to update to a valid state. https://bugzilla.gnome.org/show_bug.cgi?id=730551
* wayland: Don't free the Wayland display name string too earlyJonas Ådahl2017-08-301-4/+4
| | | | | | | We accidentally freed the Wayland display name string, meaning retrieving it later retrieved freed memory. https://bugzilla.gnome.org/show_bug.cgi?id=730551
* wayland/output: Flush clients after creating wl_output globalJonas Ådahl2017-08-303-0/+11
| | | | | | | | In order to give the clients the best chance to bind the wl_output before we later remove it (for example on fast hot plugs or in the test suite), flush the client sockets after creating the global. https://bugzilla.gnome.org/show_bug.cgi?id=730551
* wayland/xdg-foreign: Move out ID generation helper to util.cJonas Ådahl2017-08-291-16/+3
| | | | | | It'll be used to generate ID in the same way in other places later. https://bugzilla.gnome.org/show_bug.cgi?id=784199
View Lorry Controller Status