Tomasz Fujak wrote:
Hi,
Hi, Tomasz!
The event count may be useful for the reason Laurent mentioned. In case we don't have dequeue multiple (DQEVENT_MULTIPLE?) a flag should be enough, saying if there are any events immediately available. That'd be just one bit we could mash into the 'type' field.
We could have also another field for flags. It's nicer to do that than use the type field for that --- we're not short of bits here.
On the other hand I can imagine an event type that come swarming once a client registers to them (i.e.: VSYNC). In such a case they may overflow a queue and discard potentially useful events (i.e.: a cable detached from the output). We could do one of the following: - nothing (let the above happen if the application is not fast enough to retrieve events), - suggest using separate event feed for periodic events, - compress periodic events (provide 'compressed' flag, and stamp the event with the timestamp of the last of the kind) - thus at most one of a periodic event type would reside in the queue, - let the client define the window size, - define event priorities (low, normal, high) and discard overflowing events starting with the lowest priorities. I.e.: low for VSYNC, normal for picture decoding error and high for cable attach
I think it's up to the driver to define the queue size. Then the queue can just overflow when it becomes full. If the client isn't fast enough to handle the events buffering them won't help in the end... for temporary scheduling delays a deeper queue should do the trick.
Another ioctl would probably be required for queue size setting if it's ever needed. This is IMO more or less equivalent to setting the maximum allocatable memory for video buffers, which is indeed fixed to video drivers themselves.
Third, the event subscription scheme. What does a subscription call mean: "Add these new events to what I already collect" or "Discard whatever I have subscribed for and now give me this"?
Add this one / remove this one. The type is a 32-number so we should have enough different kind of events. :)
In the latter use, there are just 27 event types available; can't tell if that's enough till we try to enumerate the event types we currently have. I've just seen a few of them (DVB, UVC, ACPI), but I think the list would grow once people start using the v4l2 events. How big is it going to be?
Let's hope people start using this once it's available... -- 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
