[PATCH 1/3] xen/kbdif: Move multi-touch device parameters to backend nodes

[PATCH 1/3] xen/kbdif: Move multi-touch device parameters to backend nodes

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

In current kbdif protocol definition multi-touch device parameters
are described as a part of frontend's XenBus configuration nodes while
they belong to backend's configuration. Fix this by moving
the parameters to the proper section.

Fixes: b7a3ce49d528 ("xen/kbdif: add multi-touch support")

Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reported-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
Reviewed-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
---
 xen/include/public/io/kbdif.h | 38 +++++++++++++++++------------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index 23d1f70d5210..a68da0f1a37f 100644
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -96,6 +96,25 @@
  *      Maximum Y coordinate (height) to be used by the frontend
  *      while reporting input events, pixels, [0; UINT32_MAX].
  *
+ *----------------------- Multi-touch Device Parameters ----------------------
+ *
+ * multi-touch-num-contacts
+ *      Values:         <uint>
+ *
+ *      Number of simultaneous touches reported.
+ *
+ * multi-touch-width
+ *      Values:         <uint>
+ *
+ *      Width of the touch area to be used by the frontend
+ *      while reporting input events, pixels, [0; UINT32_MAX].
+ *
+ * multi-touch-height
+ *      Values:         <uint>
+ *
+ *      Height of the touch area to be used by the frontend
+ *      while reporting input events, pixels, [0; UINT32_MAX].
+ *
  *****************************************************************************
  *                            Frontend XenBus Nodes
  *****************************************************************************
@@ -143,25 +162,6 @@
  *
  *      OBSOLETE, not recommended for use.
  *      PFN of the shared page.
- *
- *----------------------- Multi-touch Device Parameters -----------------------
- *
- * multi-touch-num-contacts
- *      Values:         <uint>
- *
- *      Number of simultaneous touches reported.
- *
- * multi-touch-width
- *      Values:         <uint>
- *
- *      Width of the touch area to be used by the frontend
- *      while reporting input events, pixels, [0; UINT32_MAX].
- *
- * multi-touch-height
- *      Values:         <uint>
- *
- *      Height of the touch area to be used by the frontend
- *      while reporting input events, pixels, [0; UINT32_MAX].
  */
 
 /*
-- 
2.17.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 2/3] xen/kbdif: Add unique input device identifier

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

If frontend is configured to expose multiple input device instances
then backend may require a way to uniquely identify concrete input
device within the frontend. This is useful for use-cases where
virtual input device needs to be matched to physical input device.
Add XenBus "unique-id" node parameter, so this sort of use-cases can
be implemented.

Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
---
 xen/include/public/io/kbdif.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index a68da0f1a37f..45e4ff5b0a05 100644
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -82,6 +82,15 @@
  *      for pointer devices should set this to 1. Raw (unscaled) values have
  *      a range of [0, 0x7fff].
  *
+ *-----------------------  Device Instance Parameters ------------------------
+ *
+ * unique-id
+ *      Values:         <uint32_t>
+ *
+ *      After device instance initialization it is assigned a unique ID
+ *      (within the front driver), so every instance of the frontend can be
+ *      identified by the backend by this ID.
+ *
  *------------------------- Pointer Device Parameters ------------------------
  *
  * width
@@ -204,6 +213,7 @@
 #define XENKBD_FIELD_MT_WIDTH          "multi-touch-width"
 #define XENKBD_FIELD_MT_HEIGHT         "multi-touch-height"
 #define XENKBD_FIELD_MT_NUM_CONTACTS   "multi-touch-num-contacts"
+#define XENKBD_FIELD_UNIQUE_ID         "unique-id"
 
 /* OBSOLETE, not recommended for use */
 #define XENKBD_FIELD_RING_REF          "page-ref"
-- 
2.17.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 3/3] xen/displif: Add unique display connector identifier

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

If frontend is configured to expose multiple connectors then backend may
require a way to uniquely identify concrete virtual connector within the
frontend. This is useful for use-cases where connector needs to be
matched to physical display connector.
Add XenBus "unique-id" node parameter, so this sort of use-cases can
be implemented.

Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
---
 xen/include/public/io/displif.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h
