On Thu, 1 Sep 2011, Laurent Pinchart wrote:
> Hi Guennadi,
>
> On Thursday 01 September 2011 09:03:52 Guennadi Liakhovetski wrote:
> > On Thu, 1 Sep 2011, Sakari Ailus wrote:
> > > On Wed, Aug 31, 2011 at 08:02:41PM +0200, Guennadi Liakhovetski wrote:
>
> [snip]
>
> > > > +
> > > >
> > > > /*
> > > >
> > > > * I O C T L C O D E S F O R V I D E O D E V I C E S
> > > > *
> > > >
> > > > @@ -2182,6 +2194,9 @@ struct v4l2_dbg_chip_ident {
> > > >
> > > > #define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
> > > > v4l2_event_subscription) #define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V',
> > > > 91, struct v4l2_event_subscription)
> > > >
> > > > +#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct v4l2_create_buffers)
> > > > +#define VIDIOC_PREPARE_BUF _IOW('V', 93, struct v4l2_buffer)
> > >
> > > Does prepare_buf ever do anything that would need to return anything to
> > > the user? I guess the answer is "no"?
> >
> > Exactly, that's why it's an "_IOW" ioctl(), not an "_IOWR", or have I
> > misunderstood you?
>
> This caught my eyes as well. Do you think VIDIOC_PREPARE_BUF could need to
> return information to userspace in the future ?
Let's see: "[PATCH 2/9 v6]," it has been an "_IOW" since v1, posted on
01.04 - exactly 5 months ago, when it was still called SUBMIT_BUF. So,
IIRC, since then noone has come up with even a doubt, that this might need
to change in the future (until today), let alone an example, what might
need to be given back.
But sure, I cannot look into the future, so, I'm all ears.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
