Hi, 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. 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 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"? 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? Best regards -- Tomasz Fujak -- 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
