1. 08 Jun, 2021 2 commits
  2. 07 Jun, 2021 3 commits
    • Olivier Fourdan's avatar
      dix: Add optional terminate delay · 6b47321b
      Olivier Fourdan authored
      
      
      When the command line option "-terminate" is used, it could be
      interesting to give it an optional grace period to let the Xserver
      running for a little longer in case a new connection occurs.
      
      This adds an optional parameter to the "-terminate" command line option
      for this purpose.
      
      v2: Use a delay in seconds instead of milliseconds
          (Martin Peres <martin.peres@mupuf.org>)
      v3: Clarify man page entry, ensure terminateDelay is always >= 0,
          simplify TimerFree(). (Peter Hutterer <peter.hutterer@who-t.net>)
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      6b47321b
    • Olivier Fourdan's avatar
      xfixes: Add ClientDisconnectMode · e167299f
      Olivier Fourdan authored
      
      
      With Wayland compositors now being able to start Xwayland on demand, the
      next logical step is to be able to stop Xwayland when there is no more
      need for it.
      
      The Xserver itself is capable of terminating itself once all X11 clients
      are gone, yet in a typical full session, there are a number of X11
      clients running continuously (e.g. the Xsettings daemon, IBus, etc.).
      
      Those always-running clients will prevent the Xserver from terminating,
      because the actual number of X11 clients will never drop to 0. Worse,
      the X11 window manager of a Wayland compositor also counts as an X11
      client, hence also preventing Xwayland from stopping.
      
      Some compositors such as mutter use the XRes extension to query the X11
      clients connected, match their PID with the actual executable name and
      compare those with a list of executables that can be ignored when
      deciding to kill the Xserver.
      
      But that's not just clumsy, it is also racy, because a new X11 client
      might initiate a connection the X11 server right when the compositor is
      about to kill it.
      
      To solve this issue directly at the Xserver level, this add new entries
      to the XFixes extension to let the X11 clients themselves specify the
      disconnect mode they expect.
      
      Typically, those X11 daemon clients would specify the disconnect mode
      XFixesClientDisconnectFlagTerminate to let the Xserver know that they
      should not be accounted for when checking the remaining clients prior
      to terminate.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      e167299f
    • Erik Kurzinger's avatar
      glx: don't create implicit GLXWindow if one already exists · b7a85e44
      Erik Kurzinger authored
      
      
      If a GLXMakeCurrent request specifies an X window as its drawable,
      __glXGetDrawable will implicitly create a GLXWindow for it. However,
      the client may have already explicitly created a GLXWindow for that X
      window. If that happens, two __glXDrawableRes resources will be added
      to the window.
      
      If the explicitly-created GLXWindow is later destroyed by the client,
      DrawableGone will call FreeResourceByType on the X window, but this
      will actually free the resource for the implicitly-created GLXWindow,
      since that one would be at the head of the list.
      
      Then if the X window is destroyed after that, the resource for the
      explicitly-created GLXWindow will be freed. But that GLXWindow was
      already destroyed above. This crashes the server when it tries to call
      the destroyed GLXWindow's destructor. It also means the
      implicitly-created GLXWindow would have been leaked since the
      FreeResourceByType call mentioned above skips calling the destructor.
      
      To fix this, if __glXGetDrawable is given an X window, it should check
      if there is already a GLXWindow associated with it, and only create an
      implicit one if there is not.
      Signed-off-by: Erik Kurzinger's avatarErik Kurzinger <ekurzinger@nvidia.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      b7a85e44
  3. 01 Jun, 2021 1 commit
    • Jan Beich's avatar
      meson: provide fallback for *proto dependencies · 8274dd66
      Jan Beich authored
      Meson has a built-in facility to use bundled versions of dependencies
      if system packages are too old. Enable for xorgproto after 8e504d8b:
      
      Run-time dependency xproto found: YES 7.0.33
      Run-time dependency randrproto found: YES 1.6.0
      Run-time dependency renderproto found: YES 0.11.1
      Run-time dependency xextproto found: YES 7.3.0
      Dependency inputproto found: NO found 2.3.2 but need: '>= 2.3.99.1'
      Found CMake: /usr/local/bin/cmake (3.20.2)
      Run-time dependency inputproto found: NO (tried pkgconfig and cmake)
      Looking for a fallback subproject for the dependency inputproto
      
      meson.build:73:0: ERROR: Neither a subproject directory nor a xorgproto.wrap file was found.
      8274dd66
  4. 31 May, 2021 3 commits
  5. 30 May, 2021 23 commits
  6. 27 May, 2021 1 commit
  7. 20 May, 2021 1 commit
    • Erik Kurzinger's avatar
      xwayland/eglstream: flush stream after eglSwapBuffers · 7515c23a
      Erik Kurzinger authored
      When eglSwapBuffers inserts a new frame into a window's stream, there may be a
      delay before the state of the consumer end of the stream is updated to reflect
      this. If the subsequent wl_surface_attach, wl_surface_damage, wl_surface_commit
      calls are received by the compositor before then, it will (typically) re-use
      the previous frame acquired from the stream instead of the latest one.
      
      This can leave the window displaying out-of-date contents, which might never be
      updated thereafter.
      
      To fix this, after calling eglSwapBuffers, xwl_glamor_eglstream_post_damage
      should call eglStreamFlushNV. This call will block until it can be guaranteed
      that the state of the consumer end of the stream has been updated to reflect
      that a new frame is available.
      
      Closes: xorg/xserver#1171
      
      Signed-off-by: Erik Kurzinger's avatarErik Kurzinger <ekurzinger@nvidia.com>
      7515c23a
  8. 18 May, 2021 1 commit
  9. 17 May, 2021 1 commit
  10. 11 May, 2021 4 commits