On 07/03/2013 09:34 PM, Laurent Pinchart wrote:
On Wednesday 03 July 2013 02:01:59 Sakari Ailus wrote:
On Mon, Jun 24, 2013 at 03:40:14PM +0200, Hans Verkuil wrote:
...
Since the payloads are larger I am less concerned about speed. There is
one problem, though: if you dequeue the event and the buffer that should
receive the payload is too small, then you have lost that payload. You
can't allocate a new, larger, buffer and retry. So this approach can only
work if you really know the maximum payload size.
The advantage is also that you won't lose payloads.
Forgot to answer this one --- I think it's fair to assume the user knows the
maximum size of the payload. What we also could do in such a case is to
return the error (e.g. ENOSPC) and put the required size to the large event
size field. But first someone must come up with a variable size event
without well defined maximum size for this to make much sense.
And while we're discussing use cases, Hans, what are you current use cases for
64 bytes event payloads ?
One of the use cases could be face detection events. A face marker would
contain at least 4 rectangle data structures (face, left/right eye,
mouth,...),
which is itself 64 bytes. Plus Euler angle information, confidence,
smile/blink
level etc. We could add an object detection specific ioctl(s) (I'm not sure
if such won't be needed anyway), but the event API looks like a good
infrastructure to handle this kind of data.
--
Regards,
Sylwester
--
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
