Re: [Xen-devel] [PATCH v2 1/1] cameraif: add ABI for para-virtual camera
On 09/11/2018 10:29 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > 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 > 4. Support zero-copying use-cases > > Signed-off-by: Oleksandr Andrushchenko > --- > xen/include/public/io/cameraif.h | 1263 ++ > 1 file changed, 1263 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 ..38b9b3741e75 > --- /dev/null > +++ b/xen/include/public/io/cameraif.h > @@ -0,0 +1,1263 @@ > +/** > + * cameraif.h > + * > + * Unified camera device I/O interface for Xen guest OSes. > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > copy > + * of this software and associated documentation files (the "Software"), to > + * deal in the Software without restriction, including without limitation the > + * rights to use, copy, modify, merge, publish, distribute, sublicense, > and/or > + * sell copies of the Software, and to permit persons to whom the Software is > + * furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > THE > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > + * DEALINGS IN THE SOFTWARE. > + * > + * Copyright (C) 2018 EPAM Systems Inc. > + * > + * Author: Oleksandr Andrushchenko > + */ > + > +#ifndef __XEN_PUBLIC_IO_CAMERAIF_H__ > +#define __XEN_PUBLIC_IO_CAMERAIF_H__ > + > +#include "ring.h" > +#include "../grant_table.h" > + > +/* > + > ** > + * Protocol version > + > ** > + */ > +#define XENCAMERA_PROTOCOL_VERSION "1" > + > +/* > + > ** > + * Feature and Parameter Negotiation > + > ** > + * > + * Front->back notifications: when enqueuing a new request, sending a > + * notification can be made conditional on xencamera_req (i.e., the generic > + * hold-off mechanism provided by the ring macros). Backends must set > + * xencamera_req appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()). > + * > + * Back->front notifications: when enqueuing a new response, sending a > + * notification can be made conditional on xencamera_resp (i.e., the generic > + * hold-off mechanism provided by the ring macros). Frontends must set > + * xencamera_resp appropriately (e.g., using > RING_FINAL_CHECK_FOR_RESPONSES()). > + * > + * The two halves of a para-virtual camera driver utilize nodes within > + * XenStore to communicate capabilities and to negotiate operating > parameters. > + * This section enumerates these nodes which reside in the respective front > and > + * backend portions of XenStore, following the XenBus convention. > + * > + * All data in XenStore is stored as strings. Nodes specifying numeric > + * values are encoded in decimal. Integer value ranges listed below are > + * expressed as fixed sized integer types capable of storing the conversion > + * of a properly formatted node string, without loss of information. > + * > + > ** > + *Example configuration > + > ** > + * > + * This is an example of backend and frontend configuration: > + * > + *- Backend > --- > + * > + * /local/domain/0/backend/vcamera/1/0/frontend-id = "1" > + * /local/domain/0/backend/vcamera/1/
Re: [Xen-devel] [PATCH v2 1/1] cameraif: add ABI for para-virtual camera
On 09/11/18 10:29, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > 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 > 4. Support zero-copying use-cases > > Signed-off-by: Oleksandr Andrushchenko > --- > xen/include/public/io/cameraif.h | 1263 ++ > 1 file changed, 1263 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 ..38b9b3741e75 > --- /dev/null > +++ b/xen/include/public/io/cameraif.h > @@ -0,0 +1,1263 @@ > +/** > + * cameraif.h > + * > + * Unified camera device I/O interface for Xen guest OSes. > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > copy > + * of this software and associated documentation files (the "Software"), to > + * deal in the Software without restriction, including without limitation the > + * rights to use, copy, modify, merge, publish, distribute, sublicense, > and/or > + * sell copies of the Software, and to permit persons to whom the Software is > + * furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > THE > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > + * DEALINGS IN THE SOFTWARE. > + * > + * Copyright (C) 2018 EPAM Systems Inc. > + * > + * Author: Oleksandr Andrushchenko > + */ > + > +#ifndef __XEN_PUBLIC_IO_CAMERAIF_H__ > +#define __XEN_PUBLIC_IO_CAMERAIF_H__ > + > +#include "ring.h" > +#include "../grant_table.h" > + > +/* > + > ** > + * Protocol version > + > ** > + */ > +#define XENCAMERA_PROTOCOL_VERSION "1" > + > +/* > + > ** > + * Feature and Parameter Negotiation > + > ** > + * > + * Front->back notifications: when enqueuing a new request, sending a > + * notification can be made conditional on xencamera_req (i.e., the generic > + * hold-off mechanism provided by the ring macros). Backends must set > + * xencamera_req appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()). > + * > + * Back->front notifications: when enqueuing a new response, sending a > + * notification can be made conditional on xencamera_resp (i.e., the generic > + * hold-off mechanism provided by the ring macros). Frontends must set > + * xencamera_resp appropriately (e.g., using > RING_FINAL_CHECK_FOR_RESPONSES()). > + * > + * The two halves of a para-virtual camera driver utilize nodes within > + * XenStore to communicate capabilities and to negotiate operating > parameters. > + * This section enumerates these nodes which reside in the respective front > and > + * backend portions of XenStore, following the XenBus convention. > + * > + * All data in XenStore is stored as strings. Nodes specifying numeric > + * values are encoded in decimal. Integer value ranges listed below are > + * expressed as fixed sized integer types capable of storing the conversion > + * of a properly formatted node string, without loss of information. > + * > + > ** > + *Example configuration > + > ** > + * > + * This is an example of backend and frontend configuration: > + * > + *- Backend > --- > + * > + * /local/domain/0/backend/vcamera/1/0/frontend-id = "1" > + * /local/domain/0/backend/vcamera/1/0/fro
Re: [Xen-devel] [PATCH v2 1/1] cameraif: add ABI for para-virtual camera
Hi, Hans! Thank you for valuable comments and valid concerns! On 09/12/2018 10:52 AM, Hans Verkuil wrote: On 09/11/2018 10:29 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko 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 4. Support zero-copying use-cases Signed-off-by: Oleksandr Andrushchenko --- xen/include/public/io/cameraif.h | 1263 ++ 1 file changed, 1263 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 ..38b9b3741e75 --- /dev/null +++ b/xen/include/public/io/cameraif.h @@ -0,0 +1,1263 @@ +/** + * cameraif.h + * + * Unified camera device I/O interface for Xen guest OSes. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Copyright (C) 2018 EPAM Systems Inc. + * + * Author: Oleksandr Andrushchenko + */ + +#ifndef __XEN_PUBLIC_IO_CAMERAIF_H__ +#define __XEN_PUBLIC_IO_CAMERAIF_H__ + +#include "ring.h" +#include "../grant_table.h" + +/* + ** + * Protocol version + ** + */ +#define XENCAMERA_PROTOCOL_VERSION "1" + +/* + ** + * Feature and Parameter Negotiation + ** + * + * Front->back notifications: when enqueuing a new request, sending a + * notification can be made conditional on xencamera_req (i.e., the generic + * hold-off mechanism provided by the ring macros). Backends must set + * xencamera_req appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()). + * + * Back->front notifications: when enqueuing a new response, sending a + * notification can be made conditional on xencamera_resp (i.e., the generic + * hold-off mechanism provided by the ring macros). Frontends must set + * xencamera_resp appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()). + * + * The two halves of a para-virtual camera driver utilize nodes within + * XenStore to communicate capabilities and to negotiate operating parameters. + * This section enumerates these nodes which reside in the respective front and + * backend portions of XenStore, following the XenBus convention. + * + * All data in XenStore is stored as strings. Nodes specifying numeric + * values are encoded in decimal. Integer value ranges listed below are + * expressed as fixed sized integer types capable of storing the conversion + * of a properly formatted node string, without loss of information. + * + ** + *Example configuration + ** + * + * This is an example of backend and frontend configuration: + * + *- Backend --- + * + * /local/domain/0/backend/vcamera/1/0/frontend-id = "1" + * /local/domain/0/backend/vcamera/1/0/frontend = "/local/domain/1/device/vcamera/0" + * /local/domain/0/backend/vcamera/1/0/state = "4" + * /local/domain/0/backend/vcamera/1/0/
Re: [Xen-devel] [PATCH v2 1/1] cameraif: add ABI for para-virtual camera
On 09/12/2018 12:16 PM, Hans Verkuil wrote: On 09/11/18 10:29, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko 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 4. Support zero-copying use-cases Signed-off-by: Oleksandr Andrushchenko --- xen/include/public/io/cameraif.h | 1263 ++ 1 file changed, 1263 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 ..38b9b3741e75 --- /dev/null +++ b/xen/include/public/io/cameraif.h @@ -0,0 +1,1263 @@ +/** + * cameraif.h + * + * Unified camera device I/O interface for Xen guest OSes. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Copyright (C) 2018 EPAM Systems Inc. + * + * Author: Oleksandr Andrushchenko + */ + +#ifndef __XEN_PUBLIC_IO_CAMERAIF_H__ +#define __XEN_PUBLIC_IO_CAMERAIF_H__ + +#include "ring.h" +#include "../grant_table.h" + +/* + ** + * Protocol version + ** + */ +#define XENCAMERA_PROTOCOL_VERSION "1" + +/* + ** + * Feature and Parameter Negotiation + ** + * + * Front->back notifications: when enqueuing a new request, sending a + * notification can be made conditional on xencamera_req (i.e., the generic + * hold-off mechanism provided by the ring macros). Backends must set + * xencamera_req appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()). + * + * Back->front notifications: when enqueuing a new response, sending a + * notification can be made conditional on xencamera_resp (i.e., the generic + * hold-off mechanism provided by the ring macros). Frontends must set + * xencamera_resp appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()). + * + * The two halves of a para-virtual camera driver utilize nodes within + * XenStore to communicate capabilities and to negotiate operating parameters. + * This section enumerates these nodes which reside in the respective front and + * backend portions of XenStore, following the XenBus convention. + * + * All data in XenStore is stored as strings. Nodes specifying numeric + * values are encoded in decimal. Integer value ranges listed below are + * expressed as fixed sized integer types capable of storing the conversion + * of a properly formatted node string, without loss of information. + * + ** + *Example configuration + ** + * + * This is an example of backend and frontend configuration: + * + *- Backend --- + * + * /local/domain/0/backend/vcamera/1/0/frontend-id = "1" + * /local/domain/0/backend/vcamera/1/0/frontend = "/local/domain/1/device/vcamera/0" + * /local/domain/0/backend/vcamera/1/0/state = "4" + * /local/domain/0/backend/vcamera/1/0/versions = "1,2" + * + *- Frontend --
Re: [Xen-devel] [PATCH v2 1/1] cameraif: add ABI for para-virtual camera
On 09/12/18 12:09, Oleksandr Andrushchenko wrote: > Hi, Hans! > > Thank you for valuable comments and valid concerns! > > On 09/12/2018 10:52 AM, Hans Verkuil wrote: >> On 09/11/2018 10:29 AM, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko >>> >>> 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 >>> 4. Support zero-copying use-cases >>> >>> Signed-off-by: Oleksandr Andrushchenko >>> --- >>> xen/include/public/io/cameraif.h | 1263 ++ >>> 1 file changed, 1263 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 ..38b9b3741e75 >>> --- /dev/null >>> +++ b/xen/include/public/io/cameraif.h >>> @@ -0,0 +1,1263 @@ >>> +/** >>> + * cameraif.h >>> + * >>> + * Unified camera device I/O interface for Xen guest OSes. >>> + * >>> + * Permission is hereby granted, free of charge, to any person obtaining a >>> copy >>> + * of this software and associated documentation files (the "Software"), to >>> + * deal in the Software without restriction, including without limitation >>> the >>> + * rights to use, copy, modify, merge, publish, distribute, sublicense, >>> and/or >>> + * sell copies of the Software, and to permit persons to whom the Software >>> is >>> + * furnished to do so, subject to the following conditions: >>> + * >>> + * The above copyright notice and this permission notice shall be included >>> in >>> + * all copies or substantial portions of the Software. >>> + * >>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS >>> OR >>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, >>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL >>> THE >>> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER >>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING >>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER >>> + * DEALINGS IN THE SOFTWARE. >>> + * >>> + * Copyright (C) 2018 EPAM Systems Inc. >>> + * >>> + * Author: Oleksandr Andrushchenko >>> + */ >>> + >>> +#ifndef __XEN_PUBLIC_IO_CAMERAIF_H__ >>> +#define __XEN_PUBLIC_IO_CAMERAIF_H__ >>> + >>> +#include "ring.h" >>> +#include "../grant_table.h" >>> + >>> +/* >>> + >>> ** >>> + * Protocol version >>> + >>> ** >>> + */ >>> +#define XENCAMERA_PROTOCOL_VERSION "1" >>> + >>> +/* >>> + >>> ** >>> + * Feature and Parameter Negotiation >>> + >>> ** >>> + * >>> + * Front->back notifications: when enqueuing a new request, sending a >>> + * notification can be made conditional on xencamera_req (i.e., the generic >>> + * hold-off mechanism provided by the ring macros). Backends must set >>> + * xencamera_req appropriately (e.g., using >>> RING_FINAL_CHECK_FOR_REQUESTS()). >>> + * >>> + * Back->front notifications: when enqueuing a new response, sending a >>> + * notification can be made conditional on xencamera_resp (i.e., the >>> generic >>> + * hold-off mechanism provided by the ring macros). Frontends must set >>> + * xencamera_resp appropriately (e.g., using >>> RING_FINAL_CHECK_FOR_RESPONSES()). >>> + * >>> + * The two halves of a para-virtual camera driver utilize nodes within >>> + * XenStore to communicate capabilities and to negotiate operating >>> parameters. >>> + * This section enumerates these nodes which reside in the respective >>> front and >>> + * backend portions of XenStore, following the XenBus convention. >>> + * >>> + * All data in XenStore is stored as strings. Nodes specifying numeric >>> + * values are encoded in decimal. Integer value ranges listed below are >>> + * expressed as fixed sized integer types capable of storing the conversion >>> + * of a properly formatted node string, without loss of information. >>> + * >>> + >>>
Re: [Xen-devel] [PATCH v2 1/1] cameraif: add ABI for para-virtual camera
On 09/12/2018 03:25 PM, Hans Verkuil wrote: On 09/12/18 12:09, Oleksandr Andrushchenko wrote: Hi, Hans! Thank you for valuable comments and valid concerns! On 09/12/2018 10:52 AM, Hans Verkuil wrote: On 09/11/2018 10:29 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko 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 4. Support zero-copying use-cases Signed-off-by: Oleksandr Andrushchenko --- xen/include/public/io/cameraif.h | 1263 ++ 1 file changed, 1263 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 ..38b9b3741e75 --- /dev/null +++ b/xen/include/public/io/cameraif.h @@ -0,0 +1,1263 @@ +/** + * cameraif.h + * + * Unified camera device I/O interface for Xen guest OSes. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Copyright (C) 2018 EPAM Systems Inc. + * + * Author: Oleksandr Andrushchenko + */ + +#ifndef __XEN_PUBLIC_IO_CAMERAIF_H__ +#define __XEN_PUBLIC_IO_CAMERAIF_H__ + +#include "ring.h" +#include "../grant_table.h" + +/* + ** + * Protocol version + ** + */ +#define XENCAMERA_PROTOCOL_VERSION "1" + +/* + ** + * Feature and Parameter Negotiation + ** + * + * Front->back notifications: when enqueuing a new request, sending a + * notification can be made conditional on xencamera_req (i.e., the generic + * hold-off mechanism provided by the ring macros). Backends must set + * xencamera_req appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()). + * + * Back->front notifications: when enqueuing a new response, sending a + * notification can be made conditional on xencamera_resp (i.e., the generic + * hold-off mechanism provided by the ring macros). Frontends must set + * xencamera_resp appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()). + * + * The two halves of a para-virtual camera driver utilize nodes within + * XenStore to communicate capabilities and to negotiate operating parameters. + * This section enumerates these nodes which reside in the respective front and + * backend portions of XenStore, following the XenBus convention. + * + * All data in XenStore is stored as strings. Nodes specifying numeric + * values are encoded in decimal. Integer value ranges listed below are + * expressed as fixed sized integer types capable of storing the conversion + * of a properly formatted node string, without loss of information. + * + ** + *Example configuration + ** + * + * This is an example of backend and frontend configuration: + * + *- Backend --- + * + * /local/domain/0/backend/vcamera/1/0/frontend-id = "1" + * /local/domain/0/backend/vcamera/1/0/frontend = "/local/domain/1/devi
Re: [Xen-devel] [PATCH v2 1/1] cameraif: add ABI for para-virtual camera
On 09/12/18 15:02, Oleksandr Andrushchenko wrote:
> On 09/12/2018 03:25 PM, Hans Verkuil wrote:
> + * formats
> + * Values:
> + *
> + * Formats are organized as a set of directories one per each
> + * supported pixel format. The name of the directory is the
> + * corresponding FOURCC string label. The next level of
> + * the directory under represents supported resolutions.
So how will this work for a pixelformat like V4L2_PIX_FMT_ARGB555X?
As mentioned before, we display such formats as '-BE', i.e. char[7].
>>> ok, then I'll change this to char[7] and put a note on big-endian:
>>>
>>>* If format represents a big-endian FOURCC code, then "-BE"
>>>* suffix must be added, case insensitive.
>> Since the fourcc is case-sensitive, I'd keep -BE case sensitive as well.
>> Your decision, though.
> hm, I'm a little bit confused here... One of the previous comments was...
>
> >> + * Formats are organized as a set of directories one per each
> >> + * supported pixel format. The name of the directory is an
> upper case
> >> + * string of the corresponding FOURCC string label. The next
> level of
> >> + * the directory under represents supported resolutions.
>
> >Lower-case characters are also use in pixelformats, so I'd just keep
> this as-is.
> >
> >In addition it is common to set bit 31 of the fourcc to 1 if the format is
> >big-endian (see v4l2_fourcc_be macro). When v4l utilities print this
> format we
> >add a -BE suffix, so V4L2_PIX_FMT_ARGB555X becomes "AR15-BE". You
> might want to
> >keep that convention.
>
> So, finally, I'll put upper case constraint here for fourcc and "-BE"?
> Did I miss something here?
Easiest is to look at videodev2.h. Let me take two examples:
#define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16
ARGB-1-5-5-5 */
#define V4L2_PIX_FMT_ARGB555X v4l2_fourcc_be('A', 'R', '1', '5') /* 16
ARGB-5-5-5 BE */
The fourcc macros are defined as:
#define v4l2_fourcc(a, b, c, d)\
((__u32)(a) | ((__u32)(b) << 8) | ((__u32)(c) << 16) | ((__u32)(d) <<
24))
#define v4l2_fourcc_be(a, b, c, d) (v4l2_fourcc(a, b, c, d) | (1 << 31))
The characters can be any printable character, but currently we only use
a-z, A-Z, 0-9 and space (' ').
For big-endian formats we also set bit 31 (i.e. bit 7 of the last character)
to indicate this.
In our v4l2 utilities we use this function when we want to print a fourcc:
std::string fcc2s(__u32 val)
{
std::string s;
s += val & 0x7f;
s += (val >> 8) & 0x7f;
s += (val >> 16) & 0x7f;
s += (val >> 24) & 0x7f;
if (val & (1 << 31))
s += "-BE";
return s;
}
So the four characters (with bit 7 masked out) and the -BE suffix
if bit 7 was set for the fourth character.
So for your protocol, if you want to specify the fourcc, then I
assume dealing with characters with bit 7 set is a pain as well,
and in that case you are better off using the same scheme that we
do.
And to match the formats, applications should remember that the
string is case-sensitive, so 'abcd' != 'Abcd'.
Note that there can be spaces:
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale
*/
#define V4L2_PIX_FMT_Y16_BE v4l2_fourcc_be('Y', '1', '6', ' ') /* 16
Greyscale BE */
So that would be:
/local/domain/1/device/vcamera/0/formats/Y16 /1200x720/frame-rates = "15/2"
and:
/local/domain/1/device/vcamera/0/formats/Y16 -BE/1200x720/frame-rates = "15/2"
Not sure if that will fly for you.
Currently if there are spaced, then they are at the end, but I don't think
we can guarantee that for all time.
>
I assume the pixelformats you use here are based on the V4L2_PIX_FMT_
fourccs?
Note that there is no real standard for fourcc values, so if you want to
support a Windows backend as well, then you'll need mappings from whatever
Windows uses to the V4L2 fourccs.
The V4L2_PIX_FMT_ fourccs are entirely V4L2 specific.
So you have to define here whose fourccs you are using.
>>> I thought that [1] defines all these values, but if this is not the case,
>>> then I think we can use what V4L2 uses. In this case,
>>> what would be the best reference in the protocol to those fourcc
>>> codes? For example, I can reference [2] in the protocol's assumptions:
>>>
>>>
>>> **
>>>* Assumptions
>>>
>>> **
>>> ...
>>>* - all FOURCC mappings used for configuration and messaging are
>>>* Linux V4L2 ones:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/videodev2.h
>> Yeah, I'd pick videodev2.h. We document the formats fairly carefully in
>> our spec.
> Agreed
>>
>> [1] i
Re: [Xen-devel] [PATCH v2 1/1] cameraif: add ABI for para-virtual camera
On 09/12/2018 04:38 PM, Hans Verkuil wrote:
On 09/12/18 15:02, Oleksandr Andrushchenko wrote:
On 09/12/2018 03:25 PM, Hans Verkuil wrote:
+ * formats
+ * Values:
+ *
+ * Formats are organized as a set of directories one per each
+ * supported pixel format. The name of the directory is the
+ * corresponding FOURCC string label. The next level of
+ * the directory under represents supported resolutions.
So how will this work for a pixelformat like V4L2_PIX_FMT_ARGB555X?
As mentioned before, we display such formats as '-BE', i.e. char[7].
ok, then I'll change this to char[7] and put a note on big-endian:
* If format represents a big-endian FOURCC code, then "-BE"
* suffix must be added, case insensitive.
Since the fourcc is case-sensitive, I'd keep -BE case sensitive as well.
Your decision, though.
hm, I'm a little bit confused here... One of the previous comments was...
>> + * Formats are organized as a set of directories one per each
>> + * supported pixel format. The name of the directory is an
upper case
>> + * string of the corresponding FOURCC string label. The next
level of
>> + * the directory under represents supported resolutions.
>Lower-case characters are also use in pixelformats, so I'd just keep
this as-is.
>
>In addition it is common to set bit 31 of the fourcc to 1 if the format is
>big-endian (see v4l2_fourcc_be macro). When v4l utilities print this
format we
>add a -BE suffix, so V4L2_PIX_FMT_ARGB555X becomes "AR15-BE". You
might want to
>keep that convention.
So, finally, I'll put upper case constraint here for fourcc and "-BE"?
Did I miss something here?
Easiest is to look at videodev2.h. Let me take two examples:
#define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16
ARGB-1-5-5-5 */
#define V4L2_PIX_FMT_ARGB555X v4l2_fourcc_be('A', 'R', '1', '5') /* 16
ARGB-5-5-5 BE */
The fourcc macros are defined as:
#define v4l2_fourcc(a, b, c, d)\
((__u32)(a) | ((__u32)(b) << 8) | ((__u32)(c) << 16) | ((__u32)(d) <<
24))
#define v4l2_fourcc_be(a, b, c, d) (v4l2_fourcc(a, b, c, d) | (1 << 31))
The characters can be any printable character, but currently we only use
a-z, A-Z, 0-9 and space (' ').
For big-endian formats we also set bit 31 (i.e. bit 7 of the last character)
to indicate this.
In our v4l2 utilities we use this function when we want to print a fourcc:
std::string fcc2s(__u32 val)
{
std::string s;
s += val & 0x7f;
s += (val >> 8) & 0x7f;
s += (val >> 16) & 0x7f;
s += (val >> 24) & 0x7f;
if (val & (1 << 31))
s += "-BE";
return s;
}
So the four characters (with bit 7 masked out) and the -BE suffix
if bit 7 was set for the fourth character.
So for your protocol, if you want to specify the fourcc, then I
assume dealing with characters with bit 7 set is a pain as well,
and in that case you are better off using the same scheme that we
do.
And to match the formats, applications should remember that the
string is case-sensitive, so 'abcd' != 'Abcd'.
Ah, got it, so I'll just make sure that "-BE" part
is case sensitive, e.g. remove "case insensitive":
* formats
* Values:
*
* Formats are organized as a set of directories one per each
* supported pixel format. The name of the directory is the
* corresponding FOURCC string label. The next level of
* the directory under represents supported resolutions.
* If format represents a big-endian FOURCC code, then "-BE"
* suffix must be added.
Note that there can be spaces:
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale
*/
#define V4L2_PIX_FMT_Y16_BE v4l2_fourcc_be('Y', '1', '6', ' ') /* 16
Greyscale BE */
So that would be:
/local/domain/1/device/vcamera/0/formats/Y16 /1200x720/frame-rates = "15/2"
and:
/local/domain/1/device/vcamera/0/formats/Y16 -BE/1200x720/frame-rates = "15/2"
Not sure if that will fly for you.
Currently if there are spaced, then they are at the end, but I don't think
we can guarantee that for all time.
This is a problem as I cannot have spaces...
So, I can only put something like:
* If FOURCC string label has spaces then those are only allowed to
* be at the end of the label and must be trimmed.
I assume the pixelformats you use here are based on the V4L2_PIX_FMT_ fourccs?
Note that there is no real standard for fourcc values, so if you want to
support a Windows backend as well, then you'll need mappings from whatever
Windows uses to the V4L2 fourccs.
The V4L2_PIX_FMT_ fourccs are entirely V4L2 specific.
So you have to define here whose fourccs you are using.
I thought that [1] defines all these values, but if this is not the case,
then I think we can use what V4L2 uses. In this case,
what would be the best reference in the protocol to those fourcc
codes? For example, I can reference [2
Re: [Xen-devel] [PATCH v2 1/1] cameraif: add ABI for para-virtual camera
On 09/12/18 16:15, Oleksandr Andrushchenko wrote:
> On 09/12/2018 04:38 PM, Hans Verkuil wrote:
>> On 09/12/18 15:02, Oleksandr Andrushchenko wrote:
>>> On 09/12/2018 03:25 PM, Hans Verkuil wrote:
>>> + * formats
>>> + * Values:
>>> + *
>>> + * Formats are organized as a set of directories one per each
>>> + * supported pixel format. The name of the directory is the
>>> + * corresponding FOURCC string label. The next level of
>>> + * the directory under represents supported resolutions.
>> So how will this work for a pixelformat like V4L2_PIX_FMT_ARGB555X?
>>
>> As mentioned before, we display such formats as '-BE', i.e. char[7].
> ok, then I'll change this to char[7] and put a note on big-endian:
>
> * If format represents a big-endian FOURCC code, then "-BE"
> * suffix must be added, case insensitive.
Since the fourcc is case-sensitive, I'd keep -BE case sensitive as well.
Your decision, though.
>>> hm, I'm a little bit confused here... One of the previous comments was...
>>>
>>> >> + * Formats are organized as a set of directories one per each
>>> >> + * supported pixel format. The name of the directory is an
>>> upper case
>>> >> + * string of the corresponding FOURCC string label. The next
>>> level of
>>> >> + * the directory under represents supported
>>> resolutions.
>>>
>>> >Lower-case characters are also use in pixelformats, so I'd just keep
>>> this as-is.
>>> >
>>> >In addition it is common to set bit 31 of the fourcc to 1 if the format
>>> is
>>> >big-endian (see v4l2_fourcc_be macro). When v4l utilities print this
>>> format we
>>> >add a -BE suffix, so V4L2_PIX_FMT_ARGB555X becomes "AR15-BE". You
>>> might want to
>>> >keep that convention.
>>>
>>> So, finally, I'll put upper case constraint here for fourcc and "-BE"?
>>> Did I miss something here?
>> Easiest is to look at videodev2.h. Let me take two examples:
>>
>> #define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16
>> ARGB-1-5-5-5 */
>> #define V4L2_PIX_FMT_ARGB555X v4l2_fourcc_be('A', 'R', '1', '5') /* 16
>> ARGB-5-5-5 BE */
>>
>> The fourcc macros are defined as:
>>
>> #define v4l2_fourcc(a, b, c, d)\
>> ((__u32)(a) | ((__u32)(b) << 8) | ((__u32)(c) << 16) | ((__u32)(d)
>> << 24))
>> #define v4l2_fourcc_be(a, b, c, d) (v4l2_fourcc(a, b, c, d) | (1 << 31))
>>
>> The characters can be any printable character, but currently we only use
>> a-z, A-Z, 0-9 and space (' ').
>>
>> For big-endian formats we also set bit 31 (i.e. bit 7 of the last character)
>> to indicate this.
>>
>> In our v4l2 utilities we use this function when we want to print a fourcc:
>>
>> std::string fcc2s(__u32 val)
>> {
>> std::string s;
>>
>> s += val & 0x7f;
>> s += (val >> 8) & 0x7f;
>> s += (val >> 16) & 0x7f;
>> s += (val >> 24) & 0x7f;
>> if (val & (1 << 31))
>> s += "-BE";
>> return s;
>> }
>>
>> So the four characters (with bit 7 masked out) and the -BE suffix
>> if bit 7 was set for the fourth character.
>>
>> So for your protocol, if you want to specify the fourcc, then I
>> assume dealing with characters with bit 7 set is a pain as well,
>> and in that case you are better off using the same scheme that we
>> do.
>>
>> And to match the formats, applications should remember that the
>> string is case-sensitive, so 'abcd' != 'Abcd'.
> Ah, got it, so I'll just make sure that "-BE" part
> is case sensitive, e.g. remove "case insensitive":
>
> * formats
> * Values:
> *
> * Formats are organized as a set of directories one per each
> * supported pixel format. The name of the directory is the
> * corresponding FOURCC string label. The next level of
> * the directory under represents supported resolutions.
> * If format represents a big-endian FOURCC code, then "-BE"
> * suffix must be added.
Hmm. How about: "If the format represents a big-endian variant of a little
endian format, then the "-BE" suffix must be added. E.g. 'AR15' vs 'AR15-BE'."
BTW, using bit 31 for this is a complete V4L2-specific invention.
>
>>
>> Note that there can be spaces:
>>
>> #define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16
>> Greyscale */
>> #define V4L2_PIX_FMT_Y16_BE v4l2_fourcc_be('Y', '1', '6', ' ') /* 16
>> Greyscale BE */
>>
>> So that would be:
>>
>> /local/domain/1/device/vcamera/0/formats/Y16 /1200x720/frame-rates = "15/2"
>>
>> and:
>>
>> /local/domain/1/device/vcamera/0/formats/Y16 -BE/1200x720/frame-rates =
>> "15/2"
>>
>> Not sure if that will fly for you.
>>
>> Currently if there are spaced, then they are at the end, but I don't think
>> we can guarantee that for all time.
> This is a problem as I cannot have spaces...
> So, I can only put something like:
>
> * If FOURCC string label has spaces the
Re: [Xen-devel] [PATCH v2 1/1] cameraif: add ABI for para-virtual camera
On 09/12/2018 05:38 PM, Hans Verkuil wrote:
On 09/12/18 16:15, Oleksandr Andrushchenko wrote:
On 09/12/2018 04:38 PM, Hans Verkuil wrote:
On 09/12/18 15:02, Oleksandr Andrushchenko wrote:
On 09/12/2018 03:25 PM, Hans Verkuil wrote:
+ * formats
+ * Values:
+ *
+ * Formats are organized as a set of directories one per each
+ * supported pixel format. The name of the directory is the
+ * corresponding FOURCC string label. The next level of
+ * the directory under represents supported resolutions.
So how will this work for a pixelformat like V4L2_PIX_FMT_ARGB555X?
As mentioned before, we display such formats as '-BE', i.e. char[7].
ok, then I'll change this to char[7] and put a note on big-endian:
* If format represents a big-endian FOURCC code, then "-BE"
* suffix must be added, case insensitive.
Since the fourcc is case-sensitive, I'd keep -BE case sensitive as well.
Your decision, though.
hm, I'm a little bit confused here... One of the previous comments was...
>> + * Formats are organized as a set of directories one per each
>> + * supported pixel format. The name of the directory is an
upper case
>> + * string of the corresponding FOURCC string label. The next
level of
>> + * the directory under represents supported resolutions.
>Lower-case characters are also use in pixelformats, so I'd just keep
this as-is.
>
>In addition it is common to set bit 31 of the fourcc to 1 if the format is
>big-endian (see v4l2_fourcc_be macro). When v4l utilities print this
format we
>add a -BE suffix, so V4L2_PIX_FMT_ARGB555X becomes "AR15-BE". You
might want to
>keep that convention.
So, finally, I'll put upper case constraint here for fourcc and "-BE"?
Did I miss something here?
Easiest is to look at videodev2.h. Let me take two examples:
#define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16
ARGB-1-5-5-5 */
#define V4L2_PIX_FMT_ARGB555X v4l2_fourcc_be('A', 'R', '1', '5') /* 16
ARGB-5-5-5 BE */
The fourcc macros are defined as:
#define v4l2_fourcc(a, b, c, d)\
((__u32)(a) | ((__u32)(b) << 8) | ((__u32)(c) << 16) | ((__u32)(d) <<
24))
#define v4l2_fourcc_be(a, b, c, d) (v4l2_fourcc(a, b, c, d) | (1 << 31))
The characters can be any printable character, but currently we only use
a-z, A-Z, 0-9 and space (' ').
For big-endian formats we also set bit 31 (i.e. bit 7 of the last character)
to indicate this.
In our v4l2 utilities we use this function when we want to print a fourcc:
std::string fcc2s(__u32 val)
{
std::string s;
s += val & 0x7f;
s += (val >> 8) & 0x7f;
s += (val >> 16) & 0x7f;
s += (val >> 24) & 0x7f;
if (val & (1 << 31))
s += "-BE";
return s;
}
So the four characters (with bit 7 masked out) and the -BE suffix
if bit 7 was set for the fourth character.
So for your protocol, if you want to specify the fourcc, then I
assume dealing with characters with bit 7 set is a pain as well,
and in that case you are better off using the same scheme that we
do.
And to match the formats, applications should remember that the
string is case-sensitive, so 'abcd' != 'Abcd'.
Ah, got it, so I'll just make sure that "-BE" part
is case sensitive, e.g. remove "case insensitive":
* formats
* Values:
*
* Formats are organized as a set of directories one per each
* supported pixel format. The name of the directory is the
* corresponding FOURCC string label. The next level of
* the directory under represents supported resolutions.
* If format represents a big-endian FOURCC code, then "-BE"
* suffix must be added.
Hmm. How about: "If the format represents a big-endian variant of a little
endian format, then the "-BE" suffix must be added. E.g. 'AR15' vs 'AR15-BE'."
Sounds good, will use this, thank you
BTW, using bit 31 for this is a complete V4L2-specific invention.
Note that there can be spaces:
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale
*/
#define V4L2_PIX_FMT_Y16_BE v4l2_fourcc_be('Y', '1', '6', ' ') /* 16
Greyscale BE */
So that would be:
/local/domain/1/device/vcamera/0/formats/Y16 /1200x720/frame-rates = "15/2"
and:
/local/domain/1/device/vcamera/0/formats/Y16 -BE/1200x720/frame-rates = "15/2"
Not sure if that will fly for you.
Currently if there are spaced, then they are at the end, but I don't think
we can guarantee that for all time.
This is a problem as I cannot have spaces...
So, I can only put something like:
* If FOURCC string label has spaces then those are only allowed to
* be at the end of the label and must be trimmed.
I would recommend that you add comments to videodev2.h and the V4L2
specification
where you put down some requirements. E.g. spaces only at the end, characters
must
be in the range of 0x20-0x7f, and a list of