index 8a94f1f9b9d0..78158f739cf5 100644
--- a/xen/include/public/io/displif.h
+++ b/xen/include/public/io/displif.h
@@ -189,6 +189,13 @@
  *
  *----------------------------- Connector settings ----------------------------
  *
+ * unique-id
+ *      Values:         <uint32_t>
+ *
+ *      After device instance initialization each connector is assigned a
+ *      unique ID (within the front driver), so it can be identified by the
+ *      backend by this ID.
+ *
  * resolution
  *      Values:         <width, uint32_t>x<height, uint32_t>
  *
@@ -368,6 +375,7 @@
 #define XENDISPL_FIELD_EVT_CHANNEL    "evt-event-channel"
 #define XENDISPL_FIELD_RESOLUTION     "resolution"
 #define XENDISPL_FIELD_BE_ALLOC       "be-alloc"
+#define XENDISPL_FIELD_UNIQUE_ID      "unique-id"
 
 /*
  ******************************************************************************
-- 
2.17.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 2/3] xen/kbdif: Add unique input device identifier

[Konrad Rzeszutek Wilk]

On Wed, May 23, 2018 at 09:19:22AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> 
> If frontend is configured to expose multiple input device instances
> then backend may require a way to uniquely identify concrete input
> device within the frontend. This is useful for use-cases where
> virtual input device needs to be matched to physical input device.
> Add XenBus "unique-id" node parameter, so this sort of use-cases can
> be implemented.
> 
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> ---
>  xen/include/public/io/kbdif.h | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> index a68da0f1a37f..45e4ff5b0a05 100644
> --- a/xen/include/public/io/kbdif.h
> +++ b/xen/include/public/io/kbdif.h
> @@ -82,6 +82,15 @@
>   *      for pointer devices should set this to 1. Raw (unscaled) values have
>   *      a range of [0, 0x7fff].
>   *
> + *-----------------------  Device Instance Parameters ------------------------
> + *
> + * unique-id
> + *      Values:         <uint32_t>

Wouldn't a string be easier? That way you can extend this in the future
to also have an UUID or so?

> + *
> + *      After device instance initialization it is assigned a unique ID
> + *      (within the front driver), so every instance of the frontend can be
> + *      identified by the backend by this ID.
> + *
>   *------------------------- Pointer Device Parameters ------------------------
>   *
>   * width
> @@ -204,6 +213,7 @@
>  #define XENKBD_FIELD_MT_WIDTH          "multi-touch-width"
>  #define XENKBD_FIELD_MT_HEIGHT         "multi-touch-height"
>  #define XENKBD_FIELD_MT_NUM_CONTACTS   "multi-touch-num-contacts"
> +#define XENKBD_FIELD_UNIQUE_ID         "unique-id"
>  
>  /* OBSOLETE, not recommended for use */
>  #define XENKBD_FIELD_RING_REF          "page-ref"
> -- 
> 2.17.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 3/3] xen/displif: Add unique display connector identifier

[Konrad Rzeszutek Wilk]

On Wed, May 23, 2018 at 09:19:23AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> 
> If frontend is configured to expose multiple connectors then backend may
> require a way to uniquely identify concrete virtual connector within the
> frontend. This is useful for use-cases where connector needs to be
> matched to physical display connector.
> Add XenBus "unique-id" node parameter, so this sort of use-cases can
> be implemented.
> 
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> ---
>  xen/include/public/io/displif.h | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h
> index 8a94f1f9b9d0..78158f739cf5 100644
> --- a/xen/include/public/io/displif.h
> +++ b/xen/include/public/io/displif.h
> @@ -189,6 +189,13 @@
>   *
>   *----------------------------- Connector settings ----------------------------
>   *
> + * unique-id
> + *      Values:         <uint32_t>

