1. 22 Jun, 2021 2 commits
    • Zoltán Böszörményi's avatar
      glamoregl: Allow glamor to be initialized on llvmpipe if a GPUDevice is present · 24f69d2b
      Zoltán Böszörményi authored
      This allows an UDL device to be automatically set up with GPU
      acceleration via reverse PRIME.
          # DISPLAY=:0.2 xrandr --listproviders
          Providers: number : 2
          Provider 0: id: 0xec cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 1 outputs: 1 associated providers: 1 name:modesetting
          Provider 1: id: 0x12c cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 2 associated providers: 1 name:Intel
      Signed-off-by: Zoltán Böszörményi's avatarZoltán Böszörményi <zboszor@gmail.com>
    • Böszörményi Zoltán's avatar
      Don't hardcode screen 0 in GPU assignments to screens · 2145851e
      Böszörményi Zoltán authored
      When there is explicit configuration, it's better to use
      confScreen->screennum instead of hardcoded 0.
      When there is no configuration (default case) the screen number is
      still 0 so it doesn't change behaviour.
      But at least for a case when the Intel device is backed by the
      intel driver and using a screen description like this below,
      both providers are correctly assigned to :0.2.
        Section "Screen"
              Identifier      "SCREEN2"
              Option          "AutoServerLayout" "on"
              Device          "UDL"
              GPUDevice       "Intel2"
              Monitor         "Monitor-DVI-I-1"
              SubSection      "Display"
                      Modes   "1024x768"
                      Depth   24
        Section "ServerLayout"
              Identifier      "LAYOUT"
              Option          "AutoServerLayout" "on"
              Screen          0 "SCREEN"
              Screen          1 "SCREEN1" RightOf "SCREEN"
              Screen          2 "SCREEN2" RightOf "SCREEN1"
        # DISPLAY=:0.2 xrandr --listproviders
        Providers: number : 2
        Provider 0: id: 0xd2 cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 0 name:modesetting
        Provider 1: id: 0xfd cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 2 associated providers: 0 name:Intel
      Signed-off-by: Zoltán Böszörményi's avatarZoltán Böszörményi <zboszor@gmail.com>
  2. 21 Jun, 2021 2 commits
  3. 16 Jun, 2021 1 commit
  4. 15 Jun, 2021 4 commits
  5. 14 Jun, 2021 3 commits
  6. 11 Jun, 2021 1 commit
  7. 08 Jun, 2021 2 commits
  8. 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...
    • 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>
  9. 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.
  10. 31 May, 2021 3 commits
  11. 30 May, 2021 18 commits