From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Sakari Ailus <sakari.ailus@iki.fi>,
linux-media@vger.kernel.org, k.debski@samsung.com
Subject: Re: [PATCH v4.1 3/3] v4l: Add V4L2_BUF_FLAG_TIMESTAMP_SOF and use it
Date: Sun, 02 Feb 2014 10:27:49 +0100 [thread overview]
Message-ID: <1393149.6OyBNhdFTt@avalon> (raw)
In-Reply-To: <52EBDB8B.80202@xs4all.nl>
Hi Hans,
On Friday 31 January 2014 18:21:15 Hans Verkuil wrote:
> On 01/31/2014 05:42 PM, Sakari Ailus wrote:
> > On Fri, Jan 31, 2014 at 04:45:56PM +0100, Hans Verkuil wrote:
> >>
> >> How about defining a capability for use with ENUMINPUT/OUTPUT? I agree
> >> that this won't change between buffers, but it is a property of a
> >> specific input or output.
> >
> > Over 80 characters per line. :-P
>
> Stupid thunderbird doesn't show the column, and I can't enable
> automatic word-wrap because that plays hell with patches. Solutions
> welcome!
>
> >> There are more than enough bits available in v4l2_input/output to add one
> >> for SOF timestamps.
> >
> > In complex devices with a non-linear media graph inputs and outputs are
> > not very relevant, and for that reason many drivers do not even implement
> > them. I'd rather not bind video buffer queues to inputs or outputs.
>
> Then we end up again with buffer flags. It's a property of the selected
> input or output, so if you can't/don't want to use that, then it's buffer
> flags.
>
> Which I like as well, but it's probably useful that the documentation states
> that it can only change if the input or output changes as well.
>
> > My personal favourite is still to use controls for the purpose but the
> > buffer flags come close, too, especially now that we're using them for
> > timestamp sources.
>
> Laurent, can we please end this discussion? It makes perfect sense to store
> this information as a BUF_FLAG IMHO. You can just do a QUERYBUF once after
> you called REQBUFS and you know what you have to deal with.
I'm OK with a buffer flag. Can we state in the documentation that the same
timestamp flag will be used for all buffers and that QUERYBUF can be used to
query it before the first buffer gets dequeued ?
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2014-02-02 9:26 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-25 23:02 [PATCH v4 0/3] Fix buffer timestamp documentation Sakari Ailus
2013-08-25 23:02 ` [PATCH v4 1/3] v4l: Document timestamp behaviour to correspond to reality Sakari Ailus
2013-08-28 12:13 ` Hans Verkuil
2013-08-28 15:04 ` Sakari Ailus
2013-08-28 15:23 ` [PATCH v4.1 " Sakari Ailus
2013-08-28 15:19 ` Hans Verkuil
2013-08-25 23:02 ` [PATCH v4 2/3] v4l: Use full 32 bits for buffer flags Sakari Ailus
2013-08-25 23:02 ` [PATCH v4 3/3] v4l: Add V4L2_BUF_FLAG_TIMESTAMP_SOF and use it Sakari Ailus
2013-08-28 12:19 ` Hans Verkuil
2013-08-28 15:24 ` [PATCH v4.1 " Sakari Ailus
2013-08-28 15:30 ` Hans Verkuil
2013-08-28 16:06 ` Sakari Ailus
2013-08-28 16:03 ` Laurent Pinchart
2013-08-28 16:09 ` Sakari Ailus
2013-08-28 16:14 ` Laurent Pinchart
2013-08-28 16:39 ` Sakari Ailus
2013-08-28 23:25 ` Laurent Pinchart
2013-08-29 11:33 ` Sakari Ailus
2013-08-30 11:31 ` Laurent Pinchart
2013-08-30 16:08 ` Sakari Ailus
2013-08-31 21:43 ` Laurent Pinchart
2013-09-05 16:31 ` Sakari Ailus
2013-09-06 11:05 ` Laurent Pinchart
2013-12-12 12:37 ` Hans Verkuil
2014-01-31 15:39 ` Laurent Pinchart
2014-01-31 15:45 ` Hans Verkuil
2014-01-31 16:42 ` Sakari Ailus
2014-01-31 17:21 ` Hans Verkuil
2014-02-01 9:06 ` Sakari Ailus
2014-02-02 9:27 ` Laurent Pinchart [this message]
2014-02-05 8:13 ` Sakari Ailus
2014-02-07 22:52 ` [PATCH v4.2 3/4] v4l: Add timestamp source flags, mask and document them Sakari Ailus
2014-02-07 22:52 ` [PATCH v4.2 4/4] v4l: Document timestamp buffer flag behaviour Sakari Ailus
2014-02-08 12:32 ` Hans Verkuil
2014-02-08 17:30 ` Sakari Ailus
2014-02-10 9:49 ` [PATCH v4.2 3/4] v4l: Add timestamp source flags, mask and document them Hans Verkuil
2014-02-10 10:24 ` Sakari Ailus
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=1393149.6OyBNhdFTt@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=hverkuil@xs4all.nl \
--cc=k.debski@samsung.com \
--cc=linux-media@vger.kernel.org \
--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