Ditto, perhaps an string instead?
> + *
> + *      After device instance initialization each connector is assigned a
> + *      unique ID (within the front driver), so it can be identified by the
> + *      backend by this ID.
> + *
>   * resolution
>   *      Values:         <width, uint32_t>x<height, uint32_t>
>   *
> @@ -368,6 +375,7 @@
>  #define XENDISPL_FIELD_EVT_CHANNEL    "evt-event-channel"
>  #define XENDISPL_FIELD_RESOLUTION     "resolution"
>  #define XENDISPL_FIELD_BE_ALLOC       "be-alloc"
> +#define XENDISPL_FIELD_UNIQUE_ID      "unique-id"
>  
>  /*
>   ******************************************************************************
> -- 
> 2.17.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 1/3] xen/kbdif: Move multi-touch device parameters to backend nodes

[Konrad Rzeszutek Wilk]

On Wed, May 23, 2018 at 09:19:21AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> 
> In current kbdif protocol definition multi-touch device parameters
> are described as a part of frontend's XenBus configuration nodes while
> they belong to backend's configuration. Fix this by moving
> the parameters to the proper section.
> 
> Fixes: b7a3ce49d528 ("xen/kbdif: add multi-touch support")
> 
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> Reported-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
> Reviewed-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Juergen, you OK if I check this in?

> ---
>  xen/include/public/io/kbdif.h | 38 +++++++++++++++++------------------
>  1 file changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> index 23d1f70d5210..a68da0f1a37f 100644
> --- a/xen/include/public/io/kbdif.h
> +++ b/xen/include/public/io/kbdif.h
> @@ -96,6 +96,25 @@
>   *      Maximum Y coordinate (height) to be used by the frontend
>   *      while reporting input events, pixels, [0; UINT32_MAX].
>   *
> + *----------------------- Multi-touch Device Parameters ----------------------
> + *
> + * multi-touch-num-contacts
> + *      Values:         <uint>
> + *
> + *      Number of simultaneous touches reported.
> + *
> + * multi-touch-width
> + *      Values:         <uint>
> + *
> + *      Width of the touch area to be used by the frontend
> + *      while reporting input events, pixels, [0; UINT32_MAX].
> + *
> + * multi-touch-height
> + *      Values:         <uint>
> + *
> + *      Height of the touch area to be used by the frontend
> + *      while reporting input events, pixels, [0; UINT32_MAX].
> + *
>   *****************************************************************************
>   *                            Frontend XenBus Nodes
>   *****************************************************************************
> @@ -143,25 +162,6 @@
>   *
>   *      OBSOLETE, not recommended for use.
>   *      PFN of the shared page.
> - *
> - *----------------------- Multi-touch Device Parameters -----------------------
> - *
> - * multi-touch-num-contacts
> - *      Values:         <uint>
> - *
> - *      Number of simultaneous touches reported.
> - *
> - * multi-touch-width
> - *      Values:         <uint>
> - *
> - *      Width of the touch area to be used by the frontend
> - *      while reporting input events, pixels, [0; UINT32_MAX].
> - *
> - * multi-touch-height
> - *      Values:         <uint>
> - *
> - *      Height of the touch area to be used by the frontend
> - *      while reporting input events, pixels, [0; UINT32_MAX].
>   */
>  
>  /*
> -- 
> 2.17.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 2/3] xen/kbdif: Add unique input device identifier

[Oleksandr Andrushchenko]

On 06/07/2018 04:28 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, May 23, 2018 at 09:19:22AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>
>> If frontend is configured to expose multiple input device instances
>> then backend may require a way to uniquely identify concrete input
>> device within the frontend. This is useful for use-cases where
>> virtual input device needs to be matched to physical input device.
>> Add XenBus "unique-id" node parameter, so this sort of use-cases can
>> be implemented.
>>
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>> ---
>>   xen/include/public/io/kbdif.h | 10 ++++++++++
>>   1 file changed, 10 insertions(+)
>>
>> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
>> index a68da0f1a37f..45e4ff5b0a05 100644
>> --- a/xen/include/public/io/kbdif.h
>> +++ b/xen/include/public/io/kbdif.h
>> @@ -82,6 +82,15 @@
>>    *      for pointer devices should set this to 1. Raw (unscaled) values have
>>    *      a range of [0, 0x7fff].
>>    *
>> + *-----------------------  Device Instance Parameters ------------------------
>> + *
>> + * unique-id
>> + *      Values:         <uint32_t>
> Wouldn't a string be easier? That way you can extend this in the future
> to also have an UUID or so?
Much easier. We were thinking about that as well, but sndif already has it
as uint32_t. If you are ok to change uniquie-id for sndif to string then 
that
would be much better: UUID as you mention + all protocols have unique-id
consistently defined as string.
sndif's unique-id is not used by the frontend driver and we are about
to start libx/xl support for sound, so I think this is the right time for
such a change.
If you are fine with that then I'll send yet another patch for sndif.
>> + *
>> + *      After device instance initialization it is assigned a unique ID
>> + *      (within the front driver), so every instance of the frontend can be
>> + *      identified by the backend by this ID.
>> + *
>>    *------------------------- Pointer Device Parameters ------------------------
>>    *
>>    * width
>> @@ -204,6 +213,7 @@
>>   #define XENKBD_FIELD_MT_WIDTH          "multi-touch-width"
>>   #define XENKBD_FIELD_MT_HEIGHT         "multi-touch-height"
>>   #define XENKBD_FIELD_MT_NUM_CONTACTS   "multi-touch-num-contacts"
>> +#define XENKBD_FIELD_UNIQUE_ID         "unique-id"
>>   
>>   /* OBSOLETE, not recommended for use */
>>   #define XENKBD_FIELD_RING_REF          "page-ref"
>> -- 
>> 2.17.0
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 3/3] xen/displif: Add unique display connector identifier

