Question on V4L2 S_STD call

Question on V4L2 S_STD call

[Devin Heitmueller]

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 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) |
			(standard & V4L2_STD_SECAM)) {
 ...
} else {
  /* default PAL BG */
  ...
}

As a result, if you have a PAL-B/G signal and select "PAL" in tvtime,
the test passes for PAL_I/PAL_D/SECAM since that matches the bitmask.
The result of course is garbage video.

So here is the question:

How are we expected to interpret an application asking for "PAL" in
cases when the driver needs a more specific video standard?

I can obviously add code to tvtime in the long term to have the user
provide a more specific standard instead of "PAL", but since it is
supported in the V4L2 spec, I would like to understand what the
expected behavior should be in drivers.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Question on V4L2 S_STD call

[Andy Walls]

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 "0xff".  This basically selects *any* PAL standard.
> 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) |
> 			(standard & V4L2_STD_SECAM)) {
>  ...
> } else {
>   /* default PAL BG */
>   ...
> }
> 
> As a result, if you have a PAL-B/G signal and select "PAL" in tvtime,
> the test passes for PAL_I/PAL_D/SECAM since that matches the bitmask.
> The result of course is garbage video.
> 
> So here is the question:
> 
> How are we expected to interpret an application asking for "PAL" in
> cases when the driver needs a more specific video standard?

Notwithstanding any bugs in how the driver handles the flags, the
specified behavior for drivers is pretty clear:

http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-std.html

"When the standard set is ambiguous drivers may return EINVAL or choose
any of the requested standards."

If you don't have standard autodetection before the DIF, your
safest bet is to have the driver return EINVAL, if you have flags 
that don't all fall into one of the compound statements in the if()
statement.

In the situation where you already have the DIF set up to a particular
standard, and that current standard matches one of the flags passed in,
you could alternatively leave it set to the currently set standard.

Regards,
Andy

> I can obviously add code to tvtime in the long term to have the user
> provide a more specific standard instead of "PAL", but since it is
> supported in the V4L2 spec, I would like to understand what the
> expected behavior should be in drivers.

> Devin

Re: Question on V4L2 S_STD call

[Devin Heitmueller]

On Wed, Feb 23, 2011 at 4:53 PM, Andy Walls <awalls@md.metrocast.net> 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 have the driver return EINVAL, if you have flags
> that don't all fall into one of the compound statements in the if()
> statement.

This can be a bit tricky since setting the standard typically comes
before the tuning request.  Think of initial startup:  the device
isn't tuned at all.  You get the S_STD call, but you can't do
autodetect because you're not tuned to the target frequency yet.  I
suppose you could reconfigure the DIF after the S_FREQ call, but then
you will probably have to make the driver wait long enough to get a
tuning lock (or have some sort of deferred handler code which polls
for the tuning lock and configured the DIF after the lock is
achieved).

Admittedly I haven't yet dug into how other drivers do this, so I
figured I would ask around first.  Also, I'm not really sure what sort
of standard autodetection capabilities there are in the Polaris (I
should probably talk to the guy who did the DIF work on the cx23885).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Question on V4L2 S_STD call

[Mauro Carvalho Chehab]

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".  This basically selects *any* PAL standard.

Not all PAL standards. "Only" the european PAL standards (B/G/D/K/I/H):

#define V4L2_STD_PAL		(V4L2_STD_PAL_BG	|\
				 V4L2_STD_PAL_DK	|\
				 V4L2_STD_PAL_H		|\
				 V4L2_STD_PAL_I)

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, and
a hack, at bttv, for 4 more standards).

In a matter of fact, V4L2_STD_PAL is not a meaningful parameter, as
it doesn't cover all PAL standards, and if user selects it, an unpredictable
result may happen, as almost no driver is capable of auto-detecting all
variants of the PAL standards. The same issue also happens, on some extend, 
with V4L2_STD_SECAM and V4L2_STD_NTSC (the last case generally falls back
to NTSC/M, so people in Asia will likely have problems).

There's even a worse standard: V4L2_STD_ALL (yes, a few drivers handle it
properly, for example, tvp5150 can use it for video).

Basically, there's just one way to make users happy with things like PAL:
enable hardware auto-detection for all standards at the standard mask.
Unfortunately, this is is generally not possible, due to hardware issues.

The drivers should do things like:

