[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.