[Oleksandr Andrushchenko]

On 06/07/2018 04:29 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, May 23, 2018 at 09:19:23AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>
>> If frontend is configured to expose multiple connectors then backend may
>> require a way to uniquely identify concrete virtual connector within the
>> frontend. This is useful for use-cases where connector needs to be
>> matched to physical display connector.
>> Add XenBus "unique-id" node parameter, so this sort of use-cases can
>> be implemented.
>>
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>> ---
>>   xen/include/public/io/displif.h | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h
>> index 8a94f1f9b9d0..78158f739cf5 100644
>> --- a/xen/include/public/io/displif.h
>> +++ b/xen/include/public/io/displif.h
>> @@ -189,6 +189,13 @@
>>    *
>>    *----------------------------- Connector settings ----------------------------
>>    *
>> + * unique-id
>> + *      Values:         <uint32_t>
> Ditto, perhaps an string instead?
Ditto ;)
String is way better, but we have to decide if we want to be consistent 
with sndif
>> + *
>> + *      After device instance initialization each connector is assigned a
>> + *      unique ID (within the front driver), so it can be identified by the
>> + *      backend by this ID.
>> + *
>>    * resolution
>>    *      Values:         <width, uint32_t>x<height, uint32_t>
>>    *
>> @@ -368,6 +375,7 @@
>>   #define XENDISPL_FIELD_EVT_CHANNEL    "evt-event-channel"
>>   #define XENDISPL_FIELD_RESOLUTION     "resolution"
>>   #define XENDISPL_FIELD_BE_ALLOC       "be-alloc"
>> +#define XENDISPL_FIELD_UNIQUE_ID      "unique-id"
>>   
>>   /*
>>    ******************************************************************************
>> -- 
>> 2.17.0
>>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 1/3] xen/kbdif: Move multi-touch device parameters to backend nodes

[Juergen Gross]

On 07/06/18 15:29, Konrad Rzeszutek Wilk wrote:
> On Wed, May 23, 2018 at 09:19:21AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>
>> In current kbdif protocol definition multi-touch device parameters
>> are described as a part of frontend's XenBus configuration nodes while
>> they belong to backend's configuration. Fix this by moving
>> the parameters to the proper section.
>>
>> Fixes: b7a3ce49d528 ("xen/kbdif: add multi-touch support")
>>
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>> Reported-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
>> Reviewed-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Juergen, you OK if I check this in?

Looking at the changes tehy seem to be low risk. ;-)

Release-acked-by: Juergen Gross <jgross@suse.com>


Juergen

> 
>> ---
>>  xen/include/public/io/kbdif.h | 38 +++++++++++++++++------------------
>>  1 file changed, 19 insertions(+), 19 deletions(-)
>>
>> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
>> index 23d1f70d5210..a68da0f1a37f 100644
>> --- a/xen/include/public/io/kbdif.h
>> +++ b/xen/include/public/io/kbdif.h
>> @@ -96,6 +96,25 @@
>>   *      Maximum Y coordinate (height) to be used by the frontend
>>   *      while reporting input events, pixels, [0; UINT32_MAX].
>>   *
>> + *----------------------- Multi-touch Device Parameters ----------------------
>> + *
>> + * multi-touch-num-contacts
>> + *      Values:         <uint>
>> + *
>> + *      Number of simultaneous touches reported.
>> + *
>> + * multi-touch-width
>> + *      Values:         <uint>
>> + *
>> + *      Width of the touch area to be used by the frontend
>> + *      while reporting input events, pixels, [0; UINT32_MAX].
>> + *
>> + * multi-touch-height
>> + *      Values:         <uint>
>> + *
>> + *      Height of the touch area to be used by the frontend
>> + *      while reporting input events, pixels, [0; UINT32_MAX].
>> + *
>>   *****************************************************************************
>>   *                            Frontend XenBus Nodes
>>   *****************************************************************************
>> @@ -143,25 +162,6 @@
>>   *
>>   *      OBSOLETE, not recommended for use.
>>   *      PFN of the shared page.
>> - *
>> - *----------------------- Multi-touch Device Parameters -----------------------
>> - *
>> - * multi-touch-num-contacts
>> - *      Values:         <uint>
>> - *
>> - *      Number of simultaneous touches reported.
>> - *
>> - * multi-touch-width
>> - *      Values:         <uint>
>> - *
>> - *      Width of the touch area to be used by the frontend
>> - *      while reporting input events, pixels, [0; UINT32_MAX].
>> - *
>> - * multi-touch-height
>> - *      Values:         <uint>
>> - *
>> - *      Height of the touch area to be used by the frontend
>> - *      while reporting input events, pixels, [0; UINT32_MAX].
>>   */
>>  
>>  /*
>> -- 
>> 2.17.0
>>
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 2/3] xen/kbdif: Add unique input device identifier

[Konrad Rzeszutek Wilk]

On Thu, Jun 07, 2018 at 04:40:48PM +0300, Oleksandr Andrushchenko wrote:
> On 06/07/2018 04:28 PM, Konrad Rzeszutek Wilk wrote:
> > On Wed, May 23, 2018 at 09:19:22AM +0300, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> > > 
> > > If frontend is configured to expose multiple input device instances
> > > then backend may require a way to uniquely identify concrete input
> > > device within the frontend. This is useful for use-cases where
> > > virtual input device needs to be matched to physical input device.
> > > Add XenBus "unique-id" node parameter, so this sort of use-cases can
> > > be implemented.
> > > 
> > > Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> > > ---
> > >   xen/include/public/io/kbdif.h | 10 ++++++++++
> > >   1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> > > index a68da0f1a37f..45e4ff5b0a05 100644
> > > --- a/xen/include/public/io/kbdif.h
> > > +++ b/xen/include/public/io/kbdif.h
> > > @@ -82,6 +82,15 @@
> > >    *      for pointer devices should set this to 1. Raw (unscaled) values have
> > >    *      a range of [0, 0x7fff].
> > >    *
> > > + *-----------------------  Device Instance Parameters ------------------------
> > > + *
> > > + * unique-id
> > > + *      Values:         <uint32_t>
> > Wouldn't a string be easier? That way you can extend this in the future
> > to also have an UUID or so?
> Much easier. We were thinking about that as well, but sndif already has it
> as uint32_t. If you are ok to change uniquie-id for sndif to string then
> that
> would be much better: UUID as you mention + all protocols have unique-id
> consistently defined as string.
> sndif's unique-id is not used by the frontend driver and we are about
> to start libx/xl support for sound, so I think this is the right time for
> such a change.
> If you are fine with that then I'll send yet another patch for sndif.

Please do and feel free to add 

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

on it.

Also pls CC Juergen so he can release-ack it.
> > > + *
> > > + *      After device instance initialization it is assigned a unique ID
> > > + *      (within the front driver), so every instance of the frontend can be
> > > + *      identified by the backend by this ID.
> > > + *
> > >    *------------------------- Pointer Device Parameters ------------------------
> > >    *
> > >    * width
> > > @@ -204,6 +213,7 @@
> > >   #define XENKBD_FIELD_MT_WIDTH          "multi-touch-width"
> > >   #define XENKBD_FIELD_MT_HEIGHT         "multi-touch-height"
> > >   #define XENKBD_FIELD_MT_NUM_CONTACTS   "multi-touch-num-contacts"
> > > +#define XENKBD_FIELD_UNIQUE_ID         "unique-id"
> > >   /* OBSOLETE, not recommended for use */
> > >   #define XENKBD_FIELD_RING_REF          "page-ref"
> > > -- 
> > > 2.17.0
> > > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 2/3] xen/kbdif: Add unique input device identifier

