On Mon, Jun 02, 2014 at 01:04:39PM -0700, Keith Packard wrote: > Chris Wilson <ch...@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 _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel