From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752571AbdFUHYn (ORCPT ); Wed, 21 Jun 2017 03:24:43 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:35148 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751771AbdFUHY3 (ORCPT ); Wed, 21 Jun 2017 03:24:29 -0400 Date: Wed, 21 Jun 2017 00:24:25 -0700 From: Dmitry Torokhov To: Oleksandr Andrushchenko 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 Subject: Re: [PATCH 2/2] xen/input: add multi-touch support Message-ID: <20170621072425.GA36968@dtor-ws> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <222abecb-10b6-6196-9f44-6ec366377335@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > 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