On Sun, 06 Sep 2009 12:23:12 +0200 Michel Dänzer <mic...@daenzer.net> wrote:
> On Fri, 2009-09-04 at 12:17 -0700, Jesse Barnes wrote: > > I've been working on coding up the server and client side of > > SGI_video_sync, OML_sync_control and SGI_swap_control. I came up > > with this set of new protocol (against the dri2-swapbuffers branch) > > to support the new requests. > > > > We still need to change the DRI2SwapBuffers request to handle the > > various OML bits before it gets merged. > > > > To summarize: > > DRI2GetMSCReq - get MSC triple > > DRI2WaitMSCReq - wait on an MSC count or divisor/remainder > > DRI2WaitSBCReq - wait on a swap count or all pending swaps > > Waiting in the X server will make it quite unlikely that the client > will be notified within a reasonable timeframe from when vertical > blank actually occurs. Won't this jeopardize the usefulness of the > functionality? As they're mainly used for throttling drawing, I don't think so. But I also don't see a way to avoid it. In the composited case, compositor interaction will be necessary, and even for non-redirected windows, the client doesn't know which CRTC it's on w/o racing with the server. Definitely open to suggestions though. > > DRI2MSCReply - MSC triple (generated in response to any of the > > above) > > > > Kristian and I talked briefly about doing this client side using > > events to notify clients when their CRTC changes, but there are a > > few issues: > > - races between client blocking and other server events (DPMS, > > window movement) > > Maybe the X server could trigger a DRM event that the client could > wait for directly, or something like that. So make them one way requests that queue a DRM event for the client? Hm yeah that could work and would save us an extra context switch between server and client... > > - compositor interaction; in the compositor case the display server > > will be incrementing frame count based on compositor drawing > > rather than vblank events > > I think that's a bad idea, as it will confuse apps if the compositor > misses a frame or renders the app window more than once per frame. It seems to match what people want though; so far we've heard from Soren and Robert and both want to know when the pixels are actually displayed for various apps. W/o compositor interaction I don't see how we can do that. It could be easily configurable though anyway; if the compositor doesn't support the feature, the frame count would correspond to a screen of the server's choosing. That's what I'm implementing first anyway, just to make sure things work. -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
