On Fri, Nov 01, 2002 at 04:18:47PM -0600, Billy Biggs wrote:
> 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. :)
You need to be able to block on it, though. Otherwise, you have to poll
it:
for(;;) {
read(vblank, ×tamp, sizeof(struct timestamp));
if(timestamp.vblank_number > prev_vblank_number) {
prev_vblank_number = timestamp.vblank_number;
swap_buffers();
}
perform_less_than_1_millisecond_of_work_or_possibly_just_spin();
}
This will not make you happy, especially since this needs to be running
in a real-time scheduling class. :-)
-J
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
