1. 20 Sep, 2021 1 commit
    • Mario Kleiner's avatar
      Revert "modesetting: Only use GAMMA_LUT if its size is 1024" · 6e23dae7
      Mario Kleiner authored
      This reverts commit 617f591f
      
      .
      
      The problem described in that commit exists, but the two
      preceeding commits with improvements to the servers RandR
      code should avoid the mentioned problems while allowing the
      use of GAMMA_LUT's instead of legacy gamma lut.
      
      Use of legacy gamma lut's is not a good fix, because it will reduce
      color output precision of gpu's with more than 1024 GAMMA_LUT
      slots, e.g., AMD, ARM MALI and KOMEDA with 4096 slot luts,
      and some Mediathek parts with 512 slot luts. On KOMEDA, legacy
      lut's are completely unsupported by the kms driver, so gamma
      correction gets disabled.
      
      The situation is especially bad on Intel Icelake and later:
      Use of legacy gamma tables will cause the kms driver to switch
      to hardware legacy lut's with 256 slots, 8 bit wide, without
      interpolation. This way color output precision is restricted to
      8 bpc and any deep color / HDR output (10 bpc, fp16, fixed point 16)
      becomes impossible. The latest Intel gen gpu's would have worse
      color precision than parts which are more than 10 years old.
      Signed-off-by: Mario Kleiner's avatarMario Kleiner <mario.kleiner.de@gmail.com>
      6e23dae7
  2. 15 Sep, 2021 1 commit
    • Patrik Jakobsson's avatar
      modesetting: Fix dirty updates for sw rotation · db9e9d45
      Patrik Jakobsson authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      
      
      Rotation is broken for all drm drivers not providing hardware rotation
      support. Drivers that give direct access to vram and not needing dirty
      updates still work but only by accident. The problem is caused by
      modesetting not sending the correct fb_id to drmModeDirtyFB() and
      passing the damage rects in the rotated state and not as the crtc
      expects them. This patch takes care of both problems.
      Signed-off-by: Patrik Jakobsson's avatarPatrik Jakobsson <pjakobsson@suse.de>
      db9e9d45
  3. 10 Sep, 2021 1 commit
    • Aaron Plattner's avatar
      modesetting: Only use GAMMA_LUT if its size is 1024 · 617f591f
      Aaron Plattner authored
      
      
      GAMMA_LUT sizes other than 1024 cause a crash during startup if the memcpy()
      calls in xf86RandR12CrtcSetGamma() read past the end of the legacy X11 /
      XVidMode gamma ramp.
      
      This is a problem on Intel ICL / GEN11 platforms because they report a GAMMA_LUT
      size of 262145. Since it's not clear that the modesetting driver will generate a
      proper gamma ramp at that size even if xf86RandR12CrtcSetGamma() is fixed, just
      disable use of GAMMA_LUT for sizes other than 1024 for now. This will cause the
      modesetting driver to disable the CTM property and fall back to the legacy gamma
      LUT.
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Fixes: xorg/xserver#1193
      Tested-by: Mark Herbert
      617f591f
  4. 05 Apr, 2021 1 commit
    • Aaron Plattner's avatar
      modesetting: Defer crtc gamma size upgrade to drmmode_setup_colormap · b75d0cca
      Aaron Plattner authored
      Rather than trying to create a gamma ramp array of the appropriate size in
      drmmode_crtc_init when the GAMMA_LUT property should be used, just flag the crtc
      as wanting to use the GAMMA_LUT property and then replace the gamma ramp later,
      right before calling xf86HandleColormaps. This avoids a problem during initial
      startup where xf86RandR12CreateObjects12 hard-codes a gamma ramp size of 256,
      causing xf86RandR12CrtcSetGamma to read past the end of the DIX layer's RandR
      gamma ramp array:
      
        PreInit
          drmmode_pre_init
            drmmode_crtc_init
              crtc->gamma_size = 1024
      
        ScreenInit
          xf86CrtcScreenInit
            xf86RandR12Init
              xf86RandR12Init12
                xf86RandR12CreateObjects12
                  RRCrtcCreate
                    randr_crtc->gammaSize = 0
                xf86RandR12InitGamma(pScrn, 256)
                  RRCrtcGammaSetSize
                    randr_crtc->gammaSize = 256
                xf86RandR12InitGamma
                  xf86RandR12CrtcInitGamma
                    RRCrtcGammaSet
                      xf86RandR12CrtcSetGamma
                        // crtc->gamma_size is 1024 here, while randr_crtc->gammaRed
                        // is a 256-element array.
                        memcpy(crtc->gamma_red, randr_crtc->gammaRed, crtc->gamma_size * sizeof(crtc->gamma_red[0]));
          drmmode_setup_colormap
            xf86HandleColormaps
              xf86RandR12InitGamma
                RRCrtcGammaSetSize
                  randr_crtc->gammaSize = 1024
      
      Fixes: 245b9db0 - modesetting: Use GAMMA_LUT when available
      Closes: xorg/xserver#1126
      
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: Robert Morell's avatarRobert Morell <rmorell@nvidia.com>
      b75d0cca
  5. 25 Nov, 2020 1 commit
  6. 29 Oct, 2020 4 commits
  7. 25 Sep, 2020 2 commits
    • Kishore409's avatar
      modesetting: keep going if a modeset fails on EnterVT · efb3abdd
      Kishore409 authored and Martin Roukala's avatar Martin Roukala committed
      There was a time when setting a mode on a CRTC would not depend on the
      associated connector's state. If a mode had been set successfully once,
      it would mean it would work later on.
      
      This changed with the introduction of new connectors type that now
      require a link training sequence (DP, HDMI 2.0), and that means that
      some events may have happened while the X server was not master that
      would then prevent the mode from successfully be restored to its
      previous state.
      
      This patch relaxes the requirement that all modes should be restored on
      EnterVT, or the entire X-Server would go down by allowing modesets to
      fail (with some warnings). If a modeset fails, the CRTC will be
      disabled, and a RandR event will be sent for the desktop environment to
      fix the situation as well as possible.
      
      Additional patches might be needed to make sure that the user would
      never be left with all screens black in some scenarios.
      
      v2 (Martin Peres):
       - whitespace fixes
       - remove the u...
      efb3abdd
    • Martin Roukala's avatar
      modesetting: check the kms state on EnterVT · 293cf660
      Martin Roukala authored
      
      
      Normally, we would receive a uevent coming from Linux's DRM subsystem,
      which would trigger the check for disappearing/appearing resources.
      However, this event is not received when X is not master (another VT
      is selected), and so the userspace / desktop environment would not be
      notified about the changes that happened while X wasn't master.
      
      To fix the issue, this patch forces a refresh on EnterVT by splitting
      the kms-checking code from the uevent handling into its own (exported)
      function called drmmode_update_kms_state. This function is then called
      from both the uevent-handling function, and on EnterVT right before
      restoring the modes.
      Signed-off-by: Martin Roukala's avatarMartin Peres <martin.peres@linux.intel.com>
      Reviewed-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      Tested-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      293cf660
  8. 08 Sep, 2020 1 commit
    • Uday Kiran Pichika's avatar
      modesetting: Lay the foundation for enabling VRR · 9823ea4e
      Uday Kiran Pichika authored and Martin Roukala's avatar Martin Roukala committed
      
      
      These changes have been ported from AMD GPU DDX driver.
      
      This patch adds support for setting the CRTC variable refresh property
      for suitable windows flipping via the Present extension.
      
      In order for a window to be suitable for variable refresh it must have
      the _VARIABLE_REFRESH property set by the MESA and inform Modesetting
      DDX driver with window property updates.
      
      Then the window must pass the checks required to be suitable for
      Present extension flips - it must cover the entire X screen and no
      other window may already be flipping. And also DRM connector should
      be VRR capable.
      
      With these conditions met every CRTC for the X screen will have their
      variable refresh property set to true.
      
      Kernel Changes to support this feature in I915 driver is under development.
      
      Tested with DOTA2, Xonotic and custom GLX apps.
      Signed-off-by: default avatarUday Kiran Pichika <pichika.uday.kiran@intel.com>
      9823ea4e
  9. 09 Jul, 2020 1 commit
  10. 05 Jul, 2020 1 commit
  11. 27 Jun, 2020 1 commit
  12. 23 Jun, 2020 1 commit
  13. 13 Mar, 2020 2 commits
  14. 11 Feb, 2020 1 commit
  15. 05 Feb, 2020 1 commit
  16. 14 Jan, 2020 1 commit
  17. 03 Jan, 2020 1 commit
    • Aaron Plattner's avatar
      modesetting: Check whether RandR was initialized before calling rrGetScrPriv · 4226c6d0
      Aaron Plattner authored
      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.
      
       Thread 1 "Xorg" received signal SIGABRT, Aborted.
       0x00007ffff78a8f25 in raise () from /usr/lib/libc.so.6
       (gdb) bt
       #0  0x00007ffff78a8f25 in raise () from /usr/lib/libc.so.6
       #1  0x00007ffff7892897 in abort () from /usr/lib/libc.so.6
       #2  0x00007ffff7892767 in __assert_fail_base.cold () from /usr/lib/libc.so.6
       #3  0x00007ffff78a1526 in __assert_fail () from /usr/lib/libc.so.6
       #4  0x00007ffff7fb57c1 in dixGetPrivateAddr (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:121
       #5  0x00007ffff7fb5822 in dixGetPrivate (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:136
       #6  0x00007ffff7fb586a in dixLookupPrivate (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:166
       #7  0x00007ffff7fb8445 in CreateScreenResources (pScreen=0x555555ab1790) at ../hw/xfree86/drivers/modesetting/driver.c:1335
       #8  0x000055555576c5e4 in xf86CrtcCreateScreenResources (screen=0x555555ab1790) at ../hw/xfree86/modes/xf86Crtc.c:744
       #9  0x00005555555d8bb6 in dix_main (argc=4, argv=0x7fffffffead8, envp=0x7fffffffeb00) at ../dix/main.c:214
       #10 0x00005555557a4f0b in main (argc=4, argv=0x7fffffffead8, envp=0x7fffffffeb00) at ../dix/stubmain.c:34
      
      This can happen, for example, if the server is configured with Xinerama
      and there is more than one X screen:
      
       Section "ServerLayout"
         Identifier "crash"
         Screen 0 "modesetting"
         Screen 1 "dummy" RightOf "modesetting"
         Option "Xinerama"
       EndSection
      
       Section "Device"
         Identifier "modesetting"
         Driver "modesetting"
       EndSection
      
       Section "Screen"
         Identifier "modesetting"
         Device "modesetting"
       EndSection
      
       Section "Device"
         Identifier "dummy"
         Driver "dummy"
       EndSection
      
       Section "Screen"
         Identifier "dummy"
         Device "dummy"
       EndSection
      
      The problem does not reproduce if there is only one X screen because of
      this code in xf86RandR12Init:
      
       #ifdef PANORAMIX
           /* XXX disable RandR when using Xinerama */
           if (!noPanoramiXExtension) {
               if (xf86NumScreens == 1)
                   noPanoramiXExtension = TRUE;
               else
                   return TRUE;
           }
       #endif
      
      Fix the problem by checking dixPrivateKeyRegistered(rrPrivKey) before
      calling rrGetScrPriv. This is similar to what the xf86-video-amdgpu
      driver does:
      https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/blob/fd66f5c0bea2b7c22a47bfd5eb1f22d32d166d9c/src/amdgpu_kms.c#L388
      
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      4226c6d0
  18. 25 Nov, 2019 4 commits
  19. 21 Nov, 2019 1 commit
  20. 15 Nov, 2019 1 commit
  21. 13 Nov, 2019 1 commit
  22. 29 Oct, 2019 1 commit
  23. 23 Oct, 2019 1 commit
  24. 14 Oct, 2019 1 commit
  25. 11 Oct, 2019 1 commit
    • Emil Velikov's avatar
      glamor_egl: disable modifiers via glamor_init() · f3ab3d0c
      Emil Velikov authored and Emil Velikov's avatar Emil Velikov committed
      
      
      Currently we parse through xf86Info.debug to check if we the modifiers
      should be disabled. Handle that within DDX and pass GLAMOR_NO_MODIFIERS
      into the glamor_init() flags.
      
      This allows individual DDX control over the setting - say when modifiers
      are woking OK with one implementation and not the other.
      
      Most importantly, this removes the final xf86 piece from the codebase.
      Signed-off-by: Emil Velikov's avatarEmil Velikov <emil.velikov@collabora.com>
      f3ab3d0c
  26. 22 Aug, 2019 1 commit
  27. 06 Aug, 2019 2 commits
  28. 11 Dec, 2018 1 commit
  29. 29 Nov, 2018 1 commit
    • Lyude Paul's avatar
      modesetting: Actually disable CRTCs in legacy mode · 7a44e8d4
      Lyude Paul authored and Adam Jackson's avatar Adam Jackson committed
      
      
      Believe it or not, somehow we've never done this in legacy mode! We
      currently simply change the DPMS property on the CRTC's output's
      respective DRM connector, but this means that we're just setting the
      CRTC as inactive-not disabled. From the perspective of the kernel, this
      means that any shared resources used by the CRTC are still in use.
      
      This can cause problems for drivers that are not yet fully atomic,
      despite using the atomic helpers internally. For instance: if CRTC-1 and
      CRTC-2 are still enabled and use shared resources within the kernel (an
      MST topology, for example), and then userspace tries to go enable CRTC-3
      on the same topology this might suddenly fail if CRTC-3 needs the shared
      resources CRTC-1 and CRTC-2 are using. While I don't know of any
      situations in the mainline kernel that actually trigger this, future
      plans for reworking the atomic check of MST drivers are absolutely
      going to make this into a real issue (they already are in my WIP
      branches for the kernel).
      
      So: actually do the right thing here and disable CRTCs when they're not
      going to be used anymore, even in legacy mode.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      7a44e8d4
  30. 31 Oct, 2018 1 commit
  31. 01 Oct, 2018 1 commit