1. 27 Jun, 2020 1 commit
  2. 23 Jun, 2020 1 commit
  3. 13 Mar, 2020 2 commits
  4. 11 Feb, 2020 1 commit
  5. 05 Feb, 2020 1 commit
  6. 14 Jan, 2020 1 commit
  7. 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
  8. 25 Nov, 2019 4 commits
  9. 21 Nov, 2019 1 commit
  10. 15 Nov, 2019 1 commit
  11. 13 Nov, 2019 1 commit
  12. 29 Oct, 2019 1 commit
  13. 23 Oct, 2019 1 commit
  14. 14 Oct, 2019 1 commit
  15. 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
  16. 22 Aug, 2019 1 commit
  17. 06 Aug, 2019 2 commits
  18. 11 Dec, 2018 1 commit
  19. 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
  20. 31 Oct, 2018 1 commit
  21. 01 Oct, 2018 1 commit
  22. 02 Aug, 2018 1 commit
  23. 25 Jul, 2018 1 commit
  24. 03 Jul, 2018 1 commit
  25. 28 Jun, 2018 1 commit
  26. 27 Jun, 2018 2 commits
    • Lyude Paul's avatar
      modesetting: Also disable CRTC in drmmode_output_disable() · c12f1bd4
      Lyude Paul authored and Keith Packard's avatar Keith Packard committed
      
      
      So, this did actually work on older kernels at one point in time,
      however it seems that this working was a result of some of the Linux
      kernel's atomic modesetting helpers not preserving the CRTC's enabled
      state in the right spots. This was fixed in:
      
      846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2")
      
      As a result, atomic commits which simply disassociate a DRM connector
      with it's CRTC while leaving the CRTC in an enabled state aren't enough
      to disable the CRTC, and result in the atomic commit failing. This
      currently can cause issues with MST hotplugging where X will end up
      failing to disable the MST outputs after they've left the system. A
      simple reproducer:
      
      - Start up Xorg
      - Connect an MST hub with displays connected to it
      - Remove the hub
      - Now there should be CRTCs stuck on the orphaned MST connectors, and X
        won't be able to reclaim them.
      
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      c12f1bd4
    • Olivier Fourdan's avatar
      modesetting: use drmmode_bo_import() for rotate_fb · a85e94a5
      Olivier Fourdan authored and Keith Packard's avatar Keith Packard committed
      drmmode_shadow_allocate() still uses drmModeAddFB() which may fail if
      the format is not as expected, preventing from using a rotated output.
      
      Change it to use the new function drmmode_bo_import() which takes care
      of calling the drmModeAddFB2() API.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106715
      
      
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Tested-by: default avatarTomas Pelka <tpelka@redhat.com>
      Reviewed-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      a85e94a5
  27. 23 Apr, 2018 1 commit
    • Mario Kleiner's avatar
      modesetting: Only use modifiers on kms drivers which do support them. · e29d7832
      Mario Kleiner authored and Adam Jackson's avatar Adam Jackson committed
      Use the DRM_CAP_ADDFB2_MODIFIERS query to make sure the kms
      driver supports modifiers in the addfb2 ioctl, and fall back
      to addfb ioctl without modifiers if modifiers are unsupported.
      
      E.g., as of Linux 4.17, nouveau-kms so far does not suppport
      modifiers and gets angry if drmModeAddFB2WithModifiers() is
      called (-> failure to set a video mode -> blank screen), but
      Mesa's nvc0+ gallium driver causes gbm_bo_get_modifier() to
      return a valid modifier by translating the default tiling of
      bo's created via gbm_bo_create() into a modifier other than
      DRM_FORMAT_MOD_INVALID (see Mesa's nvc0_miptree_get_modifier()).
      
      Testing for != DRM_FORMAT_MOD_INVALID is apparently not
      sufficient for safe use of drmModeAddFB2WithModifiers.
      
      Bonus: Handle potential failure of populate_format_modifiers().
      
      The required DRM_CAP is defined since libdrm v2.4.65, and we
      require v2.4.89+ for the server, so we can use it unconditionally.
      
      Tested on intel-kms, radeon-kms, nouveau-kms. Fixes failure on
      NVidia Pascal.
      
      Fixes: 2f807c23
      
       ("modesetting: Add support for multi-plane pixmaps when page-flipping")
      Signed-off-by: Mario Kleiner's avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: Daniel Stone <daniels@collabora.com>
      Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
      Reviewed-by: Louis-Francis Ratté-Boulianne's avatarLouis-Francis Ratté-Boulianne <lfrb@collabora.com>
      e29d7832
  28. 16 Apr, 2018 1 commit
  29. 05 Apr, 2018 2 commits
  30. 04 Apr, 2018 4 commits