Re: [RFC] Video events, version 2.1

[Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>]

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@maxwell.research.nokia.com