1. 26 Oct, 2021 6 commits
  2. 25 Oct, 2021 1 commit
  3. 04 Sep, 2021 1 commit
  4. 15 Jul, 2021 1 commit
  5. 18 May, 2021 2 commits
    • Jonas Ådahl's avatar
      xwayland: Pass MetaWaylandCompositor pointer when initializing · dc97163b
      Jonas Ådahl authored and Marge Bot's avatar Marge Bot committed
      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: <!1863>
      dc97163b
    • Jonas Ådahl's avatar
      xwayland: Don't fetch global when shutting down DND · 5bc88237
      Jonas Ådahl authored and Marge Bot's avatar Marge Bot committed
      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: <!1863>
      5bc88237
  6. 17 May, 2021 1 commit
  7. 11 May, 2021 1 commit
  8. 06 May, 2021 1 commit
    • Jonas Ådahl's avatar
      xwayland: Handle shutting down without having started · 4490d452
      Jonas Ådahl authored
      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: <!1856>
      4490d452
  9. 05 May, 2021 3 commits
    • Jonas Ådahl's avatar
      wayland: Terminate Xwayland when shutting down · c614cc3e
      Jonas Ådahl authored and Marge Bot's avatar Marge Bot committed
      This is less confusing to Xwayland than suddenly loosing the Wayland
      socket connection.
      
      Part-of: <!1822>
      c614cc3e
    • Jonas Ådahl's avatar
      main: Tear down Wayland support before MetaDisplay · 799c6dcf
      Jonas Ådahl authored and Marge Bot's avatar Marge Bot committed
      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: <!1822>
      799c6dcf
    • Jonas Ådahl's avatar
      xwayland: Set libX11 error handlers to no-ops before terminating · b71f52ff
      Jonas Ådahl authored and Marge Bot's avatar Marge Bot committed
      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: <!1822>
      b71f52ff
  10. 18 Mar, 2021 2 commits
    • Olivier Fourdan's avatar
      xwayland: Check permissions on /tmp/.X11-unix · 1f1bf4cd
      Olivier Fourdan authored
      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.
      
      #1708
      
      Part-of: <!1787>
      1f1bf4cd
    • Olivier Fourdan's avatar
      xwayland: Use defines for X11 directory and path · 7b5e8550
      Olivier Fourdan authored
      Rather than repeating the same strings for X11 directory and path all
      around the code, use a define.
      
      No functional change.
      
      Part-of: <!1787>
      7b5e8550
  11. 24 Feb, 2021 1 commit
  12. 22 Jan, 2021 1 commit
    • Olivier Fourdan's avatar
      xwayland: Check for listenfd option · 22b926ee
      Olivier Fourdan authored
      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: <!1682>
      22b926ee
  13. 21 Jan, 2021 6 commits
    • Olivier Fourdan's avatar
      xwayland: Do not retry the same display · 26cc51a1
      Olivier Fourdan authored
      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: <!1680>
      26cc51a1
    • Olivier Fourdan's avatar
      xwayland: Do not rely on X-lock files · eb06d9e1
      Olivier Fourdan authored
      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: #1604
      Part-of: <!1669>
      eb06d9e1
    • Olivier Fourdan's avatar
      xwayland: Check for X11 unix directory only once · f6b4665b
      Olivier Fourdan authored
      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: <!1669>
      f6b4665b
    • Olivier Fourdan's avatar
      xwayland: Propagate error if display sockets failed · 1bd42e87
      Olivier Fourdan authored
      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: <!1669>
      1bd42e87
    • James Henstridge's avatar
      xwayland: Start Xwayland on connection to either public X11 socket · 063db30c
      James Henstridge authored and Olivier Fourdan's avatar Olivier Fourdan committed
      Fixes: #1454
      (cherry picked from commit 7b281507)
      
      Part-of: <!1669>
      063db30c
    • James Henstridge's avatar
      Revert "wayland: Drop Xwayland abstract socket" · df4b6d4c
      James Henstridge authored and Olivier Fourdan's avatar Olivier Fourdan committed
      This reverts commit e2123768.  Various
      container/chroot (e.g. Snaps, pressure-vessel) systems still depend on
      the presence of the abstract X11 socket.
      
      Closes: #1613
      (cherry picked from commit ea2192c4)
      
      Part-of: <!1669>
      df4b6d4c
  14. 20 Jan, 2021 1 commit
    • Carlos Garnacho's avatar
      wayland: Handle forced Xwayland shutdown elegantly · 56718887
      Carlos Garnacho authored
      In the shutdown paths we check with the X11 display whether there's
      remaining clients. However this happens in paths that happen after
      the MetaX11Display vanished in the case of Xwayland crash.
      
      Since in that situation the clients are forcibly vanishing too,
      skip the client check.
      
      Part-of: <!1677>
      56718887
  15. 19 Jan, 2021 1 commit
    • Olivier Fourdan's avatar
      xwayland: Make autoclose-xwayland an exp. feature · 3fc603ed
      Olivier Fourdan authored
      Closing automatically Xwayland once all relevant X11 clients are gone is
      inherently racy, if a new client comes along right at the time we're
      killing Xwayland.
      
      Fixing the possible race conditions between mutter, Xwayland and the X11
      clients may take some time.
      
      Meanwhile, make that an experimental feature "autoclose-xwayland".
      
      Part-of: <!1673>
      3fc603ed
  16. 18 Jan, 2021 1 commit
    • Olivier Fourdan's avatar
      xwayland: Check X11 clients prior to terminate Xwayland · e5347af0
      Olivier Fourdan authored
      Currently, mutter checks for the presence of X11 windows to decide
      whether or not Xwayland can be terminated, when Xwayland is started on
      demand.
      
      Unfortunately, not all X11 clients will map a window all the time, an
      X11 client may keep the X11 connection opened after closing all its
      windows. In that case, we may terminate Xwayland while there are some
      X11 client connected still, and terminating Xwayland will also kill
      those X11 clients.
      
      To avoid that issue, check the X11 clients actually connected using the
      XRes extension. The XRes extension provides the PID of the (local) X11
      clients connected to the Xserver, so we need to match that against the
      actual executable names, and compare with a list of known executables
      that we can safely ignore, such as ibus-x11 or gsd-xsettings.
      
      We also check against our own executable name, considering that the X11
      window manager is also an X11 client connected to the Xserver.
      
      Also, XRes returning the PID of local clients only is not a problem
      considering that Xwayland does not listen to remote connections.
      However, if the user spawns a client remotely on another system using
      ssh tunneling (ssh -X), only clients which actually map a window will
      be accounted for.
      
      Closes: #1537
      Part-of: <!1671>
      e5347af0
  17. 11 Dec, 2020 1 commit
    • Aleksandr Mezin's avatar
      xwayland: Set xrandr primary output · 4f544b63
      Aleksandr Mezin authored and Marge Bot's avatar Marge Bot committed
      To find XWayland output that should be the primary one, iterate through all
      XWayland outputs, and compare their geometry to the geometry of the primary
      logical monitor.
      
      To avoid possible race conditions (Mutter's monitor configuration already
      updated, but Xrandr not yet), set the output both after Randr notifications and
      after 'monitors-changed' signal.
      
      #1407
      
      Signed-off-by: Aleksandr Mezin's avatarAleksandr Mezin <mezin.alexander@gmail.com>
      Part-of: <!1558>
      4f544b63
  18. 10 Dec, 2020 3 commits
  19. 03 Dec, 2020 1 commit
    • Olivier Fourdan's avatar
      xwayland: Fix XIOErrorExitHandler warning · 79d4d7a4
      Olivier Fourdan authored and Marge Bot's avatar Marge Bot committed
      The XIOErrorExitHandler expects (Display *, void *) whereas mutter uses
      (Display *, MetaX11Display *).
      
      That causes a warning at build time:
      
        warning: passing argument 2 of ‘XSetIOErrorExitHandler’ from
                 incompatible pointer type [-Wincompatible-pointer-types]
          813 |   XSetIOErrorExitHandler (xdisplay, x_io_error_exit, display);
      
      Actually, the MetaX11Display is not even used, so we can just use the
      expected API and ignore the value.
      
      Part-of: <!1621>
      79d4d7a4
  20. 21 Oct, 2020 1 commit
    • Carlos Garnacho's avatar
      wayland: Set IO error exit handler · f4a1dcfc
      Carlos Garnacho authored
      If this call is available, we can turn libX11 IO errors (fatal by definition)
      into something we can recover from. Try to dispose all X11 resources and close
      the display instead, so the compositor can survive the event.
      
      !1447
      f4a1dcfc
  21. 08 Oct, 2020 1 commit
  22. 31 Aug, 2020 1 commit
  23. 29 Aug, 2020 1 commit
    • Olivier Fourdan's avatar
      xwayland: Add a setting to disable selected X extensions · 5171e35a
      Olivier Fourdan authored and Robert Mader's avatar Robert Mader committed
      The X server, including Xwayland, can be compiled with different X11
      extensions enabled at build time.
      
      When an X11 extension is built in the X server, it's usually also
      enabled at run time. Users can chose to disable those extensions at run
      time using the X server command line option "-extension".
      
      However, in the case of Xwayland, it is spawned automatically by the
      Wayland compositor, and the command line options are not configurable
      by users.
      
      Add a new setting to disable a selected set of X extension in Xwayland
      at startup, without needing to rebuild Xwayland.
      
      Of course, if Xwayland is not built with a given extension support in
      the first place (which is the default for the security extension for
      example), that option has no effect.
      
      !1405
      5171e35a
  24. 21 May, 2020 1 commit
    • Jonas Dreßler's avatar
      window: Use client PID for meta_window_get_pid() · dac09a8e
      Jonas Dreßler authored and Florian Müllner's avatar Florian Müllner committed
      The shell uses the PID of windows to map them to apps or to find out
      which window/app triggered a dialog. It currently fails to do that in
      some situations on Wayland, because meta_window_get_pid() only returns a
      valid PID for x11 clients.
      
      So use the client PID instead of the X11-exclusive _NET_WM_PID property
      to find out the PID of the process that started the window. We can do
      that by simply renaming the already existing
      meta_window_get_client_pid() API to meta_window_get_pid() and moving
      the old API providing the _NET_WM_PID to meta_window_get_netwm_pid().
      
      !1180
      dac09a8e