1. 07 Aug, 2019 3 commits
  2. 30 Jul, 2019 1 commit
  3. 05 Jul, 2019 1 commit
  4. 25 Jun, 2019 1 commit
  5. 14 Jun, 2019 2 commits
  6. 10 Jun, 2019 1 commit
  7. 30 Apr, 2019 1 commit
  8. 18 Apr, 2019 1 commit
  9. 19 Mar, 2019 1 commit
  10. 07 Mar, 2019 1 commit
  11. 06 Mar, 2019 1 commit
  12. 04 Mar, 2019 3 commits
  13. 01 Mar, 2019 2 commits
  14. 27 Feb, 2019 1 commit
  15. 22 Feb, 2019 2 commits
  16. 20 Feb, 2019 2 commits
  17. 12 Feb, 2019 1 commit
  18. 11 Feb, 2019 1 commit
  19. 07 Feb, 2019 1 commit
  20. 25 Jan, 2019 2 commits
    • Michel Dänzer's avatar
      Keep waiting for a pending flip if drm_handle_event returns 0 · 9045fb31
      Michel Dänzer authored
      drm_wait_pending_flip stopped waiting if drm_handle_event returned 0,
      but that might have processed only some unrelated DRM events. As long as
      the flip is pending, we have to keep waiting for its completion event.
      
      Noticed while working on the previous fix.
      Acked-by: 's avatarAlex Deucher <alexander.deucher@amd.com>
      9045fb31
    • Michel Dänzer's avatar
      Call drmHandleEvent again if it was interrupted by a signal · 3ff2cc22
      Michel Dänzer authored
      drmHandleEvent can be interrupted by a signal in read(), in which case
      it doesn't process any events but returns -1, which
      drm_handle_event propagated to its callers. This could cause the
      following failure cascade:
      
      1. drm_wait_pending_flip stopped waiting for a pending flip.
      2. Its caller cleared drmmode_crtc->flip_pending before the flip
         completed.
      3. Another flip was attempted but got an unexpected EBUSY error because
         the previous flip was still pending.
      4. TearFree was disabled due to the error.
      
      The solution is to call drmHandleEvent if it was interrupted by a
      signal. We can do that in drm_handle_event, because when that is called,
      either it is known that there are events ready to be processed, or the
      caller has to wait for events to arrive anyway.
      
      v2:
      * Use ErrorF instead of xf86DrvMsg with hard-coded screen 0.
      
      Bugzilla: https://bugs.freedesktop.org/109364
      Reviewed-by: Alex Deucher <alexander.deucher@amd.com> # v1
      3ff2cc22
  21. 17 Jan, 2019 1 commit
  22. 16 Jan, 2019 3 commits
  23. 11 Jan, 2019 1 commit
  24. 10 Jan, 2019 2 commits
  25. 20 Dec, 2018 2 commits
  26. 19 Dec, 2018 2 commits
    • Michel Dänzer's avatar
      Don't clear info->flip_window in present_unflip · 233a0be8
      Michel Dänzer authored
      present_unflip can get called between present_check_flip and
      present_flip, in which case the latter would pass a NULL WindowPtr to
      the former, resulting in a crash.
      
      present_flip should never get called for a window which has already been
      destroyed, so there's no need to clear info->flip_window.
      
      Bugzilla: https://bugs.freedesktop.org/109067
      Fixes: 2d18b371 "Check last flip window instead of screen root
                            before flipping"
      Reviewed-by: 's avatarAlex Deucher <alexander.deucher@amd.com>
      233a0be8
    • Mario Kleiner's avatar
      Fix crash when page flipping in multi-X-Screen/Zaphod mode · d4eab5d1
      Mario Kleiner authored
      amdgpu_do_pageflip() indexed the flipdata->fb[] array
      indexing over config->num_crtc, but the flip completion
      routines, e.g., drmmode_flip_handler(), index that array
      via the crtc hw id from drmmode_get_crtc_id(crtc).
      
      This is mismatched and causes indexing into the wrong
      array slot at flip completion -> Server crash.
      
      Always use drmmode_get_crtc_id(crtc) for indexing into
      the array to fix this.
      
      Tested on a dual-X-Screen setup with one video output
      assigned to each X-Screen, page-flipping an OpenGL app
      on either of both X-Screens. This used to crash when
      flipping on X-Screen 1, now it doesn't anymore.
      
      Fixes: 9b6782c8 "Store FB for each CRTC in drmmode_flipdata_rec"
      (Ported from radeon commit 0058fd2ebf4c900b12f129984e98886a7ac84b2f)
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: 's avatarMario Kleiner <mario.kleiner.de@gmail.com>
      d4eab5d1