[PATCH] present: Query the right CRTC to use each time

Chris Wilson chris at chris-wilson.co.uk
Mon Jun 2 13:24:16 PDT 2014


On Mon, Jun 02, 2014 at 01:04:39PM -0700, Keith Packard wrote:
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> 
> > As the CRTCs may be reconfigured between each invocation, we can not
> > assume that the previous CRTC we used last time will still be valid for
> > this call.
> 
> Is this a problem with CRTCs that are deleted? If so, hooking crtc
> destruction would be pretty easy.

The problem occurs with doing something like:

xrandr --output LVDS --crtc 0
getmsc
xrandr --output LVDS --crtc 1
getmsc

(That the client can get confused and present on the wrong CRTC is
an unfortunate race condition, but there needs to be a way to poll for
XErrors alongside the futex signalling in order to catch when the futex
will never be woken and abort.)

> > diff --git a/present/present.c b/present/present.c
> > index e35de94..d1bb9d4 100644
> > --- a/present/present.c
> > +++ b/present/present.c
> > @@ -673,15 +673,8 @@ present_pixmap(WindowPtr window,
> >  
> >      if (!screen_priv || !screen_priv->info)
> >          target_crtc = NULL;
> > -    else if (!target_crtc) {
> > -        /* Update the CRTC if we have a pixmap or we don't have a CRTC
> > -         */
> > -        if (!pixmap)
> > -            target_crtc = window_priv->crtc;
> > -
> > -        if (!target_crtc)
> > -            target_crtc = present_get_crtc(window);
> > -    }
> > +    else if (!target_crtc)
> > +        target_crtc = present_get_crtc(window);
> 
> This only changes the behavior for notify_msc, and what we want there is
> to continue using the same CRTC that the last swap used so that the
> values are reasonable. All presents with a pixmap will continue to call
> present_get_crtc each time.

Right, looking again at the loop the error hits during the
dri3_wait_for_msc() loop that doesn't break out the wait-for-event loop
due to the BadMatch from xcb_present_notify_msc(). Another annoyance
here is that for GetMSC we queue an event for the next vblank which
seems like unwanted latency.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the xorg-devel mailing list