Re: [RFC] Video events, version 2

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

Hans Verkuil wrote:
[clip]
> I'm not keen on using pointers insides structures unless there is a very
> good reason to do so. In practice it complicates the driver code
> substantially due to all the kernel-to-userspace copies that need to be
> done that are normally handled by video_ioctl2. In addition it requires
> custom code in the compat-ioctl32 part as well.

VIDIOC_DQEVENT then.

[clip]
>> The size of the structure is now 96 bytes. I guess we could make that
>> around 128 to allow a bit more space for data without really affecting
>> performance.
> 
> With 'big unions' I didn't mean the memory size. I think 64 bytes (16
> longs) is a decent size. I was talking about the union definition in the
> videodev2.h header.

That was a badly placed comment, but I meant the memory size. I have 
currently no opinion on whether to use union or not.

[clip]
>>> That said, I think the initial implementation should be that the
>>> subscribe
>>> ioctl gets a struct with the event type and a few reserved fields so
>>> that
>>> in the future we can use one of the reserved fields as a configuration
>>> parameter. So for now we just have some default watermark that is set by
>>> the
>>> driver.
>> I'd like to think a queue size defined by the driver is fine at this
>> point. It's probably depending on the driver rather than application how
>> long the queue should to be. At some point old events start becoming
>> uninteresting...
> 
> Question: will we drop old events or new events? Or make this
> configurable? Or driver dependent?

This should the same than for video buffers. I guess it's undefined? I'd 
let the driver decide at this point.

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com