linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Prabhakar Lad <prabhakar.csengg@gmail.com>,
	Manjunath Hadli <manjunath.hadli@ti.com>,
	dlos <davinci-linux-open-source@linux.davincidsp.com>,
	linux-doc@vger.kernel.org,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	Rob Landley <rob@landley.net>, LMML <linux-media@vger.kernel.org>,
	hverkuil@xs4all.nl
Subject: Re: [PATCH] [media] davinci: vpfe: Add documentation
Date: Sat, 01 Sep 2012 16:22:30 +0200	[thread overview]
Message-ID: <8524664.XGp3WDre5y@avalon> (raw)
In-Reply-To: <20120901095707.GB6348@valkosipuli.retiisi.org.uk>

Hi Sakari,

On Saturday 01 September 2012 12:57:07 Sakari Ailus wrote:
> On Wed, Aug 29, 2012 at 08:11:50PM +0530, Prabhakar Lad wrote:

[snip]

> > For test pattern you meant control to enable/disable it ?
> 
> There are two approaches I can think of.
> 
> One is a menu control which can be used to choose the test pattern (or
> disable it). The control could be standardised but the menu items would have
> to be hardware-specific since the test patterns themselves are not
> standardised.

Agreed. The test patterns themselves are highly hardware-specific.

>From personal experience with sensors, most devices implement a small, fixed 
set of test patterns that can be exposed through a menu control. However, some 
devices also implement more "configurable" test patterns. For instance the 
MT9V032 can generate horizontal, vertical or diagonal test patterns, or a 
uniform grey test pattern with a user-configurable value. This would then 
require two controls.

> The alternative is to have a boolean control to enable (and disable) the
> test pattern and then a menu control to choose which one to use. Using or
> implemeting the control to select the test pattern isn't even strictly
> necessary to get a test pattern out of the device: one can enable it without
> knowing which one it is.
> 
> So which one would be better? Similar cases include V4L2_CID_SCENE_MODE
> which is used to choose the scene mode from a list of alternatives. The main
> difference to this case is that the menu items of the scene mode control
> are standardised, too.
> 
> I'd be inclined to have a single menu control, even if the other menu items
> will be device-specific. The first value (0) still has to be documented to
> mean the test pattern is disabled.
> 
> Laurent, Hans: what do you think?

A menu control with value 0 meaning test pattern disabled has my preference as 
well.

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2012-09-01 14:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1342021166-6092-1-git-send-email-manjunath.hadli@ti.com>
2012-07-15 12:46 ` [PATCH] [media] davinci: vpfe: Add documentation Laurent Pinchart
2012-07-17 10:43   ` Hadli, Manjunath
2012-07-26  0:12     ` Laurent Pinchart
2012-07-26  0:13       ` Laurent Pinchart
2012-07-26  0:25     ` Laurent Pinchart
2012-07-27  5:49       ` Hadli, Manjunath
2012-07-27 10:49         ` Laurent Pinchart
2012-07-31  7:45           ` Manju
2012-08-02 21:25             ` Laurent Pinchart
2012-08-02  0:07 ` Sakari Ailus
2012-08-09  3:43   ` Manjunath Hadli
2012-08-16 16:23     ` Sakari Ailus
2012-08-22  8:56       ` Manjunath Hadli
2012-09-01 17:25         ` Sakari Ailus
2012-09-01 17:26           ` Sakari Ailus
2012-09-04  6:14           ` Manjunath Hadli
2012-08-29 14:41       ` Prabhakar Lad
2012-09-01  9:57         ` Sakari Ailus
2012-09-01 14:22           ` Laurent Pinchart [this message]
2012-09-01 14:53             ` Prabhakar Lad
2012-09-01 16:11               ` Sakari Ailus
2012-09-02  3:03                 ` Laurent Pinchart
2012-09-02  8:44             ` Hans Verkuil
2012-08-16 13:10 ` Rob Landley
2012-08-16 13:24   ` Prabhakar Lad

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=8524664.XGp3WDre5y@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=davinci-linux-open-source@linux.davincidsp.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=manjunath.hadli@ti.com \
    --cc=mchehab@infradead.org \
    --cc=prabhakar.csengg@gmail.com \
    --cc=rob@landley.net \
    --cc=sakari.ailus@iki.fi \
    /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).