diff options
author | Alex Goins <agoins@nvidia.com> | 2017-10-19 20:02:30 -0700 |
---|---|---|
committer | Adam Jackson <ajax@redhat.com> | 2017-10-27 10:00:47 -0400 |
commit | 266d9868ca1cf77b7d315d607b515f081a9f45c3 (patch) | |
tree | c12c674eb4e8691a81269dc83f8aedb4feb3654f /glamor/glamor.c | |
parent | 68d95e759f8b6ebca6bd52e69e6bc34cc174f8ca (diff) |
xf86-video-modesetting: Fix ms_queue_vblank(flags = MS_QUEUE_RELATIVE)
Change 677c32bc refactored all usages of drmWaitVBlank() into a helper function,
ms_queue_vblank().
ms_queue_vblank() takes in an MS_QUEUE_RELATIVE flag to indicate that the
sequence number is relative rather than absolute, but still treats the actual
sequence number as absolute, passing it through ms_crtc_msc_to_kernel_msc()
unconditionally before calling drmWaitVBlank().
ms_crtc_msc_to_kernel_msc() works by subtracting a vblank offset from the
provided sequence number, which only makes sense for absolute sequence numbers.
In the case of PRIME Sync, drmmode_SharedPixmapPrsentOnVBlank() passes in 1,
which results in a large negative vblank offset. After subtracting, we're left
with a relative sequence number of 100,000+, i.e. wait for 100,000+ vblanks...
In the relative case we want to pass in the sequence number unmodified. Simply
add a check to do this.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Diffstat (limited to 'glamor/glamor.c')
0 files changed, 0 insertions, 0 deletions