On Son, 2002-11-03 at 06:17, Elladan wrote: > On Fri, Nov 01, 2002 at 02:30:29PM -0800, [EMAIL PROTECTED] wrote: > > > Sender: [EMAIL PROTECTED] > > > On Fre, 2002-11-01 at 21:10, [EMAIL PROTECTED] wrote: > > > > Yes, XSYNC has the right things to allow applications to synchronize > > > > on arbitrary things (including vertical sync). > > > > > > > > If the fbdev and/or DRI folks are willing to support and export an > > > > interface, it should be possible to get the plumbing hooked up. > > > > > > > > Just make it a file descriptor we (and/or other things) can select against, > > > > and it should be something that can be pretty cross platform without much > > > > trouble: them's that don't implement it on a given platform won't get > > > > support... > > > > > > The interface we've implemented in the DRM is an ioctl which basically > > > blocks for a requested number of vertical blanks (it's more flexible in > > > fact). Maybe a daemon or something could provide a file descriptor to > > > select against? > > > > I've just chatted with Keith Packard on this. > > > > This interface (an ioctl that blocks) isn't a good one. > > > > How about a signal when vertical blanking arrives? (1st choice) That, or > > something we can select on? (2nd choice) > > It might be best to provide both interfaces. It's probably not > significantly harder to provide both API's - they both trigger off the > same hardware event.
Yes, I'm looking into adding a flag to the ioctl so it sends a signal instead of blocking. Shouln't be too hard, but I haven't found out yet whether a signal can be delivered from an interrupt top half, if anyone knows I'd appreciate letting me know before I find out the hard way. :) Oh, and are there any opinions about the signal to use, SIGALRM or something else? > Some things to consider: > > Very nice: > > * The interface needs to provide a vblank counter, so the user can easily > detect dropped vblanks. Has been there from day 1. I wonder what to do about this for the signal though, put the sequence number into the siginfo (is that possible?), or is the information you get back from the ioctl enough? The ioctl also provides a timestamp, but that's pretty arcane yet, so people who intend to use that please look at it and help improve it if necessary (hint, hint, Billy Biggs :). > * It would be nice to provide a way to get either the start of the > vertical blanking period, or end end of it (or both). The start is > most important, of course. Only the start is supported so far. > Nice but not as important: > * It would be nice if the interface provided a way to request the > current scan line, and block on particular scan lines. Hardware which > didn't support this (eg., LCD monitors, less-good video cards, etc.) > would of course be expected to return an error. What would that be useful for? As you've explained very well in your other post, the various latencies don't allow for such fine grained timing. > * It would be nice if the interface provided a way to latch particular > simple actions, such as a buffer flip, to the interrupt directly. For > example, with an ioctl: > > vbc.action = VB_SWAP_BUFFERS; > vbc.arg1 = BUFFER1_TOKEN; > vbc.arg2 = BUFFER2_TOKEN; > > ioctl(vblankdev, WAIT_FOR_VBLANK_AND_DO_SOMETHING, &vbc); > > Here, the ioctl blocks until the vblank, and the driver performs the > command in the interrupt handler if possible. Not sure about this. I've played with doing this for flips in the radeon 3D driver, and it didn't work out all that well. Granted, I didn't do the flip in the interrupt top half, but I'm not sure if that's feasible. > Remember, what people need isn't *only* a way to avoid tearing by > syncing on the vblank. They also need a way to schedule output onto the > vblank intelligently. For example, a video player needs some way of > determining what the refresh rate is, so it can select a scheduling > strategy for its output. I think that should be possible with what we have? IIRC all the drivers that support this ioctl also support XVideo double buffering synced to vertical refresh, so if you do the XvPutImage immediately after you get notified about a vertical blank, you can be pretty sure it'll be displayed on the next one. And you can deduce the refresh rate from the timestamps. PS: A: No. Q: Should I include quotations after my reply? ;) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
