[PATCH 0/2] xen/input: add multi-touch support

[PATCH 0/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

Hi, all!

This patch series updates existing Xen vkbd frontend driver
to use string constants from the corresponding IO protocol
(kbdif.h) and adds support for virtual multi-touch input device.

This has been tested on a guest running Weston.

This patch series depends on:
https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=linux-next&id=16b3087654b8565ae14c23ac3797e5f60ba0b13d
https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=linux-next&id=edd5bdb7b06fd1a0c68b6f39b2c776368eba00c8
https://lkml.org/lkml/2017/4/11/352

Thank you,
Oleksandr Andrushchenko

Oleksandr Andrushchenko (2):
  xen/input: use string constants from PV protocol
  xen/input: add multi-touch support

 drivers/input/misc/xen-kbdfront.c | 164 +++++++++++++++++++++++++++++++++++---
 1 file changed, 153 insertions(+), 11 deletions(-)

-- 
2.7.4

[PATCH 1/2] xen/input: use string constants from PV protocol

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

Xen input para-virtual protocol defines string constants
used by both back and frontend. Use those instead of
explicit strings in the frontend driver.

Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
---
 drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index 2fc7895373ab..01c27b4c3288 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
 		goto error_nomem;
 
 	/* Set input abs params to match backend screen res */
-	abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
-	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+	abs = xenbus_read_unsigned(dev->otherend,
+				   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+						  XENKBD_FIELD_WIDTH,
 						  ptr_size[KPARAM_X]);
-	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
+	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+						  XENKBD_FIELD_HEIGHT,
 						  ptr_size[KPARAM_Y]);
 	if (abs) {
 		ret = xenbus_write(XBT_NIL, dev->nodename,
-				   "request-abs-pointer", "1");
+				   XENKBD_FIELD_REQ_ABS_POINTER, "1");
 		if (ret) {
 			pr_warning("xenkbd: can't request abs-pointer");
 			abs = 0;
@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct xenbus_device *dev,
 		xenbus_dev_fatal(dev, ret, "starting transaction");
 		goto error_irqh;
 	}
-	ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, "%lu",
 			    virt_to_gfn(info->page));
 	if (ret)
 		goto error_xenbus;
-	ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", info->gref);
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+			    "%u", info->gref);
 	if (ret)
 		goto error_xenbus;
-	ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_EVT_CHANNEL, "%u",
 			    evtchn);
 	if (ret)
 		goto error_xenbus;
@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
 }
 
 static const struct xenbus_device_id xenkbd_ids[] = {
-	{ "vkbd" },
+	{ XENKBD_DRIVER_NAME },
 	{ "" }
 };
 
@@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
 
 MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");
 MODULE_LICENSE("GPL");
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
-- 
2.7.4

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

[Dmitry Torokhov]

On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> 
> Xen input para-virtual protocol defines string constants
> used by both back and frontend. Use those instead of
> explicit strings in the frontend driver.
> 
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

I'll have to postpone it until I receive changes containing these new
string constants. Otherwise it looks OK.

> ---
>  drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> index 2fc7895373ab..01c27b4c3288 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
>  		goto error_nomem;
>  
>  	/* Set input abs params to match backend screen res */
> -	abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
> -	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
> +	abs = xenbus_read_unsigned(dev->otherend,
> +				   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
> +	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
> +						  XENKBD_FIELD_WIDTH,
>  						  ptr_size[KPARAM_X]);
> -	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
> +	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
> +						  XENKBD_FIELD_HEIGHT,
>  						  ptr_size[KPARAM_Y]);
>  	if (abs) {
>  		ret = xenbus_write(XBT_NIL, dev->nodename,
> -				   "request-abs-pointer", "1");
> +				   XENKBD_FIELD_REQ_ABS_POINTER, "1");
>  		if (ret) {
>  			pr_warning("xenkbd: can't request abs-pointer");
>  			abs = 0;
> @@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct xenbus_device *dev,
>  		xenbus_dev_fatal(dev, ret, "starting transaction");
>  		goto error_irqh;
>  	}
> -	ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
> +	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, "%lu",
>  			    virt_to_gfn(info->page));
>  	if (ret)
>  		goto error_xenbus;
> -	ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", info->gref);
> +	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
> +			    "%u", info->gref);
>  	if (ret)
>  		goto error_xenbus;
> -	ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
> +	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_EVT_CHANNEL, "%u",
>  			    evtchn);
>  	if (ret)
>  		goto error_xenbus;
> @@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
>  }
>  
>  static const struct xenbus_device_id xenkbd_ids[] = {
> -	{ "vkbd" },
> +	{ XENKBD_DRIVER_NAME },
>  	{ "" }
>  };
>  
> @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
>  
>  MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");
>  MODULE_LICENSE("GPL");
> -MODULE_ALIAS("xen:vkbd");
> +MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
> -- 
> 2.7.4
> 

-- 
Dmitry

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

[Oleksandr Andrushchenko]

On 04/21/2017 05:11 AM, Dmitry Torokhov wrote:
> On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>
>> Xen input para-virtual protocol defines string constants
>> used by both back and frontend. Use those instead of
>> explicit strings in the frontend driver.
>>
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> I'll have to postpone it until I receive changes containing these new
> string constants.
fair enough
>   Otherwise it looks OK.
thank you
>> ---
>>   drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
>>   1 file changed, 13 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
>> index 2fc7895373ab..01c27b4c3288 100644
>> --- a/drivers/input/misc/xen-kbdfront.c
>> +++ b/drivers/input/misc/xen-kbdfront.c
>> @@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>   		goto error_nomem;
>>   
>>   	/* Set input abs params to match backend screen res */
>> -	abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
>> -	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
>> +	abs = xenbus_read_unsigned(dev->otherend,
>> +				   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
>> +	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
>> +						  XENKBD_FIELD_WIDTH,
>>   						  ptr_size[KPARAM_X]);
>> -	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
>> +	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
>> +						  XENKBD_FIELD_HEIGHT,
>>   						  ptr_size[KPARAM_Y]);
>>   	if (abs) {
>>   		ret = xenbus_write(XBT_NIL, dev->nodename,
>> -				   "request-abs-pointer", "1");
>> +				   XENKBD_FIELD_REQ_ABS_POINTER, "1");
>>   		if (ret) {
>>   			pr_warning("xenkbd: can't request abs-pointer");
>>   			abs = 0;
>> @@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct xenbus_device *dev,
>>   		xenbus_dev_fatal(dev, ret, "starting transaction");
>>   		goto error_irqh;
>>   	}
>> -	ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
>> +	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, "%lu",
>>   			    virt_to_gfn(info->page));
>>   	if (ret)
>>   		goto error_xenbus;
>> -	ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", info->gref);
>> +	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
>> +			    "%u", info->gref);
>>   	if (ret)
>>   		goto error_xenbus;
>> -	ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
>> +	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_EVT_CHANNEL, "%u",
>>   			    evtchn);
>>   	if (ret)
>>   		goto error_xenbus;
>> @@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
>>   }
>>   
>>   static const struct xenbus_device_id xenkbd_ids[] = {
>> -	{ "vkbd" },
>> +	{ XENKBD_DRIVER_NAME },
>>   	{ "" }
>>   };
>>   
>> @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
>>   
>>   MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");
>>   MODULE_LICENSE("GPL");
>> -MODULE_ALIAS("xen:vkbd");
>> +MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
>> -- 
>> 2.7.4
>>
Thank you,
Oleksandr

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

[Oleksandr Andrushchenko]

Hello, Dmitry!
On 04/21/2017 09:42 AM, Oleksandr Andrushchenko wrote:
> On 04/21/2017 05:11 AM, Dmitry Torokhov wrote:
>> On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>
>>> Xen input para-virtual protocol defines string constants
>>> used by both back and frontend. Use those instead of
>>> explicit strings in the frontend driver.
>>>
>>> Signed-off-by: Oleksandr Andrushchenko 
>>> <oleksandr_andrushchenko@epam.com>
>> I'll have to postpone it until I receive changes containing these new
>> string constants.
> fair enough
>>   Otherwise it looks OK.
> thank you
As all the dependencies are now merged into the kernel,
can we please proceed with this patch?

>>>   drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
>>>   1 file changed, 13 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/input/misc/xen-kbdfront.c 
>>> b/drivers/input/misc/xen-kbdfront.c
>>> index 2fc7895373ab..01c27b4c3288 100644
>>> --- a/drivers/input/misc/xen-kbdfront.c
>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>> @@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device 
>>> *dev,
>>>           goto error_nomem;
>>>         /* Set input abs params to match backend screen res */
>>> -    abs = xenbus_read_unsigned(dev->otherend, 
>>> "feature-abs-pointer", 0);
>>> -    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
>>> +    abs = xenbus_read_unsigned(dev->otherend,
>>> +                   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
>>> +    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
>>> +                          XENKBD_FIELD_WIDTH,
>>>                             ptr_size[KPARAM_X]);
>>> -    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
>>> +    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
>>> +                          XENKBD_FIELD_HEIGHT,
>>>                             ptr_size[KPARAM_Y]);
>>>       if (abs) {
>>>           ret = xenbus_write(XBT_NIL, dev->nodename,
>>> -                   "request-abs-pointer", "1");
>>> +                   XENKBD_FIELD_REQ_ABS_POINTER, "1");
>>>           if (ret) {
>>>               pr_warning("xenkbd: can't request abs-pointer");
>>>               abs = 0;
>>> @@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct 
>>> xenbus_device *dev,
>>>           xenbus_dev_fatal(dev, ret, "starting transaction");
>>>           goto error_irqh;
>>>       }
>>> -    ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
>>> +    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, 
>>> "%lu",
>>>                   virt_to_gfn(info->page));
>>>       if (ret)
>>>           goto error_xenbus;
>>> -    ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", 
>>> info->gref);
>>> +    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
>>> +                "%u", info->gref);
>>>       if (ret)
>>>           goto error_xenbus;
>>> -    ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
>>> +    ret = xenbus_printf(xbt, dev->nodename, 
>>> XENKBD_FIELD_EVT_CHANNEL, "%u",
>>>                   evtchn);
>>>       if (ret)
>>>           goto error_xenbus;
>>> @@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct 
>>> xenbus_device *dev,
>>>   }
>>>     static const struct xenbus_device_id xenkbd_ids[] = {
>>> -    { "vkbd" },
>>> +    { XENKBD_DRIVER_NAME },
>>>       { "" }
>>>   };
>>>   @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
>>>     MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");
>>>   MODULE_LICENSE("GPL");
>>> -MODULE_ALIAS("xen:vkbd");
>>> +MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
>>> -- 
>>> 2.7.4
>>>
> Thank you,
> Oleksandr
Thank you,
Oleksandr

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

[Oleksandr Andrushchenko]

gentle reminder


On 05/05/2017 07:43 AM, Oleksandr Andrushchenko wrote:
> Hello, Dmitry!
> On 04/21/2017 09:42 AM, Oleksandr Andrushchenko wrote:
>> On 04/21/2017 05:11 AM, Dmitry Torokhov wrote:
>>> On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko 
>>> wrote:
>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>
>>>> Xen input para-virtual protocol defines string constants
>>>> used by both back and frontend. Use those instead of
>>>> explicit strings in the frontend driver.
>>>>
>>>> Signed-off-by: Oleksandr Andrushchenko 
>>>> <oleksandr_andrushchenko@epam.com>
>>> I'll have to postpone it until I receive changes containing these new
>>> string constants.
>> fair enough
>>>   Otherwise it looks OK.
>> thank you
> As all the dependencies are now merged into the kernel,
> can we please proceed with this patch?
>
>>>>   drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
>>>>   1 file changed, 13 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/drivers/input/misc/xen-kbdfront.c 
>>>> b/drivers/input/misc/xen-kbdfront.c
>>>> index 2fc7895373ab..01c27b4c3288 100644
>>>> --- a/drivers/input/misc/xen-kbdfront.c
>>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>>> @@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device 
>>>> *dev,
>>>>           goto error_nomem;
>>>>         /* Set input abs params to match backend screen res */
>>>> -    abs = xenbus_read_unsigned(dev->otherend, 
>>>> "feature-abs-pointer", 0);
>>>> -    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
>>>> +    abs = xenbus_read_unsigned(dev->otherend,
>>>> +                   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
>>>> +    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
>>>> +                          XENKBD_FIELD_WIDTH,
>>>>                             ptr_size[KPARAM_X]);
>>>> -    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, 
>>>> "height",
>>>> +    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
>>>> +                          XENKBD_FIELD_HEIGHT,
>>>>                             ptr_size[KPARAM_Y]);
>>>>       if (abs) {
>>>>           ret = xenbus_write(XBT_NIL, dev->nodename,
>>>> -                   "request-abs-pointer", "1");
>>>> +                   XENKBD_FIELD_REQ_ABS_POINTER, "1");
>>>>           if (ret) {
>>>>               pr_warning("xenkbd: can't request abs-pointer");
>>>>               abs = 0;
>>>> @@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct 
>>>> xenbus_device *dev,
>>>>           xenbus_dev_fatal(dev, ret, "starting transaction");
>>>>           goto error_irqh;
>>>>       }
>>>> -    ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
>>>> +    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, 
>>>> "%lu",
>>>>                   virt_to_gfn(info->page));
>>>>       if (ret)
>>>>           goto error_xenbus;
>>>> -    ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", 
>>>> info->gref);
>>>> +    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
>>>> +                "%u", info->gref);
>>>>       if (ret)
>>>>           goto error_xenbus;
>>>> -    ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
>>>> +    ret = xenbus_printf(xbt, dev->nodename, 
>>>> XENKBD_FIELD_EVT_CHANNEL, "%u",
>>>>                   evtchn);
>>>>       if (ret)
>>>>           goto error_xenbus;
>>>> @@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct 
>>>> xenbus_device *dev,
>>>>   }
>>>>     static const struct xenbus_device_id xenkbd_ids[] = {
>>>> -    { "vkbd" },
>>>> +    { XENKBD_DRIVER_NAME },
>>>>       { "" }
>>>>   };
>>>>   @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
>>>>     MODULE_DESCRIPTION("Xen virtual keyboard/pointer device 
>>>> frontend");
>>>>   MODULE_LICENSE("GPL");
>>>> -MODULE_ALIAS("xen:vkbd");
>>>> +MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
>>>> -- 
>>>> 2.7.4
>>>>
>> Thank you,
>> Oleksandr
> Thank you,
> Oleksandr

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

[Oleksandr Andrushchenko]

Hi, Dmitry!

It's been quite a while now, I'm just wondering if
you had a chance to look at the patch?

Thank you,
Oleksandr

On 05/12/2017 04:43 PM, Oleksandr Andrushchenko wrote:
> gentle reminder
>
>
> On 05/05/2017 07:43 AM, Oleksandr Andrushchenko wrote:
>> Hello, Dmitry!
>> On 04/21/2017 09:42 AM, Oleksandr Andrushchenko wrote:
>>> On 04/21/2017 05:11 AM, Dmitry Torokhov wrote:
>>>> On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko 
>>>> wrote:
>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>
>>>>> Xen input para-virtual protocol defines string constants
>>>>> used by both back and frontend. Use those instead of
>>>>> explicit strings in the frontend driver.
>>>>>
>>>>> Signed-off-by: Oleksandr Andrushchenko 
>>>>> <oleksandr_andrushchenko@epam.com>
>>>> I'll have to postpone it until I receive changes containing these new
>>>> string constants.
>>> fair enough
>>>>   Otherwise it looks OK.
>>> thank you
>> As all the dependencies are now merged into the kernel,
>> can we please proceed with this patch?
>>
>>>>>   drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
>>>>>   1 file changed, 13 insertions(+), 9 deletions(-)
>>>>>
>>>>> diff --git a/drivers/input/misc/xen-kbdfront.c 
>>>>> b/drivers/input/misc/xen-kbdfront.c
>>>>> index 2fc7895373ab..01c27b4c3288 100644
>>>>> --- a/drivers/input/misc/xen-kbdfront.c
>>>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>>>> @@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device 
>>>>> *dev,
>>>>>           goto error_nomem;
>>>>>         /* Set input abs params to match backend screen res */
>>>>> -    abs = xenbus_read_unsigned(dev->otherend, 
>>>>> "feature-abs-pointer", 0);
>>>>> -    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, 
>>>>> "width",
>>>>> +    abs = xenbus_read_unsigned(dev->otherend,
>>>>> +                   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
>>>>> +    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
>>>>> +                          XENKBD_FIELD_WIDTH,
>>>>>                             ptr_size[KPARAM_X]);
>>>>> -    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, 
>>>>> "height",
>>>>> +    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
>>>>> +                          XENKBD_FIELD_HEIGHT,
>>>>>                             ptr_size[KPARAM_Y]);
>>>>>       if (abs) {
>>>>>           ret = xenbus_write(XBT_NIL, dev->nodename,
>>>>> -                   "request-abs-pointer", "1");
>>>>> +                   XENKBD_FIELD_REQ_ABS_POINTER, "1");
>>>>>           if (ret) {
>>>>>               pr_warning("xenkbd: can't request abs-pointer");
>>>>>               abs = 0;
>>>>> @@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct 
>>>>> xenbus_device *dev,
>>>>>           xenbus_dev_fatal(dev, ret, "starting transaction");
>>>>>           goto error_irqh;
>>>>>       }
>>>>> -    ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
>>>>> +    ret = xenbus_printf(xbt, dev->nodename, 
>>>>> XENKBD_FIELD_RING_REF, "%lu",
>>>>>                   virt_to_gfn(info->page));
>>>>>       if (ret)
>>>>>           goto error_xenbus;
>>>>> -    ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", 
>>>>> info->gref);
>>>>> +    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
>>>>> +                "%u", info->gref);
>>>>>       if (ret)
>>>>>           goto error_xenbus;
>>>>> -    ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
>>>>> +    ret = xenbus_printf(xbt, dev->nodename, 
>>>>> XENKBD_FIELD_EVT_CHANNEL, "%u",
>>>>>                   evtchn);
>>>>>       if (ret)
>>>>>           goto error_xenbus;
>>>>> @@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct 
>>>>> xenbus_device *dev,
>>>>>   }
>>>>>     static const struct xenbus_device_id xenkbd_ids[] = {
>>>>> -    { "vkbd" },
>>>>> +    { XENKBD_DRIVER_NAME },
>>>>>       { "" }
>>>>>   };
>>>>>   @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
>>>>>     MODULE_DESCRIPTION("Xen virtual keyboard/pointer device 
>>>>> frontend");
>>>>>   MODULE_LICENSE("GPL");
>>>>> -MODULE_ALIAS("xen:vkbd");
>>>>> +MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
>>>>> -- 
>>>>> 2.7.4
>>>>>
>>> Thank you,
>>> Oleksandr
>> Thank you,
>> Oleksandr
>

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

[Oleksandr Andrushchenko]

Hi, Dmitry!

On 04/21/2017 05:11 AM, Dmitry Torokhov wrote:
> On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>
>> Xen input para-virtual protocol defines string constants
>> used by both back and frontend. Use those instead of
>> explicit strings in the frontend driver.
>>
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> I'll have to postpone it until I receive changes containing these new
> string constants. Otherwise it looks OK.
May I put your "Reviewed-by" for this change?
>
>> ---
>>   drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
>>   1 file changed, 13 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
>> index 2fc7895373ab..01c27b4c3288 100644
>> --- a/drivers/input/misc/xen-kbdfront.c
>> +++ b/drivers/input/misc/xen-kbdfront.c
>> @@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>   		goto error_nomem;
>>   
>>   	/* Set input abs params to match backend screen res */
>> -	abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
>> -	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
>> +	abs = xenbus_read_unsigned(dev->otherend,
>> +				   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
>> +	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
>> +						  XENKBD_FIELD_WIDTH,
>>   						  ptr_size[KPARAM_X]);
>> -	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
>> +	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
>> +						  XENKBD_FIELD_HEIGHT,
>>   						  ptr_size[KPARAM_Y]);
>>   	if (abs) {
>>   		ret = xenbus_write(XBT_NIL, dev->nodename,
>> -				   "request-abs-pointer", "1");
>> +				   XENKBD_FIELD_REQ_ABS_POINTER, "1");
>>   		if (ret) {
>>   			pr_warning("xenkbd: can't request abs-pointer");
>>   			abs = 0;
>> @@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct xenbus_device *dev,
>>   		xenbus_dev_fatal(dev, ret, "starting transaction");
>>   		goto error_irqh;
>>   	}
>> -	ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
>> +	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, "%lu",
>>   			    virt_to_gfn(info->page));
>>   	if (ret)
>>   		goto error_xenbus;
>> -	ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", info->gref);
>> +	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
>> +			    "%u", info->gref);
>>   	if (ret)
>>   		goto error_xenbus;
>> -	ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
>> +	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_EVT_CHANNEL, "%u",
>>   			    evtchn);
>>   	if (ret)
>>   		goto error_xenbus;
>> @@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
>>   }
>>   
>>   static const struct xenbus_device_id xenkbd_ids[] = {
>> -	{ "vkbd" },
>> +	{ XENKBD_DRIVER_NAME },
>>   	{ "" }
>>   };
>>   
>> @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
>>   
>>   MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");
>>   MODULE_LICENSE("GPL");
>> -MODULE_ALIAS("xen:vkbd");
>> +MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
>> -- 
>> 2.7.4
>>
Thank you,
Oleksandr

[PATCH 2/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

Extend xen_kbdfront to provide multi-touch support
to unprivileged domains.

Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
---
 drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 140 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index 01c27b4c3288..e5d064aaa237 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -17,6 +17,7 @@
 #include <linux/errno.h>
 #include <linux/module.h>
 #include <linux/input.h>
+#include <linux/input/mt.h>
 #include <linux/slab.h>
 
 #include <asm/xen/hypervisor.h>
@@ -34,11 +35,14 @@
 struct xenkbd_info {
 	struct input_dev *kbd;
 	struct input_dev *ptr;
+	struct input_dev *mtouch;
 	struct xenkbd_page *page;
 	int gref;
 	int irq;
 	struct xenbus_device *xbdev;
 	char phys[32];
+	/* current MT slot/contact ID we are injecting events in */
+	int mtouch_cur_contact_id;
 };
 
 enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
@@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
 MODULE_PARM_DESC(ptr_size,
 	"Pointing device width, height in pixels (default 800,600)");
 
+enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
+static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
+module_param_array(mtouch_size, int, NULL, 0444);
+MODULE_PARM_DESC(ptr_size,
+	"Multi-touch device width, height in pixels (default 800,600)");
+
 static int xenkbd_remove(struct xenbus_device *);
 static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
 static void xenkbd_disconnect_backend(struct xenkbd_info *);
@@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void *dev_id)
 				input_report_rel(dev, REL_WHEEL,
 						 -event->pos.rel_z);
 			break;
+		case XENKBD_TYPE_MTOUCH:
+			dev = info->mtouch;
+			if (unlikely(!dev))
+				break;
+			if (unlikely(event->mtouch.contact_id !=
+					info->mtouch_cur_contact_id)) {
+				info->mtouch_cur_contact_id =
+					event->mtouch.contact_id;
+				input_mt_slot(dev, event->mtouch.contact_id);
+			}
+			switch (event->mtouch.event_type) {
+			case XENKBD_MT_EV_DOWN:
+				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
+							   true);
+				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
+					    event->mtouch.u.pos.abs_x);
+				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
+					    event->mtouch.u.pos.abs_y);
+				input_event(dev, EV_ABS, ABS_X,
+					    event->mtouch.u.pos.abs_x);
+				input_event(dev, EV_ABS, ABS_Y,
+					    event->mtouch.u.pos.abs_y);
+				break;
+			case XENKBD_MT_EV_UP:
+				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
+							   false);
+				break;
+			case XENKBD_MT_EV_MOTION:
+				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
+					    event->mtouch.u.pos.abs_x);
+				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
+					    event->mtouch.u.pos.abs_y);
+				input_event(dev, EV_ABS, ABS_X,
+					    event->mtouch.u.pos.abs_x);
+				input_event(dev, EV_ABS, ABS_Y,
+					    event->mtouch.u.pos.abs_y);
+				break;
+			case XENKBD_MT_EV_SYN:
+				input_mt_sync_frame(dev);
+				break;
+			case XENKBD_MT_EV_SHAPE:
+				input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
+					    event->mtouch.u.shape.major);
+				input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
+					    event->mtouch.u.shape.minor);
+				break;
+			case XENKBD_MT_EV_ORIENT:
+				input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
+					    event->mtouch.u.orientation);
+				break;
+			}
+			/* only report syn when requested */
+			if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
+				dev = NULL;
 		}
 		if (dev)
 			input_sync(dev);
@@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device *dev,
 				  const struct xenbus_device_id *id)
 {
 	int ret, i;
-	unsigned int abs;
+	unsigned int abs, touch;
 	struct xenkbd_info *info;
-	struct input_dev *kbd, *ptr;
+	struct input_dev *kbd, *ptr, *mtouch;
 
 	info = kzalloc(sizeof(*info), GFP_KERNEL);
 	if (!info) {
@@ -152,6 +216,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
 		}
 	}
 
+	touch = xenbus_read_unsigned(dev->nodename,
+				     XENKBD_FIELD_FEAT_MTOUCH, 0);
+	if (touch) {
+		ret = xenbus_write(XBT_NIL, dev->nodename,
+				   XENKBD_FIELD_REQ_MTOUCH, "1");
+		if (ret) {
+			pr_warning("xenkbd: can't request multi-touch");
+			touch = 0;
+		}
+	}
+
 	/* keyboard */
 	kbd = input_allocate_device();
 	if (!kbd)
@@ -208,6 +283,67 @@ static int xenkbd_probe(struct xenbus_device *dev,
 	}
 	info->ptr = ptr;
 
+	/* multi-touch device */
+	if (touch) {
+		int num_cont, width, height;
+
+		mtouch = input_allocate_device();
+		if (!mtouch)
+			goto error_nomem;
+
+		num_cont = xenbus_read_unsigned(info->xbdev->nodename,
+						XENKBD_FIELD_MT_NUM_CONTACTS,
+						1);
+		width = xenbus_read_unsigned(info->xbdev->nodename,
+					     XENKBD_FIELD_MT_WIDTH,
+					     XENFB_WIDTH);
+		height = xenbus_read_unsigned(info->xbdev->nodename,
+					      XENKBD_FIELD_MT_HEIGHT,
+					      XENFB_HEIGHT);
+
+		mtouch->name = "Xen Virtual Multi-touch";
+		mtouch->phys = info->phys;
+		mtouch->id.bustype = BUS_PCI;
+		mtouch->id.vendor = 0x5853;
+		mtouch->id.product = 0xfffd;
+
+		__set_bit(EV_ABS, mtouch->evbit);
+		__set_bit(EV_KEY, mtouch->evbit);
+		__set_bit(BTN_TOUCH, mtouch->keybit);
+
+		input_set_abs_params(mtouch, ABS_X,
+				     0, width, 0, 0);
+		input_set_abs_params(mtouch, ABS_Y,
+				     0, height, 0, 0);
+		input_set_abs_params(mtouch, ABS_PRESSURE,
+				     0, 255, 0, 0);
+
+		input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
+				     0, 255, 0, 0);
+		input_set_abs_params(mtouch, ABS_MT_POSITION_X,
+				     0, width, 0, 0);
+		input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
+				     0, height, 0, 0);
+		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
+				     0, 255, 0, 0);
+
+		input_mt_init_slots(mtouch, num_cont, 0);
+
+		mtouch_size[KPARAM_MT_X] = width;
+		mtouch_size[KPARAM_MT_Y] = height;
+		info->mtouch_cur_contact_id = -1;
+
+		ret = input_register_device(mtouch);
+		if (ret) {
+			input_free_device(mtouch);
+			xenbus_dev_fatal(info->xbdev, ret,
+					 "input_register_device(mtouch)");
+			goto error;
+		}
+		info->mtouch_cur_contact_id = -1;
+		info->mtouch = mtouch;
+	}
+
 	ret = xenkbd_connect_backend(dev, info);
 	if (ret < 0)
 		goto error;
@@ -240,6 +376,8 @@ static int xenkbd_remove(struct xenbus_device *dev)
 		input_unregister_device(info->kbd);
 	if (info->ptr)
 		input_unregister_device(info->ptr);
+	if (info->mtouch)
+		input_unregister_device(info->mtouch);
 	free_page((unsigned long)info->page);
 	kfree(info);
 	return 0;
-- 
2.7.4

Re: [PATCH 2/2] xen/input: add multi-touch support

[Dmitry Torokhov]

Hi Oleksandr,

On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> 
> Extend xen_kbdfront to provide multi-touch support
> to unprivileged domains.
> 
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> ---
>  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
>  1 file changed, 140 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> index 01c27b4c3288..e5d064aaa237 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -17,6 +17,7 @@
>  #include <linux/errno.h>
>  #include <linux/module.h>
>  #include <linux/input.h>
> +#include <linux/input/mt.h>
>  #include <linux/slab.h>
>  
>  #include <asm/xen/hypervisor.h>
> @@ -34,11 +35,14 @@
>  struct xenkbd_info {
>  	struct input_dev *kbd;
>  	struct input_dev *ptr;
> +	struct input_dev *mtouch;
>  	struct xenkbd_page *page;
>  	int gref;
>  	int irq;
>  	struct xenbus_device *xbdev;
>  	char phys[32];
> +	/* current MT slot/contact ID we are injecting events in */
> +	int mtouch_cur_contact_id;
>  };
>  
>  enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
> @@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
>  MODULE_PARM_DESC(ptr_size,
>  	"Pointing device width, height in pixels (default 800,600)");
>  
> +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
> +static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
> +module_param_array(mtouch_size, int, NULL, 0444);
> +MODULE_PARM_DESC(ptr_size,
> +	"Multi-touch device width, height in pixels (default 800,600)");
> +

Why do you need separate module parameters for multi-touch device?

>  static int xenkbd_remove(struct xenbus_device *);
>  static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
>  static void xenkbd_disconnect_backend(struct xenkbd_info *);
> @@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void *dev_id)
>  				input_report_rel(dev, REL_WHEEL,
>  						 -event->pos.rel_z);
>  			break;
> +		case XENKBD_TYPE_MTOUCH:
> +			dev = info->mtouch;
> +			if (unlikely(!dev))
> +				break;
> +			if (unlikely(event->mtouch.contact_id !=
> +					info->mtouch_cur_contact_id)) {

Why is this unlikely? Does contact ID changes once in 1000 packets or
even less?

> +				info->mtouch_cur_contact_id =
> +					event->mtouch.contact_id;
> +				input_mt_slot(dev, event->mtouch.contact_id);
> +			}
> +			switch (event->mtouch.event_type) {
> +			case XENKBD_MT_EV_DOWN:
> +				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
> +							   true);
> +				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
> +					    event->mtouch.u.pos.abs_x);
> +				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
> +					    event->mtouch.u.pos.abs_y);
> +				input_event(dev, EV_ABS, ABS_X,
> +					    event->mtouch.u.pos.abs_x);
> +				input_event(dev, EV_ABS, ABS_Y,
> +					    event->mtouch.u.pos.abs_y);
> +				break;
> +			case XENKBD_MT_EV_UP:
> +				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
> +							   false);
> +				break;
> +			case XENKBD_MT_EV_MOTION:
> +				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
> +					    event->mtouch.u.pos.abs_x);
> +				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
> +					    event->mtouch.u.pos.abs_y);
> +				input_event(dev, EV_ABS, ABS_X,
> +					    event->mtouch.u.pos.abs_x);
> +				input_event(dev, EV_ABS, ABS_Y,
> +					    event->mtouch.u.pos.abs_y);
> +				break;
> +			case XENKBD_MT_EV_SYN:
> +				input_mt_sync_frame(dev);
> +				break;
> +			case XENKBD_MT_EV_SHAPE:
> +				input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
> +					    event->mtouch.u.shape.major);
> +				input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
> +					    event->mtouch.u.shape.minor);
> +				break;
> +			case XENKBD_MT_EV_ORIENT:
> +				input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
> +					    event->mtouch.u.orientation);
> +				break;
> +			}
> +			/* only report syn when requested */
> +			if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
> +				dev = NULL;
>  		}
>  		if (dev)
>  			input_sync(dev);
> @@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device *dev,
>  				  const struct xenbus_device_id *id)
>  {
>  	int ret, i;
> -	unsigned int abs;
> +	unsigned int abs, touch;
>  	struct xenkbd_info *info;
> -	struct input_dev *kbd, *ptr;
> +	struct input_dev *kbd, *ptr, *mtouch;
>  
>  	info = kzalloc(sizeof(*info), GFP_KERNEL);
>  	if (!info) {
> @@ -152,6 +216,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
>  		}
>  	}
>  
> +	touch = xenbus_read_unsigned(dev->nodename,
> +				     XENKBD_FIELD_FEAT_MTOUCH, 0);
> +	if (touch) {
> +		ret = xenbus_write(XBT_NIL, dev->nodename,
> +				   XENKBD_FIELD_REQ_MTOUCH, "1");
> +		if (ret) {
> +			pr_warning("xenkbd: can't request multi-touch");
> +			touch = 0;
> +		}
> +	}
> +
>  	/* keyboard */
>  	kbd = input_allocate_device();
>  	if (!kbd)
> @@ -208,6 +283,67 @@ static int xenkbd_probe(struct xenbus_device *dev,
>  	}
>  	info->ptr = ptr;
>  
> +	/* multi-touch device */
> +	if (touch) {
> +		int num_cont, width, height;
> +
> +		mtouch = input_allocate_device();
> +		if (!mtouch)
> +			goto error_nomem;
> +
> +		num_cont = xenbus_read_unsigned(info->xbdev->nodename,
> +						XENKBD_FIELD_MT_NUM_CONTACTS,
> +						1);
> +		width = xenbus_read_unsigned(info->xbdev->nodename,
> +					     XENKBD_FIELD_MT_WIDTH,
> +					     XENFB_WIDTH);
> +		height = xenbus_read_unsigned(info->xbdev->nodename,
> +					      XENKBD_FIELD_MT_HEIGHT,
> +					      XENFB_HEIGHT);

Curious why you need separate parameters here too...

> +
> +		mtouch->name = "Xen Virtual Multi-touch";
> +		mtouch->phys = info->phys;
> +		mtouch->id.bustype = BUS_PCI;
> +		mtouch->id.vendor = 0x5853;
> +		mtouch->id.product = 0xfffd;
> +
> +		__set_bit(EV_ABS, mtouch->evbit);
> +		__set_bit(EV_KEY, mtouch->evbit);
> +		__set_bit(BTN_TOUCH, mtouch->keybit);
> +
> +		input_set_abs_params(mtouch, ABS_X,
> +				     0, width, 0, 0);
> +		input_set_abs_params(mtouch, ABS_Y,
> +				     0, height, 0, 0);
> +		input_set_abs_params(mtouch, ABS_PRESSURE,
> +				     0, 255, 0, 0);
> +
> +		input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
> +				     0, 255, 0, 0);
> +		input_set_abs_params(mtouch, ABS_MT_POSITION_X,
> +				     0, width, 0, 0);
> +		input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
> +				     0, height, 0, 0);
> +		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
> +				     0, 255, 0, 0);
> +
> +		input_mt_init_slots(mtouch, num_cont, 0);
> +
> +		mtouch_size[KPARAM_MT_X] = width;
> +		mtouch_size[KPARAM_MT_Y] = height;
> +		info->mtouch_cur_contact_id = -1;
> +
> +		ret = input_register_device(mtouch);
> +		if (ret) {
> +			input_free_device(mtouch);
> +			xenbus_dev_fatal(info->xbdev, ret,
> +					 "input_register_device(mtouch)");
> +			goto error;
> +		}
> +		info->mtouch_cur_contact_id = -1;
> +		info->mtouch = mtouch;
> +	}
> +
>  	ret = xenkbd_connect_backend(dev, info);
>  	if (ret < 0)
>  		goto error;
> @@ -240,6 +376,8 @@ static int xenkbd_remove(struct xenbus_device *dev)
>  		input_unregister_device(info->kbd);
>  	if (info->ptr)
>  		input_unregister_device(info->ptr);
> +	if (info->mtouch)
> +		input_unregister_device(info->mtouch);
>  	free_page((unsigned long)info->page);
>  	kfree(info);
>  	return 0;
> -- 
> 2.7.4
> 

