Owen Taylor ([EMAIL PROTECTED]): > Michel D�nzer <[EMAIL PROTECTED]> writes: > > > 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? > > Both select and a blocking ioctl are really the wrong interface here. > > select() or poll() are problematical because select() waits for a > condition, not an event. That is, these function calls are designed > things like "tell me when there is more data to read". > > The blocking ioctl is a pain because it means you have to devote a > thread to waiting for the VBI; but it at least is well defined. > > Unix signals are another possibility - a real pain to program, but at > least they were designed for things like this. "Tell me when the next > VBI occurs" has very similar semantics to alarm(2).
I like the idea of a file descriptor that, when you read() from it, gives the timestamp of the last VBI. This has a natural mapping to hardware interrupts (unlike giving milliseconds until the next VBI as was suggested in another response, since we don't really know that), and it matches the semantics of select(). It also allows nicely for async access. Good timestamps (preferably ones matches those returned from APIs like ALSA or V4L2) are essential for most of the applications I can think of, and if anyone disagrees with me on this point let me know. :) -- Billy Biggs [EMAIL PROTECTED] _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
