Linux Media Controller development
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@iki.fi>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-media@vger.kernel.org, tuukkat76@gmail.com,
	dacohen@gmail.com, g.liakhovetski@gmx.de, hverkuil@xs4all.nl,
	snjw23@gmail.com
Subject: Re: [ANN] Notes on IRC meeting on new sensor control interface, 2012-01-09 14:00 GMT+2
Date: Tue, 10 Jan 2012 01:26:46 +0200	[thread overview]
Message-ID: <4F0B77B6.2000304@iki.fi> (raw)
In-Reply-To: <201201092337.51849.laurent.pinchart@ideasonboard.com>

Hi Laurent,

Laurent Pinchart wrote:
> On Monday 09 January 2012 23:32:06 Sakari Ailus wrote:
>> Laurent Pinchart wrote:
>>> On Monday 09 January 2012 18:38:25 Sakari Ailus wrote:
...
>>>> A fourth section may be required as well: at this level the frame rate
>>>> (or frame time) range makes more sense than the low-level blanking
>>>> values. The blanking values can be calculated from the frame time and a
>>>> flag which tells whether either horizontal or vertical blanking should
>>>> be preferred.
>>>
>>> How does one typically select between horizontal and vertical blanking ?
>>> Do mixed modes make sense ?
>>
>> There are minimums and maximums for both. You can increase the frame
>> time by increasing value for either or both of them --- to achieve very
>> long frame times you may have to use both, but that's not very common in
>> practice. I think we should have a flag to tell which one should be
>> increased first --- the effect would be to have the minimum possible
>> value on the other.
>
> But how do you decide in practice which one to increase when you're an
> application (or middleware) developer ?

I think it's the responsibility of this library to do that, unless the 
user wants really, really precise control in which case they have to 
deal with the blanking values directly. In general it should be the library.

-- 
Sakari Ailus
sakari.ailus@iki.fi

  reply	other threads:[~2012-01-09 23:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-04  8:56 [ANN] IRC meeting on new sensor control interface, 2012-01-09 14:00 GMT+2 Sakari Ailus
2012-01-09 10:48 ` Sakari Ailus
2012-01-09 17:38 ` [ANN] Notes on " Sakari Ailus
2012-01-09 21:38   ` Laurent Pinchart
2012-01-09 22:32     ` Sakari Ailus
2012-01-09 22:37       ` Laurent Pinchart
2012-01-09 23:26         ` Sakari Ailus [this message]
2012-01-10  0:13           ` Laurent Pinchart
2012-01-10  9:42             ` Sakari Ailus
2012-01-10  9:50               ` Laurent Pinchart
2012-01-10  9:52                 ` Sakari Ailus
2012-01-10 10:05                   ` Laurent Pinchart
2012-01-10 10:57                     ` Sakari Ailus
2012-01-10 11:39                     ` Tuukka Toivonen

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=4F0B77B6.2000304@iki.fi \
    --to=sakari.ailus@iki.fi \
    --cc=dacohen@gmail.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=snjw23@gmail.com \
    --cc=tuukkat76@gmail.com \
    /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