1. 19 Jan, 2019 2 commits
  2. 18 Jan, 2019 1 commit
  3. 17 Jan, 2019 1 commit
  4. 16 Jan, 2019 4 commits
  5. 11 Jan, 2019 2 commits
  6. 10 Jan, 2019 4 commits
  7. 09 Jan, 2019 1 commit
    • Olivier Fourdan's avatar
      xwayland: handle case without any crtc · e8295c50
      Olivier Fourdan authored
      Xwayland creates and destroys the CRTC along with the Wayland outputs,
      so there is possibly a case where the number of CRTC drops to 0.
      
      However, `xwl_present_get_crtc()` always return `crtcs[0]` which is
      invalid when `numCrtcs` is 0.
      
      That leads to crash if a client queries the Present capabilities when
      there is no CRTC, the backtrace looks like:
      
        #0  raise() from libc.so
        #1  abort() from libc.so
        #2  OsAbort() at utils.c:1350
        #3  AbortServer() at log.c:879
        #4  FatalError() at log.c:1017
        #5  OsSigHandler() at osinit.c:156
        #6  OsSigHandler() at osinit.c:110
        #7  <signal handler called>
        #8  main_arena() from libc.so
        #9  proc_present_query_capabilities() at present_request.c:236
        #10 Dispatch() at dispatch.c:478
        #11 dix_main() at main.c:276
      
      To avoid returning an invalid pointer (`crtcs[0]`) in that case, simply
      check for `numCrtcs` being 0 and return `NULL` in that case.
      
      Thanks to Michel Dänzer <michel.daenzer@amd.com> for pointing this as a
      possible cause of the crash.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
      Bugzilla: https://bugzilla.redhat.com/1609181
      e8295c50
  8. 07 Jan, 2019 1 commit
  9. 02 Jan, 2019 1 commit
  10. 21 Dec, 2018 1 commit
  11. 20 Dec, 2018 2 commits
  12. 17 Dec, 2018 5 commits
  13. 14 Dec, 2018 2 commits
  14. 12 Dec, 2018 2 commits
  15. 11 Dec, 2018 3 commits
  16. 29 Nov, 2018 3 commits
    • Adam Jackson's avatar
    • Lionel Landwerlin's avatar
    • Lyude Paul's avatar
      modesetting: Actually disable CRTCs in legacy mode · 7a44e8d4
      Lyude Paul authored
      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
  17. 25 Nov, 2018 2 commits
  18. 19 Nov, 2018 3 commits