On Thu, 29 Jun 2006, Timothy Miller wrote:
On 6/29/06, Vesa Solonen <[EMAIL PROTECTED]> wrote:
The problem of losing sync come only then when the change is too fast. Is
there any way to implement just variable main clock to the raster
generator? Meaning a runtime access to the pixel clock pll registers.
While I'm sure it's possible to feed the video PLL from an external
source, I don't think it's the cleanest way to go, nor is it
necessary.
Like I say, there's going to be some latency between data getting into
the framebuffer and it getting scanned out of our chip. Our video
output is going to be behind the output. It might be a few scanlines,
a frame, or multiple frames, depending on any software overhead.
I think I got the definition of pixel-exact wrong... See, I understood
that the total amount of pixels in the whole frame+sync+blanking would
be constant. I have no objections for some latency as my suggestion for
syncing would introduce some anyway (one frame or field at least). Also I
meant just to steer the pixel pll in software to adjust pixel frequency to
make the frame time adjustable without touching to the frame buffer.
That's completely different beast than real genlocking, which needs hw
assistance.
-Vesa
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
