Hans Verkuil wrote:
On Sunday 13 September 2009 08:13:04 Nathaniel Kim wrote:
2009. 9. 12., 오전 7:21, Hans Verkuil 작성:
Hans,
First of all I'm very sorry that I had not enough time to go through
your new RFC. I'll checkout right after posting this mail.
I think this is a good approach and I also had in my mind that sysfs
might be a good method if we could control and monitor through this.
Recalling memory when we had a talk in San Francisco, I was frustrated
that there is no way to catch events from sort of sub-devices like
lens actuator (I mean pizeo motors in camera module). As you know lens
actuator is an extremely slow device in comparison with common v4l2
devices we are using and we need to know whether it has succeeded or
not in moving to expected position.
So I considered sysfs and udev as candidates for catching events from
sub-devices. events like success/failure of lens movement, change of
status of subdevices.
Does anybody experiencing same issue? I think I've seen a lens
controller driver in omap3 kernel from TI but not sure how did they
control that.
My point is that we need a kind of framework to give and event to user
space and catching them properly just like udev does.
When I was talking to Laurent Pinchart and Sakari and his team at Nokia
we discussed just such a framework. It actually exists already, although
it is poorly implemented.
Look at include/linux/dvb/video.h, struct video_event and ioctl VIDEO_GET_EVENT.
It is used in ivtv (ivtv-ioctl.c, look for VIDEO_GET_EVENT).
The idea is that you can either call VIDEO_GET_EVENT to wait for an event
or use select() and wait for an exception to arrive, and then call
VIDEO_GET_EVENT to find which event it was.
This is ideal for streaming-related events. In ivtv it is used to report
VSYNCs and to report when the MPEG decoder stopped (there is a delay between
stopping sending new data to the decoder and when it actually processed all
its internal buffers).
Laurent is going to look into this to clean it up and present it as a new
proper official V4L2 event mechanism.
For events completely specific to a subdev I wonder whether it wouldn't be
a good idea to use the media controller device for that. I like the select()
mechanism since in an application you can just select() on a whole bunch of
filehandles. If you can't use select() then you are forced to do awkward coding
(e.g. make a separate thread just to handle that other event mechanism).
Agree. There's no reasonable way to use video devices here since the
events may be connected to non-video related issues --- like the statistics.
One possible approach could be allocating a device node for each subdev
and use them and leave the media controller device with just the media
controller specific ioctls. Then there would be no need to set current
subdev nor bind the subdev to file handle either.
Just an idea.
So with the media controller we can easily let sub-devices notify the media
controller when an event is ready and the media controller can then generate
an exception. An application can just select() on the mc filehandle.
There are two ways of implementing this. One is that the media controller
keeps a global queue of pending events and subdevices just queue events to
that when they arrive (with some queue size limit to prevent run-away events).
With the above arrangement, the events could be easily subdev specific.
The mechanism should be generic still, though.
So when you call some GET_EVENT type ioctl it should return the ID of the
subdevice (aka entity) as well. What makes me slightly uncomfortable is that
you still want to use that same ioctl on a normal video node. And the subdev
ID has really no meaning there. But making two different ioctls doesn't sit
well with me either.
The alternative implementation is that the mc will only wait for events from
the currently selected sub-device. So if you want to wait on events from
different sub-devices, then you have to open the mc multiple times, once for
each subdev that you want to receive events from.
I think I would probably go for the second implementation because it is
consistent with the way ioctls are passed to sub-devices. I like the idea that
you can just pass regular V4L2 ioctls to sub-devices. Not all ioctls make
sense, obviously (e.g. any of the streaming I/O ioctls), but a surprisingly
large number of ioctls can be used in that way.
I agree with this. There are just a few ioctls that probably don't make
sense (e.g. the steaming related ones).
IMO even the format setting ioctls could be nice since the possible
input and output formats of the subdevs should be enumerable, too.
ENUM_FRAMESIZES and ENUM_FRAMEINTERVALS are missing the v4l2_buf_type,
but there are reserved fields...
--
Sakari Ailus
sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx
--
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
