On Thu, Jan 21, 2010 at 07:15:26PM +0100, Roland Scheidegger wrote:
> > Interesting. Would you mind to share ? Sounds strange that this requires
> > driver hacks.
>
> That gets a bit OT, but there were several discussions floating around
> (though they were mostly centered around interlaced timings). The
> problem is that those 48Hz are not synced in any way to movie playback.
> So you'll get drift and every once in a while a movie frame will be
> displayed three times (or once) instead of twice (of course, the same
> principle applies to 50Hz and deinterlaced PAL). To eliminate this, you
> hack the driver to just adjust its timings on the fly, so the drift
> can't accumulate.
> Patches for this (intel+radeon) can be found here:
> http://lowbyte.de/vga-sync-fields/vga-sync-fields/
> I believe though in current form they are only applicable for output
> with interlaced timings but I could be wrong.
Hmm. I don't even know what the API calls (OpenGL ?) are to request
frame accurate display, but why should the application not be responsible
to say what it needs. Eg: send frames, but then also do some nother API
call to 'skip' one vertical blanking interval ? Or in the case of displaying
24Hz movie on 72 Hz display skip 2 ? Or in the case of 3:2 pulldown indicate
alternatively to skip one or two.
Sounds like potentially a lot of guesswork otherwise, if the app doesn't
exactly indicate what it wants, right ? Especially when one wants to
support all those mismatches between player frame rate and display
frame/field-rate.
I guess an application could alredy do this today if it could just ask to
send a new 'picture' that 1x1 pixel large for example ? (or 0x0 ?)
And the 48Hz modeline would also be appreciated.
... and if anyone still happens to know where to find official
720p50 timings, that would be great.
Cheers
Toerless
_______________________________________________
xorg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xorg
