1. 21 Jul, 2020 1 commit
    • Alex Goins's avatar
      randr: Check rrPrivKey before autobinding GPU screens · 6172bd2b
      Alex Goins authored
      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>
      6172bd2b
  2. 09 Jul, 2020 1 commit
  3. 10 Feb, 2020 1 commit
    • Pekka Paalanen's avatar
      randr: auto-bind of GPU is a config change · bfb36a58
      Pekka Paalanen authored
      When a GPU is auto-bound adding more outputs to a screen, that needs to count
      as a configuration change on that screen so that a WM listening for
      RRScreenChangeNotify gets notified and handles it as a hotplug. This is
      particularly for cases where the outputs are already connected. Otherwise
      nothing might happen.
      
      Issue #909 describes a real world case where plugging in a DisplayLink dock
      with a monitor already connected is sometimes left inactive by GNOME. That
      issue is a race, and requires adding a sleep(5); as the first thing in
      NewGPUDeviceRequest() to reproduce reliably. With the sleep, the monitor in the
      dock will never activate automatically. Add this fix over the sleep, and the
      issue is gone.
      
      This fix was originally developed on a branch replicating Ubuntu 19.04 patch
      set based on xserver 1.20.4. Testing on master branch was impossible due to
      xorg/xserver#910.
      
      Closes: xorg/xserver#909
      
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      bfb36a58
  4. 07 Aug, 2019 1 commit
    • Dave Airlie's avatar
      xf86: autobind GPUs to the screen · 078277e4
      Dave Airlie authored
      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 sti...
      078277e4
  5. 08 May, 2018 1 commit
  6. 11 Jan, 2017 1 commit
  7. 05 Jul, 2016 1 commit
    • Alex Goins's avatar
      randr: Add ability to turn PRIME sync off · df8e8693
      Alex Goins authored
      
      
      Adds an output parameter to disable PRIME synchronization.
      
      Output parameter is created when the user calls 'xrandr
      --setprovideroutputsource <sink> <source>' to prevent polluting output
      parameters of non-PRIME configurations.
      
      Defaults to on, so if the user wants PRIME synchronization they don't need
      to do anything.
      
      If the user wishes to disable PRIME synchronization when they first set up
      PRIME, they can run 'xrandr --output <output> --set "PRIME Synchronization"
      0' after running 'xrandr --setprovideroutputsource <sink> <source>', but
      before 'xrandr --auto'.
      
      If the user wishes to enable or disable PRIME synchronization after PRIME has
      already been set up, they can run 'xrandr --output <output> --set "PRIME
      Synchronization" <0 or 1>' at any time, xrandr will trigger a modeset, which
      will tear down and setup PRIME in the configuration they requested on CRTCs
      associated with that output.
      
      randrstr.h:
          Add central definition of the output property name.
      
      rrcrtc.c:
          Add function rrGetPixmapSharingSyncProp() to query the status of the
          output property.
      
          Add function rrSetPixmapSharingSyncProp() to set the output property.
      
          Add 'sync' parameter to rrSetupPixmapSharing(), which when false will
          use single buffering even if the required ABI functions are supported.
          Changes rrSetupPixmapSharing() to only report an error if falling back
          to single buffering when the user requested synchronization.
      
          Change RRCrtcSet() to use rrPixmapSharingSyncProp() to query the status
          of the output property and feed it into rrSetupPixmapSharing() using
          the 'sync' parameter.
      
      rrprovider.c:
          Add RR(Init/Fini)PrimeSyncProps(), functions to create and destroy the
          PRIME synchronization output property.
      
          Add a call to RRInitPrimeSyncProps() in
          ProcRRSetProviderOutputSource(), such that the output property is
          created when the user requests PRIME.
      
          Add a call to RRFiniPrimeSyncProps() in RRProviderDestroy().
      
      v1: Initial commit
      v2: Unchanged
      v3: Add /* TODO */ for handling different sources with different outputs
          Make rrSetupPixmapSharing() set the output property to 0 if it has to fall
          back, to avoid user confusion.
          Make rr(Get)PixmapSharingSyncProp() check the current value if there isn't a
          pending value
      v4: Unchanged
      v5: Unchanged
      v6: Rebase onto ToT
      v7: Unchanged
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      df8e8693
  8. 17 Jun, 2016 1 commit
    • Hans de Goede's avatar
      xrandrprovider: Do not use separate lists for unbound / source / offload slaves · 5c7af02b
      Hans de Goede authored
      
      
      A single provider can be both a offload and source slave at the same time,
      the use of seperate lists breaks in this case e.g. :
      
      xrandr --listproviders
      Providers: number : 2
      Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 0 name:modesetting
      Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 0 name:modesetting
      
      xrandr --setprovideroutputsource 1 0x7b
      xrandr --listproviders
      Providers: number : 2
      Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 1 name:modesetting
      Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 1 name:modesetting
      
      xrandr --setprovideroffloadsink 1 0x7b
      xrandr --listproviders
      Providers: number : 3
      Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 2 name:modesetting
      Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 2 name:modesetting
      Provider 2: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 2 name:modesetting
      
      Not good. The problem is that the provider with id 0x46 now is on both
      the output_slave_list and the offload_slave_list of the master screen.
      
      This commit fixes this by unifying all 3 lists into a single slaves list.
      
      Note that this does change the struct _Screen definition, so this is an ABI
      break. I do not expect any of the drivers to actually use the removed / changed
      fields so a recompile should suffice.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      5c7af02b
  9. 04 May, 2016 1 commit
  10. 12 Nov, 2014 1 commit
  11. 21 Apr, 2014 1 commit
  12. 12 Jan, 2014 1 commit
  13. 30 Oct, 2013 1 commit
  14. 01 Mar, 2013 1 commit
  15. 17 Jul, 2012 1 commit
  16. 07 Jul, 2012 5 commits
  17. 06 Jul, 2012 1 commit
    • Dave Airlie's avatar
      randr: add provider object and provider property support (v6) · 66d92afe
      Dave Airlie authored
      
      
      This adds the initial provider object and provider property
      support to the randr dix code.
      
      v2: destroy provider in screen close
      v2.1: fix whitespace
      
      v3: update for latest rev of protocol + renumber after 1.4 tearout.
      
      v4: fix logic issue, thanks Samsagax on irc
      
      v5: keithp's review: fix current_role, fix copyrights, fix master
      reporting crtc/outputs.
      
      v6: port to new randr interface, drop all set role bits for now
      
      v7: drop devPrivate in provider, not needed, add BadMatch returns
      for NULL SetProviderOffloadSink and SetProviderOutputSource, drop
      the old typedef.
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      66d92afe