Thanks.

-- 
Dmitry

Re: [PATCH 2/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

Hi, Dmitry!

On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
> Hi Oleksandr,
>
> On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>
>> Extend xen_kbdfront to provide multi-touch support
>> to unprivileged domains.
>>
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>> ---
>>   drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
>>   1 file changed, 140 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
>> index 01c27b4c3288..e5d064aaa237 100644
>> --- a/drivers/input/misc/xen-kbdfront.c
>> +++ b/drivers/input/misc/xen-kbdfront.c
>> @@ -17,6 +17,7 @@
>>   #include <linux/errno.h>
>>   #include <linux/module.h>
>>   #include <linux/input.h>
>> +#include <linux/input/mt.h>
>>   #include <linux/slab.h>
>>   
>>   #include <asm/xen/hypervisor.h>
>> @@ -34,11 +35,14 @@
>>   struct xenkbd_info {
>>   	struct input_dev *kbd;
>>   	struct input_dev *ptr;
>> +	struct input_dev *mtouch;
>>   	struct xenkbd_page *page;
>>   	int gref;
>>   	int irq;
>>   	struct xenbus_device *xbdev;
>>   	char phys[32];
>> +	/* current MT slot/contact ID we are injecting events in */
>> +	int mtouch_cur_contact_id;
>>   };
>>   
>>   enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
>> @@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
>>   MODULE_PARM_DESC(ptr_size,
>>   	"Pointing device width, height in pixels (default 800,600)");
>>   
>> +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>> +static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
>> +module_param_array(mtouch_size, int, NULL, 0444);
>> +MODULE_PARM_DESC(ptr_size,
>> +	"Multi-touch device width, height in pixels (default 800,600)");
>> +
> Why do you need separate module parameters for multi-touch device?
please see below
>
>>   static int xenkbd_remove(struct xenbus_device *);
>>   static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>> @@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void *dev_id)
>>   				input_report_rel(dev, REL_WHEEL,
>>   						 -event->pos.rel_z);
>>   			break;
>> +		case XENKBD_TYPE_MTOUCH:
>> +			dev = info->mtouch;
>> +			if (unlikely(!dev))
>> +				break;
>> +			if (unlikely(event->mtouch.contact_id !=
>> +					info->mtouch_cur_contact_id)) {
> Why is this unlikely? Does contact ID changes once in 1000 packets or
> even less?
Mu assumption was that regardless of the fact that we are multi-touch
device still single touches will come in more frequently
But I can remove *unlikely* if my assumption is not correct
>> +				info->mtouch_cur_contact_id =
>> +					event->mtouch.contact_id;
>> +				input_mt_slot(dev, event->mtouch.contact_id);
>> +			}
>> +			switch (event->mtouch.event_type) {
>> +			case XENKBD_MT_EV_DOWN:
>> +				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>> +							   true);
>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>> +					    event->mtouch.u.pos.abs_x);
>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>> +					    event->mtouch.u.pos.abs_y);
>> +				input_event(dev, EV_ABS, ABS_X,
>> +					    event->mtouch.u.pos.abs_x);
>> +				input_event(dev, EV_ABS, ABS_Y,
>> +					    event->mtouch.u.pos.abs_y);
>> +				break;
>> +			case XENKBD_MT_EV_UP:
>> +				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>> +							   false);
>> +				break;
>> +			case XENKBD_MT_EV_MOTION:
>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>> +					    event->mtouch.u.pos.abs_x);
>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>> +					    event->mtouch.u.pos.abs_y);
>> +				input_event(dev, EV_ABS, ABS_X,
>> +					    event->mtouch.u.pos.abs_x);
>> +				input_event(dev, EV_ABS, ABS_Y,
>> +					    event->mtouch.u.pos.abs_y);
>> +				break;
>> +			case XENKBD_MT_EV_SYN:
>> +				input_mt_sync_frame(dev);
>> +				break;
>> +			case XENKBD_MT_EV_SHAPE:
>> +				input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
>> +					    event->mtouch.u.shape.major);
>> +				input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
>> +					    event->mtouch.u.shape.minor);
>> +				break;
>> +			case XENKBD_MT_EV_ORIENT:
>> +				input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
>> +					    event->mtouch.u.orientation);
>> +				break;
>> +			}
>> +			/* only report syn when requested */
>> +			if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
>> +				dev = NULL;
>>   		}
>>   		if (dev)
>>   			input_sync(dev);
>> @@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>   				  const struct xenbus_device_id *id)
>>   {
>>   	int ret, i;
>> -	unsigned int abs;
>> +	unsigned int abs, touch;
>>   	struct xenkbd_info *info;
>> -	struct input_dev *kbd, *ptr;
>> +	struct input_dev *kbd, *ptr, *mtouch;
>>   
>>   	info = kzalloc(sizeof(*info), GFP_KERNEL);
>>   	if (!info) {
>> @@ -152,6 +216,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>   		}
>>   	}
>>   
>> +	touch = xenbus_read_unsigned(dev->nodename,
>> +				     XENKBD_FIELD_FEAT_MTOUCH, 0);
>> +	if (touch) {
>> +		ret = xenbus_write(XBT_NIL, dev->nodename,
>> +				   XENKBD_FIELD_REQ_MTOUCH, "1");
>> +		if (ret) {
>> +			pr_warning("xenkbd: can't request multi-touch");
>> +			touch = 0;
>> +		}
>> +	}
>> +
>>   	/* keyboard */
>>   	kbd = input_allocate_device();
>>   	if (!kbd)
>> @@ -208,6 +283,67 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>   	}
>>   	info->ptr = ptr;
>>   
>> +	/* multi-touch device */
>> +	if (touch) {
>> +		int num_cont, width, height;
>> +
>> +		mtouch = input_allocate_device();
>> +		if (!mtouch)
>> +			goto error_nomem;
>> +
>> +		num_cont = xenbus_read_unsigned(info->xbdev->nodename,
>> +						XENKBD_FIELD_MT_NUM_CONTACTS,
>> +						1);
>> +		width = xenbus_read_unsigned(info->xbdev->nodename,
>> +					     XENKBD_FIELD_MT_WIDTH,
>> +					     XENFB_WIDTH);
>> +		height = xenbus_read_unsigned(info->xbdev->nodename,
>> +					      XENKBD_FIELD_MT_HEIGHT,
>> +					      XENFB_HEIGHT);
> Curious why you need separate parameters here too...
This is because mt parameters are different from ptr
in a way that they are configurable per front driver's
instance rather than per backend, e.g. in XenStore:

/local/domain/0/backend/vkbd/1/0/width = "1920"
/local/domain/0/backend/vkbd/1/0/height = "1080"

/local/domain/1/device/vkbd/0/multi-touch-width = "1920"
/local/domain/1/device/vkbd/0/multi-touch-height = "1080"
/local/domain/1/device/vkbd/0/multi-touch-num-contacts = "10"

/local/domain/1/device/vkbd/1/multi-touch-width = "800"
/local/domain/1/device/vkbd/1/multi-touch-height = "600"
/local/domain/1/device/vkbd/1/multi-touch-num-contacts = "3"

The main reason for such configuration is that you can
configure multiple mt input devices even for the same guest
with different resolutions which may not match those
configured for ptr.
(In my use-case I use new displif protocol [1] in conjunction
with mt input devices and the corresponding backend is not
QEMU's xenfb)

As to module parameters, I added those to be consistent with
ptr device. Do you think we can live without them and
do you want me to remove them?
>> +
>> +		mtouch->name = "Xen Virtual Multi-touch";
>> +		mtouch->phys = info->phys;
>> +		mtouch->id.bustype = BUS_PCI;
>> +		mtouch->id.vendor = 0x5853;
>> +		mtouch->id.product = 0xfffd;
>> +
>> +		__set_bit(EV_ABS, mtouch->evbit);
>> +		__set_bit(EV_KEY, mtouch->evbit);
>> +		__set_bit(BTN_TOUCH, mtouch->keybit);
>> +
>> +		input_set_abs_params(mtouch, ABS_X,
>> +				     0, width, 0, 0);
>> +		input_set_abs_params(mtouch, ABS_Y,
>> +				     0, height, 0, 0);
>> +		input_set_abs_params(mtouch, ABS_PRESSURE,
>> +				     0, 255, 0, 0);
>> +
>> +		input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
>> +				     0, 255, 0, 0);
>> +		input_set_abs_params(mtouch, ABS_MT_POSITION_X,
>> +				     0, width, 0, 0);
>> +		input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
>> +				     0, height, 0, 0);
>> +		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>> +				     0, 255, 0, 0);
>> +
>> +		input_mt_init_slots(mtouch, num_cont, 0);
>> +
>> +		mtouch_size[KPARAM_MT_X] = width;
>> +		mtouch_size[KPARAM_MT_Y] = height;
>> +		info->mtouch_cur_contact_id = -1;
>> +
>> +		ret = input_register_device(mtouch);
>> +		if (ret) {
>> +			input_free_device(mtouch);
>> +			xenbus_dev_fatal(info->xbdev, ret,
>> +					 "input_register_device(mtouch)");
>> +			goto error;
>> +		}
>> +		info->mtouch_cur_contact_id = -1;
>> +		info->mtouch = mtouch;
>> +	}
>> +
>>   	ret = xenkbd_connect_backend(dev, info);
>>   	if (ret < 0)
>>   		goto error;
>> @@ -240,6 +376,8 @@ static int xenkbd_remove(struct xenbus_device *dev)
>>   		input_unregister_device(info->kbd);
>>   	if (info->ptr)
>>   		input_unregister_device(info->ptr);
>> +	if (info->mtouch)
>> +		input_unregister_device(info->mtouch);
>>   	free_page((unsigned long)info->page);
>>   	kfree(info);
>>   	return 0;
>> -- 
>> 2.7.4
>>
> Thanks.
Thank you,
Oleksandr
[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.12&id=e27c533dc4d0338266ccb6dab428150d4d629e6a

Re: [PATCH 2/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

Hi, Dmitry!

On 04/21/2017 09:40 AM, Oleksandr Andrushchenko wrote:
> Hi, Dmitry!
>
> On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
>> Hi Oleksandr,
>>
>> On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>
>>> Extend xen_kbdfront to provide multi-touch support
>>> to unprivileged domains.
>>>
>>> Signed-off-by: Oleksandr Andrushchenko 
>>> <oleksandr_andrushchenko@epam.com>
>>> ---
>>>   drivers/input/misc/xen-kbdfront.c | 142 
>>> +++++++++++++++++++++++++++++++++++++-
>>>   1 file changed, 140 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/input/misc/xen-kbdfront.c 
>>> b/drivers/input/misc/xen-kbdfront.c
>>> index 01c27b4c3288..e5d064aaa237 100644
>>> --- a/drivers/input/misc/xen-kbdfront.c
>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>> @@ -17,6 +17,7 @@
>>>   #include <linux/errno.h>
>>>   #include <linux/module.h>
>>>   #include <linux/input.h>
>>> +#include <linux/input/mt.h>
>>>   #include <linux/slab.h>
>>>     #include <asm/xen/hypervisor.h>
>>> @@ -34,11 +35,14 @@
>>>   struct xenkbd_info {
>>>       struct input_dev *kbd;
>>>       struct input_dev *ptr;
>>> +    struct input_dev *mtouch;
>>>       struct xenkbd_page *page;
>>>       int gref;
>>>       int irq;
>>>       struct xenbus_device *xbdev;
>>>       char phys[32];
>>> +    /* current MT slot/contact ID we are injecting events in */
>>> +    int mtouch_cur_contact_id;
>>>   };
>>>     enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
>>> @@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
>>>   MODULE_PARM_DESC(ptr_size,
>>>       "Pointing device width, height in pixels (default 800,600)");
>>>   +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>>> +static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
>>> +module_param_array(mtouch_size, int, NULL, 0444);
>>> +MODULE_PARM_DESC(ptr_size,
>>> +    "Multi-touch device width, height in pixels (default 800,600)");
>>> +
>> Why do you need separate module parameters for multi-touch device?
> please see below
>>
>>>   static int xenkbd_remove(struct xenbus_device *);
>>>   static int xenkbd_connect_backend(struct xenbus_device *, struct 
>>> xenkbd_info *);
>>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>>> @@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void 
>>> *dev_id)
>>>                   input_report_rel(dev, REL_WHEEL,
>>>                            -event->pos.rel_z);
>>>               break;
>>> +        case XENKBD_TYPE_MTOUCH:
>>> +            dev = info->mtouch;
>>> +            if (unlikely(!dev))
>>> +                break;
>>> +            if (unlikely(event->mtouch.contact_id !=
>>> +                    info->mtouch_cur_contact_id)) {
>> Why is this unlikely? Does contact ID changes once in 1000 packets or
>> even less?
> Mu assumption was that regardless of the fact that we are multi-touch
> device still single touches will come in more frequently
> But I can remove *unlikely* if my assumption is not correct
>>> + info->mtouch_cur_contact_id =
>>> +                    event->mtouch.contact_id;
>>> +                input_mt_slot(dev, event->mtouch.contact_id);
>>> +            }
>>> +            switch (event->mtouch.event_type) {
>>> +            case XENKBD_MT_EV_DOWN:
>>> +                input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>> +                               true);
>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>> +                        event->mtouch.u.pos.abs_x);
>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>> +                        event->mtouch.u.pos.abs_y);
>>> +                input_event(dev, EV_ABS, ABS_X,
>>> +                        event->mtouch.u.pos.abs_x);
>>> +                input_event(dev, EV_ABS, ABS_Y,
>>> +                        event->mtouch.u.pos.abs_y);
>>> +                break;
>>> +            case XENKBD_MT_EV_UP:
>>> +                input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>> +                               false);
>>> +                break;
>>> +            case XENKBD_MT_EV_MOTION:
>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>> +                        event->mtouch.u.pos.abs_x);
>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>> +                        event->mtouch.u.pos.abs_y);
>>> +                input_event(dev, EV_ABS, ABS_X,
>>> +                        event->mtouch.u.pos.abs_x);
>>> +                input_event(dev, EV_ABS, ABS_Y,
>>> +                        event->mtouch.u.pos.abs_y);
>>> +                break;
>>> +            case XENKBD_MT_EV_SYN:
>>> +                input_mt_sync_frame(dev);
>>> +                break;
>>> +            case XENKBD_MT_EV_SHAPE:
>>> +                input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
>>> +                        event->mtouch.u.shape.major);
>>> +                input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
>>> +                        event->mtouch.u.shape.minor);
>>> +                break;
>>> +            case XENKBD_MT_EV_ORIENT:
>>> +                input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
>>> +                        event->mtouch.u.orientation);
>>> +                break;
>>> +            }
>>> +            /* only report syn when requested */
>>> +            if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
>>> +                dev = NULL;
>>>           }
>>>           if (dev)
>>>               input_sync(dev);
>>> @@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>                     const struct xenbus_device_id *id)
>>>   {
>>>       int ret, i;
>>> -    unsigned int abs;
>>> +    unsigned int abs, touch;
>>>       struct xenkbd_info *info;
>>> -    struct input_dev *kbd, *ptr;
>>> +    struct input_dev *kbd, *ptr, *mtouch;
>>>         info = kzalloc(sizeof(*info), GFP_KERNEL);
>>>       if (!info) {
>>> @@ -152,6 +216,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>           }
>>>       }
>>>   +    touch = xenbus_read_unsigned(dev->nodename,
>>> +                     XENKBD_FIELD_FEAT_MTOUCH, 0);
>>> +    if (touch) {
>>> +        ret = xenbus_write(XBT_NIL, dev->nodename,
>>> +                   XENKBD_FIELD_REQ_MTOUCH, "1");
>>> +        if (ret) {
>>> +            pr_warning("xenkbd: can't request multi-touch");
>>> +            touch = 0;
>>> +        }
>>> +    }
>>> +
>>>       /* keyboard */
>>>       kbd = input_allocate_device();
>>>       if (!kbd)
>>> @@ -208,6 +283,67 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>       }
>>>       info->ptr = ptr;
>>>   +    /* multi-touch device */
>>> +    if (touch) {
>>> +        int num_cont, width, height;
>>> +
>>> +        mtouch = input_allocate_device();
>>> +        if (!mtouch)
>>> +            goto error_nomem;
>>> +
>>> +        num_cont = xenbus_read_unsigned(info->xbdev->nodename,
>>> +                        XENKBD_FIELD_MT_NUM_CONTACTS,
>>> +                        1);
>>> +        width = xenbus_read_unsigned(info->xbdev->nodename,
>>> +                         XENKBD_FIELD_MT_WIDTH,
>>> +                         XENFB_WIDTH);
>>> +        height = xenbus_read_unsigned(info->xbdev->nodename,
>>> +                          XENKBD_FIELD_MT_HEIGHT,
>>> +                          XENFB_HEIGHT);
>> Curious why you need separate parameters here too...
> This is because mt parameters are different from ptr
> in a way that they are configurable per front driver's
> instance rather than per backend, e.g. in XenStore:
>
> /local/domain/0/backend/vkbd/1/0/width = "1920"
> /local/domain/0/backend/vkbd/1/0/height = "1080"
>
> /local/domain/1/device/vkbd/0/multi-touch-width = "1920"
> /local/domain/1/device/vkbd/0/multi-touch-height = "1080"
> /local/domain/1/device/vkbd/0/multi-touch-num-contacts = "10"
>
> /local/domain/1/device/vkbd/1/multi-touch-width = "800"
> /local/domain/1/device/vkbd/1/multi-touch-height = "600"
> /local/domain/1/device/vkbd/1/multi-touch-num-contacts = "3"
>
> The main reason for such configuration is that you can
> configure multiple mt input devices even for the same guest
> with different resolutions which may not match those
> configured for ptr.
> (In my use-case I use new displif protocol [1] in conjunction
> with mt input devices and the corresponding backend is not
> QEMU's xenfb)
>
> As to module parameters, I added those to be consistent with
> ptr device. Do you think we can live without them and
> do you want me to remove them?
>>> +
>>> +        mtouch->name = "Xen Virtual Multi-touch";
>>> +        mtouch->phys = info->phys;
>>> +        mtouch->id.bustype = BUS_PCI;
>>> +        mtouch->id.vendor = 0x5853;
>>> +        mtouch->id.product = 0xfffd;
>>> +
>>> +        __set_bit(EV_ABS, mtouch->evbit);
>>> +        __set_bit(EV_KEY, mtouch->evbit);
>>> +        __set_bit(BTN_TOUCH, mtouch->keybit);
>>> +
>>> +        input_set_abs_params(mtouch, ABS_X,
>>> +                     0, width, 0, 0);
>>> +        input_set_abs_params(mtouch, ABS_Y,
>>> +                     0, height, 0, 0);
>>> +        input_set_abs_params(mtouch, ABS_PRESSURE,
>>> +                     0, 255, 0, 0);
>>> +
>>> +        input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
>>> +                     0, 255, 0, 0);
>>> +        input_set_abs_params(mtouch, ABS_MT_POSITION_X,
>>> +                     0, width, 0, 0);
>>> +        input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
>>> +                     0, height, 0, 0);
>>> +        input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>>> +                     0, 255, 0, 0);
>>> +
>>> +        input_mt_init_slots(mtouch, num_cont, 0);
>>> +
>>> +        mtouch_size[KPARAM_MT_X] = width;
>>> +        mtouch_size[KPARAM_MT_Y] = height;
>>> +        info->mtouch_cur_contact_id = -1;
>>> +
>>> +        ret = input_register_device(mtouch);
>>> +        if (ret) {
>>> +            input_free_device(mtouch);
>>> +            xenbus_dev_fatal(info->xbdev, ret,
>>> +                     "input_register_device(mtouch)");
>>> +            goto error;
>>> +        }
>>> +        info->mtouch_cur_contact_id = -1;
>>> +        info->mtouch = mtouch;
>>> +    }
>>> +
>>>       ret = xenkbd_connect_backend(dev, info);
>>>       if (ret < 0)
>>>           goto error;
>>> @@ -240,6 +376,8 @@ static int xenkbd_remove(struct xenbus_device *dev)
>>>           input_unregister_device(info->kbd);
>>>       if (info->ptr)
>>>           input_unregister_device(info->ptr);
>>> +    if (info->mtouch)
>>> +        input_unregister_device(info->mtouch);
>>>       free_page((unsigned long)info->page);
>>>       kfree(info);
>>>       return 0;
>>> -- 
>>> 2.7.4
>>>
>> Thanks.
> Thank you,
> Oleksandr
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.12&id=e27c533dc4d0338266ccb6dab428150d4d629e6a
>

As all the dependencies are now merged into the kernel and *if*
the above sounds reasonable for you can we please proceed with this patch?

Thank you,
Oleksandr

Re: [PATCH 2/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

gentle reminder


On 05/05/2017 07:45 AM, Oleksandr Andrushchenko wrote:
> Hi, Dmitry!
>
> On 04/21/2017 09:40 AM, Oleksandr Andrushchenko wrote:
>> Hi, Dmitry!
>>
>> On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
>>> Hi Oleksandr,
>>>
>>> On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko 
>>> wrote:
>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>
>>>> Extend xen_kbdfront to provide multi-touch support
>>>> to unprivileged domains.
>>>>
>>>> Signed-off-by: Oleksandr Andrushchenko 
>>>> <oleksandr_andrushchenko@epam.com>
>>>> ---
>>>>   drivers/input/misc/xen-kbdfront.c | 142 
>>>> +++++++++++++++++++++++++++++++++++++-
>>>>   1 file changed, 140 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/input/misc/xen-kbdfront.c 
>>>> b/drivers/input/misc/xen-kbdfront.c
>>>> index 01c27b4c3288..e5d064aaa237 100644
>>>> --- a/drivers/input/misc/xen-kbdfront.c
>>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>>> @@ -17,6 +17,7 @@
>>>>   #include <linux/errno.h>
>>>>   #include <linux/module.h>
>>>>   #include <linux/input.h>
>>>> +#include <linux/input/mt.h>
>>>>   #include <linux/slab.h>
>>>>     #include <asm/xen/hypervisor.h>
>>>> @@ -34,11 +35,14 @@
>>>>   struct xenkbd_info {
>>>>       struct input_dev *kbd;
>>>>       struct input_dev *ptr;
>>>> +    struct input_dev *mtouch;
>>>>       struct xenkbd_page *page;
>>>>       int gref;
>>>>       int irq;
>>>>       struct xenbus_device *xbdev;
>>>>       char phys[32];
>>>> +    /* current MT slot/contact ID we are injecting events in */
>>>> +    int mtouch_cur_contact_id;
>>>>   };
>>>>     enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
>>>> @@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
>>>>   MODULE_PARM_DESC(ptr_size,
>>>>       "Pointing device width, height in pixels (default 800,600)");
>>>>   +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>>>> +static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, 
>>>> XENFB_HEIGHT };
>>>> +module_param_array(mtouch_size, int, NULL, 0444);
>>>> +MODULE_PARM_DESC(ptr_size,
>>>> +    "Multi-touch device width, height in pixels (default 800,600)");
>>>> +
>>> Why do you need separate module parameters for multi-touch device?
>> please see below
>>>
>>>>   static int xenkbd_remove(struct xenbus_device *);
>>>>   static int xenkbd_connect_backend(struct xenbus_device *, struct 
>>>> xenkbd_info *);
>>>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>>>> @@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void 
>>>> *dev_id)
>>>>                   input_report_rel(dev, REL_WHEEL,
>>>>                            -event->pos.rel_z);
>>>>               break;
>>>> +        case XENKBD_TYPE_MTOUCH:
>>>> +            dev = info->mtouch;
>>>> +            if (unlikely(!dev))
>>>> +                break;
>>>> +            if (unlikely(event->mtouch.contact_id !=
>>>> +                    info->mtouch_cur_contact_id)) {
>>> Why is this unlikely? Does contact ID changes once in 1000 packets or
>>> even less?
>> Mu assumption was that regardless of the fact that we are multi-touch
>> device still single touches will come in more frequently
>> But I can remove *unlikely* if my assumption is not correct
>>>> + info->mtouch_cur_contact_id =
>>>> +                    event->mtouch.contact_id;
>>>> +                input_mt_slot(dev, event->mtouch.contact_id);
>>>> +            }
>>>> +            switch (event->mtouch.event_type) {
>>>> +            case XENKBD_MT_EV_DOWN:
>>>> +                input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>> +                               true);
>>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>> +                        event->mtouch.u.pos.abs_x);
>>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>> +                        event->mtouch.u.pos.abs_y);
>>>> +                input_event(dev, EV_ABS, ABS_X,
>>>> +                        event->mtouch.u.pos.abs_x);
>>>> +                input_event(dev, EV_ABS, ABS_Y,
>>>> +                        event->mtouch.u.pos.abs_y);
>>>> +                break;
>>>> +            case XENKBD_MT_EV_UP:
>>>> +                input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>> +                               false);
>>>> +                break;
>>>> +            case XENKBD_MT_EV_MOTION:
>>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>> +                        event->mtouch.u.pos.abs_x);
>>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>> +                        event->mtouch.u.pos.abs_y);
>>>> +                input_event(dev, EV_ABS, ABS_X,
>>>> +                        event->mtouch.u.pos.abs_x);
>>>> +                input_event(dev, EV_ABS, ABS_Y,
>>>> +                        event->mtouch.u.pos.abs_y);
>>>> +                break;
>>>> +            case XENKBD_MT_EV_SYN:
>>>> +                input_mt_sync_frame(dev);
>>>> +                break;
>>>> +            case XENKBD_MT_EV_SHAPE:
>>>> +                input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
>>>> +                        event->mtouch.u.shape.major);
>>>> +                input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
>>>> +                        event->mtouch.u.shape.minor);
>>>> +                break;
>>>> +            case XENKBD_MT_EV_ORIENT:
>>>> +                input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
>>>> +                        event->mtouch.u.orientation);
>>>> +                break;
>>>> +            }
>>>> +            /* only report syn when requested */
>>>> +            if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
>>>> +                dev = NULL;
>>>>           }
>>>>           if (dev)
>>>>               input_sync(dev);
>>>> @@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>                     const struct xenbus_device_id *id)
>>>>   {
>>>>       int ret, i;
>>>> -    unsigned int abs;
>>>> +    unsigned int abs, touch;
>>>>       struct xenkbd_info *info;
>>>> -    struct input_dev *kbd, *ptr;
>>>> +    struct input_dev *kbd, *ptr, *mtouch;
>>>>         info = kzalloc(sizeof(*info), GFP_KERNEL);
>>>>       if (!info) {
>>>> @@ -152,6 +216,17 @@ static int xenkbd_probe(struct xenbus_device 
>>>> *dev,
>>>>           }
>>>>       }
>>>>   +    touch = xenbus_read_unsigned(dev->nodename,
>>>> +                     XENKBD_FIELD_FEAT_MTOUCH, 0);
>>>> +    if (touch) {
>>>> +        ret = xenbus_write(XBT_NIL, dev->nodename,
>>>> +                   XENKBD_FIELD_REQ_MTOUCH, "1");
>>>> +        if (ret) {
>>>> +            pr_warning("xenkbd: can't request multi-touch");
>>>> +            touch = 0;
>>>> +        }
>>>> +    }
>>>> +
>>>>       /* keyboard */
>>>>       kbd = input_allocate_device();
>>>>       if (!kbd)
>>>> @@ -208,6 +283,67 @@ static int xenkbd_probe(struct xenbus_device 
>>>> *dev,
>>>>       }
>>>>       info->ptr = ptr;
>>>>   +    /* multi-touch device */
>>>> +    if (touch) {
>>>> +        int num_cont, width, height;
>>>> +
>>>> +        mtouch = input_allocate_device();
>>>> +        if (!mtouch)
>>>> +            goto error_nomem;
>>>> +
>>>> +        num_cont = xenbus_read_unsigned(info->xbdev->nodename,
>>>> +                        XENKBD_FIELD_MT_NUM_CONTACTS,
>>>> +                        1);
>>>> +        width = xenbus_read_unsigned(info->xbdev->nodename,
>>>> +                         XENKBD_FIELD_MT_WIDTH,
>>>> +                         XENFB_WIDTH);
>>>> +        height = xenbus_read_unsigned(info->xbdev->nodename,
>>>> +                          XENKBD_FIELD_MT_HEIGHT,
>>>> +                          XENFB_HEIGHT);
>>> Curious why you need separate parameters here too...
>> This is because mt parameters are different from ptr
>> in a way that they are configurable per front driver's
>> instance rather than per backend, e.g. in XenStore:
>>
>> /local/domain/0/backend/vkbd/1/0/width = "1920"
>> /local/domain/0/backend/vkbd/1/0/height = "1080"
>>
>> /local/domain/1/device/vkbd/0/multi-touch-width = "1920"
>> /local/domain/1/device/vkbd/0/multi-touch-height = "1080"
>> /local/domain/1/device/vkbd/0/multi-touch-num-contacts = "10"
>>
>> /local/domain/1/device/vkbd/1/multi-touch-width = "800"
>> /local/domain/1/device/vkbd/1/multi-touch-height = "600"
>> /local/domain/1/device/vkbd/1/multi-touch-num-contacts = "3"
>>
>> The main reason for such configuration is that you can
>> configure multiple mt input devices even for the same guest
>> with different resolutions which may not match those
>> configured for ptr.
>> (In my use-case I use new displif protocol [1] in conjunction
>> with mt input devices and the corresponding backend is not
>> QEMU's xenfb)
>>
>> As to module parameters, I added those to be consistent with
>> ptr device. Do you think we can live without them and
>> do you want me to remove them?
>>>> +
>>>> +        mtouch->name = "Xen Virtual Multi-touch";
>>>> +        mtouch->phys = info->phys;
>>>> +        mtouch->id.bustype = BUS_PCI;
>>>> +        mtouch->id.vendor = 0x5853;
>>>> +        mtouch->id.product = 0xfffd;
>>>> +
>>>> +        __set_bit(EV_ABS, mtouch->evbit);
>>>> +        __set_bit(EV_KEY, mtouch->evbit);
>>>> +        __set_bit(BTN_TOUCH, mtouch->keybit);
>>>> +
>>>> +        input_set_abs_params(mtouch, ABS_X,
>>>> +                     0, width, 0, 0);
>>>> +        input_set_abs_params(mtouch, ABS_Y,
>>>> +                     0, height, 0, 0);
>>>> +        input_set_abs_params(mtouch, ABS_PRESSURE,
>>>> +                     0, 255, 0, 0);
>>>> +
>>>> +        input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
>>>> +                     0, 255, 0, 0);
>>>> +        input_set_abs_params(mtouch, ABS_MT_POSITION_X,
>>>> +                     0, width, 0, 0);
>>>> +        input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
>>>> +                     0, height, 0, 0);
>>>> +        input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>>>> +                     0, 255, 0, 0);
>>>> +
>>>> +        input_mt_init_slots(mtouch, num_cont, 0);
>>>> +
>>>> +        mtouch_size[KPARAM_MT_X] = width;
>>>> +        mtouch_size[KPARAM_MT_Y] = height;
>>>> +        info->mtouch_cur_contact_id = -1;
>>>> +
>>>> +        ret = input_register_device(mtouch);
>>>> +        if (ret) {
>>>> +            input_free_device(mtouch);
>>>> +            xenbus_dev_fatal(info->xbdev, ret,
>>>> +                     "input_register_device(mtouch)");
>>>> +            goto error;
>>>> +        }
>>>> +        info->mtouch_cur_contact_id = -1;
>>>> +        info->mtouch = mtouch;
>>>> +    }
>>>> +
>>>>       ret = xenkbd_connect_backend(dev, info);
>>>>       if (ret < 0)
>>>>           goto error;
>>>> @@ -240,6 +376,8 @@ static int xenkbd_remove(struct xenbus_device 
>>>> *dev)
>>>>           input_unregister_device(info->kbd);
>>>>       if (info->ptr)
>>>>           input_unregister_device(info->ptr);
>>>> +    if (info->mtouch)
>>>> +        input_unregister_device(info->mtouch);
>>>>       free_page((unsigned long)info->page);
>>>>       kfree(info);
>>>>       return 0;
>>>> -- 
>>>> 2.7.4
>>>>
>>> Thanks.
>> Thank you,
>> Oleksandr
>> [1] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.12&id=e27c533dc4d0338266ccb6dab428150d4d629e6a
>>
>
> As all the dependencies are now merged into the kernel and *if*
> the above sounds reasonable for you can we please proceed with this 
> patch?
>
> Thank you,
> Oleksandr

