On Wed, Jan 02, 2002 at 05:45:56PM +0100, Zdenek Kabelac wrote: > Well I could test TV Out only during weekends - but I guess the long > cammera panning scenes will cause some problems unless the image would > be blured. Yep. I'll send you something on which I see problems.
> > Thats the same with other cards (ATI & voodoo), at least unter linux, too, and
> > imho has nothing to do with dualhead.
> Well if I use framebuffer I could select much large area so it just
> the problem with setting right values for H/V sync signals - and
> should be easy to solve if the driver would be written by me...
Well, the ATI TVout is written by me so I know this is not possible yet :-)
> > As I said ATI handles doublebuffering inside X driver, so there was no need
> > for it. OTOH I can try to add this feature inside the new km driver (capturing
> It's not only used for double buffering but ALSO for timing - as interrupt
> will wakeup video rendering thread much more precisely then dumb linux
> scheduler (I would say it wakes the thread with 99.9% precision at least
> with my mga driver)
I should be more precise: ATI handles double buffering in hardware, when
you tell it "do yuv conversion/scaling" and set a certain bit, the picture
isn't drawn immediately, only on the next refresh. And as the command returns
immediately (compared to mga_vid blocking until refresh happens), you can see
why it happens to me, aviplay has no idea when the actual drawing happens.
I'd like to keep the double-buffering to prevent tearing. So my idea is to
write a module that wakes the video renderer thread AFTER the refresh has
finished, not when it begins. This will allow the transfer part of
XVShmPutImage to take longer without negative impact on tearing/judder, so
that sudden spikes on load will have less effect.
But I think you are right about the scheduling stuff, linux scheduler isn't
suited for realtime stuff and IRQ handler might be enough to minimize judder
to acceptable limits (at least with 25 and 29.97 fps on PAL).
> You really should try to hack the IRQ handler and test it - then let
> me know if it helps
Being consulted with other ATI developers.
Bye,
Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023
--
Intel: where Quality is job number 0.9998782345!
msg02537/pgp00000.pgp
Description: PGP signature
