On Sunday 28 February 2010, Martin Dauskardt wrote:
> The funny thing is that I cannot provoke this flickering even with a
> current unpatched driver. So there is no difference with the patch. (I
> can't say much about ghosting - I always use 720x576. I will see next
> weekend if I can do more testings)
>
> @ Ian Armstrong:
> Could you check if you can provoke the flickering without your patch, but
> with a driver that has these changes:
> http://linuxtv.org/hg/v4l-dvb/rev/7753cdcebd28
> http://linuxtv.org/hg/v4l-dvb/rev/ec42a97b1a36
>
I've just found that the delay changes partially break my patch. Full res
captures are fine with no ghosting or flickering, but the new delays
consistently break scaled captures, with ghosting every time.
My patch only seems to work properly with the current kernel version, which
has a single 300ms delay before CX2341X_ENC_INITIALIZE_INPUT. (260ms also
seems to work, but 250ms does not). There must be no delay between the init &
capture start, as that also breaks things.
I've reverted the delay changes on my test box, and it's now running the
following without problems. This is identical to the ivtv driver in 2.6.32.
/* Avoid unpredictable PCI bus hang - disable video clocks */
v4l2_subdev_call(itv->sd_video, video, s_stream, 0);
ivtv_msleep_timeout(300, 1);
ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0);
v4l2_subdev_call(itv->sd_video, video, s_stream, 1);
}
Depending on what you found with your delay tests, it may be that the delay
required is different depending on the hardware in use.
--
Ian
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
