From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752791AbdFUIyi (ORCPT ); Wed, 21 Jun 2017 04:54:38 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:35817 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752620AbdFUIyd (ORCPT ); Wed, 21 Jun 2017 04:54:33 -0400 Subject: Re: [PATCH 2/2] xen/input: add multi-touch support To: Dmitry Torokhov References: <1492083484-31786-1-git-send-email-andr2000@gmail.com> <1492083484-31786-3-git-send-email-andr2000@gmail.com> <20170421021018.GB23279@dtor-ws> <20170530055150.GA38163@dtor-ws> <8092dd49-20e0-3e8d-977d-2f570142a37d@gmail.com> <20170530163708.GA12922@dtor-ws> <20170607165630.GA13116@dtor-ws> <222abecb-10b6-6196-9f44-6ec366377335@gmail.com> <20170621072425.GA36968@dtor-ws> Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, joculator@gmail.com, al1img@gmail.com, vlad.babchuk@gmail.com, andrii.anisov@gmail.com, olekstysh@gmail.com, boris.ostrovsky@oracle.com, jgross@suse.com, Oleksandr Andrushchenko From: Oleksandr Andrushchenko Message-ID: <8eb8a2c6-1390-a2bb-3298-cb13b594a6d1@gmail.com> Date: Wed, 21 Jun 2017 11:54:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170621072425.GA36968@dtor-ws> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >>>>>>>>>> >>>>>>>>>> Extend xen_kbdfront to provide multi-touch support >>>>>>>>>> to unprivileged domains. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Oleksandr Andrushchenko >>>>>>>>>> --- >>>>>>>>>> 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 >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> +#include >>>>>>>>>> #include >>>>>>>>>> #include >>>>>>>>>> @@ -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 >>>>>> 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 >>>>>> --- >>>>>> 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. >