summaryrefslogtreecommitdiff
path: root/src/wayland/meta-xwayland.c
Commit message (Collapse)AuthorAgeFilesLines
* wayland: Move surface check to MetaWaylandSurfaceBilal Elmoussaoui2023-05-151-10/+0
| | | | | | | Allows dropping various HAVE_XWAYLAND ifdef as the function would always return false if Mutter is built without XWayland Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2445>
* wayland: Add wl_global filter managerJonas Ådahl2023-02-131-25/+1
| | | | | | | | | | | | | | One can add a wl_global filter to a wl_display instance, which can be used to decide what clients should see what globals. This has so far been used to limit a Xwayland specific protocol extension to only Xwayland. In order to expand the logic about what globals are filtered to what clients, introduce a filter manager and port the Xwayland specific protocol filter to this new manager. Tests are added, using a new dummy protocol, to ensure that filtering is working as expected. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
* Use g_clear_fd() instead of open coding the same behaviorJonas Ådahl2023-01-301-5/+2
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2806>
* xwayland: Add support for byte-swapped clientsOlivier Fourdan2023-01-171-0/+7
| | | | | | | | | | | | Instructs Xwayland to allow/disallow connections from X11 clients with a different endianess based on the "xwayland-allow-byte-swapped-clients" setting. This option has no effect if Xwayland does not support the command option +byteswappedclients/-byteswappedclients. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2576 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2785>
* wayland: Drop HAVE_XSETIOERROREXITHANDLER checksCarlos Garnacho2023-01-121-7/+2
| | | | | | | | | | | | | | | This define was dropped by commit 0e8aaebc00f (xwayland: Make XSetIOErrorExitHandler() mandatory), but some #ifdef checks were brought back by commit 36f30341acb (wayland: Add a prepare-shutdown signal). Since there's no define anymore in config.h, these pieces of code were unintentionally disabled, and a meta_get_display() call be also left over. Remove the ifdefs and update the code to build again. Fixes: 36f30341acb - wayland: Add a prepare-shutdown signal Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2786>
* wayland: Move Xwayland specific call to xwaylandBilal Elmoussaoui2023-01-031-0/+26
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2399>
* wayland: Add a prepare-shutdown signalBilal Elmoussaoui2023-01-031-54/+65
| | | | | | | This allows moving the xwayland shutdown logic to the xwayland implementation Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2399>
* build: Allow disabling xwaylandBilal Elmoussaoui2023-01-031-0/+2
| | | | | | | | | | Mostly moving things around to allow a build without xwayland. Note that more work might still be needed once the x11 build option lands as that would allow us to have a proper xwayland only build without the x server part. Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2272 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2399>
* wayland: Setup and use ownership chainsJonas Ådahl2022-12-171-27/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As elsewhere, make sure objects that need to have a ownership up to the context, and use this ownership chain to find relevant components, such as the backend or the Wayland compositor object instance. wayland/data-device: Hook up data devices to seats They are tied to a seat - make that connection in struct fields too, so that related objects can get to the context via it. wayland: Don't get Wayland compositor via singleton getter This means via the ownership chain or equivalent. xwayland: Hook up manager to Wayland compositor Same applies to the drag-n-drop struct. xwayland: Make X11 event handling compositor instance aware This avoids finding it via singletons in the callee. xwayland: Don't get Wayland compositor from singleton xwayland: Pass manager when handling dnd event window/xwayland: Don't get Wayland compositor from singleton xwayland/grab-keyboard: Don't get backend from singleton xwayland: Don't get backend from singleton wayland: Always get the backend from the context This means traveling up the ownership chain or equivalent when necessary. wayland: Hook up data devices, offers and sources to the compositor This allows tying them to a context without going through any singletons. wayland: Don't get display from singleton xwayland: Don't get display from singleton tablet: Don't get display from singleton Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
* xwayland: Make XSetIOErrorExitHandler() mandatoryJonas Ådahl2022-12-171-19/+13
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
* wayland/surface: Prepare for decoupled surface & resource lifetimesMichel Dänzer2022-12-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Need to deal with surface->resource == NULL and surface->pending_state == NULL in some places. v2: * Avoid expanding conditions to multiple lines. (Georges Basile Stavracas Neto) v3: * Use a single bailout condition in meta_wayland_client_owns_window as well. v4: * Remove spare empty line in meta_wayland_surface_apply_state. (Robert Mader) * Add wl_resource_post_error calls in xdg-shell request handlers. (Robert Mader) * Drop checks in functions which can only be called if there's a valid resource. * Drop more checks which are unnecessary due to leaving the SURFACE_DESTROY signal emission in wl_surface_destructor later. v5: * Move resource = surface->resource assignments to if (!resource) tests. (Jonas Ådahl) v6: * Fix style issue per check-style.py. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
* xwayland: Always require X11 authenticationmsizanoen12022-10-211-19/+0
| | | | | | | | | | | | | | | This reverts commit eac227a203dba4d45398dfb85ec5b4610b5f3be7. Currently, Flatpak applications can bypass the X11 permission setting and access the X server through abstract sockets because X11 authentication is not enforced for the current user ID. Fix this by always requiring X11 authentication for Xwayland. This also means applications without XAUTHORITY set to the file with Mutter's Xwayland credentials cannot connect to X, including apps launched from VT or SSH. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2633>
* xwayland: Move "code like" declarations to the bottomJonas Ådahl2022-09-191-8/+7
| | | | | | They'll be closer to the code but still after the "boring" declarations. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2619>
* xwayland: Remove stray newlineJonas Ådahl2022-05-311-1/+0
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
* xwayland: Add API to send signal to the Xwayland processJonas Ådahl2022-05-311-0/+16
| | | | | | Will be used for test cases to fake-crash the Xwayland process. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
* xwayland: Only warn on X IO errors when X11 is mandatoryJonas Ådahl2022-05-311-1/+11
| | | | | | | This avoids warnings when we're just slightly unlucky when Xwayland went away due to inactivity. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
* xwayland: Init DnD on every Xwayland startOlivier Fourdan2022-03-301-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, meta_xwayland_shutdown_dnd() is called from the handler on_x11_display_closing() triggered from the signal "x11-display-closing" hooked up from meta_xwayland_init_display(). Once the signal has been triggered, on_x11_display_closing() removes the signal handler, disconnecting from the signal. As meta_xwayland_init_display() is called from meta_display_new() which is issued only once, the signal handler is not restored again. As a result, meta_xwayland_shutdown_dnd() is not called anymore after Xwayland has been restarted, but meta_xwayland_init_dnd() will check and assert that the manager's DND object is NULL. Basically, restarting Xwayland more that once will trigger an assertion failure in mutter. That's even more of a problem with autoclose-xwayland where Xwayland is expected to terminate when there is no meaningful X11 client remaining, which can happen multiple times during the lifetime of a user session. To make sure that meta_xwayland_init_display() is called for every new instance of Xwayland, simply keep the signal hooked in place by not disconnecting it when triggered. This reverts commit 9a10b8ff94cc9506a4ecd8ade7489fa9a5af406a. Even though, originally, this issue was first introduced with commit b4fe1fdd95d52e8625c66ded1ec7162371dcf32b ("xwayland: Make setup/teardown a bit more symmetrical") which didn't actually kept 'x11-display-setup' and 'x11-display-closing' connected. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2168 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2339>
* xwayland: Relax the ownership requirements of /tmp/.X11-unixSebastian Wick2022-02-071-7/+27
| | | | | | | | | | | | | | | | | The `ensure_x11_unix_perms` function tries to detect systems on which /tmp/.X11-unix is owned by neither root nor ourselves because in that case the owner can take over the socket we create (symlink races are fixed in linux 800179c9b8a1e796e441674776d11cd4c05d61d7). This should not be possible in the first place and systems should come with some way to ensure that's the case (systemd-tmpfiles, polyinstantiationm …). That check however only works if we see the root user namespace which might not be the case when running in e.g. toolbx. This change relaxes the requirements such that in the root user namespace we detect and abort if a vulnerable system is detected but unconditionally run in toolbx. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2261>
* xwayland: Warn when autoclose-xwayland is not usableOlivier Fourdan2022-01-281-6/+17
| | | | | | | | | | | | | The experimental feature "autoclose-xwayland" requires a couple of prerequisites: 1. Be able to (re)start Xwayland on demand, i.e. with systemd 2. Xwayland must support the terminate delay Add a warning message if "autoclose-xwayland" was requested but any of those prerequisites is not met. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2258>
* xwayland: Remove stop xserver timeoutOlivier Fourdan2022-01-281-71/+0
| | | | | | | | | | | | | | | | | | | | | | Since commit 226afa24a - "Use Xwayland auto-terminate feature", the callback function shutdown_xwayland_cb() does not check for the autoclose-xwayland experimental feature anymore. As a result, when running nested or outside of systemd, gnome-shell/mutter would quit after 10 seconds unless some X11 window was mapped. But now that we rely on Xwayland's own terminate feature, there really is no need to use any xserver timeout function anymore. We do not need to keep track of X11 windows being created or unmapped, as again, Xwayland does all that for us at the client level. Remove all this code that we do not need anymore. fixes: 226afa24a - Use Xwayland auto-terminate feature Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2258>
* xwayland: Use Xwayland auto-terminate featureOlivier Fourdan2022-01-261-153/+16
| | | | | | | | | | | | When using Xwayland-on-demand (default), if the (experimental) autoclose features is enabled, we can rely on Xwayland's auto-terminate feature instead of explicitly killing the Xwayland process. With it, gone is the mechanism that was added to check the X11 clients connected and their executable to check whether we can (safely) kill Xwayland. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
* xwayland: Mark our X11 connection terminatableOlivier Fourdan2022-01-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The connection to the Xserver for the X11 window manager part of mutter even on Wayland may prevent the Xserver from shutting down. Currently, what mutter does is to check the X11 clients still connected to Xwayland using the XRes extension, with a list of X11 clients that can be safely ignored (typically the GNOME XSettings daemon, the IBus daemon, pulseaudio and even mutter window manager itself). When there is just those known clients remaining, mutter would kill Xwayland automatically. But that's racy, because between the time mutter checks with Xwayland the remaining clients and the time it actually kills the process, a new X11 client might have come along and won't be able to connect to Xwayland that mutter is just about to kill. Because of that, the feature “autoclose-xwayland” is marked as an experimental feature in mutter and not enabled by default. Thankfully, the Xserver has all it takes to manage that already, and is even capable of terminating itself once all X11 clients are gone (the -terminate option on the command line). With XFixes version 6, the X11 clients can declare themselves "terminatable", so that the Xserver could simply ignore those X11 clients when checking the remaining clients and terminate itself automatically. Use that mechanism to declare mutter's own connection to the Xserver as "terminatable" when Xwayland is started on demand so that it won't hold Xwayland alive for the sole purpose of mutter itself. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
* xwayland: Don't remove /tmp/.X11-unix/X0 when running testsJonas Ådahl2021-12-191-9/+14
| | | | | | | | | | | | | | | | | | When Xwayland was not initalized, we'd still clean things up. What this accidentally meant was that the uninitialized display number 0 was cleanud up, which very likely was main display of the host session. What this meant in practice was that /tmp/.X11-unix/X0 was often removed, causing every Flatpak X11 application to fail to start until Xwayland was restarted nad the X0 socket file was restored. Fix this in two ways: firstly only shutdown Xwayland if we ever started it, i.e. if the X11 display policy was not 'disabled'. This should fix the issue most of the times. Secondly only clean up the socket if it was ever initialized. This should fix things if the socket creation failed, as if it did, the name would be set. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2162>
* xwayland: Handle the died callback being cancelled more gracefullyJonas Ådahl2021-12-071-4/+6
| | | | | | | | If we were cancelled, it could mean we teared down, meaning fetching manager instances will attempt to fetch past freed instances. Handle this by waiting with the fetching until we know we weren't cancelled. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2140>
* xwayland: Unset shutdown idle id when source removed by callbackJonas Ådahl2021-10-261-1/+4
| | | | | | | We failed to do this when the experimental "auto-close Xwayland" setting was not enabled. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
* xwayland: Trap errors when setting primary RANDR outputJonas Ådahl2021-10-261-0/+3
| | | | | | | | This will be crucial when we start to remove the global directly when an output is removed, as that means Xwayland might have removed the output before we managed to get our queries in. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
* xwayland: Setup RANDR integration with MetaX11DisplayJonas Ådahl2021-10-261-9/+11
| | | | | | | This doesn't gain us anything right away, but will allow us to trap errors, which will soon be necessary. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
* xwayland: Init/shutdown DND using MetaX11DisplayJonas Ådahl2021-10-261-3/+3
| | | | | | | Before it was passed an Display pointer, and had to e.g. fetch the root window from GDK instead of the MetaX11Display. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
* xwayland: Make setup/teardown a bit more symmetricalJonas Ådahl2021-10-261-22/+35
| | | | | | | | | | | | | | | | | | | | | | We setup Xwayland in an early phase of the X11 display, before we had a MetaX11Display, and teared down in a couple of places happening when tearing down the Xwayland integration if the X server died or terminated. It was a bit hard to follow what happened and when it happened. Attempt to clean this up a bit, with things being structured as follows: * Early during X11 display connection setup, only setup the rudimentary X11 hooks, being the libX11 error callbacks, and adding the local user to XHost. * Move "initialize Xwayland component" code to a new 'x11-display-setup' signal handler. Things setup here are cleaned up in the 'x11-display-closing' handler. * Connect to 'x11-display-setup' and 'x11-display-closing' up front, and stay connected to these two. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
* xwayland: Pass the manager object to XSetIOErrorExitHandlerJonas Ådahl2021-10-261-3/+2
| | | | | | This means we can avoid going through global singletons in the handler. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
* wayland: Plug leak in error conditionCarlos Garnacho2021-10-251-0/+1
| | | | | | | If we fail to bind the X11 socket, free the lock file string. CID: #1505865 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2061>
* xwayland: Initialize g_autofree with NULLDor Askayo2021-09-041-3/+3
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1990>
* context: Move X11 display policy under the contextJonas Ådahl2021-07-151-8/+19
| | | | | | | | The context implementations already effectively dictate the policy, so let them do it more directly instead of going indirectly via global variables. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
* xwayland: Pass MetaWaylandCompositor pointer when initializingJonas Ådahl2021-05-181-3/+5
| | | | | | | | This way we can initialize without having any way to retrieve it via some global variable. This isn't needed now, but will be once Wayland infrastructure initializiation is done in a single step. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1863>
* xwayland: Don't fetch global when shutting down DNDJonas Ådahl2021-05-181-4/+5
| | | | | | | | | | It might not be there when shutting down, so get it from a more managed place. Note that this isn't strictly needed right now, but eventually, the MetaWaylandCompositor pointer will be cleared using a g_clear*() helper, which clears the pointer before freeing the instance, which wouldn't work here. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1863>
* Rename MetaDisplayPolicy to MetaX11DisplayPolicyJonas Ådahl2021-05-171-7/+7
| | | | | | | This lack of X11 in the name was a bit confusing, since this is about the X11 policy, not some policy of MetaDisplay. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1833>
* xwayland: Check the condition on displayfd readyOlivier Fourdan2021-05-111-1/+1
| | | | | | | | | | The callback on_displayfd_ready() would unconditionally set the return value to TRUE, regardless of the condition. Use the GIO condition to determine if there was data written and adjust the return value accordingly. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1851>
* xwayland: Handle shutting down without having startedJonas Ådahl2021-05-061-3/+8
| | | | | | | | | We initialize, but might not start, e.g. when a test case just needs a backend and doesn't start mutter. When cleaning up, we'll still try to clean up Xwayland integration, and this commit handles cleaning up without having made the mess. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1856>
* wayland: Terminate Xwayland when shutting downJonas Ådahl2021-05-051-3/+12
| | | | | | | This is less confusing to Xwayland than suddenly loosing the Wayland socket connection. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
* main: Tear down Wayland support before MetaDisplayJonas Ådahl2021-05-051-0/+2
| | | | | | | | | | | | | MetaDisplay does a lot of things, and is a central part to anything window management. To let Wayland units have an easier time tearing down, make it so that the Wayland infrastructure is terminated before MetaDisplay. This also makes sure that X11 support is turned off, so that we don't stumble upon Xwayland terminating due to the Wayland socket connection being broken. Will mitigate that in a better way in a later commit. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
* xwayland: Set libX11 error handlers to no-ops before terminatingJonas Ådahl2021-05-051-0/+21
| | | | | | | | | | | | | | We might not be the only entity holding on to the X11 GdkDisplay, meaning the X11 connection will stay alive indefinitely, e.g. if the gjs context has some reference to it. Avoid running into issues due to X11 connection errors by setting the libX11 handlers to no-ops, so when we are terminating; that means the GDK X11 connection can stay "alive" until its too late, and we'll just silently ignore any connection errors that may happen due to the lingering GDK display reference. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
* xwayland: Check permissions on /tmp/.X11-unixOlivier Fourdan2021-03-181-1/+44
| | | | | | | | | | | | | | | | | | For Xwayland, mutter creates the sockets in the standard /tmp/.X11-unix directory. Yet, if that directory already exists, it may have been created by another user with full control over the created socket. To avoid that issue, if the directory /tmp/.X11-unix already exists, check that the permissions are as we expect, i.e. the directory belongs to either root or the user herself, is writable and has the sticky bit. Thanks to fabian@ritter-vogt.de for reporting that issue. https://gitlab.gnome.org/GNOME/mutter/-/issues/1708 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1787>
* xwayland: Use defines for X11 directory and pathOlivier Fourdan2021-03-181-7/+12
| | | | | | | | | Rather than repeating the same strings for X11 directory and path all around the code, use a define. No functional change. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1787>
* xwayland: Fix some FD leaks on error pathsPhilip Withnall2021-02-241-5/+24
| | | | | | | | | | | | | | | If `meta_xwayland_start_xserver()` returned via an error path, some of the socket FDs were leaked. Fix that, and add `steal_fd()` calls to make it clearer that FDs passed to `g_subprocess_launcher_take_fd()` are transferred to it. There were no bugs with how `GSubprocessLauncher` was being used. Spotted while working on https://gitlab.gnome.org/GNOME/glib/-/issues/2332. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1738>
* xwayland: Check for listenfd optionOlivier Fourdan2021-01-221-3/+9
| | | | | | | | | | | Current Xwayland has marked the command line option "-listen" as deprecated in favor of "-listenfd". Use the pkg-config variable "have_listenfd" (if available) from Xwayland to determine if we should use that option, to avoid a deprecation warning when spawning Xwayland. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1682>
* xwayland: Do not retry the same displayOlivier Fourdan2021-01-211-12/+16
| | | | | | | | | | | | | | | | | | | | Mutter listens to two display connections, one for regular X11 clients and another one for the so called "managed services". Once an available display number is found for the regular X11 clients, mutter would then redo the work to find another available display number for the managed services. Yet, it does so starting from the same initial display, which is a waste of time since it just tried all displays to find the first available one, so all these, including the regular display it just took, are now in use. So instead of starting over from the beginning when looking for a display available for the managed services, continue from the next display immediately after the one we found precedently. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1680>
* xwayland: Do not rely on X-lock filesOlivier Fourdan2021-01-211-20/+8
| | | | | | | | | | | | | | | | | Some X11 servers may not always create a lock file, yet mutter uses the lock file to find a possible display number and then tries to bind to the socket corresponding to that display number. If it fails to bind, it will simply bail out. As a result, if an X11 server is already listening on that display but hadn't created a lock file, mutter won't be able to start Xwayland. To avoid that possible issue, make mutter retry with another display for a given number of tries when binding fails even though the display was supposed to be available based on the lock file presence. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1604 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1669>
* xwayland: Check for X11 unix directory only onceOlivier Fourdan2021-01-211-3/+3
| | | | | | | | | | | | | The function choose_xdisplay() calls open_display_sockets() which calls ensure_x11_unix_dir(). We don't need to do that from within the loop though, as the directory /tmp/.X11-unix is the same regardless of the display number. Move the call to ensure_x11_unix_dir() from open_display_sockets() to choose_xdisplay() prior to enter the display loop. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1669>
* xwayland: Propagate error if display sockets failedOlivier Fourdan2021-01-211-1/+2
| | | | | | | | | In case of failure to open the display sockets, we would not propagatre the error which can cause a crash when trying to show the error message. Properly propagate the error to avoid the crash. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1669>
* xwayland: Start Xwayland on connection to either public X11 socketJames Henstridge2021-01-211-2/+11
| | | | | | | Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1454 (cherry picked from commit 7b2815077fa1053069e00c0a21b2c3038f4b0d1c) Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1669>
View Lorry Controller Status