From: Hans Verkuil <hverkuil@xs4all.nl>
To: Mikhail Domrachev <mihail.domrychev@comexp.ru>
Cc: "Devin Heitmueller" <dheitmueller@kernellabs.com>,
"Linux Media Mailing List" <linux-media@vger.kernel.org>,
"Алексей Игонин" <aleksey.igonin@comexp.ru>
Subject: Re: [PATCH] saa7134: automatic norm detection
Date: Mon, 31 Mar 2014 13:28:04 +0200 [thread overview]
Message-ID: <53395144.2050100@xs4all.nl> (raw)
In-Reply-To: <CAGoCfiwN6Z9Whof-ZfWPxPfu+HztHTQewkXLicJkT7si_Jg9uw@mail.gmail.com>
Hi Mikhail,
On 03/28/2014 02:16 PM, Devin Heitmueller wrote:
>>> Let me explain why I created a new thread.
>>> My company is engaged in the monitoring of TV air. All TV channels are
>>> recorded 24/7 for further analysis. But some local TV channels change
>>> the standard over time (SECAM->PAL, PAL->SECAM). So the recording
>>> software must be notified about these changes to set a new standard and
>>> record the picture but not the noise.
>>
>> OK, fair enough.
>
> This is a perfectly reasonable use case, but since we don't do this
> with any other devices we probably need to decide whether this really
> should be the responsibility of the kernel at all, or whether it
> really should be done in userland. Doing it in userland would be
> trivial (even just a script which periodically runs QUERYSTD in a loop
> would accomplish the same thing), and the extra complexity of having a
> thread combined with the inconsistent behavior with all the other
> drivers might make it more worthwhile to do it in userland.
>
> If it were hooked to an interrupt line on the video decoder, I could
> certainly see doing it in kernel, but for something like this the loop
> that checks the standard could just as easily be done in userland.
I agree with Devin here. None of the existing SDTV receivers do this, and
nobody ever used interrupts to check for this. Such interrupts are rarely
available, and if they exists they are never hooked up. This is quite
different for HDTV receivers where such an event is pretty much required
(even though it still isn't officially added to the kernel, but that's
another story).
Is there any reason why your application cannot periodically call QUERYSTD?
The problem you have is not specific to the saa7134, so moving it to the
application is actually a more generic solution since it will work with
any driver that implements querystd.
Adding querystd support to saa7134 in the first place is a good idea
regardless, and I'll test your patch today or Friday.
Regards,
Hans
next prev parent reply other threads:[~2014-03-31 11:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-24 11:42 [PATCH] saa7134: automatic norm detection Mikhail Domrachev
2014-03-25 12:23 ` Mikhail Domrachev
2014-03-28 8:37 ` Hans Verkuil
2014-03-28 9:51 ` Mikhail Domrachev
2014-03-28 10:04 ` Hans Verkuil
2014-03-28 13:16 ` Devin Heitmueller
2014-03-31 11:28 ` Hans Verkuil [this message]
2014-03-31 12:29 ` Mikhail Domrachev
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=53395144.2050100@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=aleksey.igonin@comexp.ru \
--cc=dheitmueller@kernellabs.com \
--cc=linux-media@vger.kernel.org \
--cc=mihail.domrychev@comexp.ru \
/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;
as well as URLs for NNTP newsgroup(s).