Re: [PATCH 2/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

Hi, Dmitry!

It's been quite a while now, I'm just wondering if
you had a chance to look at the patch?

Thank you,
Oleksandr

On 05/12/2017 04:44 PM, Oleksandr Andrushchenko wrote:
> gentle reminder
>
>
> On 05/05/2017 07:45 AM, Oleksandr Andrushchenko wrote:
>> Hi, Dmitry!
>>
>> On 04/21/2017 09:40 AM, Oleksandr Andrushchenko wrote:
>>> Hi, Dmitry!
>>>
>>> On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
>>>> Hi Oleksandr,
>>>>
>>>> On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko 
>>>> wrote:
>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>
>>>>> Extend xen_kbdfront to provide multi-touch support
>>>>> to unprivileged domains.
>>>>>
>>>>> Signed-off-by: Oleksandr Andrushchenko 
>>>>> <oleksandr_andrushchenko@epam.com>
>>>>> ---
>>>>>   drivers/input/misc/xen-kbdfront.c | 142 
>>>>> +++++++++++++++++++++++++++++++++++++-
>>>>>   1 file changed, 140 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/input/misc/xen-kbdfront.c 
>>>>> b/drivers/input/misc/xen-kbdfront.c
>>>>> index 01c27b4c3288..e5d064aaa237 100644
>>>>> --- a/drivers/input/misc/xen-kbdfront.c
>>>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>>>> @@ -17,6 +17,7 @@
>>>>>   #include <linux/errno.h>
>>>>>   #include <linux/module.h>
>>>>>   #include <linux/input.h>
>>>>> +#include <linux/input/mt.h>
>>>>>   #include <linux/slab.h>
>>>>>     #include <asm/xen/hypervisor.h>
>>>>> @@ -34,11 +35,14 @@
>>>>>   struct xenkbd_info {
>>>>>       struct input_dev *kbd;
>>>>>       struct input_dev *ptr;
>>>>> +    struct input_dev *mtouch;
>>>>>       struct xenkbd_page *page;
>>>>>       int gref;
>>>>>       int irq;
>>>>>       struct xenbus_device *xbdev;
>>>>>       char phys[32];
>>>>> +    /* current MT slot/contact ID we are injecting events in */
>>>>> +    int mtouch_cur_contact_id;
>>>>>   };
>>>>>     enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
>>>>> @@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
>>>>>   MODULE_PARM_DESC(ptr_size,
>>>>>       "Pointing device width, height in pixels (default 800,600)");
>>>>>   +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>>>>> +static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, 
>>>>> XENFB_HEIGHT };
>>>>> +module_param_array(mtouch_size, int, NULL, 0444);
>>>>> +MODULE_PARM_DESC(ptr_size,
>>>>> +    "Multi-touch device width, height in pixels (default 800,600)");
>>>>> +
>>>> Why do you need separate module parameters for multi-touch device?
>>> please see below
>>>>
>>>>>   static int xenkbd_remove(struct xenbus_device *);
>>>>>   static int xenkbd_connect_backend(struct xenbus_device *, struct 
>>>>> xenkbd_info *);
>>>>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>>>>> @@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void 
>>>>> *dev_id)
>>>>>                   input_report_rel(dev, REL_WHEEL,
>>>>>                            -event->pos.rel_z);
>>>>>               break;
>>>>> +        case XENKBD_TYPE_MTOUCH:
>>>>> +            dev = info->mtouch;
>>>>> +            if (unlikely(!dev))
>>>>> +                break;
>>>>> +            if (unlikely(event->mtouch.contact_id !=
>>>>> +                    info->mtouch_cur_contact_id)) {
>>>> Why is this unlikely? Does contact ID changes once in 1000 packets or
>>>> even less?
>>> Mu assumption was that regardless of the fact that we are multi-touch
>>> device still single touches will come in more frequently
>>> But I can remove *unlikely* if my assumption is not correct
>>>>> + info->mtouch_cur_contact_id =
>>>>> +                    event->mtouch.contact_id;
>>>>> +                input_mt_slot(dev, event->mtouch.contact_id);
>>>>> +            }
>>>>> +            switch (event->mtouch.event_type) {
>>>>> +            case XENKBD_MT_EV_DOWN:
>>>>> +                input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>>> +                               true);
>>>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>>> +                        event->mtouch.u.pos.abs_x);
>>>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>>> +                        event->mtouch.u.pos.abs_y);
>>>>> +                input_event(dev, EV_ABS, ABS_X,
>>>>> +                        event->mtouch.u.pos.abs_x);
>>>>> +                input_event(dev, EV_ABS, ABS_Y,
>>>>> +                        event->mtouch.u.pos.abs_y);
>>>>> +                break;
>>>>> +            case XENKBD_MT_EV_UP:
>>>>> +                input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>>> +                               false);
>>>>> +                break;
>>>>> +            case XENKBD_MT_EV_MOTION:
>>>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>>> +                        event->mtouch.u.pos.abs_x);
>>>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>>> +                        event->mtouch.u.pos.abs_y);
>>>>> +                input_event(dev, EV_ABS, ABS_X,
>>>>> +                        event->mtouch.u.pos.abs_x);
>>>>> +                input_event(dev, EV_ABS, ABS_Y,
>>>>> +                        event->mtouch.u.pos.abs_y);
>>>>> +                break;
>>>>> +            case XENKBD_MT_EV_SYN:
>>>>> +                input_mt_sync_frame(dev);
>>>>> +                break;
>>>>> +            case XENKBD_MT_EV_SHAPE:
>>>>> +                input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
>>>>> +                        event->mtouch.u.shape.major);
>>>>> +                input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
>>>>> +                        event->mtouch.u.shape.minor);
>>>>> +                break;
>>>>> +            case XENKBD_MT_EV_ORIENT:
>>>>> +                input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
>>>>> +                        event->mtouch.u.orientation);
>>>>> +                break;
>>>>> +            }
>>>>> +            /* only report syn when requested */
>>>>> +            if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
>>>>> +                dev = NULL;
>>>>>           }
>>>>>           if (dev)
>>>>>               input_sync(dev);
>>>>> @@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device 
>>>>> *dev,
>>>>>                     const struct xenbus_device_id *id)
>>>>>   {
>>>>>       int ret, i;
>>>>> -    unsigned int abs;
>>>>> +    unsigned int abs, touch;
>>>>>       struct xenkbd_info *info;
>>>>> -    struct input_dev *kbd, *ptr;
>>>>> +    struct input_dev *kbd, *ptr, *mtouch;
>>>>>         info = kzalloc(sizeof(*info), GFP_KERNEL);
>>>>>       if (!info) {
>>>>> @@ -152,6 +216,17 @@ static int xenkbd_probe(struct xenbus_device 
>>>>> *dev,
>>>>>           }
>>>>>       }
>>>>>   +    touch = xenbus_read_unsigned(dev->nodename,
>>>>> +                     XENKBD_FIELD_FEAT_MTOUCH, 0);
>>>>> +    if (touch) {
>>>>> +        ret = xenbus_write(XBT_NIL, dev->nodename,
>>>>> +                   XENKBD_FIELD_REQ_MTOUCH, "1");
>>>>> +        if (ret) {
>>>>> +            pr_warning("xenkbd: can't request multi-touch");
>>>>> +            touch = 0;
>>>>> +        }
>>>>> +    }
>>>>> +
>>>>>       /* keyboard */
>>>>>       kbd = input_allocate_device();
>>>>>       if (!kbd)
>>>>> @@ -208,6 +283,67 @@ static int xenkbd_probe(struct xenbus_device 
>>>>> *dev,
>>>>>       }
>>>>>       info->ptr = ptr;
>>>>>   +    /* multi-touch device */
>>>>> +    if (touch) {
>>>>> +        int num_cont, width, height;
>>>>> +
>>>>> +        mtouch = input_allocate_device();
>>>>> +        if (!mtouch)
>>>>> +            goto error_nomem;
>>>>> +
>>>>> +        num_cont = xenbus_read_unsigned(info->xbdev->nodename,
>>>>> +                        XENKBD_FIELD_MT_NUM_CONTACTS,
>>>>> +                        1);
>>>>> +        width = xenbus_read_unsigned(info->xbdev->nodename,
>>>>> +                         XENKBD_FIELD_MT_WIDTH,
>>>>> +                         XENFB_WIDTH);
>>>>> +        height = xenbus_read_unsigned(info->xbdev->nodename,
>>>>> +                          XENKBD_FIELD_MT_HEIGHT,
>>>>> +                          XENFB_HEIGHT);
>>>> Curious why you need separate parameters here too...
>>> This is because mt parameters are different from ptr
>>> in a way that they are configurable per front driver's
>>> instance rather than per backend, e.g. in XenStore:
>>>
>>> /local/domain/0/backend/vkbd/1/0/width = "1920"
>>> /local/domain/0/backend/vkbd/1/0/height = "1080"
>>>
>>> /local/domain/1/device/vkbd/0/multi-touch-width = "1920"
>>> /local/domain/1/device/vkbd/0/multi-touch-height = "1080"
>>> /local/domain/1/device/vkbd/0/multi-touch-num-contacts = "10"
>>>
>>> /local/domain/1/device/vkbd/1/multi-touch-width = "800"
>>> /local/domain/1/device/vkbd/1/multi-touch-height = "600"
>>> /local/domain/1/device/vkbd/1/multi-touch-num-contacts = "3"
>>>
>>> The main reason for such configuration is that you can
>>> configure multiple mt input devices even for the same guest
>>> with different resolutions which may not match those
>>> configured for ptr.
>>> (In my use-case I use new displif protocol [1] in conjunction
>>> with mt input devices and the corresponding backend is not
>>> QEMU's xenfb)
>>>
>>> As to module parameters, I added those to be consistent with
>>> ptr device. Do you think we can live without them and
>>> do you want me to remove them?
>>>>> +
>>>>> +        mtouch->name = "Xen Virtual Multi-touch";
>>>>> +        mtouch->phys = info->phys;
>>>>> +        mtouch->id.bustype = BUS_PCI;
>>>>> +        mtouch->id.vendor = 0x5853;
>>>>> +        mtouch->id.product = 0xfffd;
>>>>> +
>>>>> +        __set_bit(EV_ABS, mtouch->evbit);
>>>>> +        __set_bit(EV_KEY, mtouch->evbit);
>>>>> +        __set_bit(BTN_TOUCH, mtouch->keybit);
>>>>> +
>>>>> +        input_set_abs_params(mtouch, ABS_X,
>>>>> +                     0, width, 0, 0);
>>>>> +        input_set_abs_params(mtouch, ABS_Y,
>>>>> +                     0, height, 0, 0);
>>>>> +        input_set_abs_params(mtouch, ABS_PRESSURE,
>>>>> +                     0, 255, 0, 0);
>>>>> +
>>>>> +        input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
>>>>> +                     0, 255, 0, 0);
>>>>> +        input_set_abs_params(mtouch, ABS_MT_POSITION_X,
>>>>> +                     0, width, 0, 0);
>>>>> +        input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
>>>>> +                     0, height, 0, 0);
>>>>> +        input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>>>>> +                     0, 255, 0, 0);
>>>>> +
>>>>> +        input_mt_init_slots(mtouch, num_cont, 0);
>>>>> +
>>>>> +        mtouch_size[KPARAM_MT_X] = width;
>>>>> +        mtouch_size[KPARAM_MT_Y] = height;
>>>>> +        info->mtouch_cur_contact_id = -1;
>>>>> +
>>>>> +        ret = input_register_device(mtouch);
>>>>> +        if (ret) {
>>>>> +            input_free_device(mtouch);
>>>>> +            xenbus_dev_fatal(info->xbdev, ret,
>>>>> +                     "input_register_device(mtouch)");
>>>>> +            goto error;
>>>>> +        }
>>>>> +        info->mtouch_cur_contact_id = -1;
>>>>> +        info->mtouch = mtouch;
>>>>> +    }
>>>>> +
>>>>>       ret = xenkbd_connect_backend(dev, info);
>>>>>       if (ret < 0)
>>>>>           goto error;
>>>>> @@ -240,6 +376,8 @@ static int xenkbd_remove(struct xenbus_device 
>>>>> *dev)
>>>>>           input_unregister_device(info->kbd);
>>>>>       if (info->ptr)
>>>>>           input_unregister_device(info->ptr);
>>>>> +    if (info->mtouch)
>>>>> +        input_unregister_device(info->mtouch);
>>>>>       free_page((unsigned long)info->page);
>>>>>       kfree(info);
>>>>>       return 0;
>>>>> -- 
>>>>> 2.7.4
>>>>>
>>>> Thanks.
>>> Thank you,
>>> Oleksandr
>>> [1] 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.12&id=e27c533dc4d0338266ccb6dab428150d4d629e6a
>>>
>>
>> As all the dependencies are now merged into the kernel and *if*
>> the above sounds reasonable for you can we please proceed with this 
>> patch?
>>
>> Thank you,
>> Oleksandr
>

Re: [PATCH 2/2] xen/input: add multi-touch support

[Dmitry Torokhov]

On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko wrote:
> Hi, Dmitry!
> 
> On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
> >Hi Oleksandr,
> >
> >On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
> >>From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>
> >>Extend xen_kbdfront to provide multi-touch support
> >>to unprivileged domains.
> >>
> >>Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>---
> >>  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
> >>  1 file changed, 140 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> >>index 01c27b4c3288..e5d064aaa237 100644
> >>--- a/drivers/input/misc/xen-kbdfront.c
> >>+++ b/drivers/input/misc/xen-kbdfront.c
> >>@@ -17,6 +17,7 @@
> >>  #include <linux/errno.h>
> >>  #include <linux/module.h>
> >>  #include <linux/input.h>
> >>+#include <linux/input/mt.h>
> >>  #include <linux/slab.h>
> >>  #include <asm/xen/hypervisor.h>
> >>@@ -34,11 +35,14 @@
> >>  struct xenkbd_info {
> >>  	struct input_dev *kbd;
> >>  	struct input_dev *ptr;
> >>+	struct input_dev *mtouch;
> >>  	struct xenkbd_page *page;
> >>  	int gref;
> >>  	int irq;
> >>  	struct xenbus_device *xbdev;
> >>  	char phys[32];
> >>+	/* current MT slot/contact ID we are injecting events in */
> >>+	int mtouch_cur_contact_id;
> >>  };
> >>  enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
> >>@@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
> >>  MODULE_PARM_DESC(ptr_size,
> >>  	"Pointing device width, height in pixels (default 800,600)");
> >>+enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
> >>+static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
> >>+module_param_array(mtouch_size, int, NULL, 0444);
> >>+MODULE_PARM_DESC(ptr_size,
> >>+	"Multi-touch device width, height in pixels (default 800,600)");
> >>+
> >Why do you need separate module parameters for multi-touch device?
> please see below
> >
> >>  static int xenkbd_remove(struct xenbus_device *);
> >>  static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
> >>  static void xenkbd_disconnect_backend(struct xenkbd_info *);
> >>@@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void *dev_id)
> >>  				input_report_rel(dev, REL_WHEEL,
> >>  						 -event->pos.rel_z);
> >>  			break;
> >>+		case XENKBD_TYPE_MTOUCH:
> >>+			dev = info->mtouch;
> >>+			if (unlikely(!dev))
> >>+				break;
> >>+			if (unlikely(event->mtouch.contact_id !=
> >>+					info->mtouch_cur_contact_id)) {
> >Why is this unlikely? Does contact ID changes once in 1000 packets or
> >even less?
> Mu assumption was that regardless of the fact that we are multi-touch
> device still single touches will come in more frequently
> But I can remove *unlikely* if my assumption is not correct

I think the normal expectation is that "unlikely" is supposed for
something that happens once in a blue moon, so I'd rather remove it.

> >>+				info->mtouch_cur_contact_id =
> >>+					event->mtouch.contact_id;
> >>+				input_mt_slot(dev, event->mtouch.contact_id);
> >>+			}
> >>+			switch (event->mtouch.event_type) {
> >>+			case XENKBD_MT_EV_DOWN:
> >>+				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
> >>+							   true);

Should we establish tool event? We have MT_TOOL_PEN, etc.

> >>+				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
> >>+					    event->mtouch.u.pos.abs_x);
> >>+				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
> >>+					    event->mtouch.u.pos.abs_y);
> >>+				input_event(dev, EV_ABS, ABS_X,
> >>+					    event->mtouch.u.pos.abs_x);
> >>+				input_event(dev, EV_ABS, ABS_Y,
> >>+					    event->mtouch.u.pos.abs_y);
> >>+				break;
> >>+			case XENKBD_MT_EV_UP:
> >>+				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
> >>+							   false);
> >>+				break;
> >>+			case XENKBD_MT_EV_MOTION:
> >>+				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
> >>+					    event->mtouch.u.pos.abs_x);
> >>+				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
> >>+					    event->mtouch.u.pos.abs_y);
> >>+				input_event(dev, EV_ABS, ABS_X,
> >>+					    event->mtouch.u.pos.abs_x);
> >>+				input_event(dev, EV_ABS, ABS_Y,
> >>+					    event->mtouch.u.pos.abs_y);
> >>+				break;
> >>+			case XENKBD_MT_EV_SYN:
> >>+				input_mt_sync_frame(dev);
> >>+				break;
> >>+			case XENKBD_MT_EV_SHAPE:
> >>+				input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
> >>+					    event->mtouch.u.shape.major);
> >>+				input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
> >>+					    event->mtouch.u.shape.minor);
> >>+				break;
> >>+			case XENKBD_MT_EV_ORIENT:
> >>+				input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
> >>+					    event->mtouch.u.orientation);
> >>+				break;
> >>+			}
> >>+			/* only report syn when requested */
> >>+			if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
> >>+				dev = NULL;
> >>  		}
> >>  		if (dev)
> >>  			input_sync(dev);
> >>@@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >>  				  const struct xenbus_device_id *id)
> >>  {
> >>  	int ret, i;
> >>-	unsigned int abs;
> >>+	unsigned int abs, touch;
> >>  	struct xenkbd_info *info;
> >>-	struct input_dev *kbd, *ptr;
> >>+	struct input_dev *kbd, *ptr, *mtouch;
> >>  	info = kzalloc(sizeof(*info), GFP_KERNEL);
> >>  	if (!info) {
> >>@@ -152,6 +216,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >>  		}
> >>  	}
> >>+	touch = xenbus_read_unsigned(dev->nodename,
> >>+				     XENKBD_FIELD_FEAT_MTOUCH, 0);
> >>+	if (touch) {
> >>+		ret = xenbus_write(XBT_NIL, dev->nodename,
> >>+				   XENKBD_FIELD_REQ_MTOUCH, "1");
> >>+		if (ret) {
> >>+			pr_warning("xenkbd: can't request multi-touch");
> >>+			touch = 0;
> >>+		}
> >>+	}
> >>+
> >>  	/* keyboard */
> >>  	kbd = input_allocate_device();
> >>  	if (!kbd)
> >>@@ -208,6 +283,67 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >>  	}
> >>  	info->ptr = ptr;
> >>+	/* multi-touch device */
> >>+	if (touch) {
> >>+		int num_cont, width, height;
> >>+
> >>+		mtouch = input_allocate_device();
> >>+		if (!mtouch)
> >>+			goto error_nomem;
> >>+
> >>+		num_cont = xenbus_read_unsigned(info->xbdev->nodename,
> >>+						XENKBD_FIELD_MT_NUM_CONTACTS,
> >>+						1);

Should we refuse MT devices with number of contacts less than 2?

> >>+		width = xenbus_read_unsigned(info->xbdev->nodename,
> >>+					     XENKBD_FIELD_MT_WIDTH,
> >>+					     XENFB_WIDTH);
> >>+		height = xenbus_read_unsigned(info->xbdev->nodename,
> >>+					      XENKBD_FIELD_MT_HEIGHT,
> >>+					      XENFB_HEIGHT);
> >Curious why you need separate parameters here too...
> This is because mt parameters are different from ptr
> in a way that they are configurable per front driver's
> instance rather than per backend, e.g. in XenStore:
> 
> /local/domain/0/backend/vkbd/1/0/width = "1920"
> /local/domain/0/backend/vkbd/1/0/height = "1080"
> 
> /local/domain/1/device/vkbd/0/multi-touch-width = "1920"
> /local/domain/1/device/vkbd/0/multi-touch-height = "1080"
> /local/domain/1/device/vkbd/0/multi-touch-num-contacts = "10"
> 
> /local/domain/1/device/vkbd/1/multi-touch-width = "800"
> /local/domain/1/device/vkbd/1/multi-touch-height = "600"
> /local/domain/1/device/vkbd/1/multi-touch-num-contacts = "3"
> 
> The main reason for such configuration is that you can
> configure multiple mt input devices even for the same guest
> with different resolutions which may not match those
> configured for ptr.
> (In my use-case I use new displif protocol [1] in conjunction
> with mt input devices and the corresponding backend is not
> QEMU's xenfb)

I see.

> 
> As to module parameters, I added those to be consistent with
> ptr device. Do you think we can live without them and
> do you want me to remove them?

Yes, I think we better. I am also confused by the way you are handling
the module parameters. It looks to me you update them with data passed
from the backend, but never use the data...

> >>+
> >>+		mtouch->name = "Xen Virtual Multi-touch";
> >>+		mtouch->phys = info->phys;
> >>+		mtouch->id.bustype = BUS_PCI;
> >>+		mtouch->id.vendor = 0x5853;
> >>+		mtouch->id.product = 0xfffd;
> >>+
> >>+		__set_bit(EV_ABS, mtouch->evbit);
> >>+		__set_bit(EV_KEY, mtouch->evbit);
> >>+		__set_bit(BTN_TOUCH, mtouch->keybit);
> >>+
> >>+		input_set_abs_params(mtouch, ABS_X,
> >>+				     0, width, 0, 0);
> >>+		input_set_abs_params(mtouch, ABS_Y,
> >>+				     0, height, 0, 0);
> >>+		input_set_abs_params(mtouch, ABS_PRESSURE,
> >>+				     0, 255, 0, 0);
> >>+
> >>+		input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
> >>+				     0, 255, 0, 0);
> >>+		input_set_abs_params(mtouch, ABS_MT_POSITION_X,
> >>+				     0, width, 0, 0);
> >>+		input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
> >>+				     0, height, 0, 0);
> >>+		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
> >>+				     0, 255, 0, 0);
> >>+
> >>+		input_mt_init_slots(mtouch, num_cont, 0);

We need error handling here. Also, it would be nice if we set INPUT_MT_*
flags here, so that userspace had better chance of figuring how to
handle the device.

> >>+
> >>+		mtouch_size[KPARAM_MT_X] = width;
> >>+		mtouch_size[KPARAM_MT_Y] = height;
> >>+		info->mtouch_cur_contact_id = -1;
> >>+
> >>+		ret = input_register_device(mtouch);
> >>+		if (ret) {
> >>+			input_free_device(mtouch);
> >>+			xenbus_dev_fatal(info->xbdev, ret,
> >>+					 "input_register_device(mtouch)");
> >>+			goto error;
> >>+		}
> >>+		info->mtouch_cur_contact_id = -1;
> >>+		info->mtouch = mtouch;
> >>+	}
> >>+
> >>  	ret = xenkbd_connect_backend(dev, info);
> >>  	if (ret < 0)
> >>  		goto error;
> >>@@ -240,6 +376,8 @@ static int xenkbd_remove(struct xenbus_device *dev)
> >>  		input_unregister_device(info->kbd);
> >>  	if (info->ptr)
> >>  		input_unregister_device(info->ptr);
> >>+	if (info->mtouch)
> >>+		input_unregister_device(info->mtouch);
> >>  	free_page((unsigned long)info->page);
> >>  	kfree(info);
> >>  	return 0;
> >>-- 
> >>2.7.4
> >>


Thanks.

-- 
Dmitry

Re: [PATCH 2/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

[-- Attachment #1: Type: text/plain, Size: 11162 bytes --]

Hi, Dmitry!

On 05/30/2017 08:51 AM, Dmitry Torokhov wrote:
> On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko wrote:
>> Hi, Dmitry!
>>
>> On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
>>> Hi Oleksandr,
>>>
>>> On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>
>>>> Extend xen_kbdfront to provide multi-touch support
>>>> to unprivileged domains.
>>>>
>>>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>> ---
>>>>   drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
>>>>   1 file changed, 140 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
>>>> index 01c27b4c3288..e5d064aaa237 100644
>>>> --- a/drivers/input/misc/xen-kbdfront.c
>>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>>> @@ -17,6 +17,7 @@
>>>>   #include <linux/errno.h>
>>>>   #include <linux/module.h>
>>>>   #include <linux/input.h>
>>>> +#include <linux/input/mt.h>
>>>>   #include <linux/slab.h>
>>>>   #include <asm/xen/hypervisor.h>
>>>> @@ -34,11 +35,14 @@
>>>>   struct xenkbd_info {
>>>>   	struct input_dev *kbd;
>>>>   	struct input_dev *ptr;
>>>> +	struct input_dev *mtouch;
>>>>   	struct xenkbd_page *page;
>>>>   	int gref;
>>>>   	int irq;
>>>>   	struct xenbus_device *xbdev;
>>>>   	char phys[32];
>>>> +	/* current MT slot/contact ID we are injecting events in */
>>>> +	int mtouch_cur_contact_id;
>>>>   };
>>>>   enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
>>>> @@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
>>>>   MODULE_PARM_DESC(ptr_size,
>>>>   	"Pointing device width, height in pixels (default 800,600)");
>>>> +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>>>> +static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
>>>> +module_param_array(mtouch_size, int, NULL, 0444);
>>>> +MODULE_PARM_DESC(ptr_size,
>>>> +	"Multi-touch device width, height in pixels (default 800,600)");
>>>> +
>>> Why do you need separate module parameters for multi-touch device?
>> please see below
>>>>   static int xenkbd_remove(struct xenbus_device *);
>>>>   static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
>>>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>>>> @@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void *dev_id)
>>>>   				input_report_rel(dev, REL_WHEEL,
>>>>   						 -event->pos.rel_z);
>>>>   			break;
>>>> +		case XENKBD_TYPE_MTOUCH:
>>>> +			dev = info->mtouch;
>>>> +			if (unlikely(!dev))
>>>> +				break;
>>>> +			if (unlikely(event->mtouch.contact_id !=
>>>> +					info->mtouch_cur_contact_id)) {
>>> Why is this unlikely? Does contact ID changes once in 1000 packets or
>>> even less?
>> Mu assumption was that regardless of the fact that we are multi-touch
>> device still single touches will come in more frequently
>> But I can remove *unlikely* if my assumption is not correct
> I think the normal expectation is that "unlikely" is supposed for
> something that happens once in a blue moon, so I'd rather remove it.
>
agree, removed "unlikely"
>>>> +				info->mtouch_cur_contact_id =
>>>> +					event->mtouch.contact_id;
>>>> +				input_mt_slot(dev, event->mtouch.contact_id);
>>>> +			}
>>>> +			switch (event->mtouch.event_type) {
>>>> +			case XENKBD_MT_EV_DOWN:
>>>> +				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>> +							   true);
> Should we establish tool event? We have MT_TOOL_PEN, etc.
I think that for multi-touch MT_TOOL_FINGER is enough
any reason we would also want MT_TOOL_PEN here?
(I guess MT_TOOL_PALM is not appropriate anyways)
>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>> +					    event->mtouch.u.pos.abs_x);
>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>> +					    event->mtouch.u.pos.abs_y);
>>>> +				input_event(dev, EV_ABS, ABS_X,
>>>> +					    event->mtouch.u.pos.abs_x);
>>>> +				input_event(dev, EV_ABS, ABS_Y,
>>>> +					    event->mtouch.u.pos.abs_y);
>>>> +				break;
>>>> +			case XENKBD_MT_EV_UP:
>>>> +				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>> +							   false);
>>>> +				break;
>>>> +			case XENKBD_MT_EV_MOTION:
>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>> +					    event->mtouch.u.pos.abs_x);
>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>> +					    event->mtouch.u.pos.abs_y);
>>>> +				input_event(dev, EV_ABS, ABS_X,
>>>> +					    event->mtouch.u.pos.abs_x);
>>>> +				input_event(dev, EV_ABS, ABS_Y,
>>>> +					    event->mtouch.u.pos.abs_y);
>>>> +				break;
>>>> +			case XENKBD_MT_EV_SYN:
>>>> +				input_mt_sync_frame(dev);
>>>> +				break;
>>>> +			case XENKBD_MT_EV_SHAPE:
>>>> +				input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
>>>> +					    event->mtouch.u.shape.major);
>>>> +				input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
>>>> +					    event->mtouch.u.shape.minor);
>>>> +				break;
>>>> +			case XENKBD_MT_EV_ORIENT:
>>>> +				input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
>>>> +					    event->mtouch.u.orientation);
>>>> +				break;
>>>> +			}
>>>> +			/* only report syn when requested */
>>>> +			if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
>>>> +				dev = NULL;
>>>>   		}
>>>>   		if (dev)
>>>>   			input_sync(dev);
>>>> @@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>   				  const struct xenbus_device_id *id)
>>>>   {
>>>>   	int ret, i;
>>>> -	unsigned int abs;
>>>> +	unsigned int abs, touch;
>>>>   	struct xenkbd_info *info;
>>>> -	struct input_dev *kbd, *ptr;
>>>> +	struct input_dev *kbd, *ptr, *mtouch;
>>>>   	info = kzalloc(sizeof(*info), GFP_KERNEL);
>>>>   	if (!info) {
>>>> @@ -152,6 +216,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>   		}
>>>>   	}
>>>> +	touch = xenbus_read_unsigned(dev->nodename,
>>>> +				     XENKBD_FIELD_FEAT_MTOUCH, 0);
>>>> +	if (touch) {
>>>> +		ret = xenbus_write(XBT_NIL, dev->nodename,
>>>> +				   XENKBD_FIELD_REQ_MTOUCH, "1");
>>>> +		if (ret) {
>>>> +			pr_warning("xenkbd: can't request multi-touch");
>>>> +			touch = 0;
>>>> +		}
>>>> +	}
>>>> +
>>>>   	/* keyboard */
>>>>   	kbd = input_allocate_device();
>>>>   	if (!kbd)
>>>> @@ -208,6 +283,67 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>   	}
>>>>   	info->ptr = ptr;
>>>> +	/* multi-touch device */
>>>> +	if (touch) {
>>>> +		int num_cont, width, height;
>>>> +
>>>> +		mtouch = input_allocate_device();
>>>> +		if (!mtouch)
>>>> +			goto error_nomem;
>>>> +
>>>> +		num_cont = xenbus_read_unsigned(info->xbdev->nodename,
>>>> +						XENKBD_FIELD_MT_NUM_CONTACTS,
>>>> +						1);
> Should we refuse MT devices with number of contacts less than 2?
we can, but I see no harm in 1. what is more, this may
allow guests to emulate more pointing devices
but, if you insist, then I will add appropriate code to
reject if number of contacts is less then 2
>>>> +		width = xenbus_read_unsigned(info->xbdev->nodename,
>>>> +					     XENKBD_FIELD_MT_WIDTH,
>>>> +					     XENFB_WIDTH);
>>>> +		height = xenbus_read_unsigned(info->xbdev->nodename,
>>>> +					      XENKBD_FIELD_MT_HEIGHT,
>>>> +					      XENFB_HEIGHT);
>>> Curious why you need separate parameters here too...
>> This is because mt parameters are different from ptr
>> in a way that they are configurable per front driver's
>> instance rather than per backend, e.g. in XenStore:
>>
>> /local/domain/0/backend/vkbd/1/0/width = "1920"
>> /local/domain/0/backend/vkbd/1/0/height = "1080"
>>
>> /local/domain/1/device/vkbd/0/multi-touch-width = "1920"
>> /local/domain/1/device/vkbd/0/multi-touch-height = "1080"
>> /local/domain/1/device/vkbd/0/multi-touch-num-contacts = "10"
>>
>> /local/domain/1/device/vkbd/1/multi-touch-width = "800"
>> /local/domain/1/device/vkbd/1/multi-touch-height = "600"
>> /local/domain/1/device/vkbd/1/multi-touch-num-contacts = "3"
>>
>> The main reason for such configuration is that you can
>> configure multiple mt input devices even for the same guest
>> with different resolutions which may not match those
>> configured for ptr.
>> (In my use-case I use new displif protocol [1] in conjunction
>> with mt input devices and the corresponding backend is not
>> QEMU's xenfb)
> I see.
>
>> As to module parameters, I added those to be consistent with
>> ptr device. Do you think we can live without them and
>> do you want me to remove them?
> Yes, I think we better. I am also confused by the way you are handling
> the module parameters. It looks to me you update them with data passed
> from the backend, but never use the data...
I have removed module parameters (the only use of those
was to be able to see configured width and height on
guest side, but this is minor)
>>>> +
>>>> +		mtouch->name = "Xen Virtual Multi-touch";
>>>> +		mtouch->phys = info->phys;
>>>> +		mtouch->id.bustype = BUS_PCI;
>>>> +		mtouch->id.vendor = 0x5853;
>>>> +		mtouch->id.product = 0xfffd;
>>>> +
>>>> +		__set_bit(EV_ABS, mtouch->evbit);
>>>> +		__set_bit(EV_KEY, mtouch->evbit);
>>>> +		__set_bit(BTN_TOUCH, mtouch->keybit);
>>>> +
>>>> +		input_set_abs_params(mtouch, ABS_X,
>>>> +				     0, width, 0, 0);
>>>> +		input_set_abs_params(mtouch, ABS_Y,
>>>> +				     0, height, 0, 0);
>>>> +		input_set_abs_params(mtouch, ABS_PRESSURE,
>>>> +				     0, 255, 0, 0);
>>>> +
>>>> +		input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
>>>> +				     0, 255, 0, 0);
>>>> +		input_set_abs_params(mtouch, ABS_MT_POSITION_X,
>>>> +				     0, width, 0, 0);
>>>> +		input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
>>>> +				     0, height, 0, 0);
>>>> +		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>>>> +				     0, 255, 0, 0);
>>>> +
>>>> +		input_mt_init_slots(mtouch, num_cont, 0);
> We need error handling here.
done
>   Also, it would be nice if we set INPUT_MT_*
> flags here, so that userspace had better chance of figuring how to
> handle the device.
done, I will use INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED
>>>> +
>>>> +		mtouch_size[KPARAM_MT_X] = width;
>>>> +		mtouch_size[KPARAM_MT_Y] = height;
>>>> +		info->mtouch_cur_contact_id = -1;
>>>> +
>>>> +		ret = input_register_device(mtouch);
>>>> +		if (ret) {
>>>> +			input_free_device(mtouch);
>>>> +			xenbus_dev_fatal(info->xbdev, ret,
>>>> +					 "input_register_device(mtouch)");
>>>> +			goto error;
>>>> +		}
>>>> +		info->mtouch_cur_contact_id = -1;
>>>> +		info->mtouch = mtouch;
>>>> +	}
>>>> +
>>>>   	ret = xenkbd_connect_backend(dev, info);
>>>>   	if (ret < 0)
>>>>   		goto error;
>>>> @@ -240,6 +376,8 @@ static int xenkbd_remove(struct xenbus_device *dev)
>>>>   		input_unregister_device(info->kbd);
>>>>   	if (info->ptr)
>>>>   		input_unregister_device(info->ptr);
>>>> +	if (info->mtouch)
>>>> +		input_unregister_device(info->mtouch);
>>>>   	free_page((unsigned long)info->page);
>>>>   	kfree(info);
>>>>   	return 0;
>>>> -- 
>>>> 2.7.4
>>>>
>
> Thanks.
>

