> Hi Hans,
>
> On Monday 18 January 2010 14:07:33 Hans Verkuil wrote:
>> On Tue, 22 Dec 2009, Sakari Ailus wrote:
>> > Hi,
>> >
>> > Here's the second version of the V4L2 file handle and event interface
>> > patchset. Still RFC since I'd like to get more feedback on it.
>> >
>> > The first patch adds the V4L2 file handle support and the rest are for
>> > V4L2 events.
>> >
>> > The patchset works with the OMAP 3 ISP driver. Patches for OMAP 3 ISP
>> are
>> > not part of this patchset but are available in Gitorious (branch is
>> > called events):
>> >
>> > git://gitorious.org/omap3camera/mainline.git event
>> >
>> > The major change since the last one v4l2_fh structure is now part of
>> > driver's own file handle. It's used as file->private_data as well. I
>> did
>> > this based on Hans Verkuil's suggestion. Sequence numbers and event
>> queue
>> > length limitation is there as well. There are countless of smaller
>> > changes, too.
>> >
>> > A few notes on the patches:
>> >
>> > - I don't like the locking too much. Perhaps the file handle specific
>> > lock (events->lock) could be dropped in favour of the lock for
>> > v4l2_file_handle in video_device?
>> >
>> > - Poll. The V4L2 specifiction says:
>> >
>> > "When the application did not call VIDIOC_QBUF or
>> > VIDIOC_STREAMON yet the poll() function succeeds, but sets the
>> > POLLERR flag in the revents field."
>> >
>> > The current events for OMAP 3 ISP are related to streaming but not
>> all
>> > might be in future. For example there might be some radio or DVB
>> related
>> > events.
>>
>> I know for sure that we will have to be able to handle events when not
>> streaming. E.g. events that tell when a HDMI connector was plugged in
>> or when the EDID was read will need to arrive whether streaming is on
>> or off.
>
> I agree with you. The V4L2 specification will then need to be changed,
> otherwise we won't be able to poll() for events. poll() wouldn't return
> immediately anymore if no buffer is queued or if the device isn't
> streaming.
> That might break existing applications (although we could argue that some
> of
> those applications are somehow broken already if they rely on such a weird
> feature).
>
> If we want to avoid disturbing existing applications we could still return
> POLLERR immediately when not streaming if no event has been subscribed to.
I think this is a very reasonable approach.
Regards,
Hans
>
>> > - Sequence numbers are local to file handles.
>>
>> That is how it should be.
>>
>> > - Subscribing V4L2_EVENT_ALL causes any other events to be
>> unsubscribed.
>> >
>> > - If V4L2_EVENT_ALL has been subscribed, unsubscribing any one of the
>> > events leads to V4L2_EVENT_ALL to be unsubscribed. This problem would
>> be
>> > difficult to work around since this would require the event system to
>> be
>> > aware of the driver private events as well.
>>
>> Good point. Perhaps attempting to unsubscribe a single event when
>> EVENT_ALL
>> has been subscribed should result in an error? I.e., you can only
>> unsubscribe ALL when you subscribed to ALL in the first place.
>
> --
> Regards,
>
> Laurent Pinchart
>
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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
