xserver-multidpi/hw/xfree86/drivers/modesetting/vblank.c

567 lines
16 KiB
C
Raw Normal View History

/*
* Copyright © 2013 Keith Packard
*
* Permission to use, copy, modify, distribute, and sell this software and its
* documentation for any purpose is hereby granted without fee, provided that
* the above copyright notice appear in all copies and that both that copyright
* notice and this permission notice appear in supporting documentation, and
* that the name of the copyright holders not be used in advertising or
* publicity pertaining to distribution of the software without specific,
* written prior permission. The copyright holders make no representations
* about the suitability of this software for any purpose. It is provided "as
* is" without express or implied warranty.
*
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
* EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
* TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
* OF THIS SOFTWARE.
*/
/** @file vblank.c
*
* Support for tracking the DRM's vblank events.
*/
#ifdef HAVE_DIX_CONFIG_H
#include "dix-config.h"
#endif
#include <unistd.h>
#include <xf86.h>
#include <xf86Crtc.h>
#include "driver.h"
#include "drmmode_display.h"
/**
* Tracking for outstanding events queued to the kernel.
*
* Each list entry is a struct ms_drm_queue, which has a uint32_t
* value generated from drm_seq that identifies the event and a
* reference back to the crtc/screen associated with the event. It's
* done this way rather than in the screen because we want to be able
* to drain the list of event handlers that should be called at server
* regen time, even though we don't close the drm fd and have no way
* to actually drain the kernel events.
*/
static struct xorg_list ms_drm_queue;
static uint32_t ms_drm_seq;
static void box_intersect(BoxPtr dest, BoxPtr a, BoxPtr b)
{
dest->x1 = a->x1 > b->x1 ? a->x1 : b->x1;
dest->x2 = a->x2 < b->x2 ? a->x2 : b->x2;
if (dest->x1 >= dest->x2) {
dest->x1 = dest->x2 = dest->y1 = dest->y2 = 0;
return;
}
dest->y1 = a->y1 > b->y1 ? a->y1 : b->y1;
dest->y2 = a->y2 < b->y2 ? a->y2 : b->y2;
if (dest->y1 >= dest->y2)
dest->x1 = dest->x2 = dest->y1 = dest->y2 = 0;
}
static void rr_crtc_box(RRCrtcPtr crtc, BoxPtr crtc_box)
{
if (crtc->mode) {
crtc_box->x1 = crtc->x;
crtc_box->y1 = crtc->y;
switch (crtc->rotation) {
case RR_Rotate_0:
case RR_Rotate_180:
default:
crtc_box->x2 = crtc->x + crtc->mode->mode.width;
crtc_box->y2 = crtc->y + crtc->mode->mode.height;
break;
case RR_Rotate_90:
case RR_Rotate_270:
crtc_box->x2 = crtc->x + crtc->mode->mode.height;
crtc_box->y2 = crtc->y + crtc->mode->mode.width;
break;
}
} else
crtc_box->x1 = crtc_box->x2 = crtc_box->y1 = crtc_box->y2 = 0;
}
static int box_area(BoxPtr box)
{
return (int)(box->x2 - box->x1) * (int)(box->y2 - box->y1);
}
static Bool rr_crtc_on(RRCrtcPtr crtc, Bool crtc_is_xf86_hint)
{
if (!crtc) {
return FALSE;
}
if (crtc_is_xf86_hint && crtc->devPrivate) {
return xf86_crtc_on(crtc->devPrivate);
} else {
return !!crtc->mode;
}
}
Bool
xf86_crtc_on(xf86CrtcPtr crtc)
{
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
return crtc->enabled && drmmode_crtc->dpms_mode == DPMSModeOn;
}
/*
* Return the crtc covering 'box'. If two crtcs cover a portion of
* 'box', then prefer the crtc with greater coverage.
*/
static RRCrtcPtr
rr_crtc_covering_box(ScreenPtr pScreen, BoxPtr box, Bool screen_is_xf86_hint)
{
modesetting: Check whether RandR was initialized before calling rrGetScrPriv 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 <aplattner@nvidia.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-12-26 22:40:17 +01:00
rrScrPrivPtr pScrPriv;
RRCrtcPtr crtc, best_crtc;
int coverage, best_coverage;
int c;
BoxRec crtc_box, cover_box;
best_crtc = NULL;
best_coverage = 0;
modesetting: Check whether RandR was initialized before calling rrGetScrPriv 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 <aplattner@nvidia.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-12-26 22:40:17 +01:00
if (!dixPrivateKeyRegistered(rrPrivKey))
return NULL;
pScrPriv = rrGetScrPriv(pScreen);
if (!pScrPriv)
return NULL;
for (c = 0; c < pScrPriv->numCrtcs; c++) {
crtc = pScrPriv->crtcs[c];
/* If the CRTC is off, treat it as not covering */
if (!rr_crtc_on(crtc, screen_is_xf86_hint))
continue;
rr_crtc_box(crtc, &crtc_box);
box_intersect(&cover_box, &crtc_box, box);
coverage = box_area(&cover_box);
if (coverage > best_coverage) {
best_crtc = crtc;
best_coverage = coverage;
}
}
return best_crtc;
}
static RRCrtcPtr
rr_crtc_covering_box_on_secondary(ScreenPtr pScreen, BoxPtr box)
{
if (!pScreen->isGPU) {
ScreenPtr secondary;
RRCrtcPtr crtc = NULL;
xorg_list_for_each_entry(secondary, &pScreen->secondary_list, secondary_head) {
if (!secondary->is_output_secondary)
continue;
crtc = rr_crtc_covering_box(secondary, box, FALSE);
if (crtc)
return crtc;
}
}
return NULL;
}
xf86CrtcPtr
ms_dri2_crtc_covering_drawable(DrawablePtr pDraw)
{
ScreenPtr pScreen = pDraw->pScreen;
RRCrtcPtr crtc = NULL;
BoxRec box;
box.x1 = pDraw->x;
box.y1 = pDraw->y;
box.x2 = box.x1 + pDraw->width;
box.y2 = box.y1 + pDraw->height;
crtc = rr_crtc_covering_box(pScreen, &box, TRUE);
if (crtc) {
return crtc->devPrivate;
}
return NULL;
}
RRCrtcPtr
ms_randr_crtc_covering_drawable(DrawablePtr pDraw)
{
ScreenPtr pScreen = pDraw->pScreen;
RRCrtcPtr crtc = NULL;
BoxRec box;
box.x1 = pDraw->x;
box.y1 = pDraw->y;
box.x2 = box.x1 + pDraw->width;
box.y2 = box.y1 + pDraw->height;
crtc = rr_crtc_covering_box(pScreen, &box, TRUE);
if (!crtc) {
crtc = rr_crtc_covering_box_on_secondary(pScreen, &box);
}
return crtc;
}
static Bool
ms_get_kernel_ust_msc(xf86CrtcPtr crtc,
uint64_t *msc, uint64_t *ust)
{
ScreenPtr screen = crtc->randr_crtc->pScreen;
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
modesettingPtr ms = modesettingPTR(scrn);
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
drmVBlank vbl;
int ret;
if (ms->has_queue_sequence || !ms->tried_queue_sequence) {
uint64_t ns;
ms->tried_queue_sequence = TRUE;
ret = drmCrtcGetSequence(ms->fd, drmmode_crtc->mode_crtc->crtc_id,
msc, &ns);
if (ret != -1 || (errno != ENOTTY && errno != EINVAL)) {
ms->has_queue_sequence = TRUE;
if (ret == 0)
*ust = ns / 1000;
return ret == 0;
}
}
/* Get current count */
vbl.request.type = DRM_VBLANK_RELATIVE | drmmode_crtc->vblank_pipe;
vbl.request.sequence = 0;
vbl.request.signal = 0;
ret = drmWaitVBlank(ms->fd, &vbl);
if (ret) {
*msc = 0;
*ust = 0;
return FALSE;
} else {
*msc = vbl.reply.sequence;
*ust = (CARD64) vbl.reply.tval_sec * 1000000 + vbl.reply.tval_usec;
return TRUE;
}
}
Bool
ms_queue_vblank(xf86CrtcPtr crtc, ms_queue_flag flags,
uint64_t msc, uint64_t *msc_queued, uint32_t seq)
{
ScreenPtr screen = crtc->randr_crtc->pScreen;
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
modesettingPtr ms = modesettingPTR(scrn);
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
drmVBlank vbl;
int ret;
for (;;) {
/* Queue an event at the specified sequence */
if (ms->has_queue_sequence || !ms->tried_queue_sequence) {
uint32_t drm_flags = 0;
uint64_t kernel_queued;
ms->tried_queue_sequence = TRUE;
if (flags & MS_QUEUE_RELATIVE)
drm_flags |= DRM_CRTC_SEQUENCE_RELATIVE;
if (flags & MS_QUEUE_NEXT_ON_MISS)
drm_flags |= DRM_CRTC_SEQUENCE_NEXT_ON_MISS;
ret = drmCrtcQueueSequence(ms->fd, drmmode_crtc->mode_crtc->crtc_id,
modesetting: Remove ms_crtc_msc_to_kernel_msc(). The function is ported from intel-ddx uxa backend around 2013, where its stated purpose was to apply a vblank_offset to msc values to correct for problems with those kernel provided msc values. Some (somewhat magic and puzzling to myself) heuristic tried to guess if provided values were unreasonable and tried to adapt the corrective vblank_offset to account for that. Except: It wasn't applied to kernel provided msc values, but the values delivered by clients via DRI2 or Present, so valid client targetmsc values, e.g., requesting a vblank event > 1000 vblanks in the future, triggered the offset correction in arbitrarily wrong ways, leading to wrong msc values being returned and thereby vblank events queued to the kernel for the wrong time. This causes glXSwapBuffersMscOML and glXWaitForMscOML to swap / return immediately whenever a swap/wait in > 1000 vblanks is requested. The original code was also written to only deal with 32 bit mscs, but server 1.20 modesetting ddx can now use new Linux 4.15+ kernel vblank api to process true 64 bit msc's, which may confuse the heuristic even more due to 32 bit integer truncation/wrapping. This code caused various problems in the intel-ddx in the past since year 2013, and was removed there in 2015 by Chris Wilson in commit 42ebe2ef9646be5c4586868cf332b4cd79bb4618: " uxa: Remove the filtering of bogus Present MSC values If the intention was to filter the return values from the kernel, the filtering would have been applied to the kernel values and not to the incoming values from Present. This filtering introduces crazy integer promotion and truncation bugs all because Present feeds garbage into its vblank requests. " Indeed, i found a Mesa bug yesterday which can cause Mesa's PresentPixmap request to spuriously feed garbage targetMSC's into the driver under some conditions. However, while other video drivers seem to cope relatively well with that, modesetting ddx causes KDE-5's plasmashell to lock up badly quite frequently, and my suspicion is that the code removed in this commit is one major source of the extra fragility. Also my own tests fail for any swap scheduled more than 1000 vblanks into the future, which is not uncommon for some scientific applications. Iow. modesetting's swap scheduling seems to be more robust without this function afaics. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Keith Packard <keithp@keithp.com> Tested-by: Mike Lothian <mike@fireburn.co.uk>
2018-05-04 14:14:10 +02:00
drm_flags, msc, &kernel_queued, seq);
if (ret == 0) {
if (msc_queued)
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
2018-05-06 07:34:31 +02:00
*msc_queued = ms_kernel_msc_to_crtc_msc(crtc, kernel_queued, TRUE);
ms->has_queue_sequence = TRUE;
return TRUE;
}
if (ret != -1 || (errno != ENOTTY && errno != EINVAL)) {
ms->has_queue_sequence = TRUE;
goto check;
}
}
vbl.request.type = DRM_VBLANK_EVENT | drmmode_crtc->vblank_pipe;
if (flags & MS_QUEUE_RELATIVE)
vbl.request.type |= DRM_VBLANK_RELATIVE;
else
vbl.request.type |= DRM_VBLANK_ABSOLUTE;
if (flags & MS_QUEUE_NEXT_ON_MISS)
vbl.request.type |= DRM_VBLANK_NEXTONMISS;
modesetting: Remove ms_crtc_msc_to_kernel_msc(). The function is ported from intel-ddx uxa backend around 2013, where its stated purpose was to apply a vblank_offset to msc values to correct for problems with those kernel provided msc values. Some (somewhat magic and puzzling to myself) heuristic tried to guess if provided values were unreasonable and tried to adapt the corrective vblank_offset to account for that. Except: It wasn't applied to kernel provided msc values, but the values delivered by clients via DRI2 or Present, so valid client targetmsc values, e.g., requesting a vblank event > 1000 vblanks in the future, triggered the offset correction in arbitrarily wrong ways, leading to wrong msc values being returned and thereby vblank events queued to the kernel for the wrong time. This causes glXSwapBuffersMscOML and glXWaitForMscOML to swap / return immediately whenever a swap/wait in > 1000 vblanks is requested. The original code was also written to only deal with 32 bit mscs, but server 1.20 modesetting ddx can now use new Linux 4.15+ kernel vblank api to process true 64 bit msc's, which may confuse the heuristic even more due to 32 bit integer truncation/wrapping. This code caused various problems in the intel-ddx in the past since year 2013, and was removed there in 2015 by Chris Wilson in commit 42ebe2ef9646be5c4586868cf332b4cd79bb4618: " uxa: Remove the filtering of bogus Present MSC values If the intention was to filter the return values from the kernel, the filtering would have been applied to the kernel values and not to the incoming values from Present. This filtering introduces crazy integer promotion and truncation bugs all because Present feeds garbage into its vblank requests. " Indeed, i found a Mesa bug yesterday which can cause Mesa's PresentPixmap request to spuriously feed garbage targetMSC's into the driver under some conditions. However, while other video drivers seem to cope relatively well with that, modesetting ddx causes KDE-5's plasmashell to lock up badly quite frequently, and my suspicion is that the code removed in this commit is one major source of the extra fragility. Also my own tests fail for any swap scheduled more than 1000 vblanks into the future, which is not uncommon for some scientific applications. Iow. modesetting's swap scheduling seems to be more robust without this function afaics. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Keith Packard <keithp@keithp.com> Tested-by: Mike Lothian <mike@fireburn.co.uk>
2018-05-04 14:14:10 +02:00
vbl.request.sequence = msc;
vbl.request.signal = seq;
ret = drmWaitVBlank(ms->fd, &vbl);
if (ret == 0) {
if (msc_queued)
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
2018-05-06 07:34:31 +02:00
*msc_queued = ms_kernel_msc_to_crtc_msc(crtc, vbl.reply.sequence, FALSE);
return TRUE;
}
check:
if (errno != EBUSY) {
ms_drm_abort_seq(scrn, seq);
return FALSE;
}
ms_flush_drm_events(screen);
}
}
/**
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
2018-05-06 07:34:31 +02:00
* Convert a 32-bit or 64-bit kernel MSC sequence number to a 64-bit local
* sequence number, adding in the high 32 bits, and dealing with 32-bit
* wrapping if needed.
*/
uint64_t
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
2018-05-06 07:34:31 +02:00
ms_kernel_msc_to_crtc_msc(xf86CrtcPtr crtc, uint64_t sequence, Bool is64bit)
{
drmmode_crtc_private_rec *drmmode_crtc = crtc->driver_private;
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
2018-05-06 07:34:31 +02:00
if (!is64bit) {
/* sequence is provided as a 32 bit value from one of the 32 bit apis,
* e.g., drmWaitVBlank(), classic vblank events, or pageflip events.
*
* Track and handle 32-Bit wrapping, somewhat robust against occasional
* out-of-order not always monotonically increasing sequence values.
*/
if ((int64_t) sequence < ((int64_t) drmmode_crtc->msc_prev - 0x40000000))
drmmode_crtc->msc_high += 0x100000000L;
if ((int64_t) sequence > ((int64_t) drmmode_crtc->msc_prev + 0x40000000))
drmmode_crtc->msc_high -= 0x100000000L;
drmmode_crtc->msc_prev = sequence;
return drmmode_crtc->msc_high + sequence;
}
/* True 64-Bit sequence from Linux 4.15+ 64-Bit drmCrtcGetSequence /
* drmCrtcQueueSequence apis and events. Pass through sequence unmodified,
* but update the 32-bit tracking variables with reliable ground truth.
*
* With 64-Bit api in use, the only !is64bit input is from pageflip events,
2019-09-30 18:43:13 +02:00
* and any pageflip event is usually preceded by some is64bit input from
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
2018-05-06 07:34:31 +02:00
* swap scheduling, so this should provide reliable mapping for pageflip
* events based on true 64-bit input as baseline as well.
*/
drmmode_crtc->msc_prev = sequence;
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
2018-05-06 07:34:31 +02:00
drmmode_crtc->msc_high = sequence & 0xffffffff00000000;
return sequence;
}
int
ms_get_crtc_ust_msc(xf86CrtcPtr crtc, CARD64 *ust, CARD64 *msc)
{
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
2018-05-06 07:34:31 +02:00
ScreenPtr screen = crtc->randr_crtc->pScreen;
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
modesettingPtr ms = modesettingPTR(scrn);
uint64_t kernel_msc;
if (!ms_get_kernel_ust_msc(crtc, &kernel_msc, ust))
return BadMatch;
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
2018-05-06 07:34:31 +02:00
*msc = ms_kernel_msc_to_crtc_msc(crtc, kernel_msc, ms->has_queue_sequence);
return Success;
}
/**
* Check for pending DRM events and process them.
*/
static void
ms_drm_socket_handler(int fd, int ready, void *data)
{
ScreenPtr screen = data;
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
modesettingPtr ms = modesettingPTR(scrn);
if (data == NULL)
return;
drmHandleEvent(fd, &ms->event_context);
}
/*
* Enqueue a potential drm response; when the associated response
* appears, we've got data to pass to the handler from here
*/
uint32_t
ms_drm_queue_alloc(xf86CrtcPtr crtc,
void *data,
ms_drm_handler_proc handler,
ms_drm_abort_proc abort)
{
ScreenPtr screen = crtc->randr_crtc->pScreen;
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
struct ms_drm_queue *q;
q = calloc(1, sizeof(struct ms_drm_queue));
if (!q)
return 0;
if (!ms_drm_seq)
++ms_drm_seq;
q->seq = ms_drm_seq++;
q->scrn = scrn;
q->crtc = crtc;
q->data = data;
q->handler = handler;
q->abort = abort;
xorg_list_add(&q->list, &ms_drm_queue);
return q->seq;
}
/**
* Abort one queued DRM entry, removing it
* from the list, calling the abort function and
* freeing the memory
*/
static void
ms_drm_abort_one(struct ms_drm_queue *q)
{
xorg_list_del(&q->list);
q->abort(q->data);
free(q);
}
/**
* Abort all queued entries on a specific scrn, used
* when resetting the X server
*/
static void
ms_drm_abort_scrn(ScrnInfoPtr scrn)
{
struct ms_drm_queue *q, *tmp;
xorg_list_for_each_entry_safe(q, tmp, &ms_drm_queue, list) {
if (q->scrn == scrn)
ms_drm_abort_one(q);
}
}
/**
* Abort by drm queue sequence number.
*/
void
ms_drm_abort_seq(ScrnInfoPtr scrn, uint32_t seq)
{
struct ms_drm_queue *q, *tmp;
xorg_list_for_each_entry_safe(q, tmp, &ms_drm_queue, list) {
if (q->seq == seq) {
ms_drm_abort_one(q);
break;
}
}
}
/*
* Externally usable abort function that uses a callback to match a single
* queued entry to abort
*/
void
ms_drm_abort(ScrnInfoPtr scrn, Bool (*match)(void *data, void *match_data),
void *match_data)
{
struct ms_drm_queue *q;
xorg_list_for_each_entry(q, &ms_drm_queue, list) {
if (match(q->data, match_data)) {
ms_drm_abort_one(q);
break;
}
}
}
/*
* General DRM kernel handler. Looks for the matching sequence number in the
* drm event queue and calls the handler for it.
*/
static void
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
2018-05-06 07:34:31 +02:00
ms_drm_sequence_handler(int fd, uint64_t frame, uint64_t ns, Bool is64bit, uint64_t user_data)
{
struct ms_drm_queue *q, *tmp;
uint32_t seq = (uint32_t) user_data;
xorg_list_for_each_entry_safe(q, tmp, &ms_drm_queue, list) {
if (q->seq == seq) {
uint64_t msc;
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
2018-05-06 07:34:31 +02:00
msc = ms_kernel_msc_to_crtc_msc(q->crtc, frame, is64bit);
xorg_list_del(&q->list);
q->handler(msc, ns / 1000, q->data);
free(q);
break;
}
}
}
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
2018-05-06 07:34:31 +02:00
static void
ms_drm_sequence_handler_64bit(int fd, uint64_t frame, uint64_t ns, uint64_t user_data)
{
/* frame is true 64 bit wrapped into 64 bit */
ms_drm_sequence_handler(fd, frame, ns, TRUE, user_data);
}
static void
ms_drm_handler(int fd, uint32_t frame, uint32_t sec, uint32_t usec,
void *user_ptr)
{
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
2018-05-06 07:34:31 +02:00
/* frame is 32 bit wrapped into 64 bit */
ms_drm_sequence_handler(fd, frame, ((uint64_t) sec * 1000000 + usec) * 1000,
FALSE, (uint32_t) (uintptr_t) user_ptr);
}
Bool
ms_vblank_screen_init(ScreenPtr screen)
{
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
modesettingPtr ms = modesettingPTR(scrn);
modesettingEntPtr ms_ent = ms_ent_priv(scrn);
xorg_list_init(&ms_drm_queue);
ms->event_context.version = 4;
ms->event_context.vblank_handler = ms_drm_handler;
ms->event_context.page_flip_handler = ms_drm_handler;
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Cc: Keith Packard <keithp@keithp.com> Cc: Michel Dänzer <michel.daenzer@amd.com>
2018-05-06 07:34:31 +02:00
ms->event_context.sequence_handler = ms_drm_sequence_handler_64bit;
/* We need to re-register the DRM fd for the synchronisation
* feedback on every server generation, so perform the
* registration within ScreenInit and not PreInit.
*/
if (ms_ent->fd_wakeup_registered != serverGeneration) {
SetNotifyFd(ms->fd, ms_drm_socket_handler, X_NOTIFY_READ, screen);
ms_ent->fd_wakeup_registered = serverGeneration;
ms_ent->fd_wakeup_ref = 1;
} else
ms_ent->fd_wakeup_ref++;
return TRUE;
}
void
ms_vblank_close_screen(ScreenPtr screen)
{
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
modesettingPtr ms = modesettingPTR(scrn);
modesettingEntPtr ms_ent = ms_ent_priv(scrn);
ms_drm_abort_scrn(scrn);
if (ms_ent->fd_wakeup_registered == serverGeneration &&
!--ms_ent->fd_wakeup_ref) {
RemoveNotifyFd(ms->fd);
}
}