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.
Some things to consider: Very nice: * The interface needs to provide a vblank counter, so the user can easily detect dropped vblanks. * 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. 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. * 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. 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. For example, for 24fps movie content, a video player should be able to detect the refresh rate (a vblank counter would allow for this) and select different strategies in different situations: 72hz VGA: 3 perfect vb/frame - 3:3:3:3:3:3:3:3 60hz NTSC: 2:3 pulldown - 2:3:2:3:2:3:2:3 50hz PAL: 2 vb/frame, temporal resample: 2:2:2:2 + resample audio -J On Fri, Nov 01, 2002 at 02:30:29PM -0800, [EMAIL PROTECTED] wrote: > 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) > > - Jim Gettys > > > Sender: [EMAIL PROTECTED] > > From: Michel =?ISO-8859-1?Q?D=E4nzer?= <[EMAIL PROTECTED]> > > Date: 01 Nov 2002 22:01:46 +0100 > > To: [EMAIL PROTECTED] > > Subject: Re: [Xpert]But *why* no vblank? > > ----- > > 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? > > > > > > > -- > Jim Gettys > Cambridge Research Laboratory > HP Labs, Hewlett-Packard Company > [EMAIL PROTECTED] > > _______________________________________________ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
