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 · c4917a6d
      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>
      (cherry picked from commit 24f69d2b)
      c4917a6d
    • Böszörményi Zoltán's avatar
      Don't hardcode screen 0 in GPU assignments to screens · f3d42959
      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>
      (cherry picked from commit 2145851e)
      f3d42959
  2. 18 Jun, 2021 2 commits
    • Alex Goins's avatar
      randr: Check rrPrivKey before autobinding GPU screens · 305042d5
      Alex Goins authored and Zoltán Böszörményi's avatar Zoltán Böszörményi committed
      RRProviderAutoConfigGpuScreen() is called from outside RandR, so there is no
      guarantee that RandR has been initialized when it is called.
      
      As mentioned in commit 4226c6d0, it's possible that RandR has not been
      initialized if the server is configured with Xinerama and there is more than one
      X screen. Calling rrGetScrPriv when RandR isn't initialized causes an assertion
      failure that aborts the server:
      
        Xorg: ../include/privates.h:121: dixGetPrivateAddr: Assertion
        key->initialized' failed.
      
      Just as in commit 4226c6d0
      
      , fix the problem by checking
      dixPrivateKeyRegistered(rrPrivKey) before calling rrGetScrPriv.
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      (cherry picked from commit 6172bd2b)
      305042d5
    • Dave Airlie's avatar
      xf86: autobind GPUs to the screen · 8fa79378
      Dave Airlie authored and Zoltán Böszörményi's avatar Zoltán Böszörményi committed
      
      
      This is a modified version of a patch we've been carry-ing in Fedora and
      RHEL for years now. This patch automatically adds secondary GPUs to the
      master as output sink / offload source making e.g. the use of
      slave-outputs just work, with requiring the user to manually run
      "xrandr --setprovideroutputsource" before he can hookup an external
      monitor to his hybrid graphics laptop.
      
      There is one problem with this patch, which is why it was not upstreamed
      before. What to do when a secondary GPU gets detected really is a policy
      decission (e.g. one may want to autobind PCI GPUs but not USB ones) and
      as such should be under control of the Desktop Environment.
      
      Unconditionally adding autobinding support to the xserver will result
      in races between the DE dealing with the hotplug of a secondary GPU
      and the server itself dealing with it.
      
      However we've waited for years for any Desktop Environments to actually
      start doing some sort of autoconfiguration of secondary GPUs and there
      is still not a single DE dealing with this, so I believe that it is
      time to upstream this now.
      
      To avoid potential future problems if any DEs get support for doing
      secondary GPU configuration themselves, the new autobind functionality
      is made optional. Since no DEs currently support doing this themselves it
      is enabled by default. When DEs grow support for doing this themselves
      they can disable the servers autobinding through the servers cmdline or a
      xorg.conf snippet.
      Signed-off-by: Dave Airlie's avatarDave Airlie <airlied@gmail.com>
      [hdegoede@redhat.com: Make configurable, fix with nvidia, submit upstream]
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Emil Velikov's avatarEmil Velikov <emil.velikov@collabora.com>
      ---
      Changes in v2:
      -Make the default enabled instead of installing a xorg.conf
       snippet which enables it unconditionally
      
      Changes in v3:
      -Handle GPUScreen autoconfig in randr/rrprovider.c, looking at
       rrScrPriv->provider, rather then in hw/xfree86/modes/xf86Crtc.c
       looking at xf86CrtcConfig->provider. This fixes the autoconfig not
       working with the nvidia binary driver
      
      (cherry picked from commit 078277e4)
      8fa79378
  3. 15 Jun, 2021 1 commit
  4. 14 Jun, 2021 13 commits
  5. 09 Jun, 2021 1 commit
  6. 08 Jun, 2021 2 commits
  7. 04 May, 2021 1 commit
    • Vasily Khoruzhick's avatar
      glx: fixup symbol name for get_extensions function · 23a53f0d
      Vasily Khoruzhick authored
      
      
      glxProbeDriver() concatenates __DRI_DRIVER_GET_EXTENSIONS with driver name
      to get symbol name for get_extension function. Unfortunately that doesn't
      work for drivers that have hyphen in their name, e.g. sun4i-drm --
      get_extensions() for these uses underscore instead.
      
      As result dlsym() doesn't find get_extension() function and AIGLX
      initialization fails resulting in following message in Xorg.0.log:
      
      (EE) AIGLX error: sun4i-drm does not export required DRI extension
      
      Replace all non-alpha-numeric characters with underscore to fix the issue.
      Signed-off-by: Vasily Khoruzhick's avatarVasily Khoruzhick <anarsoul@gmail.com>
      (cherry picked from commit b56e5010)
      23a53f0d
  8. 13 Apr, 2021 2 commits
  9. 22 Feb, 2021 3 commits
  10. 21 Feb, 2021 2 commits
    • Jeremy Huddleston Sequoia's avatar
    • Jeremy Huddleston Sequoia's avatar
      xquartz: Allocate each fbconfig separately · aa6f8402
      Jeremy Huddleston Sequoia authored
      A change during the 1.20 development cycle resulted in fbconfigs being walked
      and deallocated individually during __glXScreenDestroy.  This change
      now avoids a use-after-free caused by that change.
      
      ==50859==ERROR: AddressSanitizer: heap-use-after-free on address 0x00010d3819c8 at pc 0x0001009d4230 bp 0x00016feca7a0 sp 0x00016feca798
      READ of size 8 at 0x00010d3819c8 thread T5
          #0 0x1009d422c in __glXScreenDestroy glxscreens.c:448
          #1 0x10091cc98 in __glXAquaScreenDestroy indirect.c:510
          #2 0x1009d2734 in glxCloseScreen glxscreens.c:169
          #3 0x100740a24 in dix_main main.c:325
          #4 0x10023ed50 in server_thread quartzStartup.c:65
          #5 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
          #6 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)
      
      0x00010d3819c8 is located 200 bytes inside of 12800-byte region [0x00010d381900,0x00010d384b00)
      freed by thread T5 here:
          #0 0x101477ba8 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fba8)
          #1 0x1009d4240 in __glXScreenDestroy glxscreens.c:449
          #2 0x10091cc98 in __glXAquaScreenDestroy indirect.c:510
          #3 0x1009d2734 in glxCloseScreen glxscreens.c:169
          #4 0x100740a24 in dix_main main.c:325
          #5 0x10023ed50 in server_thread quartzStartup.c:65
          #6 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
          #7 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)
      
      previously allocated by thread T5 here:
          #0 0x101477e38 in wrap_calloc+0x9c (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fe38)
          #1 0x100925a40 in __glXAquaCreateVisualConfigs visualConfigs.c:116
          #2 0x10091cb24 in __glXAquaScreenProbe+0x224 (X11.bin:arm64+0x100730b24)
          #3 0x1009cd840 in xorgGlxServerInit glxext.c:528
          #4 0x10074539c in _CallCallbacks dixutils.c:743
          #5 0x100932a70 in CallCallbacks callback.h:83
          #6 0x100932478 in GlxExtensionInit vndext.c:244
          #7 0x10020a364 in InitExtensions miinitext.c:267
          #8 0x10073fe7c in dix_main main.c:197
          #9 0x10023ed50 in server_thread quartzStartup.c:65
          #10 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
          #11 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)
      
      Regressed-in: 4b0a3cba
      
      
      CC: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
      Signed-off-by: Jeremy Huddleston Sequoia's avatarJeremy Huddleston Sequoia <jeremyhu@apple.com>
      (cherry picked from commit 487286d4)
      aa6f8402
  11. 20 Feb, 2021 2 commits
  12. 19 Feb, 2021 9 commits