For your convenience I am attaching the changes I am about
to put into v1 of the series:
  - remove unlikely
  - remove module parameters
  - error handling for input_mt_init_slots
  - let userspace better chance of figuring how to handle the device

Thank you,
Oleksandr

[-- Attachment #2: mtouch_v0_review_fixes.patch --]
[-- Type: text/x-patch, Size: 2379 bytes --]

>From e76506c55846e2bb4ccbafa430642e368643e51d Mon Sep 17 00:00:00 2001
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Date: Tue, 30 May 2017 14:49:58 +0300
Subject: [PATCH] Fix: remove unlikely Fix: remove module paramters Fix: error
 handling for input_mt_init_slots Fix: let userspace better chance of figuring
 how to handle the device

Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
---
 drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index 8266ef948a06..273d786a19cd 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -51,12 +51,6 @@ module_param_array(ptr_size, int, NULL, 0444);
 MODULE_PARM_DESC(ptr_size,
 	"Pointing device width, height in pixels (default 800,600)");
 
-enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
-static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
-module_param_array(mtouch_size, int, NULL, 0444);
-MODULE_PARM_DESC(ptr_size,
-	"Multi-touch device width, height in pixels (default 800,600)");
-
 static int xenkbd_remove(struct xenbus_device *);
 static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
 static void xenkbd_disconnect_backend(struct xenkbd_info *);
@@ -114,8 +108,8 @@ static irqreturn_t input_handler(int rq, void *dev_id)
 			dev = info->mtouch;
 			if (unlikely(!dev))
 				break;
-			if (unlikely(event->mtouch.contact_id !=
-					info->mtouch_cur_contact_id)) {
+			if (event->mtouch.contact_id !=
+					info->mtouch_cur_contact_id) {
 				info->mtouch_cur_contact_id =
 					event->mtouch.contact_id;
 				input_mt_slot(dev, event->mtouch.contact_id);
@@ -327,10 +321,15 @@ static int xenkbd_probe(struct xenbus_device *dev,
 		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
 				     0, 255, 0, 0);
 
-		input_mt_init_slots(mtouch, num_cont, 0);
+		ret = input_mt_init_slots(mtouch, num_cont,
+				INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED);
+		if (ret) {
+			input_free_device(mtouch);
+			xenbus_dev_fatal(info->xbdev, ret,
+					 "input_mt_init_slots");
+			goto error;
+		}
 
-		mtouch_size[KPARAM_MT_X] = width;
-		mtouch_size[KPARAM_MT_Y] = height;
 		info->mtouch_cur_contact_id = -1;
 
 		ret = input_register_device(mtouch);
-- 
2.7.4

Re: [PATCH 2/2] xen/input: add multi-touch support

[Dmitry Torokhov]

On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko wrote:
> Hi, Dmitry!
> 
> On 05/30/2017 08:51 AM, Dmitry Torokhov wrote:
> >On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko wrote:
> >>Hi, Dmitry!
> >>
> >>On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
> >>>Hi Oleksandr,
> >>>
> >>>On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
> >>>>From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>>>
> >>>>Extend xen_kbdfront to provide multi-touch support
> >>>>to unprivileged domains.
> >>>>
> >>>>Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>>>---
> >>>>  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
> >>>>  1 file changed, 140 insertions(+), 2 deletions(-)
> >>>>
> >>>>diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> >>>>index 01c27b4c3288..e5d064aaa237 100644
> >>>>--- a/drivers/input/misc/xen-kbdfront.c
> >>>>+++ b/drivers/input/misc/xen-kbdfront.c
> >>>>@@ -17,6 +17,7 @@
> >>>>  #include <linux/errno.h>
> >>>>  #include <linux/module.h>
> >>>>  #include <linux/input.h>
> >>>>+#include <linux/input/mt.h>
> >>>>  #include <linux/slab.h>
> >>>>  #include <asm/xen/hypervisor.h>
> >>>>@@ -34,11 +35,14 @@
> >>>>  struct xenkbd_info {
> >>>>  	struct input_dev *kbd;
> >>>>  	struct input_dev *ptr;
> >>>>+	struct input_dev *mtouch;
> >>>>  	struct xenkbd_page *page;
> >>>>  	int gref;
> >>>>  	int irq;
> >>>>  	struct xenbus_device *xbdev;
> >>>>  	char phys[32];
> >>>>+	/* current MT slot/contact ID we are injecting events in */
> >>>>+	int mtouch_cur_contact_id;
> >>>>  };
> >>>>  enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
> >>>>@@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
> >>>>  MODULE_PARM_DESC(ptr_size,
> >>>>  	"Pointing device width, height in pixels (default 800,600)");
> >>>>+enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
> >>>>+static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
> >>>>+module_param_array(mtouch_size, int, NULL, 0444);
> >>>>+MODULE_PARM_DESC(ptr_size,
> >>>>+	"Multi-touch device width, height in pixels (default 800,600)");
> >>>>+
> >>>Why do you need separate module parameters for multi-touch device?
> >>please see below
> >>>>  static int xenkbd_remove(struct xenbus_device *);
> >>>>  static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
> >>>>  static void xenkbd_disconnect_backend(struct xenkbd_info *);
> >>>>@@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void *dev_id)
> >>>>  				input_report_rel(dev, REL_WHEEL,
> >>>>  						 -event->pos.rel_z);
> >>>>  			break;
> >>>>+		case XENKBD_TYPE_MTOUCH:
> >>>>+			dev = info->mtouch;
> >>>>+			if (unlikely(!dev))
> >>>>+				break;
> >>>>+			if (unlikely(event->mtouch.contact_id !=
> >>>>+					info->mtouch_cur_contact_id)) {
> >>>Why is this unlikely? Does contact ID changes once in 1000 packets or
> >>>even less?
> >>Mu assumption was that regardless of the fact that we are multi-touch
> >>device still single touches will come in more frequently
> >>But I can remove *unlikely* if my assumption is not correct
> >I think the normal expectation is that "unlikely" is supposed for
> >something that happens once in a blue moon, so I'd rather remove it.
> >
> agree, removed "unlikely"
> >>>>+				info->mtouch_cur_contact_id =
> >>>>+					event->mtouch.contact_id;
> >>>>+				input_mt_slot(dev, event->mtouch.contact_id);
> >>>>+			}
> >>>>+			switch (event->mtouch.event_type) {
> >>>>+			case XENKBD_MT_EV_DOWN:
> >>>>+				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
> >>>>+							   true);
> >Should we establish tool event? We have MT_TOOL_PEN, etc.
> I think that for multi-touch MT_TOOL_FINGER is enough
> any reason we would also want MT_TOOL_PEN here?

Why would not you? Let's say you have a drawing application running in
guest that can make use of tool types. Why would not you want to tell it
that the tool user is currently using is in fact a pen and not finger?

> (I guess MT_TOOL_PALM is not appropriate anyways)

Depends on if you do straight pass-through from the host side or not. If
you stack does palm rejection before passing the data through then you
would not see MT_TOOL_PALM in guest.

> >>>>+				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
> >>>>+					    event->mtouch.u.pos.abs_x);
> >>>>+				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
> >>>>+					    event->mtouch.u.pos.abs_y);
> >>>>+				input_event(dev, EV_ABS, ABS_X,
> >>>>+					    event->mtouch.u.pos.abs_x);
> >>>>+				input_event(dev, EV_ABS, ABS_Y,
> >>>>+					    event->mtouch.u.pos.abs_y);
> >>>>+				break;
> >>>>+			case XENKBD_MT_EV_UP:
> >>>>+				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
> >>>>+							   false);
> >>>>+				break;
> >>>>+			case XENKBD_MT_EV_MOTION:
> >>>>+				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
> >>>>+					    event->mtouch.u.pos.abs_x);
> >>>>+				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
> >>>>+					    event->mtouch.u.pos.abs_y);
> >>>>+				input_event(dev, EV_ABS, ABS_X,
> >>>>+					    event->mtouch.u.pos.abs_x);
> >>>>+				input_event(dev, EV_ABS, ABS_Y,
> >>>>+					    event->mtouch.u.pos.abs_y);
> >>>>+				break;
> >>>>+			case XENKBD_MT_EV_SYN:
> >>>>+				input_mt_sync_frame(dev);
> >>>>+				break;
> >>>>+			case XENKBD_MT_EV_SHAPE:
> >>>>+				input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
> >>>>+					    event->mtouch.u.shape.major);
> >>>>+				input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
> >>>>+					    event->mtouch.u.shape.minor);
> >>>>+				break;
> >>>>+			case XENKBD_MT_EV_ORIENT:
> >>>>+				input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
> >>>>+					    event->mtouch.u.orientation);
> >>>>+				break;
> >>>>+			}
> >>>>+			/* only report syn when requested */
> >>>>+			if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
> >>>>+				dev = NULL;
> >>>>  		}
> >>>>  		if (dev)
> >>>>  			input_sync(dev);
> >>>>@@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >>>>  				  const struct xenbus_device_id *id)
> >>>>  {
> >>>>  	int ret, i;
> >>>>-	unsigned int abs;
> >>>>+	unsigned int abs, touch;
> >>>>  	struct xenkbd_info *info;
> >>>>-	struct input_dev *kbd, *ptr;
> >>>>+	struct input_dev *kbd, *ptr, *mtouch;
> >>>>  	info = kzalloc(sizeof(*info), GFP_KERNEL);
> >>>>  	if (!info) {
> >>>>@@ -152,6 +216,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >>>>  		}
> >>>>  	}
> >>>>+	touch = xenbus_read_unsigned(dev->nodename,
> >>>>+				     XENKBD_FIELD_FEAT_MTOUCH, 0);
> >>>>+	if (touch) {
> >>>>+		ret = xenbus_write(XBT_NIL, dev->nodename,
> >>>>+				   XENKBD_FIELD_REQ_MTOUCH, "1");
> >>>>+		if (ret) {
> >>>>+			pr_warning("xenkbd: can't request multi-touch");
> >>>>+			touch = 0;
> >>>>+		}
> >>>>+	}
> >>>>+
> >>>>  	/* keyboard */
> >>>>  	kbd = input_allocate_device();
> >>>>  	if (!kbd)
> >>>>@@ -208,6 +283,67 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >>>>  	}
> >>>>  	info->ptr = ptr;
> >>>>+	/* multi-touch device */
> >>>>+	if (touch) {
> >>>>+		int num_cont, width, height;
> >>>>+
> >>>>+		mtouch = input_allocate_device();
> >>>>+		if (!mtouch)
> >>>>+			goto error_nomem;
> >>>>+
> >>>>+		num_cont = xenbus_read_unsigned(info->xbdev->nodename,
> >>>>+						XENKBD_FIELD_MT_NUM_CONTACTS,
> >>>>+						1);
> >Should we refuse MT devices with number of contacts less than 2?
> we can, but I see no harm in 1. what is more, this may
> allow guests to emulate more pointing devices
> but, if you insist, then I will add appropriate code to
> reject if number of contacts is less then 2
> >>>>+		width = xenbus_read_unsigned(info->xbdev->nodename,
> >>>>+					     XENKBD_FIELD_MT_WIDTH,
> >>>>+					     XENFB_WIDTH);
> >>>>+		height = xenbus_read_unsigned(info->xbdev->nodename,
> >>>>+					      XENKBD_FIELD_MT_HEIGHT,
> >>>>+					      XENFB_HEIGHT);
> >>>Curious why you need separate parameters here too...
> >>This is because mt parameters are different from ptr
> >>in a way that they are configurable per front driver's
> >>instance rather than per backend, e.g. in XenStore:
> >>
> >>/local/domain/0/backend/vkbd/1/0/width = "1920"
> >>/local/domain/0/backend/vkbd/1/0/height = "1080"
> >>
> >>/local/domain/1/device/vkbd/0/multi-touch-width = "1920"
> >>/local/domain/1/device/vkbd/0/multi-touch-height = "1080"
> >>/local/domain/1/device/vkbd/0/multi-touch-num-contacts = "10"
> >>
> >>/local/domain/1/device/vkbd/1/multi-touch-width = "800"
> >>/local/domain/1/device/vkbd/1/multi-touch-height = "600"
> >>/local/domain/1/device/vkbd/1/multi-touch-num-contacts = "3"
> >>
> >>The main reason for such configuration is that you can
> >>configure multiple mt input devices even for the same guest
> >>with different resolutions which may not match those
> >>configured for ptr.
> >>(In my use-case I use new displif protocol [1] in conjunction
> >>with mt input devices and the corresponding backend is not
> >>QEMU's xenfb)
> >I see.
> >
> >>As to module parameters, I added those to be consistent with
> >>ptr device. Do you think we can live without them and
> >>do you want me to remove them?
> >Yes, I think we better. I am also confused by the way you are handling
> >the module parameters. It looks to me you update them with data passed
> >from the backend, but never use the data...
> I have removed module parameters (the only use of those
> was to be able to see configured width and height on
> guest side, but this is minor)

evtest would show it to you. Or you can query input device yourself
(EVIOCGABS iotcl).

> >>>>+
> >>>>+		mtouch->name = "Xen Virtual Multi-touch";
> >>>>+		mtouch->phys = info->phys;
> >>>>+		mtouch->id.bustype = BUS_PCI;
> >>>>+		mtouch->id.vendor = 0x5853;
> >>>>+		mtouch->id.product = 0xfffd;
> >>>>+
> >>>>+		__set_bit(EV_ABS, mtouch->evbit);
> >>>>+		__set_bit(EV_KEY, mtouch->evbit);
> >>>>+		__set_bit(BTN_TOUCH, mtouch->keybit);

Please make it
		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);

and drop all __set_bit()s.

> >>>>+
> >>>>+		input_set_abs_params(mtouch, ABS_X,
> >>>>+				     0, width, 0, 0);
> >>>>+		input_set_abs_params(mtouch, ABS_Y,
> >>>>+				     0, height, 0, 0);
> >>>>+		input_set_abs_params(mtouch, ABS_PRESSURE,
> >>>>+				     0, 255, 0, 0);
> >>>>+
> >>>>+		input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
> >>>>+				     0, 255, 0, 0);
> >>>>+		input_set_abs_params(mtouch, ABS_MT_POSITION_X,
> >>>>+				     0, width, 0, 0);
> >>>>+		input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
> >>>>+				     0, height, 0, 0);
> >>>>+		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
> >>>>+				     0, 255, 0, 0);
> >>>>+
> >>>>+		input_mt_init_slots(mtouch, num_cont, 0);
> >We need error handling here.
> done
> >  Also, it would be nice if we set INPUT_MT_*
> >flags here, so that userspace had better chance of figuring how to
> >handle the device.
> done, I will use INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED

Does that mean that your backend does not reliably report release of
contacts?

Thanks.

> >>>>+
> >>>>+		mtouch_size[KPARAM_MT_X] = width;
> >>>>+		mtouch_size[KPARAM_MT_Y] = height;
> >>>>+		info->mtouch_cur_contact_id = -1;
> >>>>+
> >>>>+		ret = input_register_device(mtouch);
> >>>>+		if (ret) {
> >>>>+			input_free_device(mtouch);
> >>>>+			xenbus_dev_fatal(info->xbdev, ret,
> >>>>+					 "input_register_device(mtouch)");
> >>>>+			goto error;
> >>>>+		}
> >>>>+		info->mtouch_cur_contact_id = -1;
> >>>>+		info->mtouch = mtouch;
> >>>>+	}
> >>>>+
> >>>>  	ret = xenkbd_connect_backend(dev, info);
> >>>>  	if (ret < 0)
> >>>>  		goto error;
> >>>>@@ -240,6 +376,8 @@ static int xenkbd_remove(struct xenbus_device *dev)
> >>>>  		input_unregister_device(info->kbd);
> >>>>  	if (info->ptr)
> >>>>  		input_unregister_device(info->ptr);
> >>>>+	if (info->mtouch)
> >>>>+		input_unregister_device(info->mtouch);
> >>>>  	free_page((unsigned long)info->page);
> >>>>  	kfree(info);
> >>>>  	return 0;
> >>>>-- 
> >>>>2.7.4
> >>>>
> >
> >Thanks.
> >
> 
> For your convenience I am attaching the changes I am about
> to put into v1 of the series:
>  - remove unlikely
>  - remove module parameters
>  - error handling for input_mt_init_slots
>  - let userspace better chance of figuring how to handle the device
> 
> Thank you,
> Oleksandr

