Chris Wilson <[email protected]> writes:

> (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.)

Perhaps we should actually signal the futex even if an error is
generated? That would be a bit unusual, but could avoid this problem.

> 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.

GetMSC should execute an immediate kernel call, not queue an event. Sounds
like it's doing something wrong...

-- 
[email protected]

Attachment: pgpTahd1KgHcK.pgp
Description: PGP signature

_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to