Skip to content
GitLab
Switch branch/tag
  1. 06 Jan, 2021 1 commit
  3. 18 Dec, 2020 1 commit
  5. 17 Dec, 2020 3 commits
  7. 14 Dec, 2020 1 commit
  9. 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
  11. 25 Nov, 2020 1 commit
  13. 29 Oct, 2020 4 commits
  15. 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
  17. 08 Sep, 2020 3 commits
  19. 09 Jul, 2020 1 commit
  21. 05 Jul, 2020 1 commit
  23. 27 Jun, 2020 1 commit
  25. 23 Jun, 2020 1 commit
  27. 13 Mar, 2020 2 commits
  29. 11 Feb, 2020 1 commit
  31. 10 Feb, 2020 1 commit
  33. 05 Feb, 2020 1 commit
  35. 14 Jan, 2020 1 commit
  37. 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
  39. 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
  41. 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
  43. 25 Nov, 2019 4 commits
  45. 21 Nov, 2019 1 commit
  47. 15 Nov, 2019 1 commit
  49. 13 Nov, 2019 2 commits
  51. 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