[PATCH xserver] modesetting: Fix and improve ms_kernel_msc_to_crtc_msc()

Adam Jackson ajax at redhat.com
Mon May 7 18:09:26 UTC 2018


On Sun, 2018-05-06 at 07:34 +0200, Mario Kleiner wrote:
> 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.

A tiny nit:

>  int
>  ms_get_crtc_ust_msc(xf86CrtcPtr crtc, CARD64 *ust, CARD64 *msc)
>  {
> +    ScreenPtr screen = crtc->randr_crtc->pScreen;
> +    ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
> +    modesettingPtr ms = modesettingPTR(scrn);

This could almost certainly be:

    modesettingPtr ms = modesettingPTR(crtc->scrn);

But it hardly matters. The rest looks good, merged, thanks:

remote: I: patch #220897 updated using rev c9afd8cb5ec975b189ab7b678e1f997d6a2ba5ee.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   73f0ed2d92..c9afd8cb5e  master -> master

- ajax


More information about the xorg-devel mailing list