From: Andy Walls <awalls@md.metrocast.net>
To: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: Question on V4L2 S_STD call
Date: Wed, 23 Feb 2011 16:53:41 -0500 [thread overview]
Message-ID: <1298498021.2408.14.camel@localhost> (raw)
In-Reply-To: <AANLkTikqDACH2rVd6PBVr3eofnJP-UmD0bNDar9RDUoL@mail.gmail.com>
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
next prev parent reply other threads:[~2011-02-23 21:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-23 21:09 Question on V4L2 S_STD call Devin Heitmueller
2011-02-23 21:53 ` Andy Walls [this message]
2011-02-23 22:07 ` Devin Heitmueller
2011-02-23 22:29 ` Mauro Carvalho Chehab
2011-02-23 22:56 ` Devin Heitmueller
2011-02-23 23:52 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1298498021.2408.14.camel@localhost \
--to=awalls@md.metrocast.net \
--cc=dheitmueller@kernellabs.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox