linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: Some comments on the new autocluster patches
Date: Sat, 02 Jul 2011 16:31:47 +0200	[thread overview]
Message-ID: <4E0F2BD3.3050803@redhat.com> (raw)
In-Reply-To: <201107021310.25562.hverkuil@xs4all.nl>

Hi,

On 07/02/2011 01:10 PM, Hans Verkuil wrote:
> On Saturday, July 02, 2011 12:28:35 Hans de Goede wrote:
>> Hi,
>>
>> <snip snip snip>
>>
>> Ok, thinking about this some more and reading Hans V's comments
>> I think that the current code in Hans V's core8c branch is fine,
>> and should go to 3.1 (rather then be delayed to 3.2).
>>
>> As for the fundamental question what to do with foo
>> controls when autofoo goes from auto to manual, as discussed
>> there are 2 options:
>> 1) Restore the last known / previous manual setting
>> 2) Keep foo at the current setting, iow the last setting
>>      configured by autofoo
>
> Or option 3:
>
> Just don't report the automatic foo values at all. What possible purpose
> does it serve?
Reporting should be seen separate of what to do with the actual
setting of for example gain as in use by the device when autogain
gets turned off, that is what I'm talking about here, when autogain
gets turned off (iow gain gets set to manual) there are 2 and only
2 options

1) leave the gain at the value last set by the devices
    autogain function (this may not be supported on all hardware)
2) restore the last known manual gain setting

What we report or not report for gain while autogain is active
is irrelevant for this choice, when switching to manual we can
either leave gain as is, or we restore the last known setting.
Independent of any values we may have reported.

 > It is my impression that drivers implement it 'just because
 > they can', and not because it is meaningful.

Well it is drivers responsibility to export hardware functionality
(in a standardized manner), then it is up to applications whether
they use it or not. And it is actually quite meaning full, you
are very much thinking TV and not webcams here, being able to
see that the autofoo is actually doing something, and what
it is doing is very useful for webcams. For example maybe it is
choosing a low exposure (to get highframerate) high gain, which
leads to more noise in the picture then the user wants

webcams are like photography, you've a shutter and a sensitivity
(iso) setting being able to see what a camera chooses in full
auto mode is quite useful.

> I'm not aware of any application that actually refreshes e.g. gain values
> when autogain is on, so end-users never see it anyway.

v4l2ucp has an option to update the ctrl readings every 1 / 2 / 5
seconds. And I use this often to track what the autofoo is doing
and / or to verify that it doing anything at all.

> But I think we should stop supporting volatile writable controls.

NACK, and note that we already don't do that, what we do is switch
a control from volatile read only (inactive) to non volatile rw-mode
and back. The only question is what to do at the transition.

Regards,

Hans

  reply	other threads:[~2011-07-02 14:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-01 15:06 Some comments on the new autocluster patches Hans de Goede
2011-07-01 16:21 ` Hans Verkuil
2011-07-02 10:28   ` Hans de Goede
2011-07-02 11:10     ` Hans Verkuil
2011-07-02 14:31       ` Hans de Goede [this message]
2011-07-04  9:43         ` Hans Verkuil
2011-07-12 13:25           ` Hans de Goede
2011-07-26  9:26             ` Hans Verkuil
2011-07-26 13:51               ` Hans de Goede
2011-07-26 14:19                 ` Hans Verkuil
2011-07-26 14:38                   ` Hans de Goede
2011-07-26 14:39                     ` Hans Verkuil
2011-07-02  0:55 ` Mauro Carvalho Chehab
2011-07-02  9:36   ` Hans Verkuil
2011-07-02 18:33     ` 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=4E0F2BD3.3050803@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --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;
as well as URLs for NNTP newsgroup(s).