xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Oleksandr Andrushchenko <andr2000@gmail.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: jgross@suse.com,
	Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>,
	vlad.babchuk@gmail.com, linux-kernel@vger.kernel.org,
	andrii.anisov@gmail.com, olekstysh@gmail.com, al1img@gmail.com,
	linux-input@vger.kernel.org, xen-devel@lists.xenproject.org,
	boris.ostrovsky@oracle.com, joculator@gmail.com
Subject: Re: [PATCH 2/2] xen/input: add multi-touch support
Date: Tue, 30 May 2017 15:50:20 +0300	[thread overview]
Message-ID: <8092dd49-20e0-3e8d-977d-2f570142a37d__9323.65807607329$1496148685$gmane$org@gmail.com> (raw)
In-Reply-To: <20170530055150.GA38163@dtor-ws>

[-- 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


[-- Attachment #3: Type: text/plain, Size: 127 bytes --]

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

  parent reply	other threads:[~2017-05-30 12:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1492083484-31786-1-git-send-email-andr2000@gmail.com>
2017-04-13 11:38 ` [PATCH 1/2] xen/input: use string constants from PV protocol Oleksandr Andrushchenko
2017-04-13 11:38 ` [PATCH 2/2] xen/input: add multi-touch support Oleksandr Andrushchenko
     [not found] ` <1492083484-31786-3-git-send-email-andr2000@gmail.com>
2017-04-21  2:10   ` Dmitry Torokhov
     [not found]   ` <20170421021018.GB23279@dtor-ws>
2017-04-21  6:40     ` Oleksandr Andrushchenko
     [not found]     ` <bd6b6680-6023-765f-d80f-b00e2b6dd597@gmail.com>
2017-05-05  4:45       ` Oleksandr Andrushchenko
     [not found]       ` <8a43bbdf-f843-2c4d-e7b7-0cddb2e7fd7e@gmail.com>
2017-05-12 13:44         ` Oleksandr Andrushchenko
     [not found]         ` <8d522e12-8a1b-1eb4-981c-9bb1042e9703@gmail.com>
2017-05-22 13:25           ` Oleksandr Andrushchenko
2017-05-30  5:51       ` Dmitry Torokhov
     [not found]       ` <20170530055150.GA38163@dtor-ws>
2017-05-30 12:50         ` Oleksandr Andrushchenko [this message]
     [not found]         ` <8092dd49-20e0-3e8d-977d-2f570142a37d@gmail.com>
2017-05-30 16:37           ` Dmitry Torokhov
     [not found]           ` <20170530163708.GA12922@dtor-ws>
2017-05-31  9:06             ` Oleksandr Andrushchenko
     [not found]             ` <c355258d-f207-aa5e-a170-e52438102a37@gmail.com>
2017-06-07  7:15               ` Oleksandr Andrushchenko
2017-06-07 16:56               ` Dmitry Torokhov
     [not found]               ` <20170607165630.GA13116@dtor-ws>
2017-06-08  6:45                 ` Oleksandr Andrushchenko
     [not found]                 ` <222abecb-10b6-6196-9f44-6ec366377335@gmail.com>
2017-06-19 10:00                   ` Oleksandr Andrushchenko
2017-06-21  7:24                   ` Dmitry Torokhov
     [not found]                   ` <20170621072425.GA36968@dtor-ws>
2017-06-21  8:54                     ` Oleksandr Andrushchenko
     [not found] ` <1492083484-31786-2-git-send-email-andr2000@gmail.com>
2017-04-21  2:11   ` [PATCH 1/2] xen/input: use string constants from PV protocol Dmitry Torokhov
     [not found]   ` <20170421021100.GC23279@dtor-ws>
2017-04-21  6:42     ` Oleksandr Andrushchenko
     [not found]     ` <696b4545-2fb9-4267-8561-55d3f67d83ad@gmail.com>
2017-05-05  4:43       ` Oleksandr Andrushchenko
     [not found]       ` <b16fa500-0776-3544-b442-20239d4ffcb1@gmail.com>
2017-05-12 13:43         ` Oleksandr Andrushchenko
     [not found]         ` <390ca032-8123-d9d6-734d-e424dce43708@gmail.com>
2017-05-22 13:24           ` Oleksandr Andrushchenko
2017-05-30 12:37     ` Oleksandr Andrushchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='8092dd49-20e0-3e8d-977d-2f570142a37d__9323.65807607329$1496148685$gmane$org@gmail.com' \
    --to=andr2000@gmail.com \
    --cc=al1img@gmail.com \
    --cc=andrii.anisov@gmail.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jgross@suse.com \
    --cc=joculator@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleksandr_andrushchenko@epam.com \
    --cc=olekstysh@gmail.com \
    --cc=vlad.babchuk@gmail.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).