Em 23-02-2011 19:56, Devin Heitmueller escreveu:
>>> However, the cx231xx has code for setting up the DIF which basically
>>> says:
>>>
>>> if (standard & V4L2_STD_MN) {
>>> ...
>>> } else if ((standard == V4L2_STD_PAL_I) |
>>> (standard & V4L2_STD_PAL_D) |
>>>
On Wed, Feb 23, 2011 at 5:29 PM, Mauro Carvalho Chehab
wrote:
> Not all PAL standards. "Only" the european PAL standards (B/G/D/K/I/H):
Correct.
> PAL/M, PAL/N, PAL/Nc and PAL/60 are not part of it. This is the equivalent
> of the V4L1 definition for PAL (on V4L1, there was just PAL/NSTC/SECAM,
Em 23-02-2011 18:09, Devin Heitmueller escreveu:
> Hello there,
>
> I was debugging some PAL issues with cx231xx, and noticed some
> unexpected behavior with regards to selecting PAL standards.
>
> In particular, tvtime has an option for PAL which corresponds to the
> underlying value "0xff". Th
On Wed, Feb 23, 2011 at 4:53 PM, Andy Walls wrote:
> "When the standard set is ambiguous drivers may return EINVAL or choose
> any of the requested standards."
Returning -EINVAL is really not desired behavior.
> If you don't have standard autodetection before the DIF, your
> safest bet is to hav
On Wed, 2011-02-23 at 16:09 -0500, Devin Heitmueller wrote:
> Hello there,
>
> I was debugging some PAL issues with cx231xx, and noticed some
> unexpected behavior with regards to selecting PAL standards.
>
> In particular, tvtime has an option for PAL which corresponds to the
> underlying value
Hello there,
I was debugging some PAL issues with cx231xx, and noticed some
unexpected behavior with regards to selecting PAL standards.
In particular, tvtime has an option for PAL which corresponds to the
underlying value "0xff". This basically selects *any* PAL standard.
However, the cx231xx h
