All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
Cc: linux-media@vger.kernel.org, Sakari Ailus <sakari.ailus@iki.fi>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	remi@remlab.net
Subject: Re: [RFC] Timestamps and V4L2
Date: Tue, 25 Sep 2012 02:35:47 +0200	[thread overview]
Message-ID: <32114057.tIVjSTYujk@avalon> (raw)
In-Reply-To: <505F57A4.3040409@gmail.com>

Hi Sylwester,

On Sunday 23 September 2012 20:40:36 Sylwester Nawrocki wrote:
> On 09/22/2012 10:28 PM, Daniel Glöckner wrote:
> > On Sat, Sep 22, 2012 at 07:12:52PM +0200, Sylwester Nawrocki wrote:
> >> If we ever need the clock selection API I would vote for an IOCTL.
> >> The controls API is a bad choice for something such fundamental as
> >> type of clock for buffer timestamping IMHO. Let's stop making the
> >> controls API a dumping ground for almost everything in V4L2! ;)
> >> 
> >> Perhaps VIDIOC_QUERYBUF and VIDIOC_DQBUF should be reporting
> >> timestamps type only for the time they are being called. Not per buffer,
> >> per device. And applications would be checking the flags any time they
> >> want to find out what is the buffer timestamp type. Or every time if it
> >> don't have full control over the device (S/G_PRIORITY).
> > 
> > I'm all for adding an IOCTL, but if we think about adding a
> > VIDIOC_S_TIMESTAMP_TYPE in the future, we might as well add a
> > VIDIOC_G_TIMESTAMP_TYPE right now. Old drivers will return ENOSYS,
> > so the application knows it will have to guess the type (or take own
> > timestamps).
> 
> Hmm, would it make sense to design a single ioctl that would allow
> getting and setting the clock type, e.g. VIDIOC_CLOCK/TIMESTAMP_TYPE ?
> 
> > I can't imagine anything useful coming from an app that has to process
> > timestamps that change their source every now and then and I seriously
> > doubt anyone will go to such an extent that they check the timestamp
> > type on every buffer. If they don't set their priority high enough to
> > prevent others from changing the timestamp type, they also run the
> > risk of someone else changing the image format. It should be enough to
> > forbid changing the timestamp type while I/O is in progress, as it is
> > done for VIDIOC_S_FMT.
> 
> I agree, but mem-to-mem devices can have multiple logically independent,
> "concurrent" streams active. If the clock type is per device it might
> not be that straightforward...

Does the clock type need to be selectable for mem-to-mem devices ? Do device-
specific timestamps make sense there ?

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2012-09-25  0:35 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-20 20:21 [RFC] Timestamps and V4L2 Sakari Ailus
2012-09-20 21:08 ` Rémi Denis-Courmont
2012-09-21  8:47 ` Christian Gmeiner
2012-09-21  9:33 ` Hans Verkuil
2012-09-22 12:38   ` Sakari Ailus
2012-09-22 17:12     ` Sylwester Nawrocki
2012-09-22 20:28       ` Daniel Glöckner
2012-09-23 18:40         ` Sylwester Nawrocki
2012-09-25  0:35           ` Laurent Pinchart [this message]
     [not found]             ` <5061DAE3.2080808@samsung.com>
2012-09-25 17:17               ` Kamil Debski
2012-09-26 22:30             ` Sylwester Nawrocki
2012-09-27 10:41               ` Laurent Pinchart
2012-09-23 11:43       ` Sakari Ailus
2012-09-24 20:11         ` Rémi Denis-Courmont
2012-09-25  6:50           ` Hans Verkuil
2012-09-25  0:34       ` Laurent Pinchart
2012-09-25 22:48         ` Sylwester Nawrocki
2012-09-23  9:18     ` Hans Verkuil
2012-09-23 13:07       ` Sakari Ailus
2012-09-24  8:30         ` Hans Verkuil
2012-09-25  0:21       ` Laurent Pinchart
2012-09-24 23:42   ` Laurent Pinchart
2012-09-25  0:00   ` Laurent Pinchart
2012-09-25  6:47     ` Hans Verkuil
2012-09-25 10:48       ` Laurent Pinchart
2012-09-25 10:54         ` Hans Verkuil
2012-09-25 11:09           ` Laurent Pinchart
2012-09-25 20:12           ` Sakari Ailus
2012-09-26  9:13             ` Laurent Pinchart
2012-09-26 19:17               ` Sakari Ailus
2012-09-27 10:55                 ` Laurent Pinchart
2012-09-25 20:05       ` Sakari Ailus
2012-10-15 16:05 ` Sakari Ailus
2012-10-15 18:45   ` Laurent Pinchart
2012-10-15 18:53     ` Chris MacGregor
2012-10-15 19:59       ` Sakari Ailus
2012-10-15 20:10         ` Rémi Denis-Courmont
2012-10-16  1:25         ` Chris MacGregor
2012-10-25  0:47           ` Laurent Pinchart
2012-10-16  6:13     ` Hans Verkuil

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=32114057.tIVjSTYujk@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=remi@remlab.net \
    --cc=sakari.ailus@iki.fi \
    --cc=sylvester.nawrocki@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.