[EMAIL PROTECTED] ([EMAIL PROTECTED]): > > If we had the vsync as an interrupt (/dev/vsync or something), > > then quality would increase with less system load! Very nice! > > But SCHED_FIFO would still be needed to guarentee accurate blits. > > The other approach is to have a device which you mmap and write your > frames into. Then you issue an ioctl and the driver DMAs the buffers > at the next available opportunity.
Yes, you could make a cool API to solve the issue. It would be really neat. My only concern would be the difficulty of implementing it with consumer video cards. Ideally I'd want 'here's a frame, blit at time X' and hope that someone in the kernel has an accurate clock. It would also need to tell me the (exact) refresh rate + sync point. > > Check out deinterlace.sf.net (aka dscaler.sf.net). [...] > > How big are the cpu requirements ? This is something that is quite > useful, because, at the moment, v4l does not allow to convey such > information as field parity.. Not sure yet. For v4l, I assume all frames are top-field-first. v4l2 provides field parity information, and I'm getting flamed on the video4linux list to switch to it. > One thing - did you try your dvd player with recent ATI drivers ? ATI > can doublebuffer frames switching them automatically on vsync. If you > still see the issue you are worried about something is wrong with our > drivers - I'd appreciate a lot if you could write a test up to debug > the issue. (or a test mpeg stream) I'm not worried about tearing, I'm worried about amortizing frame time over the refresh rate in a pleasing way (especially for special refresh rates like 72hz: think projector). -- Billy Biggs [EMAIL PROTECTED] _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