> From e76506c55846e2bb4ccbafa430642e368643e51d Mon Sep 17 00:00:00 2001
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> Date: Tue, 30 May 2017 14:49:58 +0300
> Subject: [PATCH] Fix: remove unlikely Fix: remove module paramters Fix: error
>  handling for input_mt_init_slots Fix: let userspace better chance of figuring
>  how to handle the device
> 
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> ---
>  drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
>  1 file changed, 10 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> index 8266ef948a06..273d786a19cd 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -51,12 +51,6 @@ module_param_array(ptr_size, int, NULL, 0444);
>  MODULE_PARM_DESC(ptr_size,
>  	"Pointing device width, height in pixels (default 800,600)");
>  
> -enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
> -static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
> -module_param_array(mtouch_size, int, NULL, 0444);
> -MODULE_PARM_DESC(ptr_size,
> -	"Multi-touch device width, height in pixels (default 800,600)");
> -
>  static int xenkbd_remove(struct xenbus_device *);
>  static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
>  static void xenkbd_disconnect_backend(struct xenkbd_info *);
> @@ -114,8 +108,8 @@ static irqreturn_t input_handler(int rq, void *dev_id)
>  			dev = info->mtouch;
>  			if (unlikely(!dev))
>  				break;
> -			if (unlikely(event->mtouch.contact_id !=
> -					info->mtouch_cur_contact_id)) {
> +			if (event->mtouch.contact_id !=
> +					info->mtouch_cur_contact_id) {
>  				info->mtouch_cur_contact_id =
>  					event->mtouch.contact_id;
>  				input_mt_slot(dev, event->mtouch.contact_id);
> @@ -327,10 +321,15 @@ static int xenkbd_probe(struct xenbus_device *dev,
>  		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>  				     0, 255, 0, 0);
>  
> -		input_mt_init_slots(mtouch, num_cont, 0);
> +		ret = input_mt_init_slots(mtouch, num_cont,
> +				INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED);
> +		if (ret) {
> +			input_free_device(mtouch);
> +			xenbus_dev_fatal(info->xbdev, ret,
> +					 "input_mt_init_slots");
> +			goto error;
> +		}
>  
> -		mtouch_size[KPARAM_MT_X] = width;
> -		mtouch_size[KPARAM_MT_Y] = height;
>  		info->mtouch_cur_contact_id = -1;
>  
>  		ret = input_register_device(mtouch);
> -- 
> 2.7.4
> 


-- 
Dmitry

Re: [PATCH 2/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

Hi, Dmitry!

On 05/30/2017 07:37 PM, Dmitry Torokhov wrote:
> On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko wrote:
>> Hi, Dmitry!
>>
>> On 05/30/2017 08:51 AM, Dmitry Torokhov wrote:
>>> On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko wrote:
>>>> Hi, Dmitry!
>>>>
>>>> On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
>>>>> Hi Oleksandr,
>>>>>
>>>>> On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>
>>>>>> Extend xen_kbdfront to provide multi-touch support
>>>>>> to unprivileged domains.
>>>>>>
>>>>>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>> ---
>>>>>>   drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
>>>>>>   1 file changed, 140 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
>>>>>> index 01c27b4c3288..e5d064aaa237 100644
>>>>>> --- a/drivers/input/misc/xen-kbdfront.c
>>>>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>>>>> @@ -17,6 +17,7 @@
>>>>>>   #include <linux/errno.h>
>>>>>>   #include <linux/module.h>
>>>>>>   #include <linux/input.h>
>>>>>> +#include <linux/input/mt.h>
>>>>>>   #include <linux/slab.h>
>>>>>>   #include <asm/xen/hypervisor.h>
>>>>>> @@ -34,11 +35,14 @@
>>>>>>   struct xenkbd_info {
>>>>>>   	struct input_dev *kbd;
>>>>>>   	struct input_dev *ptr;
>>>>>> +	struct input_dev *mtouch;
>>>>>>   	struct xenkbd_page *page;
>>>>>>   	int gref;
>>>>>>   	int irq;
>>>>>>   	struct xenbus_device *xbdev;
>>>>>>   	char phys[32];
>>>>>> +	/* current MT slot/contact ID we are injecting events in */
>>>>>> +	int mtouch_cur_contact_id;
>>>>>>   };
>>>>>>   enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
>>>>>> @@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
>>>>>>   MODULE_PARM_DESC(ptr_size,
>>>>>>   	"Pointing device width, height in pixels (default 800,600)");
>>>>>> +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>>>>>> +static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
>>>>>> +module_param_array(mtouch_size, int, NULL, 0444);
>>>>>> +MODULE_PARM_DESC(ptr_size,
>>>>>> +	"Multi-touch device width, height in pixels (default 800,600)");
>>>>>> +
>>>>> Why do you need separate module parameters for multi-touch device?
>>>> please see below
>>>>>>   static int xenkbd_remove(struct xenbus_device *);
>>>>>>   static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
>>>>>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>>>>>> @@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void *dev_id)
>>>>>>   				input_report_rel(dev, REL_WHEEL,
>>>>>>   						 -event->pos.rel_z);
>>>>>>   			break;
>>>>>> +		case XENKBD_TYPE_MTOUCH:
>>>>>> +			dev = info->mtouch;
>>>>>> +			if (unlikely(!dev))
>>>>>> +				break;
>>>>>> +			if (unlikely(event->mtouch.contact_id !=
>>>>>> +					info->mtouch_cur_contact_id)) {
>>>>> Why is this unlikely? Does contact ID changes once in 1000 packets or
>>>>> even less?
>>>> Mu assumption was that regardless of the fact that we are multi-touch
>>>> device still single touches will come in more frequently
>>>> But I can remove *unlikely* if my assumption is not correct
>>> I think the normal expectation is that "unlikely" is supposed for
>>> something that happens once in a blue moon, so I'd rather remove it.
>>>
>> agree, removed "unlikely"
>>>>>> +				info->mtouch_cur_contact_id =
>>>>>> +					event->mtouch.contact_id;
>>>>>> +				input_mt_slot(dev, event->mtouch.contact_id);
>>>>>> +			}
>>>>>> +			switch (event->mtouch.event_type) {
>>>>>> +			case XENKBD_MT_EV_DOWN:
>>>>>> +				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>>>> +							   true);
>>> Should we establish tool event? We have MT_TOOL_PEN, etc.
>> I think that for multi-touch MT_TOOL_FINGER is enough
>> any reason we would also want MT_TOOL_PEN here?
> Why would not you? Let's say you have a drawing application running in
> guest that can make use of tool types. Why would not you want to tell it
> that the tool user is currently using is in fact a pen and not finger?
But it is a finger :) we are multi-touch, not multi pen

Besides, that, if I am about to implement pen support
(which I still not convinced we really need), how will I
do that?
My understanding is that I need 2 different slots to report
the same coordinates for finger and pen. This is because
input_mt_report_slot_state has a check that if tool has
changed for the current slot then a new tracking ID is set.
Do I also need to allocate twice more slots, so I can
report 2 * num_contacts events simultaneously (one for finger
and another for pen)?
That said, I believe we can start with multi-touch support
and if need be then add pen support as a separate change,
does that make sense for you?
>
>> (I guess MT_TOOL_PALM is not appropriate anyways)
> Depends on if you do straight pass-through from the host side or not. If
> you stack does palm rejection before passing the data through then you
> would not see MT_TOOL_PALM in guest.
the protocol used between guest and host is a generic one,
not using Linux types/constants/events.
So, no PALM/TOOL support is in place
>>>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>>>> +					    event->mtouch.u.pos.abs_x);
>>>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>>>> +					    event->mtouch.u.pos.abs_y);
>>>>>> +				input_event(dev, EV_ABS, ABS_X,
>>>>>> +					    event->mtouch.u.pos.abs_x);
>>>>>> +				input_event(dev, EV_ABS, ABS_Y,
>>>>>> +					    event->mtouch.u.pos.abs_y);
>>>>>> +				break;
>>>>>> +			case XENKBD_MT_EV_UP:
>>>>>> +				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>>>> +							   false);
>>>>>> +				break;
>>>>>> +			case XENKBD_MT_EV_MOTION:
>>>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>>>> +					    event->mtouch.u.pos.abs_x);
>>>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>>>> +					    event->mtouch.u.pos.abs_y);
>>>>>> +				input_event(dev, EV_ABS, ABS_X,
>>>>>> +					    event->mtouch.u.pos.abs_x);
>>>>>> +				input_event(dev, EV_ABS, ABS_Y,
>>>>>> +					    event->mtouch.u.pos.abs_y);
>>>>>> +				break;
>>>>>> +			case XENKBD_MT_EV_SYN:
>>>>>> +				input_mt_sync_frame(dev);
>>>>>> +				break;
>>>>>> +			case XENKBD_MT_EV_SHAPE:
>>>>>> +				input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
>>>>>> +					    event->mtouch.u.shape.major);
>>>>>> +				input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
>>>>>> +					    event->mtouch.u.shape.minor);
>>>>>> +				break;
>>>>>> +			case XENKBD_MT_EV_ORIENT:
>>>>>> +				input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
>>>>>> +					    event->mtouch.u.orientation);
>>>>>> +				break;
>>>>>> +			}
>>>>>> +			/* only report syn when requested */
>>>>>> +			if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
>>>>>> +				dev = NULL;
>>>>>>   		}
>>>>>>   		if (dev)
>>>>>>   			input_sync(dev);
>>>>>> @@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>>>   				  const struct xenbus_device_id *id)
>>>>>>   {
>>>>>>   	int ret, i;
>>>>>> -	unsigned int abs;
>>>>>> +	unsigned int abs, touch;
>>>>>>   	struct xenkbd_info *info;
>>>>>> -	struct input_dev *kbd, *ptr;
>>>>>> +	struct input_dev *kbd, *ptr, *mtouch;
>>>>>>   	info = kzalloc(sizeof(*info), GFP_KERNEL);
>>>>>>   	if (!info) {
>>>>>> @@ -152,6 +216,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>>>   		}
>>>>>>   	}
>>>>>> +	touch = xenbus_read_unsigned(dev->nodename,
>>>>>> +				     XENKBD_FIELD_FEAT_MTOUCH, 0);
>>>>>> +	if (touch) {
>>>>>> +		ret = xenbus_write(XBT_NIL, dev->nodename,
>>>>>> +				   XENKBD_FIELD_REQ_MTOUCH, "1");
>>>>>> +		if (ret) {
>>>>>> +			pr_warning("xenkbd: can't request multi-touch");
>>>>>> +			touch = 0;
>>>>>> +		}
>>>>>> +	}
>>>>>> +
>>>>>>   	/* keyboard */
>>>>>>   	kbd = input_allocate_device();
>>>>>>   	if (!kbd)
>>>>>> @@ -208,6 +283,67 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>>>   	}
>>>>>>   	info->ptr = ptr;
>>>>>> +	/* multi-touch device */
>>>>>> +	if (touch) {
>>>>>> +		int num_cont, width, height;
>>>>>> +
>>>>>> +		mtouch = input_allocate_device();
>>>>>> +		if (!mtouch)
>>>>>> +			goto error_nomem;
>>>>>> +
>>>>>> +		num_cont = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>> +						XENKBD_FIELD_MT_NUM_CONTACTS,
>>>>>> +						1);
>>> Should we refuse MT devices with number of contacts less than 2?
>> we can, but I see no harm in 1. what is more, this may
>> allow guests to emulate more pointing devices
>> but, if you insist, then I will add appropriate code to
>> reject if number of contacts is less then 2
>>>>>> +		width = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>> +					     XENKBD_FIELD_MT_WIDTH,
>>>>>> +					     XENFB_WIDTH);
>>>>>> +		height = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>> +					      XENKBD_FIELD_MT_HEIGHT,
>>>>>> +					      XENFB_HEIGHT);
>>>>> Curious why you need separate parameters here too...
>>>> This is because mt parameters are different from ptr
>>>> in a way that they are configurable per front driver's
>>>> instance rather than per backend, e.g. in XenStore:
>>>>
>>>> /local/domain/0/backend/vkbd/1/0/width = "1920"
>>>> /local/domain/0/backend/vkbd/1/0/height = "1080"
>>>>
>>>> /local/domain/1/device/vkbd/0/multi-touch-width = "1920"
>>>> /local/domain/1/device/vkbd/0/multi-touch-height = "1080"
>>>> /local/domain/1/device/vkbd/0/multi-touch-num-contacts = "10"
>>>>
>>>> /local/domain/1/device/vkbd/1/multi-touch-width = "800"
>>>> /local/domain/1/device/vkbd/1/multi-touch-height = "600"
>>>> /local/domain/1/device/vkbd/1/multi-touch-num-contacts = "3"
>>>>
>>>> The main reason for such configuration is that you can
>>>> configure multiple mt input devices even for the same guest
>>>> with different resolutions which may not match those
>>>> configured for ptr.
>>>> (In my use-case I use new displif protocol [1] in conjunction
>>>> with mt input devices and the corresponding backend is not
>>>> QEMU's xenfb)
>>> I see.
>>>
>>>> As to module parameters, I added those to be consistent with
>>>> ptr device. Do you think we can live without them and
>>>> do you want me to remove them?
>>> Yes, I think we better. I am also confused by the way you are handling
>>> the module parameters. It looks to me you update them with data passed
>> >from the backend, but never use the data...
>> I have removed module parameters (the only use of those
>> was to be able to see configured width and height on
>> guest side, but this is minor)
> evtest would show it to you. Or you can query input device yourself
> (EVIOCGABS iotcl).
yes, if embedded system (which is my target) has evtest
but it definitely does have ioctl though
>>>>>> +
>>>>>> +		mtouch->name = "Xen Virtual Multi-touch";
>>>>>> +		mtouch->phys = info->phys;
>>>>>> +		mtouch->id.bustype = BUS_PCI;
>>>>>> +		mtouch->id.vendor = 0x5853;
>>>>>> +		mtouch->id.product = 0xfffd;
>>>>>> +
>>>>>> +		__set_bit(EV_ABS, mtouch->evbit);
>>>>>> +		__set_bit(EV_KEY, mtouch->evbit);
>>>>>> +		__set_bit(BTN_TOUCH, mtouch->keybit);
> Please make it
> 		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
>
> and drop all __set_bit()s.
done, thank you
>>>>>> +
>>>>>> +		input_set_abs_params(mtouch, ABS_X,
>>>>>> +				     0, width, 0, 0);
>>>>>> +		input_set_abs_params(mtouch, ABS_Y,
>>>>>> +				     0, height, 0, 0);
>>>>>> +		input_set_abs_params(mtouch, ABS_PRESSURE,
>>>>>> +				     0, 255, 0, 0);
>>>>>> +
>>>>>> +		input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
>>>>>> +				     0, 255, 0, 0);
>>>>>> +		input_set_abs_params(mtouch, ABS_MT_POSITION_X,
>>>>>> +				     0, width, 0, 0);
>>>>>> +		input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
>>>>>> +				     0, height, 0, 0);
>>>>>> +		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>>>>>> +				     0, 255, 0, 0);
>>>>>> +
>>>>>> +		input_mt_init_slots(mtouch, num_cont, 0);
>>> We need error handling here.
>> done
>>>   Also, it would be nice if we set INPUT_MT_*
>>> flags here, so that userspace had better chance of figuring how to
>>> handle the device.
>> done, I will use INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED
> Does that mean that your backend does not reliably report release of
> contacts?
there is a ring buffer between host and guest,
so there is always a possibility (rather small I believe)
that the buffer overruns. Do you think I need INPUT_MT_DROP_UNUSED or
we can live without it?
>
> Thanks.
>
>>>>>> +
>>>>>> +		mtouch_size[KPARAM_MT_X] = width;
>>>>>> +		mtouch_size[KPARAM_MT_Y] = height;
>>>>>> +		info->mtouch_cur_contact_id = -1;
>>>>>> +
>>>>>> +		ret = input_register_device(mtouch);
>>>>>> +		if (ret) {
>>>>>> +			input_free_device(mtouch);
>>>>>> +			xenbus_dev_fatal(info->xbdev, ret,
>>>>>> +					 "input_register_device(mtouch)");
>>>>>> +			goto error;
>>>>>> +		}
>>>>>> +		info->mtouch_cur_contact_id = -1;
>>>>>> +		info->mtouch = mtouch;
>>>>>> +	}
>>>>>> +
>>>>>>   	ret = xenkbd_connect_backend(dev, info);
>>>>>>   	if (ret < 0)
>>>>>>   		goto error;
>>>>>> @@ -240,6 +376,8 @@ static int xenkbd_remove(struct xenbus_device *dev)
>>>>>>   		input_unregister_device(info->kbd);
>>>>>>   	if (info->ptr)
>>>>>>   		input_unregister_device(info->ptr);
>>>>>> +	if (info->mtouch)
>>>>>> +		input_unregister_device(info->mtouch);
>>>>>>   	free_page((unsigned long)info->page);
>>>>>>   	kfree(info);
>>>>>>   	return 0;
>>>>>> -- 
>>>>>> 2.7.4
>>>>>>
>>> Thanks.
>>>
>> For your convenience I am attaching the changes I am about
>> to put into v1 of the series:
>>   - remove unlikely
>>   - remove module parameters
>>   - error handling for input_mt_init_slots
>>   - let userspace better chance of figuring how to handle the device
>>
>> Thank you,
>> Oleksandr
>>  From e76506c55846e2bb4ccbafa430642e368643e51d Mon Sep 17 00:00:00 2001
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>> Date: Tue, 30 May 2017 14:49:58 +0300
>> Subject: [PATCH] Fix: remove unlikely Fix: remove module paramters Fix: error
>>   handling for input_mt_init_slots Fix: let userspace better chance of figuring
>>   how to handle the device
>>
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>> ---
>>   drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
>>   1 file changed, 10 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
>> index 8266ef948a06..273d786a19cd 100644
>> --- a/drivers/input/misc/xen-kbdfront.c
>> +++ b/drivers/input/misc/xen-kbdfront.c
>> @@ -51,12 +51,6 @@ module_param_array(ptr_size, int, NULL, 0444);
>>   MODULE_PARM_DESC(ptr_size,
>>   	"Pointing device width, height in pixels (default 800,600)");
>>   
>> -enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>> -static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
>> -module_param_array(mtouch_size, int, NULL, 0444);
>> -MODULE_PARM_DESC(ptr_size,
>> -	"Multi-touch device width, height in pixels (default 800,600)");
>> -
>>   static int xenkbd_remove(struct xenbus_device *);
>>   static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>> @@ -114,8 +108,8 @@ static irqreturn_t input_handler(int rq, void *dev_id)
>>   			dev = info->mtouch;
>>   			if (unlikely(!dev))
>>   				break;
>> -			if (unlikely(event->mtouch.contact_id !=
>> -					info->mtouch_cur_contact_id)) {
>> +			if (event->mtouch.contact_id !=
>> +					info->mtouch_cur_contact_id) {
>>   				info->mtouch_cur_contact_id =
>>   					event->mtouch.contact_id;
>>   				input_mt_slot(dev, event->mtouch.contact_id);
>> @@ -327,10 +321,15 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>   		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>>   				     0, 255, 0, 0);
>>   
>> -		input_mt_init_slots(mtouch, num_cont, 0);
>> +		ret = input_mt_init_slots(mtouch, num_cont,
>> +				INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED);
>> +		if (ret) {
>> +			input_free_device(mtouch);
>> +			xenbus_dev_fatal(info->xbdev, ret,
>> +					 "input_mt_init_slots");
>> +			goto error;
>> +		}
>>   
>> -		mtouch_size[KPARAM_MT_X] = width;
>> -		mtouch_size[KPARAM_MT_Y] = height;
>>   		info->mtouch_cur_contact_id = -1;
>>   
>>   		ret = input_register_device(mtouch);
>> -- 
>> 2.7.4
>>
>
Thank you,
Oleksandr

Re: [PATCH 2/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

Hi, Dmitry!

I would appreciate your comments on the below

On 05/31/2017 12:06 PM, Oleksandr Andrushchenko wrote:
> Hi, Dmitry!
>
> On 05/30/2017 07:37 PM, Dmitry Torokhov wrote:
>> On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko wrote:
>>> Hi, Dmitry!
>>>
>>> On 05/30/2017 08:51 AM, Dmitry Torokhov wrote:
>>>> On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko 
>>>> wrote:
>>>>> Hi, Dmitry!
>>>>>
>>>>> On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
>>>>>> Hi Oleksandr,
>>>>>>
>>>>>> On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko 
>>>>>> wrote:
>>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>>
>>>>>>> Extend xen_kbdfront to provide multi-touch support
>>>>>>> to unprivileged domains.
>>>>>>>
>>>>>>> Signed-off-by: Oleksandr Andrushchenko 
>>>>>>> <oleksandr_andrushchenko@epam.com>
>>>>>>> ---
>>>>>>>   drivers/input/misc/xen-kbdfront.c | 142 
>>>>>>> +++++++++++++++++++++++++++++++++++++-
>>>>>>>   1 file changed, 140 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/input/misc/xen-kbdfront.c 
>>>>>>> b/drivers/input/misc/xen-kbdfront.c
>>>>>>> index 01c27b4c3288..e5d064aaa237 100644
>>>>>>> --- a/drivers/input/misc/xen-kbdfront.c
>>>>>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>>>>>> @@ -17,6 +17,7 @@
>>>>>>>   #include <linux/errno.h>
>>>>>>>   #include <linux/module.h>
>>>>>>>   #include <linux/input.h>
>>>>>>> +#include <linux/input/mt.h>
>>>>>>>   #include <linux/slab.h>
>>>>>>>   #include <asm/xen/hypervisor.h>
>>>>>>> @@ -34,11 +35,14 @@
>>>>>>>   struct xenkbd_info {
>>>>>>>       struct input_dev *kbd;
>>>>>>>       struct input_dev *ptr;
>>>>>>> +    struct input_dev *mtouch;
>>>>>>>       struct xenkbd_page *page;
>>>>>>>       int gref;
>>>>>>>       int irq;
>>>>>>>       struct xenbus_device *xbdev;
>>>>>>>       char phys[32];
>>>>>>> +    /* current MT slot/contact ID we are injecting events in */
>>>>>>> +    int mtouch_cur_contact_id;
>>>>>>>   };
>>>>>>>   enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
>>>>>>> @@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
>>>>>>>   MODULE_PARM_DESC(ptr_size,
>>>>>>>       "Pointing device width, height in pixels (default 800,600)");
>>>>>>> +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>>>>>>> +static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, 
>>>>>>> XENFB_HEIGHT };
>>>>>>> +module_param_array(mtouch_size, int, NULL, 0444);
>>>>>>> +MODULE_PARM_DESC(ptr_size,
>>>>>>> +    "Multi-touch device width, height in pixels (default 
>>>>>>> 800,600)");
>>>>>>> +
>>>>>> Why do you need separate module parameters for multi-touch device?
>>>>> please see below
>>>>>>>   static int xenkbd_remove(struct xenbus_device *);
>>>>>>>   static int xenkbd_connect_backend(struct xenbus_device *, 
>>>>>>> struct xenkbd_info *);
>>>>>>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>>>>>>> @@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, 
>>>>>>> void *dev_id)
>>>>>>>                   input_report_rel(dev, REL_WHEEL,
>>>>>>>                            -event->pos.rel_z);
>>>>>>>               break;
>>>>>>> +        case XENKBD_TYPE_MTOUCH:
>>>>>>> +            dev = info->mtouch;
>>>>>>> +            if (unlikely(!dev))
>>>>>>> +                break;
>>>>>>> +            if (unlikely(event->mtouch.contact_id !=
>>>>>>> +                    info->mtouch_cur_contact_id)) {
>>>>>> Why is this unlikely? Does contact ID changes once in 1000 
>>>>>> packets or
>>>>>> even less?
>>>>> Mu assumption was that regardless of the fact that we are multi-touch
>>>>> device still single touches will come in more frequently
>>>>> But I can remove *unlikely* if my assumption is not correct
>>>> I think the normal expectation is that "unlikely" is supposed for
>>>> something that happens once in a blue moon, so I'd rather remove it.
>>>>
>>> agree, removed "unlikely"
>>>>>>> + info->mtouch_cur_contact_id =
>>>>>>> +                    event->mtouch.contact_id;
>>>>>>> +                input_mt_slot(dev, event->mtouch.contact_id);
>>>>>>> +            }
>>>>>>> +            switch (event->mtouch.event_type) {
>>>>>>> +            case XENKBD_MT_EV_DOWN:
>>>>>>> +                input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>>>>> +                               true);
>>>> Should we establish tool event? We have MT_TOOL_PEN, etc.
>>> I think that for multi-touch MT_TOOL_FINGER is enough
>>> any reason we would also want MT_TOOL_PEN here?
>> Why would not you? Let's say you have a drawing application running in
>> guest that can make use of tool types. Why would not you want to tell it
>> that the tool user is currently using is in fact a pen and not finger?
> But it is a finger :) we are multi-touch, not multi pen
>
> Besides, that, if I am about to implement pen support
> (which I still not convinced we really need), how will I
> do that?
> My understanding is that I need 2 different slots to report
> the same coordinates for finger and pen. This is because
> input_mt_report_slot_state has a check that if tool has
> changed for the current slot then a new tracking ID is set.
> Do I also need to allocate twice more slots, so I can
> report 2 * num_contacts events simultaneously (one for finger
> and another for pen)?
> That said, I believe we can start with multi-touch support
> and if need be then add pen support as a separate change,
> does that make sense for you?
>>
>>> (I guess MT_TOOL_PALM is not appropriate anyways)
>> Depends on if you do straight pass-through from the host side or not. If
>> you stack does palm rejection before passing the data through then you
>> would not see MT_TOOL_PALM in guest.
> the protocol used between guest and host is a generic one,
> not using Linux types/constants/events.
> So, no PALM/TOOL support is in place
>>>>>>> + input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>>>>> + event->mtouch.u.pos.abs_x);
>>>>>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>>>>> + event->mtouch.u.pos.abs_y);
>>>>>>> +                input_event(dev, EV_ABS, ABS_X,
>>>>>>> + event->mtouch.u.pos.abs_x);
>>>>>>> +                input_event(dev, EV_ABS, ABS_Y,
>>>>>>> + event->mtouch.u.pos.abs_y);
>>>>>>> +                break;
>>>>>>> +            case XENKBD_MT_EV_UP:
>>>>>>> +                input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>>>>> +                               false);
>>>>>>> +                break;
>>>>>>> +            case XENKBD_MT_EV_MOTION:
>>>>>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>>>>> + event->mtouch.u.pos.abs_x);
>>>>>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>>>>> + event->mtouch.u.pos.abs_y);
>>>>>>> +                input_event(dev, EV_ABS, ABS_X,
>>>>>>> + event->mtouch.u.pos.abs_x);
>>>>>>> +                input_event(dev, EV_ABS, ABS_Y,
>>>>>>> + event->mtouch.u.pos.abs_y);
>>>>>>> +                break;
>>>>>>> +            case XENKBD_MT_EV_SYN:
>>>>>>> +                input_mt_sync_frame(dev);
>>>>>>> +                break;
>>>>>>> +            case XENKBD_MT_EV_SHAPE:
>>>>>>> +                input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
>>>>>>> + event->mtouch.u.shape.major);
>>>>>>> +                input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
>>>>>>> + event->mtouch.u.shape.minor);
>>>>>>> +                break;
>>>>>>> +            case XENKBD_MT_EV_ORIENT:
>>>>>>> +                input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
>>>>>>> + event->mtouch.u.orientation);
>>>>>>> +                break;
>>>>>>> +            }
>>>>>>> +            /* only report syn when requested */
>>>>>>> +            if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
>>>>>>> +                dev = NULL;
>>>>>>>           }
>>>>>>>           if (dev)
>>>>>>>               input_sync(dev);
>>>>>>> @@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device 
>>>>>>> *dev,
>>>>>>>                     const struct xenbus_device_id *id)
>>>>>>>   {
>>>>>>>       int ret, i;
>>>>>>> -    unsigned int abs;
>>>>>>> +    unsigned int abs, touch;
>>>>>>>       struct xenkbd_info *info;
>>>>>>> -    struct input_dev *kbd, *ptr;
>>>>>>> +    struct input_dev *kbd, *ptr, *mtouch;
>>>>>>>       info = kzalloc(sizeof(*info), GFP_KERNEL);
>>>>>>>       if (!info) {
>>>>>>> @@ -152,6 +216,17 @@ static int xenkbd_probe(struct 
>>>>>>> xenbus_device *dev,
>>>>>>>           }
>>>>>>>       }
>>>>>>> +    touch = xenbus_read_unsigned(dev->nodename,
>>>>>>> +                     XENKBD_FIELD_FEAT_MTOUCH, 0);
>>>>>>> +    if (touch) {
>>>>>>> +        ret = xenbus_write(XBT_NIL, dev->nodename,
>>>>>>> +                   XENKBD_FIELD_REQ_MTOUCH, "1");
>>>>>>> +        if (ret) {
>>>>>>> +            pr_warning("xenkbd: can't request multi-touch");
>>>>>>> +            touch = 0;
>>>>>>> +        }
>>>>>>> +    }
>>>>>>> +
>>>>>>>       /* keyboard */
>>>>>>>       kbd = input_allocate_device();
>>>>>>>       if (!kbd)
>>>>>>> @@ -208,6 +283,67 @@ static int xenkbd_probe(struct 
>>>>>>> xenbus_device *dev,
>>>>>>>       }
>>>>>>>       info->ptr = ptr;
>>>>>>> +    /* multi-touch device */
>>>>>>> +    if (touch) {
>>>>>>> +        int num_cont, width, height;
>>>>>>> +
>>>>>>> +        mtouch = input_allocate_device();
>>>>>>> +        if (!mtouch)
>>>>>>> +            goto error_nomem;
>>>>>>> +
>>>>>>> +        num_cont = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>>> +                        XENKBD_FIELD_MT_NUM_CONTACTS,
>>>>>>> +                        1);
>>>> Should we refuse MT devices with number of contacts less than 2?
>>> we can, but I see no harm in 1. what is more, this may
>>> allow guests to emulate more pointing devices
>>> but, if you insist, then I will add appropriate code to
>>> reject if number of contacts is less then 2
>>>>>>> +        width = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>>> +                         XENKBD_FIELD_MT_WIDTH,
>>>>>>> +                         XENFB_WIDTH);
>>>>>>> +        height = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>>> +                          XENKBD_FIELD_MT_HEIGHT,
>>>>>>> +                          XENFB_HEIGHT);
>>>>>> Curious why you need separate parameters here too...
>>>>> This is because mt parameters are different from ptr
>>>>> in a way that they are configurable per front driver's
>>>>> instance rather than per backend, e.g. in XenStore:
>>>>>
>>>>> /local/domain/0/backend/vkbd/1/0/width = "1920"
>>>>> /local/domain/0/backend/vkbd/1/0/height = "1080"
>>>>>
>>>>> /local/domain/1/device/vkbd/0/multi-touch-width = "1920"
>>>>> /local/domain/1/device/vkbd/0/multi-touch-height = "1080"
>>>>> /local/domain/1/device/vkbd/0/multi-touch-num-contacts = "10"
>>>>>
>>>>> /local/domain/1/device/vkbd/1/multi-touch-width = "800"
>>>>> /local/domain/1/device/vkbd/1/multi-touch-height = "600"
>>>>> /local/domain/1/device/vkbd/1/multi-touch-num-contacts = "3"
>>>>>
>>>>> The main reason for such configuration is that you can
>>>>> configure multiple mt input devices even for the same guest
>>>>> with different resolutions which may not match those
>>>>> configured for ptr.
>>>>> (In my use-case I use new displif protocol [1] in conjunction
>>>>> with mt input devices and the corresponding backend is not
>>>>> QEMU's xenfb)
>>>> I see.
>>>>
>>>>> As to module parameters, I added those to be consistent with
>>>>> ptr device. Do you think we can live without them and
>>>>> do you want me to remove them?
>>>> Yes, I think we better. I am also confused by the way you are handling
>>>> the module parameters. It looks to me you update them with data passed
>>> >from the backend, but never use the data...
>>> I have removed module parameters (the only use of those
>>> was to be able to see configured width and height on
>>> guest side, but this is minor)
>> evtest would show it to you. Or you can query input device yourself
>> (EVIOCGABS iotcl).
> yes, if embedded system (which is my target) has evtest
> but it definitely does have ioctl though
>>>>>>> +
>>>>>>> +        mtouch->name = "Xen Virtual Multi-touch";
>>>>>>> +        mtouch->phys = info->phys;
>>>>>>> +        mtouch->id.bustype = BUS_PCI;
>>>>>>> +        mtouch->id.vendor = 0x5853;
>>>>>>> +        mtouch->id.product = 0xfffd;
>>>>>>> +
>>>>>>> +        __set_bit(EV_ABS, mtouch->evbit);
>>>>>>> +        __set_bit(EV_KEY, mtouch->evbit);
>>>>>>> +        __set_bit(BTN_TOUCH, mtouch->keybit);
>> Please make it
>>         input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
>>
>> and drop all __set_bit()s.
> done, thank you
>>>>>>> +
>>>>>>> +        input_set_abs_params(mtouch, ABS_X,
>>>>>>> +                     0, width, 0, 0);
>>>>>>> +        input_set_abs_params(mtouch, ABS_Y,
>>>>>>> +                     0, height, 0, 0);
>>>>>>> +        input_set_abs_params(mtouch, ABS_PRESSURE,
>>>>>>> +                     0, 255, 0, 0);
>>>>>>> +
>>>>>>> +        input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
>>>>>>> +                     0, 255, 0, 0);
>>>>>>> +        input_set_abs_params(mtouch, ABS_MT_POSITION_X,
>>>>>>> +                     0, width, 0, 0);
>>>>>>> +        input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
>>>>>>> +                     0, height, 0, 0);
>>>>>>> +        input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>>>>>>> +                     0, 255, 0, 0);
>>>>>>> +
>>>>>>> +        input_mt_init_slots(mtouch, num_cont, 0);
>>>> We need error handling here.
>>> done
>>>>   Also, it would be nice if we set INPUT_MT_*
>>>> flags here, so that userspace had better chance of figuring how to
>>>> handle the device.
>>> done, I will use INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED
>> Does that mean that your backend does not reliably report release of
>> contacts?
> there is a ring buffer between host and guest,
> so there is always a possibility (rather small I believe)
> that the buffer overruns. Do you think I need INPUT_MT_DROP_UNUSED or
> we can live without it?
>>
>> Thanks.
>>
>>>>>>> +
>>>>>>> +        mtouch_size[KPARAM_MT_X] = width;
>>>>>>> +        mtouch_size[KPARAM_MT_Y] = height;
>>>>>>> +        info->mtouch_cur_contact_id = -1;
>>>>>>> +
>>>>>>> +        ret = input_register_device(mtouch);
>>>>>>> +        if (ret) {
>>>>>>> +            input_free_device(mtouch);
>>>>>>> +            xenbus_dev_fatal(info->xbdev, ret,
>>>>>>> + "input_register_device(mtouch)");
>>>>>>> +            goto error;
>>>>>>> +        }
>>>>>>> +        info->mtouch_cur_contact_id = -1;
>>>>>>> +        info->mtouch = mtouch;
>>>>>>> +    }
>>>>>>> +
>>>>>>>       ret = xenkbd_connect_backend(dev, info);
>>>>>>>       if (ret < 0)
>>>>>>>           goto error;
>>>>>>> @@ -240,6 +376,8 @@ static int xenkbd_remove(struct 
>>>>>>> xenbus_device *dev)
>>>>>>>           input_unregister_device(info->kbd);
>>>>>>>       if (info->ptr)
>>>>>>>           input_unregister_device(info->ptr);
>>>>>>> +    if (info->mtouch)
>>>>>>> +        input_unregister_device(info->mtouch);
>>>>>>>       free_page((unsigned long)info->page);
>>>>>>>       kfree(info);
>>>>>>>       return 0;
>>>>>>> -- 
>>>>>>> 2.7.4
>>>>>>>
>>>> Thanks.
>>>>
>>> For your convenience I am attaching the changes I am about
>>> to put into v1 of the series:
>>>   - remove unlikely
>>>   - remove module parameters
>>>   - error handling for input_mt_init_slots
>>>   - let userspace better chance of figuring how to handle the device
>>>
>>> Thank you,
>>> Oleksandr
>>>  From e76506c55846e2bb4ccbafa430642e368643e51d Mon Sep 17 00:00:00 2001
>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>> Date: Tue, 30 May 2017 14:49:58 +0300
>>> Subject: [PATCH] Fix: remove unlikely Fix: remove module paramters 
>>> Fix: error
>>>   handling for input_mt_init_slots Fix: let userspace better chance 
>>> of figuring
>>>   how to handle the device
>>>
>>> Signed-off-by: Oleksandr Andrushchenko 
>>> <oleksandr_andrushchenko@epam.com>
>>> ---
>>>   drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
>>>   1 file changed, 10 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/input/misc/xen-kbdfront.c 
>>> b/drivers/input/misc/xen-kbdfront.c
>>> index 8266ef948a06..273d786a19cd 100644
>>> --- a/drivers/input/misc/xen-kbdfront.c
>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>> @@ -51,12 +51,6 @@ module_param_array(ptr_size, int, NULL, 0444);
>>>   MODULE_PARM_DESC(ptr_size,
>>>       "Pointing device width, height in pixels (default 800,600)");
>>>   -enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>>> -static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
>>> -module_param_array(mtouch_size, int, NULL, 0444);
>>> -MODULE_PARM_DESC(ptr_size,
>>> -    "Multi-touch device width, height in pixels (default 800,600)");
>>> -
>>>   static int xenkbd_remove(struct xenbus_device *);
>>>   static int xenkbd_connect_backend(struct xenbus_device *, struct 
>>> xenkbd_info *);
>>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>>> @@ -114,8 +108,8 @@ static irqreturn_t input_handler(int rq, void 
>>> *dev_id)
>>>               dev = info->mtouch;
>>>               if (unlikely(!dev))
>>>                   break;
>>> -            if (unlikely(event->mtouch.contact_id !=
>>> -                    info->mtouch_cur_contact_id)) {
>>> +            if (event->mtouch.contact_id !=
>>> +                    info->mtouch_cur_contact_id) {
>>>                   info->mtouch_cur_contact_id =
>>>                       event->mtouch.contact_id;
>>>                   input_mt_slot(dev, event->mtouch.contact_id);
>>> @@ -327,10 +321,15 @@ static int xenkbd_probe(struct xenbus_device 
>>> *dev,
>>>           input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>>>                        0, 255, 0, 0);
>>>   -        input_mt_init_slots(mtouch, num_cont, 0);
>>> +        ret = input_mt_init_slots(mtouch, num_cont,
>>> +                INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED);
>>> +        if (ret) {
>>> +            input_free_device(mtouch);
>>> +            xenbus_dev_fatal(info->xbdev, ret,
>>> +                     "input_mt_init_slots");
>>> +            goto error;
>>> +        }
>>>   -        mtouch_size[KPARAM_MT_X] = width;
>>> -        mtouch_size[KPARAM_MT_Y] = height;
>>>           info->mtouch_cur_contact_id = -1;
>>>             ret = input_register_device(mtouch);
>>> -- 
>>> 2.7.4
>>>
>>
> Thank you,
> Oleksandr

Re: [PATCH 2/2] xen/input: add multi-touch support

[Dmitry Torokhov]

On Wed, May 31, 2017 at 12:06:56PM +0300, Oleksandr Andrushchenko wrote:
> Hi, Dmitry!
> 
> On 05/30/2017 07:37 PM, Dmitry Torokhov wrote:
> >On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko wrote:
> >>Hi, Dmitry!
> >>
> >>On 05/30/2017 08:51 AM, Dmitry Torokhov wrote:
> >>>On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko wrote:
> >>>>Hi, Dmitry!
> >>>>
> >>>>On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
> >>>>>Hi Oleksandr,
> >>>>>
> >>>>>On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
> >>>>>>From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>>>>>
> >>>>>>Extend xen_kbdfront to provide multi-touch support
> >>>>>>to unprivileged domains.
> >>>>>>
> >>>>>>Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>>>>>---
> >>>>>>  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
> >>>>>>  1 file changed, 140 insertions(+), 2 deletions(-)
> >>>>>>
> >>>>>>diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> >>>>>>index 01c27b4c3288..e5d064aaa237 100644
> >>>>>>--- a/drivers/input/misc/xen-kbdfront.c
> >>>>>>+++ b/drivers/input/misc/xen-kbdfront.c
> >>>>>>@@ -17,6 +17,7 @@
> >>>>>>  #include <linux/errno.h>
> >>>>>>  #include <linux/module.h>
> >>>>>>  #include <linux/input.h>
> >>>>>>+#include <linux/input/mt.h>
> >>>>>>  #include <linux/slab.h>
> >>>>>>  #include <asm/xen/hypervisor.h>
> >>>>>>@@ -34,11 +35,14 @@
> >>>>>>  struct xenkbd_info {
> >>>>>>  	struct input_dev *kbd;
> >>>>>>  	struct input_dev *ptr;
> >>>>>>+	struct input_dev *mtouch;
> >>>>>>  	struct xenkbd_page *page;
> >>>>>>  	int gref;
> >>>>>>  	int irq;
> >>>>>>  	struct xenbus_device *xbdev;
> >>>>>>  	char phys[32];
> >>>>>>+	/* current MT slot/contact ID we are injecting events in */
> >>>>>>+	int mtouch_cur_contact_id;
> >>>>>>  };
> >>>>>>  enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
> >>>>>>@@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
> >>>>>>  MODULE_PARM_DESC(ptr_size,
> >>>>>>  	"Pointing device width, height in pixels (default 800,600)");
> >>>>>>+enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
> >>>>>>+static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
> >>>>>>+module_param_array(mtouch_size, int, NULL, 0444);
> >>>>>>+MODULE_PARM_DESC(ptr_size,
> >>>>>>+	"Multi-touch device width, height in pixels (default 800,600)");
> >>>>>>+
> >>>>>Why do you need separate module parameters for multi-touch device?
> >>>>please see below
> >>>>>>  static int xenkbd_remove(struct xenbus_device *);
> >>>>>>  static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
> >>>>>>  static void xenkbd_disconnect_backend(struct xenkbd_info *);
> >>>>>>@@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void *dev_id)
> >>>>>>  				input_report_rel(dev, REL_WHEEL,
> >>>>>>  						 -event->pos.rel_z);
> >>>>>>  			break;
> >>>>>>+		case XENKBD_TYPE_MTOUCH:
> >>>>>>+			dev = info->mtouch;
> >>>>>>+			if (unlikely(!dev))
> >>>>>>+				break;
> >>>>>>+			if (unlikely(event->mtouch.contact_id !=
> >>>>>>+					info->mtouch_cur_contact_id)) {
> >>>>>Why is this unlikely? Does contact ID changes once in 1000 packets or
> >>>>>even less?
> >>>>Mu assumption was that regardless of the fact that we are multi-touch
> >>>>device still single touches will come in more frequently
> >>>>But I can remove *unlikely* if my assumption is not correct
> >>>I think the normal expectation is that "unlikely" is supposed for
> >>>something that happens once in a blue moon, so I'd rather remove it.
> >>>
> >>agree, removed "unlikely"
> >>>>>>+				info->mtouch_cur_contact_id =
> >>>>>>+					event->mtouch.contact_id;
> >>>>>>+				input_mt_slot(dev, event->mtouch.contact_id);
> >>>>>>+			}
> >>>>>>+			switch (event->mtouch.event_type) {
> >>>>>>+			case XENKBD_MT_EV_DOWN:
> >>>>>>+				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
> >>>>>>+							   true);
> >>>Should we establish tool event? We have MT_TOOL_PEN, etc.
> >>I think that for multi-touch MT_TOOL_FINGER is enough
> >>any reason we would also want MT_TOOL_PEN here?
> >Why would not you? Let's say you have a drawing application running in
> >guest that can make use of tool types. Why would not you want to tell it
> >that the tool user is currently using is in fact a pen and not finger?
> But it is a finger :) we are multi-touch, not multi pen

So for tablets that support both touch and stylus you would export them
as 2 separate devices?

> 
> Besides, that, if I am about to implement pen support
> (which I still not convinced we really need), how will I
> do that?

I do not know what you have on the backend side, but roughly speaking if
you detect a pen/stylus you let your guest know that the contact is not
a finger, but pen. How you plumb it through is up to you.

> My understanding is that I need 2 different slots to report
> the same coordinates for finger and pen. This is because
> input_mt_report_slot_state has a check that if tool has
> changed for the current slot then a new tracking ID is set.
> Do I also need to allocate twice more slots, so I can
> report 2 * num_contacts events simultaneously (one for finger
> and another for pen)?
> That said, I believe we can start with multi-touch support
> and if need be then add pen support as a separate change,
> does that make sense for you?
> >
> >>(I guess MT_TOOL_PALM is not appropriate anyways)
> >Depends on if you do straight pass-through from the host side or not. If
> >you stack does palm rejection before passing the data through then you
> >would not see MT_TOOL_PALM in guest.
> the protocol used between guest and host is a generic one,
> not using Linux types/constants/events.

It does not have to use Linux types to support the concept of different
tools.

> So, no PALM/TOOL support is in place

OK, that is fair. The pen support is definitely not a hard requirement.
I was just wondering if you considered or have plans for adding that. Or
if you want to review the protocol so it can be easily added in the
future. For example you could have tool type to be part of
XENKBD_MT_EV_DOWN event.

> >>>>>>+				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
> >>>>>>+					    event->mtouch.u.pos.abs_x);
> >>>>>>+				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
> >>>>>>+					    event->mtouch.u.pos.abs_y);
> >>>>>>+				input_event(dev, EV_ABS, ABS_X,
> >>>>>>+					    event->mtouch.u.pos.abs_x);
> >>>>>>+				input_event(dev, EV_ABS, ABS_Y,
> >>>>>>+					    event->mtouch.u.pos.abs_y);
> >>>>>>+				break;
> >>>>>>+			case XENKBD_MT_EV_UP:
> >>>>>>+				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
> >>>>>>+							   false);
> >>>>>>+				break;
> >>>>>>+			case XENKBD_MT_EV_MOTION:
> >>>>>>+				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
> >>>>>>+					    event->mtouch.u.pos.abs_x);
> >>>>>>+				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
> >>>>>>+					    event->mtouch.u.pos.abs_y);
> >>>>>>+				input_event(dev, EV_ABS, ABS_X,
> >>>>>>+					    event->mtouch.u.pos.abs_x);
> >>>>>>+				input_event(dev, EV_ABS, ABS_Y,
> >>>>>>+					    event->mtouch.u.pos.abs_y);
> >>>>>>+				break;
> >>>>>>+			case XENKBD_MT_EV_SYN:
> >>>>>>+				input_mt_sync_frame(dev);
> >>>>>>+				break;
> >>>>>>+			case XENKBD_MT_EV_SHAPE:
> >>>>>>+				input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
> >>>>>>+					    event->mtouch.u.shape.major);
> >>>>>>+				input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
> >>>>>>+					    event->mtouch.u.shape.minor);
> >>>>>>+				break;
> >>>>>>+			case XENKBD_MT_EV_ORIENT:
> >>>>>>+				input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
> >>>>>>+					    event->mtouch.u.orientation);
> >>>>>>+				break;
> >>>>>>+			}
> >>>>>>+			/* only report syn when requested */
> >>>>>>+			if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
> >>>>>>+				dev = NULL;
> >>>>>>  		}
> >>>>>>  		if (dev)
> >>>>>>  			input_sync(dev);
> >>>>>>@@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >>>>>>  				  const struct xenbus_device_id *id)
> >>>>>>  {
> >>>>>>  	int ret, i;
> >>>>>>-	unsigned int abs;
> >>>>>>+	unsigned int abs, touch;
> >>>>>>  	struct xenkbd_info *info;
> >>>>>>-	struct input_dev *kbd, *ptr;
> >>>>>>+	struct input_dev *kbd, *ptr, *mtouch;
> >>>>>>  	info = kzalloc(sizeof(*info), GFP_KERNEL);
> >>>>>>  	if (!info) {
> >>>>>>@@ -152,6 +216,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >>>>>>  		}
> >>>>>>  	}
> >>>>>>+	touch = xenbus_read_unsigned(dev->nodename,
> >>>>>>+				     XENKBD_FIELD_FEAT_MTOUCH, 0);
> >>>>>>+	if (touch) {
> >>>>>>+		ret = xenbus_write(XBT_NIL, dev->nodename,
> >>>>>>+				   XENKBD_FIELD_REQ_MTOUCH, "1");
> >>>>>>+		if (ret) {
> >>>>>>+			pr_warning("xenkbd: can't request multi-touch");
> >>>>>>+			touch = 0;
> >>>>>>+		}
> >>>>>>+	}
> >>>>>>+
> >>>>>>  	/* keyboard */
> >>>>>>  	kbd = input_allocate_device();
> >>>>>>  	if (!kbd)
> >>>>>>@@ -208,6 +283,67 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >>>>>>  	}
> >>>>>>  	info->ptr = ptr;
> >>>>>>+	/* multi-touch device */
> >>>>>>+	if (touch) {
> >>>>>>+		int num_cont, width, height;
> >>>>>>+
> >>>>>>+		mtouch = input_allocate_device();
> >>>>>>+		if (!mtouch)
> >>>>>>+			goto error_nomem;
> >>>>>>+
> >>>>>>+		num_cont = xenbus_read_unsigned(info->xbdev->nodename,
> >>>>>>+						XENKBD_FIELD_MT_NUM_CONTACTS,
> >>>>>>+						1);
> >>>Should we refuse MT devices with number of contacts less than 2?
> >>we can, but I see no harm in 1. what is more, this may
> >>allow guests to emulate more pointing devices
> >>but, if you insist, then I will add appropriate code to
> >>reject if number of contacts is less then 2

The question is if you are planning to keep the single-touch interface
or you will migrate everything to multi-touch.

> >>>>>>+		width = xenbus_read_unsigned(info->xbdev->nodename,
> >>>>>>+					     XENKBD_FIELD_MT_WIDTH,
> >>>>>>+					     XENFB_WIDTH);
> >>>>>>+		height = xenbus_read_unsigned(info->xbdev->nodename,
> >>>>>>+					      XENKBD_FIELD_MT_HEIGHT,
> >>>>>>+					      XENFB_HEIGHT);
> >>>>>Curious why you need separate parameters here too...
> >>>>This is because mt parameters are different from ptr
> >>>>in a way that they are configurable per front driver's
> >>>>instance rather than per backend, e.g. in XenStore:
> >>>>
> >>>>/local/domain/0/backend/vkbd/1/0/width = "1920"
> >>>>/local/domain/0/backend/vkbd/1/0/height = "1080"
> >>>>
> >>>>/local/domain/1/device/vkbd/0/multi-touch-width = "1920"
> >>>>/local/domain/1/device/vkbd/0/multi-touch-height = "1080"
> >>>>/local/domain/1/device/vkbd/0/multi-touch-num-contacts = "10"
> >>>>
> >>>>/local/domain/1/device/vkbd/1/multi-touch-width = "800"
> >>>>/local/domain/1/device/vkbd/1/multi-touch-height = "600"
> >>>>/local/domain/1/device/vkbd/1/multi-touch-num-contacts = "3"
> >>>>
> >>>>The main reason for such configuration is that you can
> >>>>configure multiple mt input devices even for the same guest
> >>>>with different resolutions which may not match those
> >>>>configured for ptr.
> >>>>(In my use-case I use new displif protocol [1] in conjunction
> >>>>with mt input devices and the corresponding backend is not
> >>>>QEMU's xenfb)
> >>>I see.
> >>>
> >>>>As to module parameters, I added those to be consistent with
> >>>>ptr device. Do you think we can live without them and
> >>>>do you want me to remove them?
> >>>Yes, I think we better. I am also confused by the way you are handling
> >>>the module parameters. It looks to me you update them with data passed
> >>>from the backend, but never use the data...
> >>I have removed module parameters (the only use of those
> >>was to be able to see configured width and height on
> >>guest side, but this is minor)
> >evtest would show it to you. Or you can query input device yourself
> >(EVIOCGABS iotcl).
> yes, if embedded system (which is my target) has evtest
> but it definitely does have ioctl though
> >>>>>>+
> >>>>>>+		mtouch->name = "Xen Virtual Multi-touch";
> >>>>>>+		mtouch->phys = info->phys;
> >>>>>>+		mtouch->id.bustype = BUS_PCI;
> >>>>>>+		mtouch->id.vendor = 0x5853;
> >>>>>>+		mtouch->id.product = 0xfffd;
> >>>>>>+
> >>>>>>+		__set_bit(EV_ABS, mtouch->evbit);
> >>>>>>+		__set_bit(EV_KEY, mtouch->evbit);
> >>>>>>+		__set_bit(BTN_TOUCH, mtouch->keybit);
> >Please make it
> >		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
> >
> >and drop all __set_bit()s.
> done, thank you
> >>>>>>+
> >>>>>>+		input_set_abs_params(mtouch, ABS_X,
> >>>>>>+				     0, width, 0, 0);
> >>>>>>+		input_set_abs_params(mtouch, ABS_Y,
> >>>>>>+				     0, height, 0, 0);
> >>>>>>+		input_set_abs_params(mtouch, ABS_PRESSURE,
> >>>>>>+				     0, 255, 0, 0);
> >>>>>>+
> >>>>>>+		input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
> >>>>>>+				     0, 255, 0, 0);
> >>>>>>+		input_set_abs_params(mtouch, ABS_MT_POSITION_X,
> >>>>>>+				     0, width, 0, 0);
> >>>>>>+		input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
> >>>>>>+				     0, height, 0, 0);
> >>>>>>+		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
> >>>>>>+				     0, 255, 0, 0);
> >>>>>>+
> >>>>>>+		input_mt_init_slots(mtouch, num_cont, 0);
> >>>We need error handling here.
> >>done
> >>>  Also, it would be nice if we set INPUT_MT_*
> >>>flags here, so that userspace had better chance of figuring how to
> >>>handle the device.
> >>done, I will use INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED
> >Does that mean that your backend does not reliably report release of
> >contacts?
> there is a ring buffer between host and guest,
> so there is always a possibility (rather small I believe)
> that the buffer overruns. Do you think I need INPUT_MT_DROP_UNUSED or
> we can live without it?

