1. 06 Jan, 2021 1 commit
  2. 18 Dec, 2020 1 commit
  3. 17 Dec, 2020 3 commits
  4. 14 Dec, 2020 1 commit
  5. 26 Nov, 2020 1 commit
    • Olivier Fourdan's avatar
      modesetting: Fix build with DebugPresent() enabled · 3ce05a44
      Olivier Fourdan authored and Peter Hutterer's avatar Peter Hutterer committed
      
      
      By default, the macro DebugPresent() is a no-op but it can be enabled
      at build time for debugging purpose.
      
      However, doing so prevents the code to build because one debug statement
      tries to make use of a non-existent variable:
      
        present.c: In function ‘ms_present_queue_vblank’:
        present.c:147:18: error: ‘vbl’ undeclared (first use in this function)
          147 |                  vbl.request.sequence));
              |                  ^~~
        present.c:49:32: note: in definition of macro ‘DebugPresent’
          49 | #define DebugPresent(x) ErrorF x
             |                                ^
      
      Fix the build with DebugPresent() by removing the vbl variable from the
      debug message.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      3ce05a44
  6. 25 Nov, 2020 1 commit
  7. 29 Oct, 2020 4 commits
  8. 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 uevent handling (it is done in a previous patch)
       - improve the commit message
       - reduce the size of the patch by not changing lines needlessly
       - return FALSE if one modeset fails in ignore mode
       - add comments/todos to explain why we do things
       - disable the CRTCs that failed the modeset
      Signed-off-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      Signed-off-by: Martin Roukala's avatarMartin Peres <martin.peres@linux.intel.com>
      Reviewed-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      Closes: #1010
      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
  9. 08 Sep, 2020 3 commits
  10. 09 Jul, 2020 1 commit
  11. 05 Jul, 2020 1 commit
  12. 27 Jun, 2020 1 commit
  13. 23 Jun, 2020 1 commit
  14. 13 Mar, 2020 2 commits
  15. 11 Feb, 2020 1 commit
  16. 10 Feb, 2020 1 commit
  17. 05 Feb, 2020 1 commit
  18. 14 Jan, 2020 1 commit
  19. 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
  20. 23 Dec, 2019 1 commit
    • Alex Goins's avatar
      modesetting: Fix msSharePixmapBacking Segfault Regression · 456dff1b
      Alex Goins authored and Aaron Plattner's avatar Aaron Plattner committed
      Commit cb1b1e18
      
       modified msSharePixmapBacking() to derive modesettingPtr from
      the 'screen' argument. Unfortunately, the name of the argument is misleading --
      the screen is the slave screen. If the master is modesetting,
      and the slave is not modesetting, it will segfault.
      
      To fix the problem, this change derives modesettingPtr from
      ppix->drawable.pScreen. This method is already used when calling
      ms->glamor.shareable_fd_from_pixmap() later in the function.
      
      To avoid future issues, this change also renames the 'screen' argument to
      'slave'.
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      456dff1b
  21. 26 Nov, 2019 1 commit
    • Kenneth Graunke's avatar
      modesetting: Use EGL_MESA_query_driver to select DRI driver if possible · 8d4be7f6
      Kenneth Graunke authored
      New now ask Glamor to use EGL_MESA_query_driver to obtain the DRI driver
      name; if successful, we use that as the DRI driver name.  Following the
      existing dri2.c logic, we also use the same name for the VDPAU driver,
      except for i965 (and now iris), where we switch to the "va_gl" fallback.
      
      This allows us to bypass the PCI ID lists in xserver and centralize the
      driver selection mechanism inside Mesa.  The hope is that we no longer
      have to update these lists for any future hardware.
      8d4be7f6
  22. 25 Nov, 2019 4 commits
  23. 21 Nov, 2019 1 commit
  24. 15 Nov, 2019 1 commit
  25. 13 Nov, 2019 2 commits
  26. 11 Nov, 2019 2 commits
    • Alex Goins's avatar
      modesetting: Implement ms_covering_randr_crtc() for ms_present_get_crtc() · 562c7888
      Alex Goins authored and Aaron Plattner's avatar Aaron Plattner committed
      
      
      ms_present_get_crtc() returns an RRCrtcPtr, but derives it from a xf86CrtcPtr
      found via ms_dri2_crtc_covering_drawable()=>ms_covering_crtc(). As a result, it
      depends on all associated DIX ScreenRecs having an xf86CrtcConfigPtr DDX
      private.
      
      Some DIX ScreenRecs don't have an xf86CrtcConfigPtr DDX private, but do have an
      rrScrPrivPtr DDX private. Given that we can derive all of the information we
      need from RandR, we can support these screens by avoiding the use of xf86Crtc.
      This change implements an RandR-based path for ms_present_get_crtc(), allowing
      drawables to successfully fall back to syncing to the primary output, even if
      the slave doesn't have an xf86CrtcConfigPtr DDX private.
      
      Without this change, if a slave doesn't have an xf86CrtcConfigPtr DDX private,
      drawables will fall back to 1 FPS if they overlap an output on that slave.
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      562c7888
    • Alex Goins's avatar
      modesetting: Fix ms_covering_crtc() segfault with non-xf86Crtc slave · 797e7a0c
      Alex Goins authored and Aaron Plattner's avatar Aaron Plattner committed
      
      
      DIX ScreenRecs don't necessarily have an xf86CrtcConfigPtr DDX private.
      ms_covering_crtc() assumes that they do, which can result in a segfault.
      
      Update ms_covering_crtc() to check the XF86_CRTC_CONFIG_PTR() returned pointer
      before dereferencing it. This will still mean that ms_covering_crtc() can't fall
      back to the primary output when a drawable overlaps a slave output (going to the
      1 FPS default instead), but it won't segfault.
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      797e7a0c