28 Jul, 2011
3 commits
-
The driver had to decide how many events to allocate when the v4l2_fh struct
was created. It was possible to add more events afterwards, but there was no
way to ensure that you wouldn't miss important events if the event queue
would fill up for that filehandle.In addition, once there were no more free events, any new events were simply
dropped on the floor.For the control event in particular this made life very difficult since
control status/value changes could just be missed if the number of allocated
events and the speed at which the application read events was too low to keep
up with the number of generated events. The application would have no idea
what the latest state was for a control since it could have missed the latest
control change.So this patch makes some major changes in how events are allocated. Instead
of allocating events per-filehandle they are now allocated when subscribing an
event. So for that particular event type N events (determined by the driver)
are allocated. Those events are reserved for that particular event type.
This ensures that you will not miss events for a particular type altogether.In addition, if there are N events in use and a new event is raised, then
the oldest event is dropped and the new one is added. So the latest event
is always available.This can be further improved by adding the ability to merge the state of
two events together, ensuring that no data is lost at all. This will be
added in the next patch.This also makes it possible to allow the user to determine the number of
events that will be allocated. This is not implemented at the moment, but
would be trivial.Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab -
Drivers that supported events used to be rare, but now that controls can also
raise events this will become much more common since almost all drivers have
controls.This means that keeping struct v4l2_events as a separate struct make no more
sense. Merging it into struct v4l2_fh simplifies things substantially as it
is now an integral part of the filehandle struct.Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab -
This is required to implement control events and is also needed to allow
for per-filehandle control handlers.Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
23 Mar, 2011
3 commits
-
Several drivers need to do something when the first filehandle is opened
or the last filehandle is closed. Most implement some use count mechanism,
but if they use v4l2_fh, then you can also just check if this is the only
filehandle for the device node. A simple helper function can do this.Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab -
Add two new functions: v4l2_fh_open allocates and initializes a struct v4l2_fh
based on a struct file pointer and v4l2_fh_release releases and frees a struct
v4l2_fh.Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab -
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
19 May, 2010
2 commits
-
Add event handling backend to V4L2. The backend handles event subscription
and delivery to file handles. Event subscriptions are based on file handle.
Events may be delivered to all subscribed file handles on a device
independent of where they originate from.Signed-off-by: Sakari Ailus
Signed-off-by: Mauro Carvalho Chehab -
This patch adds a list of v4l2_fh structures to every video_device.
It allows using file handle related information in V4L2. The event interface
is one example of such use.The use of v4l2_fh is not mandatory for drivers.
Signed-off-by: Sakari Ailus
Signed-off-by: Mauro Carvalho Chehab
