Hmm, no good. I am getting hard system freezes when transferring to and from a vid stream. The framebuffer isn't visually getting corrupted like 'l' but its still freezing on stream interruption.
The visual artifacts are being caused by mythtv .17 I think. I reverted back to my working driver and I still have them. When I close the program guide, I get a black square until I bring up something on the osd. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Kennedy Sent: Thursday, March 24, 2005 7:15 PM To: [email protected] Subject: Re: [ivtv-devel] Re: #0.3.2m remove OSD vsync wait This actually was in there just to keep the OSD DMA speed from going too fast, although it's easy to add back in, so I'm curious of the results. I think tearing would be more the way one wrote to the framebuffer than when, and if breaking up the DMA like we do, it's actually writing less than 1 frame and thus we are slowing it down quite a bit this way. There may be a need for something else, probably DMA and BLT would be best for anti-tearing, possibly moving the OSD window too. I suspect it won't be different and to minimize tearing (which is probably a problem just when using the OSD alone without decoding), in the no-decoding case we can now safely write a frame at a time. So testing will be interesting since it was a limit that may have been arbitrary and definitely not well fitting for cases where the OSD isn't updated a frame at a time (like X and Myth I believe), also the vsync interrupt isn't the most accurate thing and I suspect we aren't really able to use it to get there right at each vsync unfortunately. Thanks, Chris On Thu, Mar 24, 2005 at 06:33:54PM -0500, Jelle Foks wrote: > Chris Kennedy wrote: > >This removes the OSD vsync wait stuff, just like the patch I posted. > > Wouldn't that cause a lot of tearing? I thought the vsync wait was in > there to minimize tearing (update the framebuffer exactly in between > frames). > > jelle. > > > >Also > >some minor YUV encoding Get Input Format V4L2 fixes so that gives the > >correct pixelsize and type of frames. I made the encoder PIO mode able to > >be set from ivtv-driver.h, of course it'll eat you CPU like crazy, but if > >not able to use DMA for some reason you could set that and the decoder one > >even and possibly still use the card on your system (paying the price with > >CPU of course, like near 90% on a 2.6 Ghz system probably for both > >enc/dec). > > > >http://ivtv.no-ip.info/ivtv-0.3/ivtv-0.3.2m.tgz > > > > > >Thanks, > >Chris > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > ivtv-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
