From: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sakari Ailus <sakari.ailus@iki.fi>,
Hans Verkuil <hverkuil@xs4all.nl>,
linux-media <linux-media@vger.kernel.org>
Subject: Re: [RFC] Support for events with a large payload
Date: Sat, 06 Jul 2013 23:54:20 +0200 [thread overview]
Message-ID: <51D8920C.8020306@gmail.com> (raw)
In-Reply-To: <3981855.thaXQaXO7C@avalon>
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
prev parent reply other threads:[~2013-07-06 21:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-13 12:14 [RFC] Support for events with a large payload Hans Verkuil
2013-06-06 21:38 ` Sakari Ailus
2013-06-18 21:22 ` Laurent Pinchart
2013-06-19 6:32 ` Hans Verkuil
2013-06-22 22:46 ` Sakari Ailus
2013-06-24 12:57 ` Hans Verkuil
2013-06-24 22:05 ` Sylwester Nawrocki
2013-06-22 20:58 ` Sakari Ailus
2013-06-24 13:40 ` Hans Verkuil
2013-07-02 22:57 ` Sakari Ailus
2013-07-02 23:01 ` Sakari Ailus
2013-07-03 19:34 ` Laurent Pinchart
2013-07-06 21:54 ` Sylwester Nawrocki [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51D8920C.8020306@gmail.com \
--to=sylvester.nawrocki@gmail.com \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=sakari.ailus@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.