1. 09 Jul, 2021 2 commits
  2. 08 Jul, 2021 1 commit
  3. 06 Jul, 2021 2 commits
  4. 05 Jul, 2021 2 commits
  5. 01 Jul, 2021 1 commit
    • Adam Jackson's avatar
      xfixes: Allow the client to upgrade the fixes protocol version · b2a0de4f
      Adam Jackson authored and Adam Jackson's avatar Adam Jackson committed
      If you say FixesQueryVersion twice we remember whatever the second
      version number was. With just libXfixes this isn't an issue because the
      request is hidden in extension setup, but libxcb-xfixes doesn't do that
      for you, which means the second one can _lower_ the requested fixes
      version, disabling requests that the client thought it had enabled.
      Paper over this by allowing the version number to be raised but not
      lowered. Also go ahead and delete the minor version number from the
      client state since xfixes doesn't have minor versions (yet, anyway).
  6. 30 Jun, 2021 1 commit
    • Olivier Fourdan's avatar
      xwayland/eglstream: Remove stream validity · 7d509b6f
      Olivier Fourdan authored
      To avoid an EGL stream in the wrong state, if the window pixmap changed
      before the stream was connected, we would still keep the pending stream
      but mark it as invalid. Once the callback is received, the pending would
      be simply discarded.
      But all of this is actually to avoid a bug in egl-wayland, there should
      not be any problem with Xwayland destroying an EGL stream while the
      compositor is still using it.
      With that bug now fixed in egl-wayland 1.1.7, we can safely drop all
      that logic from Xwayland EGLstream backend.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      Closes: xorg/xserver#1189
  7. 29 Jun, 2021 1 commit
  8. 25 Jun, 2021 3 commits
  9. 24 Jun, 2021 1 commit
  10. 23 Jun, 2021 3 commits
  11. 21 Jun, 2021 2 commits
  12. 16 Jun, 2021 1 commit
  13. 15 Jun, 2021 4 commits
  14. 14 Jun, 2021 3 commits
  15. 11 Jun, 2021 1 commit
  16. 08 Jun, 2021 2 commits
  17. 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: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • 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: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Erik Kurzinger's avatar
      glx: don't create implicit GLXWindow if one already exists · b7a85e44
      Erik Kurzinger authored and Olivier Fourdan's avatar Olivier Fourdan committed
      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>
  18. 01 Jun, 2021 1 commit
    • Jan Beich's avatar
      meson: provide fallback for *proto dependencies · 8274dd66
      Jan Beich authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      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: '>='
      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.
  19. 31 May, 2021 3 commits
  20. 30 May, 2021 3 commits