1. 05 Jul, 2021 9 commits
  2. 01 Jul, 2021 1 commit
    • Adam Jackson's avatar
      xfixes: Allow the client to upgrade the fixes protocol version · b2a0de4f
      Adam Jackson authored
      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).
      b2a0de4f
  3. 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: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      Closes: xorg/xserver#1189
      7d509b6f
  4. 29 Jun, 2021 1 commit
  5. 25 Jun, 2021 3 commits
  6. 24 Jun, 2021 1 commit
  7. 23 Jun, 2021 3 commits
  8. 21 Jun, 2021 2 commits
  9. 16 Jun, 2021 1 commit
  10. 15 Jun, 2021 4 commits
    • Daniel Strnad's avatar
      hw/xfree86: Propagate physical dimensions from DRM connector · 05b3c681
      Daniel Strnad authored
      Physical dimmension of display can be obtained not just by configuration or
      DDC, but also directly from kernel via drmModeGetConnector(). Until now
      xserver silently discarded these values even when no configuration nor EDID
      were present and fallbacked to default DPI.
      05b3c681
    • Łukasz Spintzyk's avatar
      xfree86: Change displays array to pointers array to fix invalid pointer issues... · f8a6be04
      Łukasz Spintzyk authored
      
      xfree86: Change displays array to pointers array to fix invalid pointer issues after table reallocation
      
      There are rare cases when xf86SetDepthBpp is resizing displays array in confScreen.
      As that array is shared between set of ScrnInfoRec's then realloc might invalidate chached DispPtr display values in
      otheres ScrnInfoRec objects.
      
      If we will change displays array as an array of pointers to DispRec then cached DispRec pointers in ScrnInfoRec
      won't be invalid after reallocation of displays array.
      Signed-off-by: Łukasz Spintzyk's avatarŁukasz Spintzyk <lukasz.spintzyk@synaptics.com>
      f8a6be04
    • Povilas Kanapickas's avatar
      modesetting: Add a limit on async page flip error log frequency · 1a1bd5cf
      Povilas Kanapickas authored
      
      
      In certain circumstances we will have a lot of flip errors without a
      reasonable way to prevent them. In such case we reduce the number of
      logged messages to at least not fill the error logs.
      
      The details are as follows:
      
      At least on i915 hardware support for async page flip support depends on
      the used modifiers which themselves can change dynamically for a screen.
      This results in the following problems:
      
      - We can't know about whether a particular CRTC will be able to do an
      async flip without hardcoding the same logic as the kernel as there's no
      interface to query this information.
      
      - There is no way to give this information to an application, because
      the protocol of the present extension does not specify anything about
      changing of the capabilities on runtime or the need to re-query them.
      
      Even if the above was solved, the only benefit would be avoiding a
      roundtrip to the kernel and reduced amount of error logs. The former
      does not seem to be a good enough benefit compared to the amount of work
      that would need to be done. The latter is solved in this commit.
      Reviewed-by: Eero Tamminen's avatarEero Tamminen <eero.t.tamminen@intel.com>
      Signed-off-by: Povilas Kanapickas's avatarPovilas Kanapickas <povilas@radix.lt>
      1a1bd5cf
    • Povilas Kanapickas's avatar
  11. 14 Jun, 2021 3 commits
  12. 11 Jun, 2021 1 commit
  13. 08 Jun, 2021 2 commits
  14. 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
  15. 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
  16. 31 May, 2021 3 commits
  17. 30 May, 2021 1 commit