if (standard == V4L2_STD_PAL_I) {
	/* Select PAL/I standard */
} else if (standard == V4L2_STD_PAL_N) {
	/* Select PAL/N standard */
} else if ((standard & V4L2_STD_MN) == V4L2_STD_MN) {
	/* enable STD M/N autodetection */
} else if ((standard & V4L2_STD_PAL && !(standard & ~V4L2_STD_PAL)) {
	/* enable PAL autodetection for B/G/D/K/H/I */
...
} else {
	/* enable autodetection for all supported standards */
}

Testing first for restrict standards, then for more generic ones, adding
autodetection code for them.

> 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) |
> 			(standard & V4L2_STD_SECAM)) {
>  ...
> } else {
>   /* default PAL BG */
>   ...
> }

This doesn't soung wrong to me.

> As a result, if you have a PAL-B/G signal and select "PAL" in tvtime,
> the test passes for PAL_I/PAL_D/SECAM since that matches the bitmask.
> The result of course is garbage video.

Garbage on some Countries, good video and audio on others. People where
PAL/D or PAL/I is the standard will be happy with this.

> So here is the question:
> 
> How are we expected to interpret an application asking for "PAL" in
> cases when the driver needs a more specific video standard?
> 
> I can obviously add code to tvtime in the long term to have the user
> provide a more specific standard instead of "PAL", but since it is
> supported in the V4L2 spec, I would like to understand what the
> expected behavior should be in drivers.

Basically, tvtime does the wrong thing with respect to video standards.

The simplest fix is to enumerate the supported standards and to display
them to the userspace, letting userspace to select a standard, allowing
them to tell the driver what standard is needed, and not requiring a restart
if the user changes the video standard, especially if the number of
lines doesn't change.

Another way would be to ask user where he lives and then tell the kernel
driver to use the standards available on that Country only. This won't work
100%, as the user may want to force to a specific standard anyway (for
example, here, most STB's output signals in NTSC/M, but the broadcast and
official standard is PAL/M). People with equipments like VCR/game consoles
and other random stuff may also need to force it to PAL/60, NTSC/443, etc
for the composite/svideo ports.

What most drivers do is to first select the more specific standards,
assuming that, if userspace is requesting a specific standard, this 
should take precedence over the generic ones. If everything fails, go
to the default PAL standards.

Cheers,
Mauro

Re: Question on V4L2 S_STD call

[Devin Heitmueller]

On Wed, Feb 23, 2011 at 5:29 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> 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, and
> a hack, at bttv, for 4 more standards).
>
> In a matter of fact, V4L2_STD_PAL is not a meaningful parameter, as
> it doesn't cover all PAL standards, and if user selects it, an unpredictable
> result may happen, as almost no driver is capable of auto-detecting all
> variants of the PAL standards. The same issue also happens, on some extend,
> with V4L2_STD_SECAM and V4L2_STD_NTSC (the last case generally falls back
> to NTSC/M, so people in Asia will likely have problems).
>
> There's even a worse standard: V4L2_STD_ALL (yes, a few drivers handle it
> properly, for example, tvp5150 can use it for video).
>
> Basically, there's just one way to make users happy with things like PAL:
> enable hardware auto-detection for all standards at the standard mask.
> Unfortunately, this is is generally not possible, due to hardware issues.
>
> The drivers should do things like:
>
> if (standard == V4L2_STD_PAL_I) {
>        /* Select PAL/I standard */
> } else if (standard == V4L2_STD_PAL_N) {
>        /* Select PAL/N standard */
> } else if ((standard & V4L2_STD_MN) == V4L2_STD_MN) {
>        /* enable STD M/N autodetection */
> } else if ((standard & V4L2_STD_PAL && !(standard & ~V4L2_STD_PAL)) {
>        /* enable PAL autodetection for B/G/D/K/H/I */
> ...
> } else {
>        /* enable autodetection for all supported standards */
> }
>
> Testing first for restrict standards, then for more generic ones, adding
> autodetection code for them.
>
>> 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) |
>>                       (standard & V4L2_STD_SECAM)) {
>>  ...
>> } else {
>>   /* default PAL BG */
>>   ...
>> }
>
> This doesn't soung wrong to me.

If it were doing "standard == V4L2_STD_PAL_D" instead of "standard &
V4L2_STD_PAL_D", then it would be behaving as you described.  But it's
just checking to see if it's in the mask at all, which means if you
pass "PAL", then you always get the second block.

>> As a result, if you have a PAL-B/G signal and select "PAL" in tvtime,
>> the test passes for PAL_I/PAL_D/SECAM since that matches the bitmask.
>> The result of course is garbage video.
>
> Garbage on some Countries, good video and audio on others. People where
> PAL/D or PAL/I is the standard will be happy with this.

