From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com> To: Hans Verkuil <hverkuil@xs4all.nl>, Oleksandr Andrushchenko <andr2000@gmail.com>, "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "jgross@suse.com" <jgross@suse.com>, "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>, "mchehab@kernel.org" <mchehab@kernel.org>, "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>, "sakari.ailus@linux.intel.com" <sakari.ailus@linux.intel.com>, "koji.matsuoka.xm@renesas.com" <koji.matsuoka.xm@renesas.com> Subject: Re: [Xen-devel][PATCH v4 1/1] cameraif: add ABI for para-virtual camera Date: Tue, 15 Jan 2019 14:49:11 +0000 [thread overview] Message-ID: <f8cb4201-ae29-2d93-353f-7bf403b6e83c@epam.com> (raw) In-Reply-To: <393f824d-e543-476c-777f-402bcc1c0bcb@xs4all.nl> On 1/15/19 4:44 PM, Hans Verkuil wrote: > Hi Oleksandr, Hello, Hans! > Just two remaining comments: > > On 1/15/19 10:38 AM, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> >> >> This is the ABI for the two halves of a para-virtualized >> camera driver which extends Xen's reach multimedia capabilities even >> farther enabling it for video conferencing, In-Vehicle Infotainment, >> high definition maps etc. >> >> The initial goal is to support most needed functionality with the >> final idea to make it possible to extend the protocol if need be: >> >> 1. Provide means for base virtual device configuration: >> - pixel formats >> - resolutions >> - frame rates >> 2. Support basic camera controls: >> - contrast >> - brightness >> - hue >> - saturation >> 3. Support streaming control >> >> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> >> --- >> xen/include/public/io/cameraif.h | 1364 ++++++++++++++++++++++++++++++ >> 1 file changed, 1364 insertions(+) >> create mode 100644 xen/include/public/io/cameraif.h >> >> diff --git a/xen/include/public/io/cameraif.h b/xen/include/public/io/cameraif.h >> new file mode 100644 >> index 000000000000..246eb2457f40 >> --- /dev/null >> +++ b/xen/include/public/io/cameraif.h >> @@ -0,0 +1,1364 @@ > <snip> > >> +/* >> + ****************************************************************************** >> + * EVENT CODES >> + ****************************************************************************** >> + */ >> +#define XENCAMERA_EVT_FRAME_AVAIL 0x00 >> +#define XENCAMERA_EVT_CTRL_CHANGE 0x01 >> + >> +/* Resolution has changed. */ >> +#define XENCAMERA_EVT_CFG_FLG_RESOL (1 << 0) > I think this flag is a left-over from v2 and should be removed. Good catch, will remove > > <snip> > >> + * Request number of buffers to be used: >> + * 0 1 2 3 octet >> + * +----------------+----------------+----------------+----------------+ >> + * | id | _OP_BUF_REQUEST| reserved | 4 >> + * +----------------+----------------+----------------+----------------+ >> + * | reserved | 8 >> + * +----------------+----------------+----------------+----------------+ >> + * | num_bufs | reserved | 12 >> + * +----------------+----------------+----------------+----------------+ >> + * | reserved | 16 >> + * +----------------+----------------+----------------+----------------+ >> + * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| >> + * +----------------+----------------+----------------+----------------+ >> + * | reserved | 64 >> + * +----------------+----------------+----------------+----------------+ >> + * >> + * num_bufs - uint8_t, desired number of buffers to be used. This is >> + * limited to the value configured in XenStore.max-buffers. >> + * Passing zero num_bufs in this request (after streaming has stopped >> + * and all buffers destroyed) unblocks camera configuration changes. > I think the phrase 'unblocks camera configuration changes' is confusing. > > In v3 this sentence came after the third note below, and so it made sense > in that context, but now the order has been reversed and it became hard to > understand. > > I'm not sure what the best approach is to fix this. One option is to remove > the third note and integrate it somehow in the sentence above. Or perhaps > do away with the 'notes' at all and just write a more extensive documentation > for this op. I leave that up to you. I'll think about what can be done here >> + * >> + * See response format for this request. >> + * >> + * Notes: >> + * - frontend must check the corresponding response in order to see >> + * if the values reported back by the backend do match the desired ones >> + * and can be accepted. >> + * - frontend may send multiple XENCAMERA_OP_BUF_REQUEST requests before >> + * sending XENCAMERA_OP_STREAM_START request to update or tune the >> + * configuration. >> + * - after this request camera configuration cannot be changed, unless > camera configuration -> the camera configuration Will fix >> + * streaming is stopped and buffers destroyed >> + */ > Regards, > > Hans Thank you for helping with this, Oleksandr
WARNING: multiple messages have this Message-ID (diff)
From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com> To: Hans Verkuil <hverkuil@xs4all.nl>, Oleksandr Andrushchenko <andr2000@gmail.com>, "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, "jgross@suse.com" <jgross@suse.com>, "boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>, "mchehab@kernel.org" <mchehab@kernel.org>, "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>, "sakari.ailus@linux.intel.com" <sakari.ailus@linux.intel.com>, "koji.matsuoka.xm@renesas.com" <koji.matsuoka.xm@renesas.com> Subject: Re: [PATCH v4 1/1] cameraif: add ABI for para-virtual camera Date: Tue, 15 Jan 2019 14:49:11 +0000 [thread overview] Message-ID: <f8cb4201-ae29-2d93-353f-7bf403b6e83c@epam.com> (raw) In-Reply-To: <393f824d-e543-476c-777f-402bcc1c0bcb@xs4all.nl> On 1/15/19 4:44 PM, Hans Verkuil wrote: > Hi Oleksandr, Hello, Hans! > Just two remaining comments: > > On 1/15/19 10:38 AM, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> >> >> This is the ABI for the two halves of a para-virtualized >> camera driver which extends Xen's reach multimedia capabilities even >> farther enabling it for video conferencing, In-Vehicle Infotainment, >> high definition maps etc. >> >> The initial goal is to support most needed functionality with the >> final idea to make it possible to extend the protocol if need be: >> >> 1. Provide means for base virtual device configuration: >> - pixel formats >> - resolutions >> - frame rates >> 2. Support basic camera controls: >> - contrast >> - brightness >> - hue >> - saturation >> 3. Support streaming control >> >> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> >> --- >> xen/include/public/io/cameraif.h | 1364 ++++++++++++++++++++++++++++++ >> 1 file changed, 1364 insertions(+) >> create mode 100644 xen/include/public/io/cameraif.h >> >> diff --git a/xen/include/public/io/cameraif.h b/xen/include/public/io/cameraif.h >> new file mode 100644 >> index 000000000000..246eb2457f40 >> --- /dev/null >> +++ b/xen/include/public/io/cameraif.h >> @@ -0,0 +1,1364 @@ > <snip> > >> +/* >> + ****************************************************************************** >> + * EVENT CODES >> + ****************************************************************************** >> + */ >> +#define XENCAMERA_EVT_FRAME_AVAIL 0x00 >> +#define XENCAMERA_EVT_CTRL_CHANGE 0x01 >> + >> +/* Resolution has changed. */ >> +#define XENCAMERA_EVT_CFG_FLG_RESOL (1 << 0) > I think this flag is a left-over from v2 and should be removed. Good catch, will remove > > <snip> > >> + * Request number of buffers to be used: >> + * 0 1 2 3 octet >> + * +----------------+----------------+----------------+----------------+ >> + * | id | _OP_BUF_REQUEST| reserved | 4 >> + * +----------------+----------------+----------------+----------------+ >> + * | reserved | 8 >> + * +----------------+----------------+----------------+----------------+ >> + * | num_bufs | reserved | 12 >> + * +----------------+----------------+----------------+----------------+ >> + * | reserved | 16 >> + * +----------------+----------------+----------------+----------------+ >> + * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| >> + * +----------------+----------------+----------------+----------------+ >> + * | reserved | 64 >> + * +----------------+----------------+----------------+----------------+ >> + * >> + * num_bufs - uint8_t, desired number of buffers to be used. This is >> + * limited to the value configured in XenStore.max-buffers. >> + * Passing zero num_bufs in this request (after streaming has stopped >> + * and all buffers destroyed) unblocks camera configuration changes. > I think the phrase 'unblocks camera configuration changes' is confusing. > > In v3 this sentence came after the third note below, and so it made sense > in that context, but now the order has been reversed and it became hard to > understand. > > I'm not sure what the best approach is to fix this. One option is to remove > the third note and integrate it somehow in the sentence above. Or perhaps > do away with the 'notes' at all and just write a more extensive documentation > for this op. I leave that up to you. I'll think about what can be done here >> + * >> + * See response format for this request. >> + * >> + * Notes: >> + * - frontend must check the corresponding response in order to see >> + * if the values reported back by the backend do match the desired ones >> + * and can be accepted. >> + * - frontend may send multiple XENCAMERA_OP_BUF_REQUEST requests before >> + * sending XENCAMERA_OP_STREAM_START request to update or tune the >> + * configuration. >> + * - after this request camera configuration cannot be changed, unless > camera configuration -> the camera configuration Will fix >> + * streaming is stopped and buffers destroyed >> + */ > Regards, > > Hans Thank you for helping with this, Oleksandr _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-01-15 14:49 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-15 9:38 [Xen-devel][PATCH v4 0/1] cameraif: add ABI for para-virtual camera Oleksandr Andrushchenko 2019-01-15 9:38 ` [PATCH " Oleksandr Andrushchenko 2019-01-15 9:38 ` [Xen-devel][PATCH v4 1/1] " Oleksandr Andrushchenko 2019-01-15 9:38 ` [PATCH " Oleksandr Andrushchenko 2019-01-15 14:44 ` [Xen-devel][PATCH " Hans Verkuil 2019-01-15 14:44 ` [PATCH " Hans Verkuil 2019-01-15 14:49 ` Oleksandr Andrushchenko [this message] 2019-01-15 14:49 ` Oleksandr Andrushchenko 2019-01-23 8:14 ` [Xen-devel][PATCH " Oleksandr Andrushchenko 2019-01-23 8:14 ` [PATCH " Oleksandr Andrushchenko 2019-02-05 8:48 ` [Xen-devel][PATCH " Oleksandr Andrushchenko 2019-02-05 8:48 ` [PATCH " Oleksandr Andrushchenko 2019-02-05 9:34 ` [Xen-devel][PATCH " Hans Verkuil 2019-02-05 9:34 ` [PATCH " Hans Verkuil 2019-02-05 10:44 ` [Xen-devel][PATCH " Oleksandr Andrushchenko 2019-02-05 10:44 ` [PATCH " Oleksandr Andrushchenko 2019-02-05 10:53 ` [Xen-devel][PATCH " Hans Verkuil 2019-02-05 10:53 ` [PATCH " Hans Verkuil 2019-02-05 11:44 ` [Xen-devel][PATCH " Oleksandr Andrushchenko 2019-02-05 11:44 ` [PATCH " Oleksandr Andrushchenko 2019-02-05 12:14 ` [Xen-devel][PATCH " Hans Verkuil 2019-02-05 12:14 ` [PATCH " Hans Verkuil 2019-02-05 12:30 ` [Xen-devel][PATCH " Oleksandr Andrushchenko 2019-02-05 12:30 ` [PATCH " Oleksandr Andrushchenko 2019-02-05 13:02 ` [Xen-devel][PATCH " Hans Verkuil 2019-02-05 13:02 ` [PATCH " Hans Verkuil 2019-02-05 13:06 ` [Xen-devel][PATCH " Oleksandr Andrushchenko 2019-02-05 13:06 ` [PATCH " Oleksandr Andrushchenko 2019-02-13 12:11 ` [Xen-devel][PATCH " Oleksandr Andrushchenko 2019-02-13 12:11 ` [PATCH " Oleksandr Andrushchenko 2019-01-31 8:24 ` [Xen-devel][PATCH v4 0/1] " Oleksandr Andrushchenko 2019-01-31 8:24 ` [PATCH " Oleksandr Andrushchenko
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=f8cb4201-ae29-2d93-353f-7bf403b6e83c@epam.com \ --to=oleksandr_andrushchenko@epam.com \ --cc=andr2000@gmail.com \ --cc=boris.ostrovsky@oracle.com \ --cc=hverkuil@xs4all.nl \ --cc=jgross@suse.com \ --cc=koji.matsuoka.xm@renesas.com \ --cc=konrad.wilk@oracle.com \ --cc=linux-media@vger.kernel.org \ --cc=mchehab@kernel.org \ --cc=sakari.ailus@linux.intel.com \ --cc=xen-devel@lists.xenproject.org \ /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: linkBe 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.