Date:   Wed, 21 Jun 2017 11:54:28 +0300
From:   Oleksandr Andrushchenko <andr2000@...il.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
        linux-input@...r.kernel.org, joculator@...il.com, al1img@...il.com,
        vlad.babchuk@...il.com, andrii.anisov@...il.com,
        olekstysh@...il.com, boris.ostrovsky@...cle.com, jgross@...e.com,
        Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
Subject: Re: [PATCH 2/2] xen/input: add multi-touch support

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@...m.com>
>>>>>>>>>>
>>>>>>>>>> Extend xen_kbdfront to provide multi-touch support
>>>>>>>>>> to unprivileged domains.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.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@...m.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@...m.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.
>

Powered by blists - more mailing lists