Martin: It looks like what you're trying to do is to delay starting of the mpeg encoder until the video decoder (i.e. saa7115) has run for at least 300msec, right? Causing the state machine to freeze for 300msec right after the video decoder is started will have that effect.
I'd like to restructure this patch. The driver uses a non-blocking event oriented approach via a state machine when controlling the video pipeline - sleep style operations are normally not done. So to create the effect of this patch, the code which calls this function to start the saa7115 streaming just needs to not set the "yes the decoder is working flag" until 300msec later. That can be done without blocking anything, via an adjustment of the state machine which I can set up. Then the other various things should work properly. Also, if this fix is specific to the saa7115 then it should be keyed against PVR2_CLIENT_ID_SAA7115 rather than "everything but PVR2_CLIENT_ID_CX25840" (minor detail). -Mike On Sun, 24 Jan 2010, Martin Dauskardt wrote: > Some time ago I reported the problem, that after starting a read access the > screen is sometimes black. > http://www.isely.net/pipermail/pvrusb2/2009-October/002637.html > > This is definetely a timing issue. A similar problem existed in the ivtv > driver and was solved 2007 by adding a 300ms sleep. Obviously only devices > with saa7115 digitizer are effected. > This has been discussed again in December and January on > <http://article.gmane.org/gmane.linux.drivers.video-input- > infrastructure/14332> > > The attached patch fixes the problem in a similar way for the pvrusb2 driver. > I reverted also a previous increase for another delay as this was the wrong > place. > > Greets, > Martin > -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
