[pvrusb2] [patch] fix black screen after encoder start (saa7115)
Mike Isely
isely at isely.net
Wed Feb 3 22:48:56 CST 2010
On Tue, 26 Jan 2010, Martin Dauskardt wrote:
> > From: Mike Isely <isely at isely.net>
>
> > 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?
> yes, that seems to be the best place. It should also work if the delay is
> placed directly at the beginning of pvr2_encoder_start in pvrusb2-encoder.c
>
> > 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.
>
> I think every delay of 300ms at this place would help, no matter how it is
> done. Give me a patch with your solution and I will test it.
>
> > 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).
>
> yes, this is obviously better.
>
Martin:
I have some changes ready, but I've just discovered a very disturbing
problem - I am completely unable to initialize the device!
The problem is specific to 29xxx device type (I have two). I also have
two 24xxx tuners and those are initializing correctly.
The perplexing part is that the failure is happening right after the FX2
firmware is downloaded: The device never reconnects. At that stage of
initialization there is NO difference among the device types! This
would be explainable if the firmware was corrupted, but I've
rechecksummed it and it is correct.
This is using a 2.6.31.9 kernel. I've also reproduced the failure using
the existing in-kernel pvrusb2 driver as well (i.e. no changes).
What kernel version are you testing under?
Off to debug this little distraction...
-Mike
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
More information about the pvrusb2
mailing list