On Friday 16 October 2009 14:34:28 Sakari Ailus wrote:
> Laurent Pinchart wrote:
> > On Friday 16 October 2009 09:36:51 Sakari Ailus wrote:
> >> Hans Verkuil wrote:
> >>> On Thursday 15 October 2009 23:11:33 Laurent Pinchart wrote:
> >>>> For efficiency reasons a V4L2_G_EVENTS ioctl could also be provided to
> >>>> retrieve multiple events.
> >>>>
> >>>> struct v4l2_events {
> >>>> __u32 count;
> >>>> struct v4l2_event __user *events;
> >>>> };
> >>>>
> >>>> #define VIDIOC_G_EVENTS _IOW('V', xx, struct v4l2_events)
> >>>
> >>> Hmm. Premature optimization. Perhaps as a future extension.
> >>
> >> That *could* save one ioctl sometimes --- then you'd no there are no
> >> more events coming right now. But just one should be supported IMO,
> >> VIDIOC_G_EVENT or VIDIOC_G_EVENTS.
> >
> > I forgot to mention in my last mail that we should add a flag to the
> > v4l2_event structure to report if more events are pending (or even
> > possible a pending event count).
>
> Then the V4L (or driver) would have to check the queue for that type of
> events. OTOH, the queue size could be quite small and it'd never
> overflow since the maximum size is number of different event types.
>
> Can there be situations when the first or last event timestamp of
> certain event would be necessary? If we put count there, then we need to
> make a decision which one is useful for the userspace. The last one is
> obviously useful for the AF/AEWB algorightms. I currently see no use for
> the first one, but that doesn't mean there couldn't be use for it.
That's not what I meant. The idea of a count field is to report the number of
events still pending after that one, type aside. If v4l2_event::count equals 0
the userspace application will know there is no need to call VIDIOC_G_EVENT
just to get a -EAGAIN.
--
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