Again, it depends on your backend behavior. Do you report all slots
repeatedly for every packet or you report only changed slots?

Thanks.

> >
> >Thanks.
> >
> >>>>>>+
> >>>>>>+		mtouch_size[KPARAM_MT_X] = width;
> >>>>>>+		mtouch_size[KPARAM_MT_Y] = height;
> >>>>>>+		info->mtouch_cur_contact_id = -1;
> >>>>>>+
> >>>>>>+		ret = input_register_device(mtouch);
> >>>>>>+		if (ret) {
> >>>>>>+			input_free_device(mtouch);
> >>>>>>+			xenbus_dev_fatal(info->xbdev, ret,
> >>>>>>+					 "input_register_device(mtouch)");
> >>>>>>+			goto error;
> >>>>>>+		}
> >>>>>>+		info->mtouch_cur_contact_id = -1;
> >>>>>>+		info->mtouch = mtouch;
> >>>>>>+	}
> >>>>>>+
> >>>>>>  	ret = xenkbd_connect_backend(dev, info);
> >>>>>>  	if (ret < 0)
> >>>>>>  		goto error;
> >>>>>>@@ -240,6 +376,8 @@ static int xenkbd_remove(struct xenbus_device *dev)
> >>>>>>  		input_unregister_device(info->kbd);
> >>>>>>  	if (info->ptr)
> >>>>>>  		input_unregister_device(info->ptr);
> >>>>>>+	if (info->mtouch)
> >>>>>>+		input_unregister_device(info->mtouch);
> >>>>>>  	free_page((unsigned long)info->page);
> >>>>>>  	kfree(info);
> >>>>>>  	return 0;
> >>>>>>-- 
> >>>>>>2.7.4
> >>>>>>
> >>>Thanks.
> >>>
> >>For your convenience I am attaching the changes I am about
> >>to put into v1 of the series:
> >>  - remove unlikely
> >>  - remove module parameters
> >>  - error handling for input_mt_init_slots
> >>  - let userspace better chance of figuring how to handle the device
> >>
> >>Thank you,
> >>Oleksandr
> >> From e76506c55846e2bb4ccbafa430642e368643e51d Mon Sep 17 00:00:00 2001
> >>From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>Date: Tue, 30 May 2017 14:49:58 +0300
> >>Subject: [PATCH] Fix: remove unlikely Fix: remove module paramters Fix: error
> >>  handling for input_mt_init_slots Fix: let userspace better chance of figuring
> >>  how to handle the device
> >>
> >>Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>---
> >>  drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
> >>  1 file changed, 10 insertions(+), 11 deletions(-)
> >>
> >>diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> >>index 8266ef948a06..273d786a19cd 100644
> >>--- a/drivers/input/misc/xen-kbdfront.c
> >>+++ b/drivers/input/misc/xen-kbdfront.c
> >>@@ -51,12 +51,6 @@ module_param_array(ptr_size, int, NULL, 0444);
> >>  MODULE_PARM_DESC(ptr_size,
> >>  	"Pointing device width, height in pixels (default 800,600)");
> >>-enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
> >>-static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
> >>-module_param_array(mtouch_size, int, NULL, 0444);
> >>-MODULE_PARM_DESC(ptr_size,
> >>-	"Multi-touch device width, height in pixels (default 800,600)");
> >>-
> >>  static int xenkbd_remove(struct xenbus_device *);
> >>  static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
> >>  static void xenkbd_disconnect_backend(struct xenkbd_info *);
> >>@@ -114,8 +108,8 @@ static irqreturn_t input_handler(int rq, void *dev_id)
> >>  			dev = info->mtouch;
> >>  			if (unlikely(!dev))
> >>  				break;
> >>-			if (unlikely(event->mtouch.contact_id !=
> >>-					info->mtouch_cur_contact_id)) {
> >>+			if (event->mtouch.contact_id !=
> >>+					info->mtouch_cur_contact_id) {
> >>  				info->mtouch_cur_contact_id =
> >>  					event->mtouch.contact_id;
> >>  				input_mt_slot(dev, event->mtouch.contact_id);
> >>@@ -327,10 +321,15 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >>  		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
> >>  				     0, 255, 0, 0);
> >>-		input_mt_init_slots(mtouch, num_cont, 0);
> >>+		ret = input_mt_init_slots(mtouch, num_cont,
> >>+				INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED);
> >>+		if (ret) {
> >>+			input_free_device(mtouch);
> >>+			xenbus_dev_fatal(info->xbdev, ret,
> >>+					 "input_mt_init_slots");
> >>+			goto error;
> >>+		}
> >>-		mtouch_size[KPARAM_MT_X] = width;
> >>-		mtouch_size[KPARAM_MT_Y] = height;
> >>  		info->mtouch_cur_contact_id = -1;
> >>  		ret = input_register_device(mtouch);
> >>-- 
> >>2.7.4
> >>
> >
> Thank you,
> Oleksandr

-- 
Dmitry

Re: [PATCH 2/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

Hi, Dmitry!

On 06/07/2017 07:56 PM, Dmitry Torokhov wrote:
> On Wed, May 31, 2017 at 12:06:56PM +0300, Oleksandr Andrushchenko wrote:
>> Hi, Dmitry!
>>
>> On 05/30/2017 07:37 PM, Dmitry Torokhov wrote:
>>> On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko wrote:
>>>> Hi, Dmitry!
>>>>
>>>> On 05/30/2017 08:51 AM, Dmitry Torokhov wrote:
>>>>> On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko wrote:
>>>>>> Hi, Dmitry!
>>>>>>
>>>>>> On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
>>>>>>> Hi Oleksandr,
>>>>>>>
>>>>>>> On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
>>>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>>>
>>>>>>>> Extend xen_kbdfront to provide multi-touch support
>>>>>>>> to unprivileged domains.
>>>>>>>>
>>>>>>>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>>> ---
>>>>>>>>   drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
>>>>>>>>   1 file changed, 140 insertions(+), 2 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
>>>>>>>> index 01c27b4c3288..e5d064aaa237 100644
>>>>>>>> --- a/drivers/input/misc/xen-kbdfront.c
>>>>>>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>>>>>>> @@ -17,6 +17,7 @@
>>>>>>>>   #include <linux/errno.h>
>>>>>>>>   #include <linux/module.h>
>>>>>>>>   #include <linux/input.h>
>>>>>>>> +#include <linux/input/mt.h>
>>>>>>>>   #include <linux/slab.h>
>>>>>>>>   #include <asm/xen/hypervisor.h>
>>>>>>>> @@ -34,11 +35,14 @@
>>>>>>>>   struct xenkbd_info {
>>>>>>>>   	struct input_dev *kbd;
>>>>>>>>   	struct input_dev *ptr;
>>>>>>>> +	struct input_dev *mtouch;
>>>>>>>>   	struct xenkbd_page *page;
>>>>>>>>   	int gref;
>>>>>>>>   	int irq;
>>>>>>>>   	struct xenbus_device *xbdev;
>>>>>>>>   	char phys[32];
>>>>>>>> +	/* current MT slot/contact ID we are injecting events in */
>>>>>>>> +	int mtouch_cur_contact_id;
>>>>>>>>   };
>>>>>>>>   enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
>>>>>>>> @@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
>>>>>>>>   MODULE_PARM_DESC(ptr_size,
>>>>>>>>   	"Pointing device width, height in pixels (default 800,600)");
>>>>>>>> +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>>>>>>>> +static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
>>>>>>>> +module_param_array(mtouch_size, int, NULL, 0444);
>>>>>>>> +MODULE_PARM_DESC(ptr_size,
>>>>>>>> +	"Multi-touch device width, height in pixels (default 800,600)");
>>>>>>>> +
>>>>>>> Why do you need separate module parameters for multi-touch device?
>>>>>> please see below
>>>>>>>>   static int xenkbd_remove(struct xenbus_device *);
>>>>>>>>   static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
>>>>>>>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>>>>>>>> @@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void *dev_id)
>>>>>>>>   				input_report_rel(dev, REL_WHEEL,
>>>>>>>>   						 -event->pos.rel_z);
>>>>>>>>   			break;
>>>>>>>> +		case XENKBD_TYPE_MTOUCH:
>>>>>>>> +			dev = info->mtouch;
>>>>>>>> +			if (unlikely(!dev))
>>>>>>>> +				break;
>>>>>>>> +			if (unlikely(event->mtouch.contact_id !=
>>>>>>>> +					info->mtouch_cur_contact_id)) {
>>>>>>> Why is this unlikely? Does contact ID changes once in 1000 packets or
>>>>>>> even less?
>>>>>> Mu assumption was that regardless of the fact that we are multi-touch
>>>>>> device still single touches will come in more frequently
>>>>>> But I can remove *unlikely* if my assumption is not correct
>>>>> I think the normal expectation is that "unlikely" is supposed for
>>>>> something that happens once in a blue moon, so I'd rather remove it.
>>>>>
>>>> agree, removed "unlikely"
>>>>>>>> +				info->mtouch_cur_contact_id =
>>>>>>>> +					event->mtouch.contact_id;
>>>>>>>> +				input_mt_slot(dev, event->mtouch.contact_id);
>>>>>>>> +			}
>>>>>>>> +			switch (event->mtouch.event_type) {
>>>>>>>> +			case XENKBD_MT_EV_DOWN:
>>>>>>>> +				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>>>>>> +							   true);
>>>>> Should we establish tool event? We have MT_TOOL_PEN, etc.
>>>> I think that for multi-touch MT_TOOL_FINGER is enough
>>>> any reason we would also want MT_TOOL_PEN here?
>>> Why would not you? Let's say you have a drawing application running in
>>> guest that can make use of tool types. Why would not you want to tell it
>>> that the tool user is currently using is in fact a pen and not finger?
>> But it is a finger :) we are multi-touch, not multi pen
> So for tablets that support both touch and stylus you would export them
> as 2 separate devices?
this could be done in different ways, but please see on
pen support below
>> Besides, that, if I am about to implement pen support
>> (which I still not convinced we really need), how will I
>> do that?
> I do not know what you have on the backend side, but roughly speaking if
> you detect a pen/stylus you let your guest know that the contact is not
> a finger, but pen. How you plumb it through is up to you.
we do not detect pen, only finger at the moment
and the existing protocol has no means to tell
type of the tool used, everything is supposed to
be "finger", so front-end has no possibility to
tell one tool from another
>> My understanding is that I need 2 different slots to report
>> the same coordinates for finger and pen. This is because
>> input_mt_report_slot_state has a check that if tool has
>> changed for the current slot then a new tracking ID is set.
>> Do I also need to allocate twice more slots, so I can
>> report 2 * num_contacts events simultaneously (one for finger
>> and another for pen)?
>> That said, I believe we can start with multi-touch support
>> and if need be then add pen support as a separate change,
>> does that make sense for you?
>>>> (I guess MT_TOOL_PALM is not appropriate anyways)
>>> Depends on if you do straight pass-through from the host side or not. If
>>> you stack does palm rejection before passing the data through then you
>>> would not see MT_TOOL_PALM in guest.
>> the protocol used between guest and host is a generic one,
>> not using Linux types/constants/events.
> It does not have to use Linux types to support the concept of different
> tools.
agree
>> So, no PALM/TOOL support is in place
> OK, that is fair. The pen support is definitely not a hard requirement.
so, can we live with finger at this point, no pen?
> I was just wondering if you considered or have plans for adding that.
well, honestly, we do not need pen at the moment,
but we did add multi-touch support into Xen protocols
and if pen required it can be done as a separate
change to both protocol and front/back ends
>   Or
> if you want to review the protocol so it can be easily added in the
> future. For example you could have tool type to be part of
> XENKBD_MT_EV_DOWN event.
protocol did a long way to get into Xen/Kernel... :)
of course, this can be done, but I would prefer it is
added when it is needed, not only that we have this functionality
>>>>>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>>>>>> +					    event->mtouch.u.pos.abs_x);
>>>>>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>>>>>> +					    event->mtouch.u.pos.abs_y);
>>>>>>>> +				input_event(dev, EV_ABS, ABS_X,
>>>>>>>> +					    event->mtouch.u.pos.abs_x);
>>>>>>>> +				input_event(dev, EV_ABS, ABS_Y,
>>>>>>>> +					    event->mtouch.u.pos.abs_y);
>>>>>>>> +				break;
>>>>>>>> +			case XENKBD_MT_EV_UP:
>>>>>>>> +				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>>>>>> +							   false);
>>>>>>>> +				break;
>>>>>>>> +			case XENKBD_MT_EV_MOTION:
>>>>>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>>>>>> +					    event->mtouch.u.pos.abs_x);
>>>>>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>>>>>> +					    event->mtouch.u.pos.abs_y);
>>>>>>>> +				input_event(dev, EV_ABS, ABS_X,
>>>>>>>> +					    event->mtouch.u.pos.abs_x);
>>>>>>>> +				input_event(dev, EV_ABS, ABS_Y,
>>>>>>>> +					    event->mtouch.u.pos.abs_y);
>>>>>>>> +				break;
>>>>>>>> +			case XENKBD_MT_EV_SYN:
>>>>>>>> +				input_mt_sync_frame(dev);
>>>>>>>> +				break;
>>>>>>>> +			case XENKBD_MT_EV_SHAPE:
>>>>>>>> +				input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
>>>>>>>> +					    event->mtouch.u.shape.major);
>>>>>>>> +				input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
>>>>>>>> +					    event->mtouch.u.shape.minor);
>>>>>>>> +				break;
>>>>>>>> +			case XENKBD_MT_EV_ORIENT:
>>>>>>>> +				input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
>>>>>>>> +					    event->mtouch.u.orientation);
>>>>>>>> +				break;
>>>>>>>> +			}
>>>>>>>> +			/* only report syn when requested */
>>>>>>>> +			if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
>>>>>>>> +				dev = NULL;
>>>>>>>>   		}
>>>>>>>>   		if (dev)
>>>>>>>>   			input_sync(dev);
>>>>>>>> @@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>>>>>   				  const struct xenbus_device_id *id)
>>>>>>>>   {
>>>>>>>>   	int ret, i;
>>>>>>>> -	unsigned int abs;
>>>>>>>> +	unsigned int abs, touch;
>>>>>>>>   	struct xenkbd_info *info;
>>>>>>>> -	struct input_dev *kbd, *ptr;
>>>>>>>> +	struct input_dev *kbd, *ptr, *mtouch;
>>>>>>>>   	info = kzalloc(sizeof(*info), GFP_KERNEL);
>>>>>>>>   	if (!info) {
>>>>>>>> @@ -152,6 +216,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>>>>>   		}
>>>>>>>>   	}
>>>>>>>> +	touch = xenbus_read_unsigned(dev->nodename,
>>>>>>>> +				     XENKBD_FIELD_FEAT_MTOUCH, 0);
>>>>>>>> +	if (touch) {
>>>>>>>> +		ret = xenbus_write(XBT_NIL, dev->nodename,
>>>>>>>> +				   XENKBD_FIELD_REQ_MTOUCH, "1");
>>>>>>>> +		if (ret) {
>>>>>>>> +			pr_warning("xenkbd: can't request multi-touch");
>>>>>>>> +			touch = 0;
>>>>>>>> +		}
>>>>>>>> +	}
>>>>>>>> +
>>>>>>>>   	/* keyboard */
>>>>>>>>   	kbd = input_allocate_device();
>>>>>>>>   	if (!kbd)
>>>>>>>> @@ -208,6 +283,67 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>>>>>   	}
>>>>>>>>   	info->ptr = ptr;
>>>>>>>> +	/* multi-touch device */
>>>>>>>> +	if (touch) {
>>>>>>>> +		int num_cont, width, height;
>>>>>>>> +
>>>>>>>> +		mtouch = input_allocate_device();
>>>>>>>> +		if (!mtouch)
>>>>>>>> +			goto error_nomem;
>>>>>>>> +
>>>>>>>> +		num_cont = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>>>> +						XENKBD_FIELD_MT_NUM_CONTACTS,
>>>>>>>> +						1);
>>>>> Should we refuse MT devices with number of contacts less than 2?
>>>> we can, but I see no harm in 1. what is more, this may
>>>> allow guests to emulate more pointing devices
>>>> but, if you insist, then I will add appropriate code to
>>>> reject if number of contacts is less then 2
> The question is if you are planning to keep the single-touch interface
> or you will migrate everything to multi-touch.
I will keep single touch as legacy, but in our use-cases
we are more focusing on using multi-touch devices.
but even with number of contacts == 1 it can still be
useful as it gives more flexibility in configuring guest OS
If you insist that num contacts == 1 must be removed,
please let me know and I will handle that
>>>>>>>> +		width = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>>>> +					     XENKBD_FIELD_MT_WIDTH,
>>>>>>>> +					     XENFB_WIDTH);
>>>>>>>> +		height = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>>>> +					      XENKBD_FIELD_MT_HEIGHT,
>>>>>>>> +					      XENFB_HEIGHT);
>>>>>>> Curious why you need separate parameters here too...
>>>>>> This is because mt parameters are different from ptr
>>>>>> in a way that they are configurable per front driver's
>>>>>> instance rather than per backend, e.g. in XenStore:
>>>>>>
>>>>>> /local/domain/0/backend/vkbd/1/0/width = "1920"
>>>>>> /local/domain/0/backend/vkbd/1/0/height = "1080"
>>>>>>
>>>>>> /local/domain/1/device/vkbd/0/multi-touch-width = "1920"
>>>>>> /local/domain/1/device/vkbd/0/multi-touch-height = "1080"
>>>>>> /local/domain/1/device/vkbd/0/multi-touch-num-contacts = "10"
>>>>>>
>>>>>> /local/domain/1/device/vkbd/1/multi-touch-width = "800"
>>>>>> /local/domain/1/device/vkbd/1/multi-touch-height = "600"
>>>>>> /local/domain/1/device/vkbd/1/multi-touch-num-contacts = "3"
>>>>>>
>>>>>> The main reason for such configuration is that you can
>>>>>> configure multiple mt input devices even for the same guest
>>>>>> with different resolutions which may not match those
>>>>>> configured for ptr.
>>>>>> (In my use-case I use new displif protocol [1] in conjunction
>>>>>> with mt input devices and the corresponding backend is not
>>>>>> QEMU's xenfb)
>>>>> I see.
>>>>>
>>>>>> As to module parameters, I added those to be consistent with
>>>>>> ptr device. Do you think we can live without them and
>>>>>> do you want me to remove them?
>>>>> Yes, I think we better. I am also confused by the way you are handling
>>>>> the module parameters. It looks to me you update them with data passed
>>>> >from the backend, but never use the data...
>>>> I have removed module parameters (the only use of those
>>>> was to be able to see configured width and height on
>>>> guest side, but this is minor)
>>> evtest would show it to you. Or you can query input device yourself
>>> (EVIOCGABS iotcl).
>> yes, if embedded system (which is my target) has evtest
>> but it definitely does have ioctl though
>>>>>>>> +
>>>>>>>> +		mtouch->name = "Xen Virtual Multi-touch";
>>>>>>>> +		mtouch->phys = info->phys;
>>>>>>>> +		mtouch->id.bustype = BUS_PCI;
>>>>>>>> +		mtouch->id.vendor = 0x5853;
>>>>>>>> +		mtouch->id.product = 0xfffd;
>>>>>>>> +
>>>>>>>> +		__set_bit(EV_ABS, mtouch->evbit);
>>>>>>>> +		__set_bit(EV_KEY, mtouch->evbit);
>>>>>>>> +		__set_bit(BTN_TOUCH, mtouch->keybit);
>>> Please make it
>>> 		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
>>>
>>> and drop all __set_bit()s.
>> done, thank you
>>>>>>>> +
>>>>>>>> +		input_set_abs_params(mtouch, ABS_X,
>>>>>>>> +				     0, width, 0, 0);
>>>>>>>> +		input_set_abs_params(mtouch, ABS_Y,
>>>>>>>> +				     0, height, 0, 0);
>>>>>>>> +		input_set_abs_params(mtouch, ABS_PRESSURE,
>>>>>>>> +				     0, 255, 0, 0);
>>>>>>>> +
>>>>>>>> +		input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
>>>>>>>> +				     0, 255, 0, 0);
>>>>>>>> +		input_set_abs_params(mtouch, ABS_MT_POSITION_X,
>>>>>>>> +				     0, width, 0, 0);
>>>>>>>> +		input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
>>>>>>>> +				     0, height, 0, 0);
>>>>>>>> +		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>>>>>>>> +				     0, 255, 0, 0);
>>>>>>>> +
>>>>>>>> +		input_mt_init_slots(mtouch, num_cont, 0);
>>>>> We need error handling here.
>>>> done
>>>>>   Also, it would be nice if we set INPUT_MT_*
>>>>> flags here, so that userspace had better chance of figuring how to
>>>>> handle the device.
>>>> done, I will use INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED
>>> Does that mean that your backend does not reliably report release of
>>> contacts?
>> there is a ring buffer between host and guest,
>> so there is always a possibility (rather small I believe)
>> that the buffer overruns. Do you think I need INPUT_MT_DROP_UNUSED or
>> we can live without it?
> Again, it depends on your backend behavior. Do you report all slots
> repeatedly for every packet or you report only changed slots?
we report events repeatedly, so I think we can live
w/o _DROP_UNUSED
> Thanks.
>
>>> Thanks.
>>>
>>>>>>>> +
>>>>>>>> +		mtouch_size[KPARAM_MT_X] = width;
>>>>>>>> +		mtouch_size[KPARAM_MT_Y] = height;
>>>>>>>> +		info->mtouch_cur_contact_id = -1;
>>>>>>>> +
>>>>>>>> +		ret = input_register_device(mtouch);
>>>>>>>> +		if (ret) {
>>>>>>>> +			input_free_device(mtouch);
>>>>>>>> +			xenbus_dev_fatal(info->xbdev, ret,
>>>>>>>> +					 "input_register_device(mtouch)");
>>>>>>>> +			goto error;
>>>>>>>> +		}
>>>>>>>> +		info->mtouch_cur_contact_id = -1;
>>>>>>>> +		info->mtouch = mtouch;
>>>>>>>> +	}
>>>>>>>> +
>>>>>>>>   	ret = xenkbd_connect_backend(dev, info);
>>>>>>>>   	if (ret < 0)
>>>>>>>>   		goto error;
>>>>>>>> @@ -240,6 +376,8 @@ static int xenkbd_remove(struct xenbus_device *dev)
>>>>>>>>   		input_unregister_device(info->kbd);
>>>>>>>>   	if (info->ptr)
>>>>>>>>   		input_unregister_device(info->ptr);
>>>>>>>> +	if (info->mtouch)
>>>>>>>> +		input_unregister_device(info->mtouch);
>>>>>>>>   	free_page((unsigned long)info->page);
>>>>>>>>   	kfree(info);
>>>>>>>>   	return 0;
>>>>>>>> -- 
>>>>>>>> 2.7.4
>>>>>>>>
>>>>> Thanks.
>>>>>
>>>> For your convenience I am attaching the changes I am about
>>>> to put into v1 of the series:
>>>>   - remove unlikely
>>>>   - remove module parameters
>>>>   - error handling for input_mt_init_slots
>>>>   - let userspace better chance of figuring how to handle the device
>>>>
>>>> Thank you,
>>>> Oleksandr
>>>>  From e76506c55846e2bb4ccbafa430642e368643e51d Mon Sep 17 00:00:00 2001
>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>> Date: Tue, 30 May 2017 14:49:58 +0300
>>>> Subject: [PATCH] Fix: remove unlikely Fix: remove module paramters Fix: error
>>>>   handling for input_mt_init_slots Fix: let userspace better chance of figuring
>>>>   how to handle the device
>>>>
>>>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>> ---
>>>>   drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
>>>>   1 file changed, 10 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
>>>> index 8266ef948a06..273d786a19cd 100644
>>>> --- a/drivers/input/misc/xen-kbdfront.c
>>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>>> @@ -51,12 +51,6 @@ module_param_array(ptr_size, int, NULL, 0444);
>>>>   MODULE_PARM_DESC(ptr_size,
>>>>   	"Pointing device width, height in pixels (default 800,600)");
>>>> -enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>>>> -static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
>>>> -module_param_array(mtouch_size, int, NULL, 0444);
>>>> -MODULE_PARM_DESC(ptr_size,
>>>> -	"Multi-touch device width, height in pixels (default 800,600)");
>>>> -
>>>>   static int xenkbd_remove(struct xenbus_device *);
>>>>   static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
>>>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>>>> @@ -114,8 +108,8 @@ static irqreturn_t input_handler(int rq, void *dev_id)
>>>>   			dev = info->mtouch;
>>>>   			if (unlikely(!dev))
>>>>   				break;
>>>> -			if (unlikely(event->mtouch.contact_id !=
>>>> -					info->mtouch_cur_contact_id)) {
>>>> +			if (event->mtouch.contact_id !=
>>>> +					info->mtouch_cur_contact_id) {
>>>>   				info->mtouch_cur_contact_id =
>>>>   					event->mtouch.contact_id;
>>>>   				input_mt_slot(dev, event->mtouch.contact_id);
>>>> @@ -327,10 +321,15 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>   		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>>>>   				     0, 255, 0, 0);
>>>> -		input_mt_init_slots(mtouch, num_cont, 0);
>>>> +		ret = input_mt_init_slots(mtouch, num_cont,
>>>> +				INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED);
>>>> +		if (ret) {
>>>> +			input_free_device(mtouch);
>>>> +			xenbus_dev_fatal(info->xbdev, ret,
>>>> +					 "input_mt_init_slots");
>>>> +			goto error;
>>>> +		}
>>>> -		mtouch_size[KPARAM_MT_X] = width;
>>>> -		mtouch_size[KPARAM_MT_Y] = height;
>>>>   		info->mtouch_cur_contact_id = -1;
>>>>   		ret = input_register_device(mtouch);
>>>> -- 
>>>> 2.7.4
>>>>
>> Thank you,
>> Oleksandr
Dmitry, thank you for comments
The bottom line I see is:
  - no support for PEN tool at the moment
  - num contacts == 1 is OK
  - I will not use INPUT_MT_DROP_UNUSED

If the above is ok to you, then I will send another version of the
series (BTW, can I use your RB for the first patch which
removes hard-codes?)

Thank you,
Oleksandr

Re: [PATCH 2/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

Ping

On 06/08/2017 09:45 AM, Oleksandr Andrushchenko wrote:
> Hi, Dmitry!
>
> On 06/07/2017 07:56 PM, Dmitry Torokhov wrote:
>> On Wed, May 31, 2017 at 12:06:56PM +0300, Oleksandr Andrushchenko wrote:
>>> Hi, Dmitry!
>>>
>>> On 05/30/2017 07:37 PM, Dmitry Torokhov wrote:
>>>> On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko 
>>>> wrote:
>>>>> Hi, Dmitry!
>>>>>
>>>>> On 05/30/2017 08:51 AM, Dmitry Torokhov wrote:
>>>>>> On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko 
>>>>>> wrote:
>>>>>>> Hi, Dmitry!
>>>>>>>
>>>>>>> On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
>>>>>>>> Hi Oleksandr,
>>>>>>>>
>>>>>>>> On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr 
>>>>>>>> Andrushchenko wrote:
>>>>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>>>>
>>>>>>>>> Extend xen_kbdfront to provide multi-touch support
>>>>>>>>> to unprivileged domains.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Oleksandr Andrushchenko 
>>>>>>>>> <oleksandr_andrushchenko@epam.com>
>>>>>>>>> ---
>>>>>>>>>   drivers/input/misc/xen-kbdfront.c | 142 
>>>>>>>>> +++++++++++++++++++++++++++++++++++++-
>>>>>>>>>   1 file changed, 140 insertions(+), 2 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/input/misc/xen-kbdfront.c 
>>>>>>>>> b/drivers/input/misc/xen-kbdfront.c
>>>>>>>>> index 01c27b4c3288..e5d064aaa237 100644
>>>>>>>>> --- a/drivers/input/misc/xen-kbdfront.c
>>>>>>>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>>>>>>>> @@ -17,6 +17,7 @@
>>>>>>>>>   #include <linux/errno.h>
>>>>>>>>>   #include <linux/module.h>
>>>>>>>>>   #include <linux/input.h>
>>>>>>>>> +#include <linux/input/mt.h>
>>>>>>>>>   #include <linux/slab.h>
>>>>>>>>>   #include <asm/xen/hypervisor.h>
>>>>>>>>> @@ -34,11 +35,14 @@
>>>>>>>>>   struct xenkbd_info {
>>>>>>>>>       struct input_dev *kbd;
>>>>>>>>>       struct input_dev *ptr;
>>>>>>>>> +    struct input_dev *mtouch;
>>>>>>>>>       struct xenkbd_page *page;
>>>>>>>>>       int gref;
>>>>>>>>>       int irq;
>>>>>>>>>       struct xenbus_device *xbdev;
>>>>>>>>>       char phys[32];
>>>>>>>>> +    /* current MT slot/contact ID we are injecting events in */
>>>>>>>>> +    int mtouch_cur_contact_id;
>>>>>>>>>   };
>>>>>>>>>   enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
>>>>>>>>> @@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
>>>>>>>>>   MODULE_PARM_DESC(ptr_size,
>>>>>>>>>       "Pointing device width, height in pixels (default 
>>>>>>>>> 800,600)");
>>>>>>>>> +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>>>>>>>>> +static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, 
>>>>>>>>> XENFB_HEIGHT };
>>>>>>>>> +module_param_array(mtouch_size, int, NULL, 0444);
>>>>>>>>> +MODULE_PARM_DESC(ptr_size,
>>>>>>>>> +    "Multi-touch device width, height in pixels (default 
>>>>>>>>> 800,600)");
>>>>>>>>> +
>>>>>>>> Why do you need separate module parameters for multi-touch device?
>>>>>>> please see below
>>>>>>>>>   static int xenkbd_remove(struct xenbus_device *);
>>>>>>>>>   static int xenkbd_connect_backend(struct xenbus_device *, 
>>>>>>>>> struct xenkbd_info *);
>>>>>>>>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>>>>>>>>> @@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, 
>>>>>>>>> void *dev_id)
>>>>>>>>>                   input_report_rel(dev, REL_WHEEL,
>>>>>>>>>                            -event->pos.rel_z);
>>>>>>>>>               break;
>>>>>>>>> +        case XENKBD_TYPE_MTOUCH:
>>>>>>>>> +            dev = info->mtouch;
>>>>>>>>> +            if (unlikely(!dev))
>>>>>>>>> +                break;
>>>>>>>>> +            if (unlikely(event->mtouch.contact_id !=
>>>>>>>>> + info->mtouch_cur_contact_id)) {
>>>>>>>> Why is this unlikely? Does contact ID changes once in 1000 
>>>>>>>> packets or
>>>>>>>> even less?
>>>>>>> Mu assumption was that regardless of the fact that we are 
>>>>>>> multi-touch
>>>>>>> device still single touches will come in more frequently
>>>>>>> But I can remove *unlikely* if my assumption is not correct
>>>>>> I think the normal expectation is that "unlikely" is supposed for
>>>>>> something that happens once in a blue moon, so I'd rather remove it.
>>>>>>
>>>>> agree, removed "unlikely"
>>>>>>>>> + info->mtouch_cur_contact_id =
>>>>>>>>> +                    event->mtouch.contact_id;
>>>>>>>>> +                input_mt_slot(dev, event->mtouch.contact_id);
>>>>>>>>> +            }
>>>>>>>>> +            switch (event->mtouch.event_type) {
>>>>>>>>> +            case XENKBD_MT_EV_DOWN:
>>>>>>>>> +                input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>>>>>>> +                               true);
>>>>>> Should we establish tool event? We have MT_TOOL_PEN, etc.
>>>>> I think that for multi-touch MT_TOOL_FINGER is enough
>>>>> any reason we would also want MT_TOOL_PEN here?
>>>> Why would not you? Let's say you have a drawing application running in
>>>> guest that can make use of tool types. Why would not you want to 
>>>> tell it
>>>> that the tool user is currently using is in fact a pen and not finger?
>>> But it is a finger :) we are multi-touch, not multi pen
>> So for tablets that support both touch and stylus you would export them
>> as 2 separate devices?
> this could be done in different ways, but please see on
> pen support below
>>> Besides, that, if I am about to implement pen support
>>> (which I still not convinced we really need), how will I
>>> do that?
>> I do not know what you have on the backend side, but roughly speaking if
>> you detect a pen/stylus you let your guest know that the contact is not
>> a finger, but pen. How you plumb it through is up to you.
> we do not detect pen, only finger at the moment
> and the existing protocol has no means to tell
> type of the tool used, everything is supposed to
> be "finger", so front-end has no possibility to
> tell one tool from another
>>> My understanding is that I need 2 different slots to report
>>> the same coordinates for finger and pen. This is because
>>> input_mt_report_slot_state has a check that if tool has
>>> changed for the current slot then a new tracking ID is set.
>>> Do I also need to allocate twice more slots, so I can
>>> report 2 * num_contacts events simultaneously (one for finger
>>> and another for pen)?
>>> That said, I believe we can start with multi-touch support
>>> and if need be then add pen support as a separate change,
>>> does that make sense for you?
>>>>> (I guess MT_TOOL_PALM is not appropriate anyways)
>>>> Depends on if you do straight pass-through from the host side or 
>>>> not. If
>>>> you stack does palm rejection before passing the data through then you
>>>> would not see MT_TOOL_PALM in guest.
>>> the protocol used between guest and host is a generic one,
>>> not using Linux types/constants/events.
>> It does not have to use Linux types to support the concept of different
>> tools.
> agree
>>> So, no PALM/TOOL support is in place
>> OK, that is fair. The pen support is definitely not a hard requirement.
> so, can we live with finger at this point, no pen?
>> I was just wondering if you considered or have plans for adding that.
> well, honestly, we do not need pen at the moment,
> but we did add multi-touch support into Xen protocols
> and if pen required it can be done as a separate
> change to both protocol and front/back ends
>>   Or
>> if you want to review the protocol so it can be easily added in the
>> future. For example you could have tool type to be part of
>> XENKBD_MT_EV_DOWN event.
> protocol did a long way to get into Xen/Kernel... :)
> of course, this can be done, but I would prefer it is
> added when it is needed, not only that we have this functionality
>>>>>>>>> + input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>>>>>>> + event->mtouch.u.pos.abs_x);
>>>>>>>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>>>>>>> + event->mtouch.u.pos.abs_y);
>>>>>>>>> +                input_event(dev, EV_ABS, ABS_X,
>>>>>>>>> + event->mtouch.u.pos.abs_x);
>>>>>>>>> +                input_event(dev, EV_ABS, ABS_Y,
>>>>>>>>> + event->mtouch.u.pos.abs_y);
>>>>>>>>> +                break;
>>>>>>>>> +            case XENKBD_MT_EV_UP:
>>>>>>>>> +                input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>>>>>>> +                               false);
>>>>>>>>> +                break;
>>>>>>>>> +            case XENKBD_MT_EV_MOTION:
>>>>>>>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>>>>>>> + event->mtouch.u.pos.abs_x);
>>>>>>>>> +                input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>>>>>>> + event->mtouch.u.pos.abs_y);
>>>>>>>>> +                input_event(dev, EV_ABS, ABS_X,
>>>>>>>>> + event->mtouch.u.pos.abs_x);
>>>>>>>>> +                input_event(dev, EV_ABS, ABS_Y,
>>>>>>>>> + event->mtouch.u.pos.abs_y);
>>>>>>>>> +                break;
>>>>>>>>> +            case XENKBD_MT_EV_SYN:
>>>>>>>>> +                input_mt_sync_frame(dev);
>>>>>>>>> +                break;
>>>>>>>>> +            case XENKBD_MT_EV_SHAPE:
>>>>>>>>> +                input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
>>>>>>>>> + event->mtouch.u.shape.major);
>>>>>>>>> +                input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
>>>>>>>>> + event->mtouch.u.shape.minor);
>>>>>>>>> +                break;
>>>>>>>>> +            case XENKBD_MT_EV_ORIENT:
>>>>>>>>> +                input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
>>>>>>>>> + event->mtouch.u.orientation);
>>>>>>>>> +                break;
>>>>>>>>> +            }
>>>>>>>>> +            /* only report syn when requested */
>>>>>>>>> +            if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
>>>>>>>>> +                dev = NULL;
>>>>>>>>>           }
>>>>>>>>>           if (dev)
>>>>>>>>>               input_sync(dev);
>>>>>>>>> @@ -115,9 +179,9 @@ static int xenkbd_probe(struct 
>>>>>>>>> xenbus_device *dev,
>>>>>>>>>                     const struct xenbus_device_id *id)
>>>>>>>>>   {
>>>>>>>>>       int ret, i;
>>>>>>>>> -    unsigned int abs;
>>>>>>>>> +    unsigned int abs, touch;
>>>>>>>>>       struct xenkbd_info *info;
>>>>>>>>> -    struct input_dev *kbd, *ptr;
>>>>>>>>> +    struct input_dev *kbd, *ptr, *mtouch;
>>>>>>>>>       info = kzalloc(sizeof(*info), GFP_KERNEL);
>>>>>>>>>       if (!info) {
>>>>>>>>> @@ -152,6 +216,17 @@ static int xenkbd_probe(struct 
>>>>>>>>> xenbus_device *dev,
>>>>>>>>>           }
>>>>>>>>>       }
>>>>>>>>> +    touch = xenbus_read_unsigned(dev->nodename,
>>>>>>>>> +                     XENKBD_FIELD_FEAT_MTOUCH, 0);
>>>>>>>>> +    if (touch) {
>>>>>>>>> +        ret = xenbus_write(XBT_NIL, dev->nodename,
>>>>>>>>> +                   XENKBD_FIELD_REQ_MTOUCH, "1");
>>>>>>>>> +        if (ret) {
>>>>>>>>> +            pr_warning("xenkbd: can't request multi-touch");
>>>>>>>>> +            touch = 0;
>>>>>>>>> +        }
>>>>>>>>> +    }
>>>>>>>>> +
>>>>>>>>>       /* keyboard */
>>>>>>>>>       kbd = input_allocate_device();
>>>>>>>>>       if (!kbd)
>>>>>>>>> @@ -208,6 +283,67 @@ static int xenkbd_probe(struct 
>>>>>>>>> xenbus_device *dev,
>>>>>>>>>       }
>>>>>>>>>       info->ptr = ptr;
>>>>>>>>> +    /* multi-touch device */
>>>>>>>>> +    if (touch) {
>>>>>>>>> +        int num_cont, width, height;
>>>>>>>>> +
>>>>>>>>> +        mtouch = input_allocate_device();
>>>>>>>>> +        if (!mtouch)
>>>>>>>>> +            goto error_nomem;
>>>>>>>>> +
>>>>>>>>> +        num_cont = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>>>>> + XENKBD_FIELD_MT_NUM_CONTACTS,
>>>>>>>>> +                        1);
>>>>>> Should we refuse MT devices with number of contacts less than 2?
>>>>> we can, but I see no harm in 1. what is more, this may
>>>>> allow guests to emulate more pointing devices
>>>>> but, if you insist, then I will add appropriate code to
>>>>> reject if number of contacts is less then 2
>> The question is if you are planning to keep the single-touch interface
>> or you will migrate everything to multi-touch.
> I will keep single touch as legacy, but in our use-cases
> we are more focusing on using multi-touch devices.
> but even with number of contacts == 1 it can still be
> useful as it gives more flexibility in configuring guest OS
> If you insist that num contacts == 1 must be removed,
> please let me know and I will handle that
>>>>>>>>> +        width = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>>>>> +                         XENKBD_FIELD_MT_WIDTH,
>>>>>>>>> +                         XENFB_WIDTH);
>>>>>>>>> +        height = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>>>>> +                          XENKBD_FIELD_MT_HEIGHT,
>>>>>>>>> +                          XENFB_HEIGHT);
>>>>>>>> Curious why you need separate parameters here too...
>>>>>>> This is because mt parameters are different from ptr
>>>>>>> in a way that they are configurable per front driver's
>>>>>>> instance rather than per backend, e.g. in XenStore:
>>>>>>>
>>>>>>> /local/domain/0/backend/vkbd/1/0/width = "1920"
>>>>>>> /local/domain/0/backend/vkbd/1/0/height = "1080"
>>>>>>>
>>>>>>> /local/domain/1/device/vkbd/0/multi-touch-width = "1920"
>>>>>>> /local/domain/1/device/vkbd/0/multi-touch-height = "1080"
>>>>>>> /local/domain/1/device/vkbd/0/multi-touch-num-contacts = "10"
>>>>>>>
>>>>>>> /local/domain/1/device/vkbd/1/multi-touch-width = "800"
>>>>>>> /local/domain/1/device/vkbd/1/multi-touch-height = "600"
>>>>>>> /local/domain/1/device/vkbd/1/multi-touch-num-contacts = "3"
>>>>>>>
>>>>>>> The main reason for such configuration is that you can
>>>>>>> configure multiple mt input devices even for the same guest
>>>>>>> with different resolutions which may not match those
>>>>>>> configured for ptr.
>>>>>>> (In my use-case I use new displif protocol [1] in conjunction
>>>>>>> with mt input devices and the corresponding backend is not
>>>>>>> QEMU's xenfb)
>>>>>> I see.
>>>>>>
>>>>>>> As to module parameters, I added those to be consistent with
>>>>>>> ptr device. Do you think we can live without them and
>>>>>>> do you want me to remove them?
>>>>>> Yes, I think we better. I am also confused by the way you are 
>>>>>> handling
>>>>>> the module parameters. It looks to me you update them with data 
>>>>>> passed
>>>>> >from the backend, but never use the data...
>>>>> I have removed module parameters (the only use of those
>>>>> was to be able to see configured width and height on
>>>>> guest side, but this is minor)
>>>> evtest would show it to you. Or you can query input device yourself
>>>> (EVIOCGABS iotcl).
>>> yes, if embedded system (which is my target) has evtest
>>> but it definitely does have ioctl though
>>>>>>>>> +
>>>>>>>>> +        mtouch->name = "Xen Virtual Multi-touch";
>>>>>>>>> +        mtouch->phys = info->phys;
>>>>>>>>> +        mtouch->id.bustype = BUS_PCI;
>>>>>>>>> +        mtouch->id.vendor = 0x5853;
>>>>>>>>> +        mtouch->id.product = 0xfffd;
>>>>>>>>> +
>>>>>>>>> +        __set_bit(EV_ABS, mtouch->evbit);
>>>>>>>>> +        __set_bit(EV_KEY, mtouch->evbit);
>>>>>>>>> +        __set_bit(BTN_TOUCH, mtouch->keybit);
>>>> Please make it
>>>>         input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
>>>>
>>>> and drop all __set_bit()s.
>>> done, thank you
>>>>>>>>> +
>>>>>>>>> +        input_set_abs_params(mtouch, ABS_X,
>>>>>>>>> +                     0, width, 0, 0);
>>>>>>>>> +        input_set_abs_params(mtouch, ABS_Y,
>>>>>>>>> +                     0, height, 0, 0);
>>>>>>>>> +        input_set_abs_params(mtouch, ABS_PRESSURE,
>>>>>>>>> +                     0, 255, 0, 0);
>>>>>>>>> +
>>>>>>>>> +        input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
>>>>>>>>> +                     0, 255, 0, 0);
>>>>>>>>> +        input_set_abs_params(mtouch, ABS_MT_POSITION_X,
>>>>>>>>> +                     0, width, 0, 0);
>>>>>>>>> +        input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
>>>>>>>>> +                     0, height, 0, 0);
>>>>>>>>> +        input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>>>>>>>>> +                     0, 255, 0, 0);
>>>>>>>>> +
>>>>>>>>> +        input_mt_init_slots(mtouch, num_cont, 0);
>>>>>> We need error handling here.
>>>>> done
>>>>>>   Also, it would be nice if we set INPUT_MT_*
>>>>>> flags here, so that userspace had better chance of figuring how to
>>>>>> handle the device.
>>>>> done, I will use INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED
>>>> Does that mean that your backend does not reliably report release of
>>>> contacts?
>>> there is a ring buffer between host and guest,
>>> so there is always a possibility (rather small I believe)
>>> that the buffer overruns. Do you think I need INPUT_MT_DROP_UNUSED or
>>> we can live without it?
>> Again, it depends on your backend behavior. Do you report all slots
>> repeatedly for every packet or you report only changed slots?
> we report events repeatedly, so I think we can live
> w/o _DROP_UNUSED
>> Thanks.
>>
>>>> Thanks.
>>>>
>>>>>>>>> +
>>>>>>>>> +        mtouch_size[KPARAM_MT_X] = width;
>>>>>>>>> +        mtouch_size[KPARAM_MT_Y] = height;
>>>>>>>>> +        info->mtouch_cur_contact_id = -1;
>>>>>>>>> +
>>>>>>>>> +        ret = input_register_device(mtouch);
>>>>>>>>> +        if (ret) {
>>>>>>>>> +            input_free_device(mtouch);
>>>>>>>>> +            xenbus_dev_fatal(info->xbdev, ret,
>>>>>>>>> + "input_register_device(mtouch)");
>>>>>>>>> +            goto error;
>>>>>>>>> +        }
>>>>>>>>> +        info->mtouch_cur_contact_id = -1;
>>>>>>>>> +        info->mtouch = mtouch;
>>>>>>>>> +    }
>>>>>>>>> +
>>>>>>>>>       ret = xenkbd_connect_backend(dev, info);
>>>>>>>>>       if (ret < 0)
>>>>>>>>>           goto error;
>>>>>>>>> @@ -240,6 +376,8 @@ static int xenkbd_remove(struct 
>>>>>>>>> xenbus_device *dev)
>>>>>>>>>           input_unregister_device(info->kbd);
>>>>>>>>>       if (info->ptr)
>>>>>>>>>           input_unregister_device(info->ptr);
>>>>>>>>> +    if (info->mtouch)
>>>>>>>>> +        input_unregister_device(info->mtouch);
>>>>>>>>>       free_page((unsigned long)info->page);
>>>>>>>>>       kfree(info);
>>>>>>>>>       return 0;
>>>>>>>>> -- 
>>>>>>>>> 2.7.4
>>>>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>> For your convenience I am attaching the changes I am about
>>>>> to put into v1 of the series:
>>>>>   - remove unlikely
>>>>>   - remove module parameters
>>>>>   - error handling for input_mt_init_slots
>>>>>   - let userspace better chance of figuring how to handle the device
>>>>>
>>>>> Thank you,
>>>>> Oleksandr
>>>>>  From e76506c55846e2bb4ccbafa430642e368643e51d Mon Sep 17 00:00:00 
>>>>> 2001
>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>> Date: Tue, 30 May 2017 14:49:58 +0300
>>>>> Subject: [PATCH] Fix: remove unlikely Fix: remove module paramters 
>>>>> Fix: error
>>>>>   handling for input_mt_init_slots Fix: let userspace better 
>>>>> chance of figuring
>>>>>   how to handle the device
>>>>>
>>>>> Signed-off-by: Oleksandr Andrushchenko 
>>>>> <oleksandr_andrushchenko@epam.com>
>>>>> ---
>>>>>   drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
>>>>>   1 file changed, 10 insertions(+), 11 deletions(-)
>>>>>
>>>>> diff --git a/drivers/input/misc/xen-kbdfront.c 
>>>>> b/drivers/input/misc/xen-kbdfront.c
>>>>> index 8266ef948a06..273d786a19cd 100644
>>>>> --- a/drivers/input/misc/xen-kbdfront.c
>>>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>>>> @@ -51,12 +51,6 @@ module_param_array(ptr_size, int, NULL, 0444);
>>>>>   MODULE_PARM_DESC(ptr_size,
>>>>>       "Pointing device width, height in pixels (default 800,600)");
>>>>> -enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>>>>> -static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, 
>>>>> XENFB_HEIGHT };
>>>>> -module_param_array(mtouch_size, int, NULL, 0444);
>>>>> -MODULE_PARM_DESC(ptr_size,
>>>>> -    "Multi-touch device width, height in pixels (default 800,600)");
>>>>> -
>>>>>   static int xenkbd_remove(struct xenbus_device *);
>>>>>   static int xenkbd_connect_backend(struct xenbus_device *, struct 
>>>>> xenkbd_info *);
>>>>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>>>>> @@ -114,8 +108,8 @@ static irqreturn_t input_handler(int rq, void 
>>>>> *dev_id)
>>>>>               dev = info->mtouch;
>>>>>               if (unlikely(!dev))
>>>>>                   break;
>>>>> -            if (unlikely(event->mtouch.contact_id !=
>>>>> -                    info->mtouch_cur_contact_id)) {
>>>>> +            if (event->mtouch.contact_id !=
>>>>> +                    info->mtouch_cur_contact_id) {
>>>>>                   info->mtouch_cur_contact_id =
>>>>>                       event->mtouch.contact_id;
>>>>>                   input_mt_slot(dev, event->mtouch.contact_id);
>>>>> @@ -327,10 +321,15 @@ static int xenkbd_probe(struct xenbus_device 
>>>>> *dev,
>>>>>           input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>>>>>                        0, 255, 0, 0);
>>>>> -        input_mt_init_slots(mtouch, num_cont, 0);
>>>>> +        ret = input_mt_init_slots(mtouch, num_cont,
>>>>> +                INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED);
>>>>> +        if (ret) {
>>>>> +            input_free_device(mtouch);
>>>>> +            xenbus_dev_fatal(info->xbdev, ret,
>>>>> +                     "input_mt_init_slots");
>>>>> +            goto error;
>>>>> +        }
>>>>> -        mtouch_size[KPARAM_MT_X] = width;
>>>>> -        mtouch_size[KPARAM_MT_Y] = height;
>>>>>           info->mtouch_cur_contact_id = -1;
>>>>>           ret = input_register_device(mtouch);
>>>>> -- 
>>>>> 2.7.4
>>>>>
>>> Thank you,
>>> Oleksandr
> Dmitry, thank you for comments
> The bottom line I see is:
>  - no support for PEN tool at the moment
>  - num contacts == 1 is OK
>  - I will not use INPUT_MT_DROP_UNUSED
>
> If the above is ok to you, then I will send another version of the
> series (BTW, can I use your RB for the first patch which
> removes hard-codes?)
>
> Thank you,
> Oleksandr

Re: [PATCH 2/2] xen/input: add multi-touch support

[Dmitry Torokhov]

On Thu, Jun 08, 2017 at 09:45:18AM +0300, Oleksandr Andrushchenko wrote:
> Hi, Dmitry!
> 
> On 06/07/2017 07:56 PM, Dmitry Torokhov wrote:
> >On Wed, May 31, 2017 at 12:06:56PM +0300, Oleksandr Andrushchenko wrote:
> >>Hi, Dmitry!
> >>
> >>On 05/30/2017 07:37 PM, Dmitry Torokhov wrote:
> >>>On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko wrote:
> >>>>Hi, Dmitry!
> >>>>
> >>>>On 05/30/2017 08:51 AM, Dmitry Torokhov wrote:
> >>>>>On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko wrote:
> >>>>>>Hi, Dmitry!
> >>>>>>
> >>>>>>On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
> >>>>>>>Hi Oleksandr,
> >>>>>>>
> >>>>>>>On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
> >>>>>>>>From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>>>>>>>
> >>>>>>>>Extend xen_kbdfront to provide multi-touch support
> >>>>>>>>to unprivileged domains.
> >>>>>>>>
> >>>>>>>>Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>>>>>>>---
> >>>>>>>>  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
> >>>>>>>>  1 file changed, 140 insertions(+), 2 deletions(-)
> >>>>>>>>
> >>>>>>>>diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> >>>>>>>>index 01c27b4c3288..e5d064aaa237 100644
> >>>>>>>>--- a/drivers/input/misc/xen-kbdfront.c
> >>>>>>>>+++ b/drivers/input/misc/xen-kbdfront.c
> >>>>>>>>@@ -17,6 +17,7 @@
> >>>>>>>>  #include <linux/errno.h>
> >>>>>>>>  #include <linux/module.h>
> >>>>>>>>  #include <linux/input.h>
> >>>>>>>>+#include <linux/input/mt.h>
> >>>>>>>>  #include <linux/slab.h>
> >>>>>>>>  #include <asm/xen/hypervisor.h>
> >>>>>>>>@@ -34,11 +35,14 @@
> >>>>>>>>  struct xenkbd_info {
> >>>>>>>>  	struct input_dev *kbd;
> >>>>>>>>  	struct input_dev *ptr;
> >>>>>>>>+	struct input_dev *mtouch;
> >>>>>>>>  	struct xenkbd_page *page;
> >>>>>>>>  	int gref;
> >>>>>>>>  	int irq;
> >>>>>>>>  	struct xenbus_device *xbdev;
> >>>>>>>>  	char phys[32];
> >>>>>>>>+	/* current MT slot/contact ID we are injecting events in */
> >>>>>>>>+	int mtouch_cur_contact_id;
> >>>>>>>>  };
> >>>>>>>>  enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
> >>>>>>>>@@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
> >>>>>>>>  MODULE_PARM_DESC(ptr_size,
> >>>>>>>>  	"Pointing device width, height in pixels (default 800,600)");
> >>>>>>>>+enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
> >>>>>>>>+static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
> >>>>>>>>+module_param_array(mtouch_size, int, NULL, 0444);
> >>>>>>>>+MODULE_PARM_DESC(ptr_size,
> >>>>>>>>+	"Multi-touch device width, height in pixels (default 800,600)");
> >>>>>>>>+
> >>>>>>>Why do you need separate module parameters for multi-touch device?
> >>>>>>please see below
> >>>>>>>>  static int xenkbd_remove(struct xenbus_device *);
> >>>>>>>>  static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
> >>>>>>>>  static void xenkbd_disconnect_backend(struct xenkbd_info *);
> >>>>>>>>@@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void *dev_id)
> >>>>>>>>  				input_report_rel(dev, REL_WHEEL,
> >>>>>>>>  						 -event->pos.rel_z);
> >>>>>>>>  			break;
> >>>>>>>>+		case XENKBD_TYPE_MTOUCH:
> >>>>>>>>+			dev = info->mtouch;
> >>>>>>>>+			if (unlikely(!dev))
> >>>>>>>>+				break;
> >>>>>>>>+			if (unlikely(event->mtouch.contact_id !=
> >>>>>>>>+					info->mtouch_cur_contact_id)) {
> >>>>>>>Why is this unlikely? Does contact ID changes once in 1000 packets or
> >>>>>>>even less?
> >>>>>>Mu assumption was that regardless of the fact that we are multi-touch
> >>>>>>device still single touches will come in more frequently
> >>>>>>But I can remove *unlikely* if my assumption is not correct
> >>>>>I think the normal expectation is that "unlikely" is supposed for
> >>>>>something that happens once in a blue moon, so I'd rather remove it.
> >>>>>
> >>>>agree, removed "unlikely"
> >>>>>>>>+				info->mtouch_cur_contact_id =
> >>>>>>>>+					event->mtouch.contact_id;
> >>>>>>>>+				input_mt_slot(dev, event->mtouch.contact_id);
> >>>>>>>>+			}
> >>>>>>>>+			switch (event->mtouch.event_type) {
> >>>>>>>>+			case XENKBD_MT_EV_DOWN:
> >>>>>>>>+				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
> >>>>>>>>+							   true);
> >>>>>Should we establish tool event? We have MT_TOOL_PEN, etc.
> >>>>I think that for multi-touch MT_TOOL_FINGER is enough
> >>>>any reason we would also want MT_TOOL_PEN here?
> >>>Why would not you? Let's say you have a drawing application running in
> >>>guest that can make use of tool types. Why would not you want to tell it
> >>>that the tool user is currently using is in fact a pen and not finger?
> >>But it is a finger :) we are multi-touch, not multi pen
> >So for tablets that support both touch and stylus you would export them
> >as 2 separate devices?
> this could be done in different ways, but please see on
> pen support below
> >>Besides, that, if I am about to implement pen support
> >>(which I still not convinced we really need), how will I
> >>do that?
> >I do not know what you have on the backend side, but roughly speaking if
> >you detect a pen/stylus you let your guest know that the contact is not
> >a finger, but pen. How you plumb it through is up to you.
> we do not detect pen, only finger at the moment
> and the existing protocol has no means to tell
> type of the tool used, everything is supposed to
> be "finger", so front-end has no possibility to
> tell one tool from another
> >>My understanding is that I need 2 different slots to report
> >>the same coordinates for finger and pen. This is because
> >>input_mt_report_slot_state has a check that if tool has
> >>changed for the current slot then a new tracking ID is set.
> >>Do I also need to allocate twice more slots, so I can
> >>report 2 * num_contacts events simultaneously (one for finger
> >>and another for pen)?
> >>That said, I believe we can start with multi-touch support
> >>and if need be then add pen support as a separate change,
> >>does that make sense for you?
> >>>>(I guess MT_TOOL_PALM is not appropriate anyways)
> >>>Depends on if you do straight pass-through from the host side or not. If
> >>>you stack does palm rejection before passing the data through then you
> >>>would not see MT_TOOL_PALM in guest.
> >>the protocol used between guest and host is a generic one,
> >>not using Linux types/constants/events.
> >It does not have to use Linux types to support the concept of different
> >tools.
> agree
> >>So, no PALM/TOOL support is in place
> >OK, that is fair. The pen support is definitely not a hard requirement.
> so, can we live with finger at this point, no pen?
> >I was just wondering if you considered or have plans for adding that.
> well, honestly, we do not need pen at the moment,
> but we did add multi-touch support into Xen protocols
> and if pen required it can be done as a separate
> change to both protocol and front/back ends
> >  Or
> >if you want to review the protocol so it can be easily added in the
> >future. For example you could have tool type to be part of
> >XENKBD_MT_EV_DOWN event.
> protocol did a long way to get into Xen/Kernel... :)
> of course, this can be done, but I would prefer it is
> added when it is needed, not only that we have this functionality

