From: Jason T. <ta...@ur...> - 2007-04-30 13:09:26
|
On 2007-04-30 06:45, Barry Scott wrote: > You can also do an ioctl to DRM to do a VSYNC avoiding the need to do > the GLX stuff. But nVidia binary driver does not support that ioctl or a > replacement so your GLX method would be needed for nVidia binary drivers. > The ioctl works for via and intel graphics. Since the GLX approach works for all of them, I suppose it would make the most sense to implement it that way. > I cannot live with a 2 second delay before output starts up. You can > use xrandr > 1.2 to find out the refresh rate and avoid the delay. If all else > fails have a config > variable that can be used to tell xine the refresh rate. I agree, a 2 second delay before output would be intolerable. But that's not what I meant; I probably should have said interval, instead of delay. The 2 second interval refers to the time between the VO is initialized and when vsync waits begin. So if we assume output begins immediately following initialization, then there will still be video output for 2 seconds, but no retrace waits until after the 2 seconds. Reimar had suggested XF86VidModeGetModeLine, which might fit the bill. Though it does require libXxf86vm, and I don't have a sense how portable that is. It might work ok to check for libXxf86vm or libXrandr 1.2 at runtime and use one of those to determine refresh rate, and if that fails, fall back to the time-based computation (retrace_count1 - retrace_count0) / (t1 - t0). Since nobody has replied yet saying the idea is moronic, is it safe to take that as a statement that this would be worthwhile to implement in xine? Cheers, Jason. |