summaryrefslogtreecommitdiff
path: root/glamor/glamor.c
diff options
context:
space:
mode:
authorAlex Goins <agoins@nvidia.com>2017-10-19 20:02:30 -0700
committerAdam Jackson <ajax@redhat.com>2017-10-27 10:00:47 -0400
commit266d9868ca1cf77b7d315d607b515f081a9f45c3 (patch)
treec12c674eb4e8691a81269dc83f8aedb4feb3654f /glamor/glamor.c
parent68d95e759f8b6ebca6bd52e69e6bc34cc174f8ca (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