Correct.  I should have been more clear as that is exactly what I meant.

>> So here is the question:
>>
>> How are we expected to interpret an application asking for "PAL" in
>> cases when the driver needs a more specific video standard?
>>
>> I can obviously add code to tvtime in the long term to have the user
>> provide a more specific standard instead of "PAL", but since it is
>> supported in the V4L2 spec, I would like to understand what the
>> expected behavior should be in drivers.
>
> Basically, tvtime does the wrong thing with respect to video standards.
>
> The simplest fix is to enumerate the supported standards and to display
> them to the userspace, letting userspace to select a standard, allowing
> them to tell the driver what standard is needed, and not requiring a restart
> if the user changes the video standard, especially if the number of
> lines doesn't change.
>
> Another way would be to ask user where he lives and then tell the kernel
> driver to use the standards available on that Country only. This won't work
> 100%, as the user may want to force to a specific standard anyway (for
> example, here, most STB's output signals in NTSC/M, but the broadcast and
> official standard is PAL/M). People with equipments like VCR/game consoles
> and other random stuff may also need to force it to PAL/60, NTSC/443, etc
> for the composite/svideo ports.
>
> What most drivers do is to first select the more specific standards,
> assuming that, if userspace is requesting a specific standard, this
> should take precedence over the generic ones. If everything fails, go
> to the default PAL standards.

Yeah, I was trying to provide as seamless an experience for users of
existing applications that have been around forever, such as tvtime.
While I admit that tvtime could definitely stand to improve in
providing more flexibility to users, I was just trying to understand
how applications such as this have managed to work the way it has for
years without more people complaining.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Question on V4L2 S_STD call

[Mauro Carvalho Chehab]

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) |
>>>                       (standard & V4L2_STD_SECAM)) {
>>>  ...
>>> } else {
>>>   /* default PAL BG */
>>>   ...
>>> }
>>
>> This doesn't soung wrong to me.
> 
> If it were doing "standard == V4L2_STD_PAL_D" instead of "standard &
> V4L2_STD_PAL_D", then it would be behaving as you described.  But it's
> just checking to see if it's in the mask at all, which means if you
> pass "PAL", then you always get the second block.

PAL/D is one of the standards where "normal" PAL fits. I think that the
"old" drivers are all capable of auto-detecting between PAL/BGDK.

Assuming that the behaviour for PAL/D would be changed like you said (e. g.
choosing to support only PAL/BG if STD_PAL is selected), tvtime won't work 
with PAL/D, as it doesn't allow selecting PAL/D. 

Btw, PAL/K works properly, if set as PAL/BG on that part of the code? It
seems to be broken on other parts of the driver, like, for example, on
cx231xx_Get_Colibri_CarrierOffset(). I remember I had to make a fix there
for PAL/M and PAL/N to work at changeset 0f86158375308804f86d36c7d45aaff1d7dc0d96.

I suspect that some other fixes are needed anyway at the driver, as it seems
that there are some bad stuff for some video standards.

>> Basically, tvtime does the wrong thing with respect to video standards.
>>
>> The simplest fix is to enumerate the supported standards and to display
>> them to the userspace, letting userspace to select a standard, allowing
>> them to tell the driver what standard is needed, and not requiring a restart
>> if the user changes the video standard, especially if the number of
>> lines doesn't change.
>>
>> Another way would be to ask user where he lives and then tell the kernel
>> driver to use the standards available on that Country only. This won't work
>> 100%, as the user may want to force to a specific standard anyway (for
>> example, here, most STB's output signals in NTSC/M, but the broadcast and
>> official standard is PAL/M). People with equipments like VCR/game consoles
>> and other random stuff may also need to force it to PAL/60, NTSC/443, etc
>> for the composite/svideo ports.
>>
>> What most drivers do is to first select the more specific standards,
>> assuming that, if userspace is requesting a specific standard, this
>> should take precedence over the generic ones. If everything fails, go
>> to the default PAL standards.
> 
> Yeah, I was trying to provide as seamless an experience for users of
> existing applications that have been around forever, such as tvtime.
> While I admit that tvtime could definitely stand to improve in
> providing more flexibility to users, I was just trying to understand
> how applications such as this have managed to work the way it has for
> years without more people complaining.

Some drivers like tuner-core have "hack" parameters just because of tvtime
(and other applications?) that doesn't/don't allow properly selecting the 
video standard. The only real fix that will work is to change userspace
apps that don't do the right thing.

Cheers,
Mauro.