[Oleksandr Andrushchenko]

On 06/07/2018 06:47 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 07, 2018 at 04:40:48PM +0300, Oleksandr Andrushchenko wrote:
>> On 06/07/2018 04:28 PM, Konrad Rzeszutek Wilk wrote:
>>> On Wed, May 23, 2018 at 09:19:22AM +0300, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>
>>>> If frontend is configured to expose multiple input device instances
>>>> then backend may require a way to uniquely identify concrete input
>>>> device within the frontend. This is useful for use-cases where
>>>> virtual input device needs to be matched to physical input device.
>>>> Add XenBus "unique-id" node parameter, so this sort of use-cases can
>>>> be implemented.
>>>>
>>>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>> ---
>>>>    xen/include/public/io/kbdif.h | 10 ++++++++++
>>>>    1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
>>>> index a68da0f1a37f..45e4ff5b0a05 100644
>>>> --- a/xen/include/public/io/kbdif.h
>>>> +++ b/xen/include/public/io/kbdif.h
>>>> @@ -82,6 +82,15 @@
>>>>     *      for pointer devices should set this to 1. Raw (unscaled) values have
>>>>     *      a range of [0, 0x7fff].
>>>>     *
>>>> + *-----------------------  Device Instance Parameters ------------------------
>>>> + *
>>>> + * unique-id
>>>> + *      Values:         <uint32_t>
>>> Wouldn't a string be easier? That way you can extend this in the future
>>> to also have an UUID or so?
>> Much easier. We were thinking about that as well, but sndif already has it
>> as uint32_t. If you are ok to change uniquie-id for sndif to string then
>> that
>> would be much better: UUID as you mention + all protocols have unique-id
>> consistently defined as string.
>> sndif's unique-id is not used by the frontend driver and we are about
>> to start libx/xl support for sound, so I think this is the right time for
>> such a change.
>> If you are fine with that then I'll send yet another patch for sndif.
> Please do and feel free to add
>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> on it.
>
> Also pls CC Juergen so he can release-ack it.
Thank you
>>>> + *
>>>> + *      After device instance initialization it is assigned a unique ID
>>>> + *      (within the front driver), so every instance of the frontend can be
>>>> + *      identified by the backend by this ID.
>>>> + *
>>>>     *------------------------- Pointer Device Parameters ------------------------
>>>>     *
>>>>     * width
>>>> @@ -204,6 +213,7 @@
>>>>    #define XENKBD_FIELD_MT_WIDTH          "multi-touch-width"
>>>>    #define XENKBD_FIELD_MT_HEIGHT         "multi-touch-height"
>>>>    #define XENKBD_FIELD_MT_NUM_CONTACTS   "multi-touch-num-contacts"
>>>> +#define XENKBD_FIELD_UNIQUE_ID         "unique-id"
>>>>    /* OBSOLETE, not recommended for use */
>>>>    #define XENKBD_FIELD_RING_REF          "page-ref"
>>>> -- 
>>>> 2.17.0
>>>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel