Skip to content

GitLab

Switch branch/tag
  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>
      24f69d2b
    • 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
        EndSubSection
  EndSection

  Section "ServerLayout"
        Identifier      "LAYOUT"
        Option          "AutoServerLayout" "on"
        Screen          0 "SCREEN"
        Screen          1 "SCREEN1" RightOf "SCREEN"
        Screen          2 "SCREEN2" RightOf "SCREEN1"
  EndSection

  # 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>
      2145851e
  3. 21 Jun, 2021 2 commits
  5. 16 Jun, 2021 1 commit
  7. 15 Jun, 2021 4 commits
  9. 14 Jun, 2021 3 commits
  11. 11 Jun, 2021 1 commit
  13. 08 Jun, 2021 2 commits
  15. 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>
      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...
      e167299f
    • 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>
      b7a85e44
  17. 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: '>= 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
  19. 31 May, 2021 3 commits
  21. 30 May, 2021 18 commits