OK.

> >>>>>>>>+				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
> >>>>>>>>+					    event->mtouch.u.pos.abs_x);
> >>>>>>>>+				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
> >>>>>>>>+					    event->mtouch.u.pos.abs_y);
> >>>>>>>>+				input_event(dev, EV_ABS, ABS_X,
> >>>>>>>>+					    event->mtouch.u.pos.abs_x);
> >>>>>>>>+				input_event(dev, EV_ABS, ABS_Y,
> >>>>>>>>+					    event->mtouch.u.pos.abs_y);
> >>>>>>>>+				break;
> >>>>>>>>+			case XENKBD_MT_EV_UP:
> >>>>>>>>+				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
> >>>>>>>>+							   false);
> >>>>>>>>+				break;
> >>>>>>>>+			case XENKBD_MT_EV_MOTION:
> >>>>>>>>+				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
> >>>>>>>>+					    event->mtouch.u.pos.abs_x);
> >>>>>>>>+				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
> >>>>>>>>+					    event->mtouch.u.pos.abs_y);
> >>>>>>>>+				input_event(dev, EV_ABS, ABS_X,
> >>>>>>>>+					    event->mtouch.u.pos.abs_x);
> >>>>>>>>+				input_event(dev, EV_ABS, ABS_Y,
> >>>>>>>>+					    event->mtouch.u.pos.abs_y);
> >>>>>>>>+				break;
> >>>>>>>>+			case XENKBD_MT_EV_SYN:
> >>>>>>>>+				input_mt_sync_frame(dev);
> >>>>>>>>+				break;
> >>>>>>>>+			case XENKBD_MT_EV_SHAPE:
> >>>>>>>>+				input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
> >>>>>>>>+					    event->mtouch.u.shape.major);
> >>>>>>>>+				input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
> >>>>>>>>+					    event->mtouch.u.shape.minor);
> >>>>>>>>+				break;
> >>>>>>>>+			case XENKBD_MT_EV_ORIENT:
> >>>>>>>>+				input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
> >>>>>>>>+					    event->mtouch.u.orientation);
> >>>>>>>>+				break;
> >>>>>>>>+			}
> >>>>>>>>+			/* only report syn when requested */
> >>>>>>>>+			if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
> >>>>>>>>+				dev = NULL;
> >>>>>>>>  		}
> >>>>>>>>  		if (dev)
> >>>>>>>>  			input_sync(dev);
> >>>>>>>>@@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >>>>>>>>  				  const struct xenbus_device_id *id)
> >>>>>>>>  {
> >>>>>>>>  	int ret, i;
> >>>>>>>>-	unsigned int abs;
> >>>>>>>>+	unsigned int abs, touch;
> >>>>>>>>  	struct xenkbd_info *info;
> >>>>>>>>-	struct input_dev *kbd, *ptr;
> >>>>>>>>+	struct input_dev *kbd, *ptr, *mtouch;
> >>>>>>>>  	info = kzalloc(sizeof(*info), GFP_KERNEL);
> >>>>>>>>  	if (!info) {
> >>>>>>>>@@ -152,6 +216,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >>>>>>>>  		}
> >>>>>>>>  	}
> >>>>>>>>+	touch = xenbus_read_unsigned(dev->nodename,
> >>>>>>>>+				     XENKBD_FIELD_FEAT_MTOUCH, 0);
> >>>>>>>>+	if (touch) {
> >>>>>>>>+		ret = xenbus_write(XBT_NIL, dev->nodename,
> >>>>>>>>+				   XENKBD_FIELD_REQ_MTOUCH, "1");
> >>>>>>>>+		if (ret) {
> >>>>>>>>+			pr_warning("xenkbd: can't request multi-touch");
> >>>>>>>>+			touch = 0;
> >>>>>>>>+		}
> >>>>>>>>+	}
> >>>>>>>>+
> >>>>>>>>  	/* keyboard */
> >>>>>>>>  	kbd = input_allocate_device();
> >>>>>>>>  	if (!kbd)
> >>>>>>>>@@ -208,6 +283,67 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >>>>>>>>  	}
> >>>>>>>>  	info->ptr = ptr;
> >>>>>>>>+	/* multi-touch device */
> >>>>>>>>+	if (touch) {
> >>>>>>>>+		int num_cont, width, height;
> >>>>>>>>+
> >>>>>>>>+		mtouch = input_allocate_device();
> >>>>>>>>+		if (!mtouch)
> >>>>>>>>+			goto error_nomem;
> >>>>>>>>+
> >>>>>>>>+		num_cont = xenbus_read_unsigned(info->xbdev->nodename,
> >>>>>>>>+						XENKBD_FIELD_MT_NUM_CONTACTS,
> >>>>>>>>+						1);
> >>>>>Should we refuse MT devices with number of contacts less than 2?
> >>>>we can, but I see no harm in 1. what is more, this may
> >>>>allow guests to emulate more pointing devices
> >>>>but, if you insist, then I will add appropriate code to
> >>>>reject if number of contacts is less then 2
> >The question is if you are planning to keep the single-touch interface
> >or you will migrate everything to multi-touch.
> I will keep single touch as legacy, but in our use-cases
> we are more focusing on using multi-touch devices.
> but even with number of contacts == 1 it can still be
> useful as it gives more flexibility in configuring guest OS
> If you insist that num contacts == 1 must be removed,
> please let me know and I will handle that

No, that is fine. I was simply trying to understand the plans for
single/multi-touch support in your backend.

> >>>>>>>>+		width = xenbus_read_unsigned(info->xbdev->nodename,
> >>>>>>>>+					     XENKBD_FIELD_MT_WIDTH,
> >>>>>>>>+					     XENFB_WIDTH);
> >>>>>>>>+		height = xenbus_read_unsigned(info->xbdev->nodename,
> >>>>>>>>+					      XENKBD_FIELD_MT_HEIGHT,
> >>>>>>>>+					      XENFB_HEIGHT);
> >>>>>>>Curious why you need separate parameters here too...
> >>>>>>This is because mt parameters are different from ptr
> >>>>>>in a way that they are configurable per front driver's
> >>>>>>instance rather than per backend, e.g. in XenStore:
> >>>>>>
> >>>>>>/local/domain/0/backend/vkbd/1/0/width = "1920"
> >>>>>>/local/domain/0/backend/vkbd/1/0/height = "1080"
> >>>>>>
> >>>>>>/local/domain/1/device/vkbd/0/multi-touch-width = "1920"
> >>>>>>/local/domain/1/device/vkbd/0/multi-touch-height = "1080"
> >>>>>>/local/domain/1/device/vkbd/0/multi-touch-num-contacts = "10"
> >>>>>>
> >>>>>>/local/domain/1/device/vkbd/1/multi-touch-width = "800"
> >>>>>>/local/domain/1/device/vkbd/1/multi-touch-height = "600"
> >>>>>>/local/domain/1/device/vkbd/1/multi-touch-num-contacts = "3"
> >>>>>>
> >>>>>>The main reason for such configuration is that you can
> >>>>>>configure multiple mt input devices even for the same guest
> >>>>>>with different resolutions which may not match those
> >>>>>>configured for ptr.
> >>>>>>(In my use-case I use new displif protocol [1] in conjunction
> >>>>>>with mt input devices and the corresponding backend is not
> >>>>>>QEMU's xenfb)
> >>>>>I see.
> >>>>>
> >>>>>>As to module parameters, I added those to be consistent with
> >>>>>>ptr device. Do you think we can live without them and
> >>>>>>do you want me to remove them?
> >>>>>Yes, I think we better. I am also confused by the way you are handling
> >>>>>the module parameters. It looks to me you update them with data passed
> >>>>>from the backend, but never use the data...
> >>>>I have removed module parameters (the only use of those
> >>>>was to be able to see configured width and height on
> >>>>guest side, but this is minor)
> >>>evtest would show it to you. Or you can query input device yourself
> >>>(EVIOCGABS iotcl).
> >>yes, if embedded system (which is my target) has evtest
> >>but it definitely does have ioctl though
> >>>>>>>>+
> >>>>>>>>+		mtouch->name = "Xen Virtual Multi-touch";
> >>>>>>>>+		mtouch->phys = info->phys;
> >>>>>>>>+		mtouch->id.bustype = BUS_PCI;
> >>>>>>>>+		mtouch->id.vendor = 0x5853;
> >>>>>>>>+		mtouch->id.product = 0xfffd;
> >>>>>>>>+
> >>>>>>>>+		__set_bit(EV_ABS, mtouch->evbit);
> >>>>>>>>+		__set_bit(EV_KEY, mtouch->evbit);
> >>>>>>>>+		__set_bit(BTN_TOUCH, mtouch->keybit);
> >>>Please make it
> >>>		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
> >>>
> >>>and drop all __set_bit()s.
> >>done, thank you
> >>>>>>>>+
> >>>>>>>>+		input_set_abs_params(mtouch, ABS_X,
> >>>>>>>>+				     0, width, 0, 0);
> >>>>>>>>+		input_set_abs_params(mtouch, ABS_Y,
> >>>>>>>>+				     0, height, 0, 0);
> >>>>>>>>+		input_set_abs_params(mtouch, ABS_PRESSURE,
> >>>>>>>>+				     0, 255, 0, 0);
> >>>>>>>>+
> >>>>>>>>+		input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
> >>>>>>>>+				     0, 255, 0, 0);
> >>>>>>>>+		input_set_abs_params(mtouch, ABS_MT_POSITION_X,
> >>>>>>>>+				     0, width, 0, 0);
> >>>>>>>>+		input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
> >>>>>>>>+				     0, height, 0, 0);
> >>>>>>>>+		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
> >>>>>>>>+				     0, 255, 0, 0);
> >>>>>>>>+
> >>>>>>>>+		input_mt_init_slots(mtouch, num_cont, 0);
> >>>>>We need error handling here.
> >>>>done
> >>>>>  Also, it would be nice if we set INPUT_MT_*
> >>>>>flags here, so that userspace had better chance of figuring how to
> >>>>>handle the device.
> >>>>done, I will use INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED
> >>>Does that mean that your backend does not reliably report release of
> >>>contacts?
> >>there is a ring buffer between host and guest,
> >>so there is always a possibility (rather small I believe)
> >>that the buffer overruns. Do you think I need INPUT_MT_DROP_UNUSED or
> >>we can live without it?
> >Again, it depends on your backend behavior. Do you report all slots
> >repeatedly for every packet or you report only changed slots?
> we report events repeatedly, so I think we can live
> w/o _DROP_UNUSED
> >Thanks.
> >
> >>>Thanks.
> >>>
> >>>>>>>>+
> >>>>>>>>+		mtouch_size[KPARAM_MT_X] = width;
> >>>>>>>>+		mtouch_size[KPARAM_MT_Y] = height;
> >>>>>>>>+		info->mtouch_cur_contact_id = -1;
> >>>>>>>>+
> >>>>>>>>+		ret = input_register_device(mtouch);
> >>>>>>>>+		if (ret) {
> >>>>>>>>+			input_free_device(mtouch);
> >>>>>>>>+			xenbus_dev_fatal(info->xbdev, ret,
> >>>>>>>>+					 "input_register_device(mtouch)");
> >>>>>>>>+			goto error;
> >>>>>>>>+		}
> >>>>>>>>+		info->mtouch_cur_contact_id = -1;
> >>>>>>>>+		info->mtouch = mtouch;
> >>>>>>>>+	}
> >>>>>>>>+
> >>>>>>>>  	ret = xenkbd_connect_backend(dev, info);
> >>>>>>>>  	if (ret < 0)
> >>>>>>>>  		goto error;
> >>>>>>>>@@ -240,6 +376,8 @@ static int xenkbd_remove(struct xenbus_device *dev)
> >>>>>>>>  		input_unregister_device(info->kbd);
> >>>>>>>>  	if (info->ptr)
> >>>>>>>>  		input_unregister_device(info->ptr);
> >>>>>>>>+	if (info->mtouch)
> >>>>>>>>+		input_unregister_device(info->mtouch);
> >>>>>>>>  	free_page((unsigned long)info->page);
> >>>>>>>>  	kfree(info);
> >>>>>>>>  	return 0;
> >>>>>>>>-- 
> >>>>>>>>2.7.4
> >>>>>>>>
> >>>>>Thanks.
> >>>>>
> >>>>For your convenience I am attaching the changes I am about
> >>>>to put into v1 of the series:
> >>>>  - remove unlikely
> >>>>  - remove module parameters
> >>>>  - error handling for input_mt_init_slots
> >>>>  - let userspace better chance of figuring how to handle the device
> >>>>
> >>>>Thank you,
> >>>>Oleksandr
> >>>> From e76506c55846e2bb4ccbafa430642e368643e51d Mon Sep 17 00:00:00 2001
> >>>>From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>>>Date: Tue, 30 May 2017 14:49:58 +0300
> >>>>Subject: [PATCH] Fix: remove unlikely Fix: remove module paramters Fix: error
> >>>>  handling for input_mt_init_slots Fix: let userspace better chance of figuring
> >>>>  how to handle the device
> >>>>
> >>>>Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>>>---
> >>>>  drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
> >>>>  1 file changed, 10 insertions(+), 11 deletions(-)
> >>>>
> >>>>diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> >>>>index 8266ef948a06..273d786a19cd 100644
> >>>>--- a/drivers/input/misc/xen-kbdfront.c
> >>>>+++ b/drivers/input/misc/xen-kbdfront.c
> >>>>@@ -51,12 +51,6 @@ module_param_array(ptr_size, int, NULL, 0444);
> >>>>  MODULE_PARM_DESC(ptr_size,
> >>>>  	"Pointing device width, height in pixels (default 800,600)");
> >>>>-enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
> >>>>-static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
> >>>>-module_param_array(mtouch_size, int, NULL, 0444);
> >>>>-MODULE_PARM_DESC(ptr_size,
> >>>>-	"Multi-touch device width, height in pixels (default 800,600)");
> >>>>-
> >>>>  static int xenkbd_remove(struct xenbus_device *);
> >>>>  static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
> >>>>  static void xenkbd_disconnect_backend(struct xenkbd_info *);
> >>>>@@ -114,8 +108,8 @@ static irqreturn_t input_handler(int rq, void *dev_id)
> >>>>  			dev = info->mtouch;
> >>>>  			if (unlikely(!dev))
> >>>>  				break;
> >>>>-			if (unlikely(event->mtouch.contact_id !=
> >>>>-					info->mtouch_cur_contact_id)) {
> >>>>+			if (event->mtouch.contact_id !=
> >>>>+					info->mtouch_cur_contact_id) {
> >>>>  				info->mtouch_cur_contact_id =
> >>>>  					event->mtouch.contact_id;
> >>>>  				input_mt_slot(dev, event->mtouch.contact_id);
> >>>>@@ -327,10 +321,15 @@ static int xenkbd_probe(struct xenbus_device *dev,
> >>>>  		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
> >>>>  				     0, 255, 0, 0);
> >>>>-		input_mt_init_slots(mtouch, num_cont, 0);
> >>>>+		ret = input_mt_init_slots(mtouch, num_cont,
> >>>>+				INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED);
> >>>>+		if (ret) {
> >>>>+			input_free_device(mtouch);
> >>>>+			xenbus_dev_fatal(info->xbdev, ret,
> >>>>+					 "input_mt_init_slots");
> >>>>+			goto error;
> >>>>+		}
> >>>>-		mtouch_size[KPARAM_MT_X] = width;
> >>>>-		mtouch_size[KPARAM_MT_Y] = height;
> >>>>  		info->mtouch_cur_contact_id = -1;
> >>>>  		ret = input_register_device(mtouch);
> >>>>-- 
> >>>>2.7.4
> >>>>
> >>Thank you,
> >>Oleksandr
> Dmitry, thank you for comments
> The bottom line I see is:
>  - no support for PEN tool at the moment
>  - num contacts == 1 is OK
>  - I will not use INPUT_MT_DROP_UNUSED

Sounds good.

> 
> If the above is ok to you, then I will send another version of the
> series (BTW, can I use your RB for the first patch which
> removes hard-codes?)

I already applied that one and it should be in -next already, there is
no need to resent the first patch.

Thanks.

-- 
Dmitry

Re: [PATCH 2/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

Hi, Dmitry!

On 06/21/2017 10:24 AM, Dmitry Torokhov wrote:
> On Thu, Jun 08, 2017 at 09:45:18AM +0300, Oleksandr Andrushchenko wrote:
>> Hi, Dmitry!
>>
>> On 06/07/2017 07:56 PM, Dmitry Torokhov wrote:
>>> On Wed, May 31, 2017 at 12:06:56PM +0300, Oleksandr Andrushchenko wrote:
>>>> Hi, Dmitry!
>>>>
>>>> On 05/30/2017 07:37 PM, Dmitry Torokhov wrote:
>>>>> On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko wrote:
>>>>>> Hi, Dmitry!
>>>>>>
>>>>>> On 05/30/2017 08:51 AM, Dmitry Torokhov wrote:
>>>>>>> On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko wrote:
>>>>>>>> Hi, Dmitry!
>>>>>>>>
>>>>>>>> On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:
>>>>>>>>> Hi Oleksandr,
>>>>>>>>>
>>>>>>>>> On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
>>>>>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>>>>>
>>>>>>>>>> Extend xen_kbdfront to provide multi-touch support
>>>>>>>>>> to unprivileged domains.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>>>>>> ---
>>>>>>>>>>   drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
>>>>>>>>>>   1 file changed, 140 insertions(+), 2 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
>>>>>>>>>> index 01c27b4c3288..e5d064aaa237 100644
>>>>>>>>>> --- a/drivers/input/misc/xen-kbdfront.c
>>>>>>>>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>>>>>>>>> @@ -17,6 +17,7 @@
>>>>>>>>>>   #include <linux/errno.h>
>>>>>>>>>>   #include <linux/module.h>
>>>>>>>>>>   #include <linux/input.h>
>>>>>>>>>> +#include <linux/input/mt.h>
>>>>>>>>>>   #include <linux/slab.h>
>>>>>>>>>>   #include <asm/xen/hypervisor.h>
>>>>>>>>>> @@ -34,11 +35,14 @@
>>>>>>>>>>   struct xenkbd_info {
>>>>>>>>>>   	struct input_dev *kbd;
>>>>>>>>>>   	struct input_dev *ptr;
>>>>>>>>>> +	struct input_dev *mtouch;
>>>>>>>>>>   	struct xenkbd_page *page;
>>>>>>>>>>   	int gref;
>>>>>>>>>>   	int irq;
>>>>>>>>>>   	struct xenbus_device *xbdev;
>>>>>>>>>>   	char phys[32];
>>>>>>>>>> +	/* current MT slot/contact ID we are injecting events in */
>>>>>>>>>> +	int mtouch_cur_contact_id;
>>>>>>>>>>   };
>>>>>>>>>>   enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
>>>>>>>>>> @@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
>>>>>>>>>>   MODULE_PARM_DESC(ptr_size,
>>>>>>>>>>   	"Pointing device width, height in pixels (default 800,600)");
>>>>>>>>>> +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>>>>>>>>>> +static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
>>>>>>>>>> +module_param_array(mtouch_size, int, NULL, 0444);
>>>>>>>>>> +MODULE_PARM_DESC(ptr_size,
>>>>>>>>>> +	"Multi-touch device width, height in pixels (default 800,600)");
>>>>>>>>>> +
>>>>>>>>> Why do you need separate module parameters for multi-touch device?
>>>>>>>> please see below
>>>>>>>>>>   static int xenkbd_remove(struct xenbus_device *);
>>>>>>>>>>   static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
>>>>>>>>>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>>>>>>>>>> @@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void *dev_id)
>>>>>>>>>>   				input_report_rel(dev, REL_WHEEL,
>>>>>>>>>>   						 -event->pos.rel_z);
>>>>>>>>>>   			break;
>>>>>>>>>> +		case XENKBD_TYPE_MTOUCH:
>>>>>>>>>> +			dev = info->mtouch;
>>>>>>>>>> +			if (unlikely(!dev))
>>>>>>>>>> +				break;
>>>>>>>>>> +			if (unlikely(event->mtouch.contact_id !=
>>>>>>>>>> +					info->mtouch_cur_contact_id)) {
>>>>>>>>> Why is this unlikely? Does contact ID changes once in 1000 packets or
>>>>>>>>> even less?
>>>>>>>> Mu assumption was that regardless of the fact that we are multi-touch
>>>>>>>> device still single touches will come in more frequently
>>>>>>>> But I can remove *unlikely* if my assumption is not correct
>>>>>>> I think the normal expectation is that "unlikely" is supposed for
>>>>>>> something that happens once in a blue moon, so I'd rather remove it.
>>>>>>>
>>>>>> agree, removed "unlikely"
>>>>>>>>>> +				info->mtouch_cur_contact_id =
>>>>>>>>>> +					event->mtouch.contact_id;
>>>>>>>>>> +				input_mt_slot(dev, event->mtouch.contact_id);
>>>>>>>>>> +			}
>>>>>>>>>> +			switch (event->mtouch.event_type) {
>>>>>>>>>> +			case XENKBD_MT_EV_DOWN:
>>>>>>>>>> +				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>>>>>>>> +							   true);
>>>>>>> Should we establish tool event? We have MT_TOOL_PEN, etc.
>>>>>> I think that for multi-touch MT_TOOL_FINGER is enough
>>>>>> any reason we would also want MT_TOOL_PEN here?
>>>>> Why would not you? Let's say you have a drawing application running in
>>>>> guest that can make use of tool types. Why would not you want to tell it
>>>>> that the tool user is currently using is in fact a pen and not finger?
>>>> But it is a finger :) we are multi-touch, not multi pen
>>> So for tablets that support both touch and stylus you would export them
>>> as 2 separate devices?
>> this could be done in different ways, but please see on
>> pen support below
>>>> Besides, that, if I am about to implement pen support
>>>> (which I still not convinced we really need), how will I
>>>> do that?
>>> I do not know what you have on the backend side, but roughly speaking if
>>> you detect a pen/stylus you let your guest know that the contact is not
>>> a finger, but pen. How you plumb it through is up to you.
>> we do not detect pen, only finger at the moment
>> and the existing protocol has no means to tell
>> type of the tool used, everything is supposed to
>> be "finger", so front-end has no possibility to
>> tell one tool from another
>>>> My understanding is that I need 2 different slots to report
>>>> the same coordinates for finger and pen. This is because
>>>> input_mt_report_slot_state has a check that if tool has
>>>> changed for the current slot then a new tracking ID is set.
>>>> Do I also need to allocate twice more slots, so I can
>>>> report 2 * num_contacts events simultaneously (one for finger
>>>> and another for pen)?
>>>> That said, I believe we can start with multi-touch support
>>>> and if need be then add pen support as a separate change,
>>>> does that make sense for you?
>>>>>> (I guess MT_TOOL_PALM is not appropriate anyways)
>>>>> Depends on if you do straight pass-through from the host side or not. If
>>>>> you stack does palm rejection before passing the data through then you
>>>>> would not see MT_TOOL_PALM in guest.
>>>> the protocol used between guest and host is a generic one,
>>>> not using Linux types/constants/events.
>>> It does not have to use Linux types to support the concept of different
>>> tools.
>> agree
>>>> So, no PALM/TOOL support is in place
>>> OK, that is fair. The pen support is definitely not a hard requirement.
>> so, can we live with finger at this point, no pen?
>>> I was just wondering if you considered or have plans for adding that.
>> well, honestly, we do not need pen at the moment,
>> but we did add multi-touch support into Xen protocols
>> and if pen required it can be done as a separate
>> change to both protocol and front/back ends
>>>   Or
>>> if you want to review the protocol so it can be easily added in the
>>> future. For example you could have tool type to be part of
>>> XENKBD_MT_EV_DOWN event.
>> protocol did a long way to get into Xen/Kernel... :)
>> of course, this can be done, but I would prefer it is
>> added when it is needed, not only that we have this functionality
> OK.
>
>>>>>>>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>>>>>>>> +					    event->mtouch.u.pos.abs_x);
>>>>>>>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>>>>>>>> +					    event->mtouch.u.pos.abs_y);
>>>>>>>>>> +				input_event(dev, EV_ABS, ABS_X,
>>>>>>>>>> +					    event->mtouch.u.pos.abs_x);
>>>>>>>>>> +				input_event(dev, EV_ABS, ABS_Y,
>>>>>>>>>> +					    event->mtouch.u.pos.abs_y);
>>>>>>>>>> +				break;
>>>>>>>>>> +			case XENKBD_MT_EV_UP:
>>>>>>>>>> +				input_mt_report_slot_state(dev, MT_TOOL_FINGER,
>>>>>>>>>> +							   false);
>>>>>>>>>> +				break;
>>>>>>>>>> +			case XENKBD_MT_EV_MOTION:
>>>>>>>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_X,
>>>>>>>>>> +					    event->mtouch.u.pos.abs_x);
>>>>>>>>>> +				input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
>>>>>>>>>> +					    event->mtouch.u.pos.abs_y);
>>>>>>>>>> +				input_event(dev, EV_ABS, ABS_X,
>>>>>>>>>> +					    event->mtouch.u.pos.abs_x);
>>>>>>>>>> +				input_event(dev, EV_ABS, ABS_Y,
>>>>>>>>>> +					    event->mtouch.u.pos.abs_y);
>>>>>>>>>> +				break;
>>>>>>>>>> +			case XENKBD_MT_EV_SYN:
>>>>>>>>>> +				input_mt_sync_frame(dev);
>>>>>>>>>> +				break;
>>>>>>>>>> +			case XENKBD_MT_EV_SHAPE:
>>>>>>>>>> +				input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
>>>>>>>>>> +					    event->mtouch.u.shape.major);
>>>>>>>>>> +				input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
>>>>>>>>>> +					    event->mtouch.u.shape.minor);
>>>>>>>>>> +				break;
>>>>>>>>>> +			case XENKBD_MT_EV_ORIENT:
>>>>>>>>>> +				input_event(dev, EV_ABS, ABS_MT_ORIENTATION,
>>>>>>>>>> +					    event->mtouch.u.orientation);
>>>>>>>>>> +				break;
>>>>>>>>>> +			}
>>>>>>>>>> +			/* only report syn when requested */
>>>>>>>>>> +			if (event->mtouch.event_type != XENKBD_MT_EV_SYN)
>>>>>>>>>> +				dev = NULL;
>>>>>>>>>>   		}
>>>>>>>>>>   		if (dev)
>>>>>>>>>>   			input_sync(dev);
>>>>>>>>>> @@ -115,9 +179,9 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>>>>>>>   				  const struct xenbus_device_id *id)
>>>>>>>>>>   {
>>>>>>>>>>   	int ret, i;
>>>>>>>>>> -	unsigned int abs;
>>>>>>>>>> +	unsigned int abs, touch;
>>>>>>>>>>   	struct xenkbd_info *info;
>>>>>>>>>> -	struct input_dev *kbd, *ptr;
>>>>>>>>>> +	struct input_dev *kbd, *ptr, *mtouch;
>>>>>>>>>>   	info = kzalloc(sizeof(*info), GFP_KERNEL);
>>>>>>>>>>   	if (!info) {
>>>>>>>>>> @@ -152,6 +216,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>>>>>>>   		}
>>>>>>>>>>   	}
>>>>>>>>>> +	touch = xenbus_read_unsigned(dev->nodename,
>>>>>>>>>> +				     XENKBD_FIELD_FEAT_MTOUCH, 0);
>>>>>>>>>> +	if (touch) {
>>>>>>>>>> +		ret = xenbus_write(XBT_NIL, dev->nodename,
>>>>>>>>>> +				   XENKBD_FIELD_REQ_MTOUCH, "1");
>>>>>>>>>> +		if (ret) {
>>>>>>>>>> +			pr_warning("xenkbd: can't request multi-touch");
>>>>>>>>>> +			touch = 0;
>>>>>>>>>> +		}
>>>>>>>>>> +	}
>>>>>>>>>> +
>>>>>>>>>>   	/* keyboard */
>>>>>>>>>>   	kbd = input_allocate_device();
>>>>>>>>>>   	if (!kbd)
>>>>>>>>>> @@ -208,6 +283,67 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>>>>>>>   	}
>>>>>>>>>>   	info->ptr = ptr;
>>>>>>>>>> +	/* multi-touch device */
>>>>>>>>>> +	if (touch) {
>>>>>>>>>> +		int num_cont, width, height;
>>>>>>>>>> +
>>>>>>>>>> +		mtouch = input_allocate_device();
>>>>>>>>>> +		if (!mtouch)
>>>>>>>>>> +			goto error_nomem;
>>>>>>>>>> +
>>>>>>>>>> +		num_cont = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>>>>>> +						XENKBD_FIELD_MT_NUM_CONTACTS,
>>>>>>>>>> +						1);
>>>>>>> Should we refuse MT devices with number of contacts less than 2?
>>>>>> we can, but I see no harm in 1. what is more, this may
>>>>>> allow guests to emulate more pointing devices
>>>>>> but, if you insist, then I will add appropriate code to
>>>>>> reject if number of contacts is less then 2
>>> The question is if you are planning to keep the single-touch interface
>>> or you will migrate everything to multi-touch.
>> I will keep single touch as legacy, but in our use-cases
>> we are more focusing on using multi-touch devices.
>> but even with number of contacts == 1 it can still be
>> useful as it gives more flexibility in configuring guest OS
>> If you insist that num contacts == 1 must be removed,
>> please let me know and I will handle that
> No, that is fine. I was simply trying to understand the plans for
> single/multi-touch support in your backend.
>
>>>>>>>>>> +		width = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>>>>>> +					     XENKBD_FIELD_MT_WIDTH,
>>>>>>>>>> +					     XENFB_WIDTH);
>>>>>>>>>> +		height = xenbus_read_unsigned(info->xbdev->nodename,
>>>>>>>>>> +					      XENKBD_FIELD_MT_HEIGHT,
>>>>>>>>>> +					      XENFB_HEIGHT);
>>>>>>>>> Curious why you need separate parameters here too...
>>>>>>>> This is because mt parameters are different from ptr
>>>>>>>> in a way that they are configurable per front driver's
>>>>>>>> instance rather than per backend, e.g. in XenStore:
>>>>>>>>
>>>>>>>> /local/domain/0/backend/vkbd/1/0/width = "1920"
>>>>>>>> /local/domain/0/backend/vkbd/1/0/height = "1080"
>>>>>>>>
>>>>>>>> /local/domain/1/device/vkbd/0/multi-touch-width = "1920"
>>>>>>>> /local/domain/1/device/vkbd/0/multi-touch-height = "1080"
>>>>>>>> /local/domain/1/device/vkbd/0/multi-touch-num-contacts = "10"
>>>>>>>>
>>>>>>>> /local/domain/1/device/vkbd/1/multi-touch-width = "800"
>>>>>>>> /local/domain/1/device/vkbd/1/multi-touch-height = "600"
>>>>>>>> /local/domain/1/device/vkbd/1/multi-touch-num-contacts = "3"
>>>>>>>>
>>>>>>>> The main reason for such configuration is that you can
>>>>>>>> configure multiple mt input devices even for the same guest
>>>>>>>> with different resolutions which may not match those
>>>>>>>> configured for ptr.
>>>>>>>> (In my use-case I use new displif protocol [1] in conjunction
>>>>>>>> with mt input devices and the corresponding backend is not
>>>>>>>> QEMU's xenfb)
>>>>>>> I see.
>>>>>>>
>>>>>>>> As to module parameters, I added those to be consistent with
>>>>>>>> ptr device. Do you think we can live without them and
>>>>>>>> do you want me to remove them?
>>>>>>> Yes, I think we better. I am also confused by the way you are handling
>>>>>>> the module parameters. It looks to me you update them with data passed
>>>>>> >from the backend, but never use the data...
>>>>>> I have removed module parameters (the only use of those
>>>>>> was to be able to see configured width and height on
>>>>>> guest side, but this is minor)
>>>>> evtest would show it to you. Or you can query input device yourself
>>>>> (EVIOCGABS iotcl).
>>>> yes, if embedded system (which is my target) has evtest
>>>> but it definitely does have ioctl though
>>>>>>>>>> +
>>>>>>>>>> +		mtouch->name = "Xen Virtual Multi-touch";
>>>>>>>>>> +		mtouch->phys = info->phys;
>>>>>>>>>> +		mtouch->id.bustype = BUS_PCI;
>>>>>>>>>> +		mtouch->id.vendor = 0x5853;
>>>>>>>>>> +		mtouch->id.product = 0xfffd;
>>>>>>>>>> +
>>>>>>>>>> +		__set_bit(EV_ABS, mtouch->evbit);
>>>>>>>>>> +		__set_bit(EV_KEY, mtouch->evbit);
>>>>>>>>>> +		__set_bit(BTN_TOUCH, mtouch->keybit);
>>>>> Please make it
>>>>> 		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
>>>>>
>>>>> and drop all __set_bit()s.
>>>> done, thank you
>>>>>>>>>> +
>>>>>>>>>> +		input_set_abs_params(mtouch, ABS_X,
>>>>>>>>>> +				     0, width, 0, 0);
>>>>>>>>>> +		input_set_abs_params(mtouch, ABS_Y,
>>>>>>>>>> +				     0, height, 0, 0);
>>>>>>>>>> +		input_set_abs_params(mtouch, ABS_PRESSURE,
>>>>>>>>>> +				     0, 255, 0, 0);
>>>>>>>>>> +
>>>>>>>>>> +		input_set_abs_params(mtouch, ABS_MT_TOUCH_MAJOR,
>>>>>>>>>> +				     0, 255, 0, 0);
>>>>>>>>>> +		input_set_abs_params(mtouch, ABS_MT_POSITION_X,
>>>>>>>>>> +				     0, width, 0, 0);
>>>>>>>>>> +		input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
>>>>>>>>>> +				     0, height, 0, 0);
>>>>>>>>>> +		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>>>>>>>>>> +				     0, 255, 0, 0);
>>>>>>>>>> +
>>>>>>>>>> +		input_mt_init_slots(mtouch, num_cont, 0);
>>>>>>> We need error handling here.
>>>>>> done
>>>>>>>   Also, it would be nice if we set INPUT_MT_*
>>>>>>> flags here, so that userspace had better chance of figuring how to
>>>>>>> handle the device.
>>>>>> done, I will use INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED
>>>>> Does that mean that your backend does not reliably report release of
>>>>> contacts?
>>>> there is a ring buffer between host and guest,
>>>> so there is always a possibility (rather small I believe)
>>>> that the buffer overruns. Do you think I need INPUT_MT_DROP_UNUSED or
>>>> we can live without it?
>>> Again, it depends on your backend behavior. Do you report all slots
>>> repeatedly for every packet or you report only changed slots?
>> we report events repeatedly, so I think we can live
>> w/o _DROP_UNUSED
>>> Thanks.
>>>
>>>>> Thanks.
>>>>>
>>>>>>>>>> +
>>>>>>>>>> +		mtouch_size[KPARAM_MT_X] = width;
>>>>>>>>>> +		mtouch_size[KPARAM_MT_Y] = height;
>>>>>>>>>> +		info->mtouch_cur_contact_id = -1;
>>>>>>>>>> +
>>>>>>>>>> +		ret = input_register_device(mtouch);
>>>>>>>>>> +		if (ret) {
>>>>>>>>>> +			input_free_device(mtouch);
>>>>>>>>>> +			xenbus_dev_fatal(info->xbdev, ret,
>>>>>>>>>> +					 "input_register_device(mtouch)");
>>>>>>>>>> +			goto error;
>>>>>>>>>> +		}
>>>>>>>>>> +		info->mtouch_cur_contact_id = -1;
>>>>>>>>>> +		info->mtouch = mtouch;
>>>>>>>>>> +	}
>>>>>>>>>> +
>>>>>>>>>>   	ret = xenkbd_connect_backend(dev, info);
>>>>>>>>>>   	if (ret < 0)
>>>>>>>>>>   		goto error;
>>>>>>>>>> @@ -240,6 +376,8 @@ static int xenkbd_remove(struct xenbus_device *dev)
>>>>>>>>>>   		input_unregister_device(info->kbd);
>>>>>>>>>>   	if (info->ptr)
>>>>>>>>>>   		input_unregister_device(info->ptr);
>>>>>>>>>> +	if (info->mtouch)
>>>>>>>>>> +		input_unregister_device(info->mtouch);
>>>>>>>>>>   	free_page((unsigned long)info->page);
>>>>>>>>>>   	kfree(info);
>>>>>>>>>>   	return 0;
>>>>>>>>>> -- 
>>>>>>>>>> 2.7.4
>>>>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>> For your convenience I am attaching the changes I am about
>>>>>> to put into v1 of the series:
>>>>>>   - remove unlikely
>>>>>>   - remove module parameters
>>>>>>   - error handling for input_mt_init_slots
>>>>>>   - let userspace better chance of figuring how to handle the device
>>>>>>
>>>>>> Thank you,
>>>>>> Oleksandr
>>>>>>  From e76506c55846e2bb4ccbafa430642e368643e51d Mon Sep 17 00:00:00 2001
>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>> Date: Tue, 30 May 2017 14:49:58 +0300
>>>>>> Subject: [PATCH] Fix: remove unlikely Fix: remove module paramters Fix: error
>>>>>>   handling for input_mt_init_slots Fix: let userspace better chance of figuring
>>>>>>   how to handle the device
>>>>>>
>>>>>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>> ---
>>>>>>   drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
>>>>>>   1 file changed, 10 insertions(+), 11 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
>>>>>> index 8266ef948a06..273d786a19cd 100644
>>>>>> --- a/drivers/input/misc/xen-kbdfront.c
>>>>>> +++ b/drivers/input/misc/xen-kbdfront.c
>>>>>> @@ -51,12 +51,6 @@ module_param_array(ptr_size, int, NULL, 0444);
>>>>>>   MODULE_PARM_DESC(ptr_size,
>>>>>>   	"Pointing device width, height in pixels (default 800,600)");
>>>>>> -enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
>>>>>> -static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
>>>>>> -module_param_array(mtouch_size, int, NULL, 0444);
>>>>>> -MODULE_PARM_DESC(ptr_size,
>>>>>> -	"Multi-touch device width, height in pixels (default 800,600)");
>>>>>> -
>>>>>>   static int xenkbd_remove(struct xenbus_device *);
>>>>>>   static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info *);
>>>>>>   static void xenkbd_disconnect_backend(struct xenkbd_info *);
>>>>>> @@ -114,8 +108,8 @@ static irqreturn_t input_handler(int rq, void *dev_id)
>>>>>>   			dev = info->mtouch;
>>>>>>   			if (unlikely(!dev))
>>>>>>   				break;
>>>>>> -			if (unlikely(event->mtouch.contact_id !=
>>>>>> -					info->mtouch_cur_contact_id)) {
>>>>>> +			if (event->mtouch.contact_id !=
>>>>>> +					info->mtouch_cur_contact_id) {
>>>>>>   				info->mtouch_cur_contact_id =
>>>>>>   					event->mtouch.contact_id;
>>>>>>   				input_mt_slot(dev, event->mtouch.contact_id);
>>>>>> @@ -327,10 +321,15 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>>>>>   		input_set_abs_params(mtouch, ABS_MT_PRESSURE,
>>>>>>   				     0, 255, 0, 0);
>>>>>> -		input_mt_init_slots(mtouch, num_cont, 0);
>>>>>> +		ret = input_mt_init_slots(mtouch, num_cont,
>>>>>> +				INPUT_MT_DIRECT | INPUT_MT_DROP_UNUSED);
>>>>>> +		if (ret) {
>>>>>> +			input_free_device(mtouch);
>>>>>> +			xenbus_dev_fatal(info->xbdev, ret,
>>>>>> +					 "input_mt_init_slots");
>>>>>> +			goto error;
>>>>>> +		}
>>>>>> -		mtouch_size[KPARAM_MT_X] = width;
>>>>>> -		mtouch_size[KPARAM_MT_Y] = height;
>>>>>>   		info->mtouch_cur_contact_id = -1;
>>>>>>   		ret = input_register_device(mtouch);
>>>>>> -- 
>>>>>> 2.7.4
>>>>>>
>>>> Thank you,
>>>> Oleksandr
>> Dmitry, thank you for comments
>> The bottom line I see is:
>>   - no support for PEN tool at the moment
>>   - num contacts == 1 is OK
>>   - I will not use INPUT_MT_DROP_UNUSED
> Sounds good.
Thank you,
I will re-test the resulting patch and will send the new version
>
>> If the above is ok to you, then I will send another version of the
>> series (BTW, can I use your RB for the first patch which
>> removes hard-codes?)
> I already applied that one and it should be in -next already, there is
> no need to resent the first patch.
Oh, that is great, thank you
> Thanks.
>