On Friday 16 October 2009 10:55:04 Sakari Ailus wrote: > 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. >From the user point of view it won't make much difference. The same number of consecutive events will be lost. Which ones will depend on the events arrival time and when/how long the application fails to retrieve pending events. I agree to let the driver decide (or rather the v4l2 core, as the queue will be implemented there). -- Laurent Pinchart -- 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
