xen/input: add multi-touch support

PATCH In review Oleksandr Andrushchenko 2 participants 47 messages Apr 13, 2017 – Jun 21, 2017

Subsystems (2)

HID Input drivers

lore

Share & tools

lore

Oleksandr Andrushchenko

author

2017-04-13 11:38 UTC #0 lore raw

cover xen/input: add multi-touch support

From: Oleksandr Andrushchenko <[email protected]>

Hi, all!

This patch series updates existing Xen vkbd frontend driver to use string constants from the corresponding IO protocol (kbdif.h) and adds support for virtual multi-touch input device.

This has been tested on a guest running Weston.

This patch series depends on:
https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=linux-next&id=16b3087654b8565ae14c23ac3797e5f60ba0b13d
https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=linux-next&id=edd5bdb7b06fd1a0c68b6f39b2c776368eba00c8
https://lkml.org/lkml/2017/4/11/352

Thank you,
Oleksandr Andrushchenko

Oleksandr Andrushchenko (2):
xen/input: use string constants from PV protocol xen/input: add multi-touch support

 drivers/input/misc/xen-kbdfront.c | 164 +++++++++++++++++++++++++++++++++++---
 1 file changed, 153 insertions(+), 11 deletions(-)

Signature · 1 line

2.7.4

Oleksandr Andrushchenko

author

2017-04-13 11:38 UTC #1 lore raw

PATCH 1/2 xen/input: use string constants from PV protocol

From: Oleksandr Andrushchenko <[email protected]>

Xen input para-virtual protocol defines string constants used by both back and frontend. Use those instead of explicit strings in the frontend driver.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
 drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

drivers/input/misc/xen-kbdfront.c +13 -9

index 2fc7895373ab..01c27b4c3288 100644
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
 		goto error_nomem;
 
 	/* Set input abs params to match backend screen res */
-	abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
-	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+	abs = xenbus_read_unsigned(dev->otherend,
+				   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+						  XENKBD_FIELD_WIDTH,
 						  ptr_size[KPARAM_X]);
-	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
+	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+						  XENKBD_FIELD_HEIGHT,
 						  ptr_size[KPARAM_Y]);
 	if (abs) {
 		ret = xenbus_write(XBT_NIL, dev->nodename,
-				   "request-abs-pointer", "1");
+				   XENKBD_FIELD_REQ_ABS_POINTER, "1");
 		if (ret) {
 			pr_warning("xenkbd: can't request abs-pointer");
 			abs = 0;

@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct xenbus_device *dev,
 		xenbus_dev_fatal(dev, ret, "starting transaction");
 		goto error_irqh;
 	}
-	ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, "%lu",
 			    virt_to_gfn(info->page));
 	if (ret)
 		goto error_xenbus;
-	ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", info->gref);
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+			    "%u", info->gref);
 	if (ret)
 		goto error_xenbus;
-	ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_EVT_CHANNEL, "%u",
 			    evtchn);
 	if (ret)
 		goto error_xenbus;

@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
 }
 
 static const struct xenbus_device_id xenkbd_ids[] = {
-	{ "vkbd" },
+	{ XENKBD_DRIVER_NAME },
 	{ "" }
 };

@@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
 
 MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");
 MODULE_LICENSE("GPL");
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);

Signature · 1 line

2.7.4

Dmitry Torokhov

maintainer

2017-04-21 02:11 UTC #2 lore raw

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

Quoted 7 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>
Xen input para-virtual protocol defines string constants used by both back and frontend. Use those instead of explicit strings in the frontend driver.
Signed-off-by Oleksandr Andrushchenko <[email protected]>

I'll have to postpone it until I receive changes containing these new string constants. Otherwise it looks OK.

Quoted 67 lines

---
 drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

drivers/input/misc/xen-kbdfront.c +13 -9

index 2fc7895373ab..01c27b4c3288 100644
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
 		goto error_nomem;
 
 	/* Set input abs params to match backend screen res */
-	abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
-	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+	abs = xenbus_read_unsigned(dev->otherend,
+				   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+						  XENKBD_FIELD_WIDTH,
 						  ptr_size[KPARAM_X]);
-	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
+	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+						  XENKBD_FIELD_HEIGHT,
 						  ptr_size[KPARAM_Y]);
 	if (abs) {
 		ret = xenbus_write(XBT_NIL, dev->nodename,
-				   "request-abs-pointer", "1");
+				   XENKBD_FIELD_REQ_ABS_POINTER, "1");
 		if (ret) {
 			pr_warning("xenkbd: can't request abs-pointer");
 			abs = 0;

@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct xenbus_device *dev,
 		xenbus_dev_fatal(dev, ret, "starting transaction");
 		goto error_irqh;
 	}
-	ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, "%lu",
 			    virt_to_gfn(info->page));
 	if (ret)
 		goto error_xenbus;
-	ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", info->gref);
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+			    "%u", info->gref);
 	if (ret)
 		goto error_xenbus;
-	ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_EVT_CHANNEL, "%u",
 			    evtchn);
 	if (ret)
 		goto error_xenbus;

@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
 }
 
 static const struct xenbus_device_id xenkbd_ids[] = {
-	{ "vkbd" },
+	{ XENKBD_DRIVER_NAME },
 	{ "" }
 };

@@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
 
 MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");
 MODULE_LICENSE("GPL");
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);

Signature · 1 line

2.7.4

Signature · 1 line

Dmitry

Oleksandr Andrushchenko

author

2017-05-05 04:44 UTC #4 lore raw

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

Hello, Dmitry!

Quoted 8 lines · Oleksandr Andrushchenko

Quoted 7 lines · Dmitry Torokhov
Quoted 6 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Xen input para-virtual protocol defines string constants used by both back and frontend. Use those instead of explicit strings in the frontend driver.

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
Signed-off-by Oleksandr Andrushchenko <[email protected]>
I'll have to postpone it until I receive changes containing these new string constants.
fair enough
Quoted 1 line
Otherwise it looks OK.
thank you

As all the dependencies are now merged into the kernel, can we please proceed with this patch?

Quoted 63 lines

  drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
  1 file changed, 13 insertions(+), 9 deletions(-)

drivers/input/misc/xen-kbdfront.c +7 -4

index 2fc7895373ab..01c27b4c3288 100644
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device 
 *dev,
          goto error_nomem;
        /* Set input abs params to match backend screen res */
-    abs = xenbus_read_unsigned(dev->otherend, 
 "feature-abs-pointer", 0);
-    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+    abs = xenbus_read_unsigned(dev->otherend,
+                   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+                          XENKBD_FIELD_WIDTH,
                            ptr_size[KPARAM_X]);
-    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
+    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+                          XENKBD_FIELD_HEIGHT,
                            ptr_size[KPARAM_Y]);
      if (abs) {
          ret = xenbus_write(XBT_NIL, dev->nodename,
-                   "request-abs-pointer", "1");
+                   XENKBD_FIELD_REQ_ABS_POINTER, "1");
          if (ret) {
              pr_warning("xenkbd: can't request abs-pointer");

              abs = 0;

drivers/input/misc/xen-kbdfront.c +4 -3

@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct 
 xenbus_device *dev,
          xenbus_dev_fatal(dev, ret, "starting transaction");
          goto error_irqh;
      }
-    ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, 
 "%lu",
                  virt_to_gfn(info->page));
      if (ret)
          goto error_xenbus;
-    ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", 
 info->gref);
+    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+                "%u", info->gref);
      if (ret)
          goto error_xenbus;
-    ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+    ret = xenbus_printf(xbt, dev->nodename,

XENKBD_FIELD_EVT_CHANNEL, "%u",

                  evtchn);
      if (ret)
          goto error_xenbus;

drivers/input/misc/xen-kbdfront.c +1 -1

@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct 
 xenbus_device *dev,
  }
    static const struct xenbus_device_id xenkbd_ids[] = {
-    { "vkbd" },
+    { XENKBD_DRIVER_NAME },
      { "" }
  };
  @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);

    MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");

Quoted 8 lines

Quoted 6 lines
Quoted 6 lines
  MODULE_LICENSE("GPL");
drivers/input/misc/xen-kbdfront.c +1 -1
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
Signature · 1 line
2.7.4
Thank you,
Oleksandr

Thank you,
Oleksandr

Oleksandr Andrushchenko

author

2017-05-12 13:43 UTC #5 lore raw

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

gentle reminder

Quoted 94 lines · Oleksandr Andrushchenko

Hello, Dmitry!

Quoted 8 lines · Oleksandr Andrushchenko

Quoted 7 lines · Dmitry Torokhov
Quoted 6 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Xen input para-virtual protocol defines string constants used by both back and frontend. Use those instead of explicit strings in the frontend driver.

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
Signed-off-by Oleksandr Andrushchenko <[email protected]>
I'll have to postpone it until I receive changes containing these new string constants.
fair enough
Quoted 1 line
Otherwise it looks OK.
thank you

As all the dependencies are now merged into the kernel, can we please proceed with this patch?

Quoted 65 lines

  drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
  1 file changed, 13 insertions(+), 9 deletions(-)

drivers/input/misc/xen-kbdfront.c +7 -4

index 2fc7895373ab..01c27b4c3288 100644
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device 
 *dev,
          goto error_nomem;
        /* Set input abs params to match backend screen res */
-    abs = xenbus_read_unsigned(dev->otherend, 
 "feature-abs-pointer", 0);
-    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+    abs = xenbus_read_unsigned(dev->otherend,
+                   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+                          XENKBD_FIELD_WIDTH,
                            ptr_size[KPARAM_X]);
-    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, 
 "height",
+    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+                          XENKBD_FIELD_HEIGHT,
                            ptr_size[KPARAM_Y]);
      if (abs) {
          ret = xenbus_write(XBT_NIL, dev->nodename,
-                   "request-abs-pointer", "1");
+                   XENKBD_FIELD_REQ_ABS_POINTER, "1");
          if (ret) {

              pr_warning("xenkbd: can't request abs-pointer");
              abs = 0;

drivers/input/misc/xen-kbdfront.c +4 -3

@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct 
 xenbus_device *dev,
          xenbus_dev_fatal(dev, ret, "starting transaction");
          goto error_irqh;
      }
-    ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, 
 "%lu",
                  virt_to_gfn(info->page));
      if (ret)
          goto error_xenbus;
-    ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", 
 info->gref);
+    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+                "%u", info->gref);
      if (ret)
          goto error_xenbus;
-    ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+    ret = xenbus_printf(xbt, dev->nodename,

XENKBD_FIELD_EVT_CHANNEL, "%u",

                  evtchn);
      if (ret)
          goto error_xenbus;

drivers/input/misc/xen-kbdfront.c +1 -1

@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct 
 xenbus_device *dev,
  }
    static const struct xenbus_device_id xenkbd_ids[] = {
-    { "vkbd" },
+    { XENKBD_DRIVER_NAME },
      { "" }
  };
  @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);

MODULE_DESCRIPTION("Xen virtual keyboard/pointer device
frontend");

Quoted 8 lines

Quoted 6 lines
Quoted 6 lines
  MODULE_LICENSE("GPL");
drivers/input/misc/xen-kbdfront.c +1 -1
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
Signature · 1 line
2.7.4
Thank you,
Oleksandr

Thank you,
Oleksandr

Oleksandr Andrushchenko

author

2017-05-22 13:24 UTC #6 lore raw

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

Hi, Dmitry!

It's been quite a while now, I'm just wondering if you had a chance to look at the patch?

Thank you,
Oleksandr

Quoted 100 lines · Oleksandr Andrushchenko

gentle reminder

Quoted 95 lines · Oleksandr Andrushchenko

Hello, Dmitry!

Quoted 8 lines · Oleksandr Andrushchenko

Quoted 7 lines · Dmitry Torokhov
Quoted 6 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Xen input para-virtual protocol defines string constants used by both back and frontend. Use those instead of explicit strings in the frontend driver.

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
Signed-off-by Oleksandr Andrushchenko <[email protected]>
I'll have to postpone it until I receive changes containing these new string constants.
fair enough
Quoted 1 line
Otherwise it looks OK.
thank you

As all the dependencies are now merged into the kernel, can we please proceed with this patch?

Quoted 66 lines

  drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
  1 file changed, 13 insertions(+), 9 deletions(-)

drivers/input/misc/xen-kbdfront.c +7 -4

index 2fc7895373ab..01c27b4c3288 100644
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device 
 *dev,
          goto error_nomem;
        /* Set input abs params to match backend screen res */
-    abs = xenbus_read_unsigned(dev->otherend, 
 "feature-abs-pointer", 0);
-    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, 
 "width",
+    abs = xenbus_read_unsigned(dev->otherend,
+                   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+                          XENKBD_FIELD_WIDTH,
                            ptr_size[KPARAM_X]);
-    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, 
 "height",
+    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+                          XENKBD_FIELD_HEIGHT,
                            ptr_size[KPARAM_Y]);
      if (abs) {
          ret = xenbus_write(XBT_NIL, dev->nodename,
-                   "request-abs-pointer", "1");
+                   XENKBD_FIELD_REQ_ABS_POINTER, "1");

          if (ret) {
              pr_warning("xenkbd: can't request abs-pointer");
              abs = 0;

drivers/input/misc/xen-kbdfront.c +4 -3

@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct 
 xenbus_device *dev,
          xenbus_dev_fatal(dev, ret, "starting transaction");
          goto error_irqh;
      }
-    ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+    ret = xenbus_printf(xbt, dev->nodename, 
 XENKBD_FIELD_RING_REF, "%lu",
                  virt_to_gfn(info->page));
      if (ret)
          goto error_xenbus;
-    ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", 
 info->gref);
+    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+                "%u", info->gref);
      if (ret)
          goto error_xenbus;
-    ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+    ret = xenbus_printf(xbt, dev->nodename,

XENKBD_FIELD_EVT_CHANNEL, "%u",

                  evtchn);
      if (ret)
          goto error_xenbus;

drivers/input/misc/xen-kbdfront.c +1 -1

@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct 
 xenbus_device *dev,
  }
    static const struct xenbus_device_id xenkbd_ids[] = {
-    { "vkbd" },
+    { XENKBD_DRIVER_NAME },
      { "" }
  };
  @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);

MODULE_DESCRIPTION("Xen virtual keyboard/pointer device
frontend");

Quoted 8 lines

Quoted 6 lines
Quoted 6 lines
  MODULE_LICENSE("GPL");
drivers/input/misc/xen-kbdfront.c +1 -1
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
Signature · 1 line
2.7.4
Thank you,
Oleksandr

Thank you,
Oleksandr

Oleksandr Andrushchenko

author

2017-05-22 13:24 UTC #7 lore raw

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

In reply to Oleksandr Andrushchenko

Hi, Dmitry!

It's been quite a while now, I'm just wondering if you had a chance to look at the patch?

Thank you,
Oleksandr

Quoted 100 lines · Oleksandr Andrushchenko

gentle reminder

Quoted 95 lines · Oleksandr Andrushchenko

Hello, Dmitry!

Quoted 8 lines · Oleksandr Andrushchenko

Quoted 7 lines · Dmitry Torokhov
Quoted 6 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Xen input para-virtual protocol defines string constants used by both back and frontend. Use those instead of explicit strings in the frontend driver.

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
Signed-off-by Oleksandr Andrushchenko <[email protected]>
I'll have to postpone it until I receive changes containing these new string constants.
fair enough
Quoted 1 line
Otherwise it looks OK.
thank you

As all the dependencies are now merged into the kernel, can we please proceed with this patch?

Quoted 66 lines

  drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
  1 file changed, 13 insertions(+), 9 deletions(-)

drivers/input/misc/xen-kbdfront.c +7 -4

index 2fc7895373ab..01c27b4c3288 100644
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device 
 *dev,
          goto error_nomem;
        /* Set input abs params to match backend screen res */
-    abs = xenbus_read_unsigned(dev->otherend, 
 "feature-abs-pointer", 0);
-    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, 
 "width",
+    abs = xenbus_read_unsigned(dev->otherend,
+                   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+                          XENKBD_FIELD_WIDTH,
                            ptr_size[KPARAM_X]);
-    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, 
 "height",
+    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+                          XENKBD_FIELD_HEIGHT,
                            ptr_size[KPARAM_Y]);
      if (abs) {
          ret = xenbus_write(XBT_NIL, dev->nodename,
-                   "request-abs-pointer", "1");
+                   XENKBD_FIELD_REQ_ABS_POINTER, "1");

          if (ret) {
              pr_warning("xenkbd: can't request abs-pointer");
              abs = 0;

drivers/input/misc/xen-kbdfront.c +4 -3

@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct 
 xenbus_device *dev,
          xenbus_dev_fatal(dev, ret, "starting transaction");
          goto error_irqh;
      }
-    ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+    ret = xenbus_printf(xbt, dev->nodename, 
 XENKBD_FIELD_RING_REF, "%lu",
                  virt_to_gfn(info->page));
      if (ret)
          goto error_xenbus;
-    ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", 
 info->gref);
+    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+                "%u", info->gref);
      if (ret)
          goto error_xenbus;
-    ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+    ret = xenbus_printf(xbt, dev->nodename,

XENKBD_FIELD_EVT_CHANNEL, "%u",

                  evtchn);
      if (ret)
          goto error_xenbus;

drivers/input/misc/xen-kbdfront.c +1 -1

@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct 
 xenbus_device *dev,
  }
    static const struct xenbus_device_id xenkbd_ids[] = {
-    { "vkbd" },
+    { XENKBD_DRIVER_NAME },
      { "" }
  };
  @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);

MODULE_DESCRIPTION("Xen virtual keyboard/pointer device
frontend");

Quoted 8 lines

Quoted 6 lines
Quoted 6 lines
  MODULE_LICENSE("GPL");
drivers/input/misc/xen-kbdfront.c +1 -1
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
Signature · 1 line
2.7.4
Thank you,
Oleksandr

Thank you,
Oleksandr

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Oleksandr Andrushchenko

author

2017-05-12 13:43 UTC #8 lore raw

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

In reply to Oleksandr Andrushchenko

gentle reminder

Quoted 92 lines · Oleksandr Andrushchenko

Hello, Dmitry!

Quoted 8 lines · Oleksandr Andrushchenko

Quoted 7 lines · Dmitry Torokhov
Quoted 6 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Xen input para-virtual protocol defines string constants used by both back and frontend. Use those instead of explicit strings in the frontend driver.

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
Signed-off-by Oleksandr Andrushchenko <[email protected]>
I'll have to postpone it until I receive changes containing these new string constants.
fair enough
Quoted 1 line
Otherwise it looks OK.
thank you

As all the dependencies are now merged into the kernel, can we please proceed with this patch?

Quoted 65 lines

  drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
  1 file changed, 13 insertions(+), 9 deletions(-)

drivers/input/misc/xen-kbdfront.c +7 -4

index 2fc7895373ab..01c27b4c3288 100644
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device 
 *dev,
          goto error_nomem;
        /* Set input abs params to match backend screen res */
-    abs = xenbus_read_unsigned(dev->otherend, 
 "feature-abs-pointer", 0);
-    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+    abs = xenbus_read_unsigned(dev->otherend,
+                   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+                          XENKBD_FIELD_WIDTH,
                            ptr_size[KPARAM_X]);
-    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, 
 "height",
+    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+                          XENKBD_FIELD_HEIGHT,
                            ptr_size[KPARAM_Y]);
      if (abs) {
          ret = xenbus_write(XBT_NIL, dev->nodename,
-                   "request-abs-pointer", "1");
+                   XENKBD_FIELD_REQ_ABS_POINTER, "1");
          if (ret) {

              pr_warning("xenkbd: can't request abs-pointer");
              abs = 0;

drivers/input/misc/xen-kbdfront.c +4 -3

@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct 
 xenbus_device *dev,
          xenbus_dev_fatal(dev, ret, "starting transaction");
          goto error_irqh;
      }
-    ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, 
 "%lu",
                  virt_to_gfn(info->page));
      if (ret)
          goto error_xenbus;
-    ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", 
 info->gref);
+    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+                "%u", info->gref);
      if (ret)
          goto error_xenbus;
-    ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+    ret = xenbus_printf(xbt, dev->nodename,

XENKBD_FIELD_EVT_CHANNEL, "%u",

                  evtchn);
      if (ret)
          goto error_xenbus;

drivers/input/misc/xen-kbdfront.c +1 -1

@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct 
 xenbus_device *dev,
  }
    static const struct xenbus_device_id xenkbd_ids[] = {
-    { "vkbd" },
+    { XENKBD_DRIVER_NAME },
      { "" }
  };
  @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);

MODULE_DESCRIPTION("Xen virtual keyboard/pointer device
frontend");

Quoted 8 lines

Quoted 6 lines
Quoted 6 lines
  MODULE_LICENSE("GPL");
drivers/input/misc/xen-kbdfront.c +1 -1
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
Signature · 1 line
2.7.4
Thank you,
Oleksandr

Quoted 2 lines

Thank you,
Oleksandr

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Oleksandr Andrushchenko

author

2017-05-05 04:44 UTC #9 lore raw

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

In reply to Oleksandr Andrushchenko

Hello, Dmitry!

Quoted 8 lines · Oleksandr Andrushchenko

Quoted 7 lines · Dmitry Torokhov
Quoted 6 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Xen input para-virtual protocol defines string constants used by both back and frontend. Use those instead of explicit strings in the frontend driver.

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
Signed-off-by Oleksandr Andrushchenko <[email protected]>
I'll have to postpone it until I receive changes containing these new string constants.
fair enough
Quoted 1 line
Otherwise it looks OK.
thank you

As all the dependencies are now merged into the kernel, can we please proceed with this patch?

Quoted 63 lines

  drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
  1 file changed, 13 insertions(+), 9 deletions(-)

drivers/input/misc/xen-kbdfront.c +7 -4

index 2fc7895373ab..01c27b4c3288 100644
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device 
 *dev,
          goto error_nomem;
        /* Set input abs params to match backend screen res */
-    abs = xenbus_read_unsigned(dev->otherend, 
 "feature-abs-pointer", 0);
-    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+    abs = xenbus_read_unsigned(dev->otherend,
+                   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+    ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+                          XENKBD_FIELD_WIDTH,
                            ptr_size[KPARAM_X]);
-    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
+    ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+                          XENKBD_FIELD_HEIGHT,
                            ptr_size[KPARAM_Y]);
      if (abs) {
          ret = xenbus_write(XBT_NIL, dev->nodename,
-                   "request-abs-pointer", "1");
+                   XENKBD_FIELD_REQ_ABS_POINTER, "1");
          if (ret) {
              pr_warning("xenkbd: can't request abs-pointer");

              abs = 0;

drivers/input/misc/xen-kbdfront.c +4 -3

@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct 
 xenbus_device *dev,
          xenbus_dev_fatal(dev, ret, "starting transaction");
          goto error_irqh;
      }
-    ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, 
 "%lu",
                  virt_to_gfn(info->page));
      if (ret)
          goto error_xenbus;
-    ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", 
 info->gref);
+    ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+                "%u", info->gref);
      if (ret)
          goto error_xenbus;
-    ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+    ret = xenbus_printf(xbt, dev->nodename,

XENKBD_FIELD_EVT_CHANNEL, "%u",

                  evtchn);
      if (ret)
          goto error_xenbus;

drivers/input/misc/xen-kbdfront.c +1 -1

@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct 
 xenbus_device *dev,
  }
    static const struct xenbus_device_id xenkbd_ids[] = {
-    { "vkbd" },
+    { XENKBD_DRIVER_NAME },
      { "" }
  };
  @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);

    MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");

Quoted 8 lines

Quoted 6 lines
Quoted 6 lines
  MODULE_LICENSE("GPL");
drivers/input/misc/xen-kbdfront.c +1 -1
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
Signature · 1 line
2.7.4
Thank you,
Oleksandr

Thank you,
Oleksandr

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Oleksandr Andrushchenko

author

2017-04-21 06:42 UTC #10 lore raw

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

In reply to Dmitry Torokhov

Quoted 10 lines · Dmitry Torokhov

Quoted 7 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Xen input para-virtual protocol defines string constants used by both back and frontend. Use those instead of explicit strings in the frontend driver.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
I'll have to postpone it until I receive changes containing these new string constants.

fair enough

Quoted 1 line

Otherwise it looks OK.

thank you

Quoted 60 lines

---
  drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
  1 file changed, 13 insertions(+), 9 deletions(-)

drivers/input/misc/xen-kbdfront.c +12 -8

index 2fc7895373ab..01c27b4c3288 100644
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
  		goto error_nomem;
 
  	/* Set input abs params to match backend screen res */
-	abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
-	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+	abs = xenbus_read_unsigned(dev->otherend,
+				   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+						  XENKBD_FIELD_WIDTH,
  						  ptr_size[KPARAM_X]);
-	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
+	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+						  XENKBD_FIELD_HEIGHT,
  						  ptr_size[KPARAM_Y]);
  	if (abs) {
  		ret = xenbus_write(XBT_NIL, dev->nodename,
-				   "request-abs-pointer", "1");
+				   XENKBD_FIELD_REQ_ABS_POINTER, "1");
  		if (ret) {
  			pr_warning("xenkbd: can't request abs-pointer");
  			abs = 0;

@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct xenbus_device *dev,
  		xenbus_dev_fatal(dev, ret, "starting transaction");
  		goto error_irqh;
  	}
-	ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, "%lu",
  			    virt_to_gfn(info->page));
  	if (ret)
  		goto error_xenbus;
-	ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", info->gref);
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+			    "%u", info->gref);
  	if (ret)
  		goto error_xenbus;
-	ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_EVT_CHANNEL, "%u",
  			    evtchn);
  	if (ret)
  		goto error_xenbus;

@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
  }
 
  static const struct xenbus_device_id xenkbd_ids[] = {
-	{ "vkbd" },
+	{ XENKBD_DRIVER_NAME },
  	{ "" }
  };

@@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c +1 -1

  MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");
  MODULE_LICENSE("GPL");
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);

Signature · 1 line

2.7.4

Thank you,
Oleksandr

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Oleksandr Andrushchenko

author

2017-05-30 12:37 UTC #12 lore raw

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

In reply to Dmitry Torokhov

Hi, Dmitry!

Quoted 10 lines · Dmitry Torokhov

Quoted 7 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Xen input para-virtual protocol defines string constants used by both back and frontend. Use those instead of explicit strings in the frontend driver.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
I'll have to postpone it until I receive changes containing these new string constants. Otherwise it looks OK.

May I put your "Reviewed-by" for this change?

Quoted 61 lines

---
  drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
  1 file changed, 13 insertions(+), 9 deletions(-)

drivers/input/misc/xen-kbdfront.c +12 -8

index 2fc7895373ab..01c27b4c3288 100644
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
  		goto error_nomem;
 
  	/* Set input abs params to match backend screen res */
-	abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
-	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+	abs = xenbus_read_unsigned(dev->otherend,
+				   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+						  XENKBD_FIELD_WIDTH,
  						  ptr_size[KPARAM_X]);
-	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
+	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+						  XENKBD_FIELD_HEIGHT,
  						  ptr_size[KPARAM_Y]);
  	if (abs) {
  		ret = xenbus_write(XBT_NIL, dev->nodename,
-				   "request-abs-pointer", "1");
+				   XENKBD_FIELD_REQ_ABS_POINTER, "1");
  		if (ret) {
  			pr_warning("xenkbd: can't request abs-pointer");
  			abs = 0;

@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct xenbus_device *dev,
  		xenbus_dev_fatal(dev, ret, "starting transaction");
  		goto error_irqh;
  	}
-	ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, "%lu",
  			    virt_to_gfn(info->page));
  	if (ret)
  		goto error_xenbus;
-	ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", info->gref);
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+			    "%u", info->gref);
  	if (ret)
  		goto error_xenbus;
-	ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_EVT_CHANNEL, "%u",
  			    evtchn);
  	if (ret)
  		goto error_xenbus;

@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
  }
 
  static const struct xenbus_device_id xenkbd_ids[] = {
-	{ "vkbd" },
+	{ XENKBD_DRIVER_NAME },
  	{ "" }
  };

@@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c +1 -1

  MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");
  MODULE_LICENSE("GPL");
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);

Signature · 1 line

2.7.4

Thank you,
Oleksandr

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Dmitry Torokhov

maintainer

2017-04-21 02:11 UTC #13 lore raw

Re: [PATCH 1/2] xen/input: use string constants from PV protocol

In reply to Oleksandr Andrushchenko

Quoted 7 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>
Xen input para-virtual protocol defines string constants used by both back and frontend. Use those instead of explicit strings in the frontend driver.
Signed-off-by Oleksandr Andrushchenko <[email protected]>

I'll have to postpone it until I receive changes containing these new string constants. Otherwise it looks OK.

Quoted 67 lines

---
 drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

drivers/input/misc/xen-kbdfront.c +13 -9

index 2fc7895373ab..01c27b4c3288 100644
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
 		goto error_nomem;
 
 	/* Set input abs params to match backend screen res */
-	abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
-	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+	abs = xenbus_read_unsigned(dev->otherend,
+				   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+						  XENKBD_FIELD_WIDTH,
 						  ptr_size[KPARAM_X]);
-	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
+	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+						  XENKBD_FIELD_HEIGHT,
 						  ptr_size[KPARAM_Y]);
 	if (abs) {
 		ret = xenbus_write(XBT_NIL, dev->nodename,
-				   "request-abs-pointer", "1");
+				   XENKBD_FIELD_REQ_ABS_POINTER, "1");
 		if (ret) {
 			pr_warning("xenkbd: can't request abs-pointer");
 			abs = 0;

@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct xenbus_device *dev,
 		xenbus_dev_fatal(dev, ret, "starting transaction");
 		goto error_irqh;
 	}
-	ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, "%lu",
 			    virt_to_gfn(info->page));
 	if (ret)
 		goto error_xenbus;
-	ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", info->gref);
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+			    "%u", info->gref);
 	if (ret)
 		goto error_xenbus;
-	ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_EVT_CHANNEL, "%u",
 			    evtchn);
 	if (ret)
 		goto error_xenbus;

@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
 }
 
 static const struct xenbus_device_id xenkbd_ids[] = {
-	{ "vkbd" },
+	{ XENKBD_DRIVER_NAME },
 	{ "" }
 };

@@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
 
 MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");
 MODULE_LICENSE("GPL");
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);

Signature · 1 line

2.7.4

Signature · 6 lines

Dmitry

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Oleksandr Andrushchenko

author

2017-04-13 11:38 UTC #14 lore raw

PATCH 1/2 xen/input: use string constants from PV protocol

In reply to Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Xen input para-virtual protocol defines string constants used by both back and frontend. Use those instead of explicit strings in the frontend driver.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
 drivers/input/misc/xen-kbdfront.c | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

drivers/input/misc/xen-kbdfront.c +13 -9

index 2fc7895373ab..01c27b4c3288 100644
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
 		goto error_nomem;
 
 	/* Set input abs params to match backend screen res */
-	abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
-	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+	abs = xenbus_read_unsigned(dev->otherend,
+				   XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+	ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+						  XENKBD_FIELD_WIDTH,
 						  ptr_size[KPARAM_X]);
-	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
+	ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+						  XENKBD_FIELD_HEIGHT,
 						  ptr_size[KPARAM_Y]);
 	if (abs) {
 		ret = xenbus_write(XBT_NIL, dev->nodename,
-				   "request-abs-pointer", "1");
+				   XENKBD_FIELD_REQ_ABS_POINTER, "1");
 		if (ret) {
 			pr_warning("xenkbd: can't request abs-pointer");
 			abs = 0;

@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct xenbus_device *dev,
 		xenbus_dev_fatal(dev, ret, "starting transaction");
 		goto error_irqh;
 	}
-	ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, "%lu",
 			    virt_to_gfn(info->page));
 	if (ret)
 		goto error_xenbus;
-	ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", info->gref);
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+			    "%u", info->gref);
 	if (ret)
 		goto error_xenbus;
-	ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+	ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_EVT_CHANNEL, "%u",
 			    evtchn);
 	if (ret)
 		goto error_xenbus;

@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
 }
 
 static const struct xenbus_device_id xenkbd_ids[] = {
-	{ "vkbd" },
+	{ XENKBD_DRIVER_NAME },
 	{ "" }
 };

@@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
 
 MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");
 MODULE_LICENSE("GPL");
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);

Signature · 7 lines

2.7.4


_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Oleksandr Andrushchenko

author

2017-04-13 11:38 UTC #15 lore raw

PATCH 2/2 xen/input: add multi-touch support

In reply to Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
 drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +140 -2

index 01c27b4c3288..e5d064aaa237 100644
@@ -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)");
+
 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)) {
+				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);
+				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);
+		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);
+
+		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);
+
+		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;

Signature · 1 line

2.7.4

Dmitry Torokhov

maintainer

2017-04-21 02:10 UTC #16 lore raw

Hi Oleksandr,

Quoted 38 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
 drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +4 -0

index 01c27b4c3288..e5d064aaa237 100644
@@ -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 };

drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 59

Quoted 9 lines

drivers/input/misc/xen-kbdfront.c +6 -0

@@ -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?

drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118

Quoted 13 lines

drivers/input/misc/xen-kbdfront.c +6 -0

 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?

Quoted 92 lines

drivers/input/misc/xen-kbdfront.c +68 -2

+				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);
+				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;

drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 302

Quoted 10 lines

drivers/input/misc/xen-kbdfront.c +10 -0

+
+		num_cont = xenbus_read_unsigned(info->xbdev->nodename,
+						XENKBD_FIELD_MT_NUM_CONTACTS,
+						1);
+		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...

Quoted 59 lines

drivers/input/misc/xen-kbdfront.c +46 -0

+
+		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);
+
+		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;

Signature · 1 line

2.7.4

Thanks.

Signature · 1 line

Dmitry

Oleksandr Andrushchenko

author

2017-04-21 06:40 UTC #17 lore raw

Hi, Dmitry!

Quoted 44 lines · Dmitry Torokhov

Hi Oleksandr,

Quoted 41 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +4 -0

index 01c27b4c3288..e5d064aaa237 100644
@@ -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)");

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 59
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+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

Quoted 16 lines

Quoted 5 lines

drivers/input/misc/xen-kbdfront.c +0 -0

  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 *);

drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118

Quoted 9 lines

drivers/input/misc/xen-kbdfront.c +6 -0

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

Quoted 95 lines

drivers/input/misc/xen-kbdfront.c +71 -2

+				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);
+				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,

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 302
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+						1);
+		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)

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?

Quoted 52 lines

drivers/input/misc/xen-kbdfront.c +45 -0

+
+		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);
+
+		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)

Quoted 8 lines

Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+		input_unregister_device(info->mtouch);
  	free_page((unsigned long)info->page);
  	kfree(info);
  	return 0;
Signature · 1 line
2.7.4
Thanks.

Thank you,
Oleksandr
[1] https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.12&id=e27c533dc4d0338266ccb6dab428150d4d629e6a

Oleksandr Andrushchenko

author

2017-05-05 04:46 UTC #18 lore raw

Hi, Dmitry!

Quoted 260 lines · Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 41 lines · Dmitry Torokhov

Hi Oleksandr,

Quoted 38 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
  drivers/input/misc/xen-kbdfront.c | 142 
+++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +4 -0

index 01c27b4c3288..e5d064aaa237 100644
@@ -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,

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 59
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +5 -0
      "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

Quoted 10 lines

drivers/input/misc/xen-kbdfront.c +0 -0

  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;

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+        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

Quoted 92 lines

drivers/input/misc/xen-kbdfront.c +48 -0

+ 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);
+                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);

drivers/input/misc/xen-kbdfront.c +21 -2

@@ -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,

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 302

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c +7 -0

+                        1);
+        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"

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?

Quoted 52 lines

drivers/input/misc/xen-kbdfront.c +45 -0

+
+        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);
+
+        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)

Quoted 8 lines

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c +1 -0

+        input_unregister_device(info->mtouch);
      free_page((unsigned long)info->page);
      kfree(info);
      return 0;

Signature · 1 line

2.7.4

Thanks.

Quoted 4 lines

Thank you,
Oleksandr
[1] https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.12&id=e27c533dc4d0338266ccb6dab428150d4d629e6a

As all the dependencies are now merged into the kernel and *if* the above sounds reasonable for you can we please proceed with this patch?

Thank you,
Oleksandr

Oleksandr Andrushchenko

author

2017-05-12 13:44 UTC #19 lore raw

gentle reminder

Quoted 277 lines · Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 264 lines · Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 42 lines · Dmitry Torokhov

Hi Oleksandr,

Quoted 39 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
  drivers/input/misc/xen-kbdfront.c | 142 
+++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +4 -0

index 01c27b4c3288..e5d064aaa237 100644
@@ -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)");

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 59
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +5 -0
  +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

Quoted 10 lines

drivers/input/misc/xen-kbdfront.c +0 -0

  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 *);

drivers/input/misc/xen-kbdfront.c +0 -0

@@ -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;

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+        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

Quoted 94 lines

drivers/input/misc/xen-kbdfront.c +48 -0

+ 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);
+                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);

drivers/input/misc/xen-kbdfront.c +21 -2

@@ -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,

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 302

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c +7 -0

+                        1);
+        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"

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?

Quoted 53 lines

drivers/input/misc/xen-kbdfront.c +45 -0

+
+        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);
+
+        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)

Quoted 8 lines

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c +1 -0

+        input_unregister_device(info->mtouch);
      free_page((unsigned long)info->page);
      kfree(info);

      return 0;

Signature · 1 line

2.7.4

Thanks.

Quoted 4 lines

Thank you,
Oleksandr
[1] https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.12&id=e27c533dc4d0338266ccb6dab428150d4d629e6a

As all the dependencies are now merged into the kernel and *if* the above sounds reasonable for you can we please proceed with this patch?

Thank you,
Oleksandr

Oleksandr Andrushchenko

author

2017-05-22 13:25 UTC #20 lore raw

Hi, Dmitry!

It's been quite a while now, I'm just wondering if you had a chance to look at the patch?

Thank you,
Oleksandr

Quoted 283 lines · Oleksandr Andrushchenko

gentle reminder

Quoted 278 lines · Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 265 lines · Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 42 lines · Dmitry Torokhov

Hi Oleksandr,

Quoted 39 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
  drivers/input/misc/xen-kbdfront.c | 142 
+++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +4 -0

index 01c27b4c3288..e5d064aaa237 100644
@@ -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)");

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 59
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +5 -0
  +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

Quoted 10 lines

drivers/input/misc/xen-kbdfront.c +0 -0

  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 *);

drivers/input/misc/xen-kbdfront.c +0 -0

@@ -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;

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+        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

Quoted 95 lines

drivers/input/misc/xen-kbdfront.c +48 -0

+ 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);
+                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);

drivers/input/misc/xen-kbdfront.c +21 -2

@@ -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,

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 302

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c +7 -0

+                        1);
+        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"

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?

Quoted 53 lines

drivers/input/misc/xen-kbdfront.c +45 -0

+
+        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);
+
+        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)

Quoted 8 lines

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c +1 -0

+        input_unregister_device(info->mtouch);
      free_page((unsigned long)info->page);
      kfree(info);

      return 0;

Signature · 1 line

2.7.4

Thanks.

Quoted 4 lines

Thank you,
Oleksandr
[1] https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.12&id=e27c533dc4d0338266ccb6dab428150d4d629e6a

As all the dependencies are now merged into the kernel and *if* the above sounds reasonable for you can we please proceed with this patch?

Thank you,
Oleksandr

Oleksandr Andrushchenko

author

2017-05-22 13:25 UTC #21 lore raw

In reply to Oleksandr Andrushchenko

Hi, Dmitry!

It's been quite a while now, I'm just wondering if you had a chance to look at the patch?

Thank you,
Oleksandr

Quoted 283 lines · Oleksandr Andrushchenko

gentle reminder

Quoted 278 lines · Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 265 lines · Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 42 lines · Dmitry Torokhov

Hi Oleksandr,

Quoted 39 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
  drivers/input/misc/xen-kbdfront.c | 142 
+++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +4 -0

index 01c27b4c3288..e5d064aaa237 100644
@@ -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)");

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 59
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +5 -0
  +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

Quoted 10 lines

drivers/input/misc/xen-kbdfront.c +0 -0

  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 *);

drivers/input/misc/xen-kbdfront.c +0 -0

@@ -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;

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+        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

Quoted 95 lines

drivers/input/misc/xen-kbdfront.c +48 -0

+ 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);
+                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);

drivers/input/misc/xen-kbdfront.c +21 -2

@@ -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,

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 302

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c +7 -0

+                        1);
+        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"

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?

Quoted 53 lines

drivers/input/misc/xen-kbdfront.c +45 -0

+
+        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);
+
+        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)

Quoted 8 lines

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c +1 -0

+        input_unregister_device(info->mtouch);
      free_page((unsigned long)info->page);
      kfree(info);

      return 0;

Signature · 1 line

2.7.4

Thanks.

Quoted 4 lines

Thank you,
Oleksandr
[1] https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.12&id=e27c533dc4d0338266ccb6dab428150d4d629e6a

As all the dependencies are now merged into the kernel and *if* the above sounds reasonable for you can we please proceed with this patch?

Thank you,
Oleksandr

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Oleksandr Andrushchenko

author

2017-05-12 13:44 UTC #22 lore raw

In reply to Oleksandr Andrushchenko

gentle reminder

Quoted 272 lines · Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 264 lines · Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 42 lines · Dmitry Torokhov

Hi Oleksandr,

Quoted 39 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
  drivers/input/misc/xen-kbdfront.c | 142 
+++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +4 -0

index 01c27b4c3288..e5d064aaa237 100644
@@ -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)");

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 59
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +5 -0
  +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

Quoted 10 lines

drivers/input/misc/xen-kbdfront.c +0 -0

  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 *);

drivers/input/misc/xen-kbdfront.c +0 -0

@@ -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;

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+        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

Quoted 94 lines

drivers/input/misc/xen-kbdfront.c +48 -0

+ 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);
+                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);

drivers/input/misc/xen-kbdfront.c +21 -2

@@ -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,

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 302

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c +7 -0

+                        1);
+        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"

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?

Quoted 53 lines

drivers/input/misc/xen-kbdfront.c +45 -0

+
+        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);
+
+        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)

Quoted 8 lines

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c +1 -0

+        input_unregister_device(info->mtouch);
      free_page((unsigned long)info->page);
      kfree(info);

      return 0;

Signature · 1 line

2.7.4

Thanks.

Quoted 4 lines

Thank you,
Oleksandr
[1] https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.12&id=e27c533dc4d0338266ccb6dab428150d4d629e6a

Quoted 5 lines

As all the dependencies are now merged into the kernel and *if* the above sounds reasonable for you can we please proceed with this patch?
Thank you,
Oleksandr

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Oleksandr Andrushchenko

author

2017-05-05 04:46 UTC #23 lore raw

In reply to Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 260 lines · Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 41 lines · Dmitry Torokhov

Hi Oleksandr,

Quoted 38 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
  drivers/input/misc/xen-kbdfront.c | 142 
+++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +4 -0

index 01c27b4c3288..e5d064aaa237 100644
@@ -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,

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 59
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +5 -0
      "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

Quoted 10 lines

drivers/input/misc/xen-kbdfront.c +0 -0

  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;

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+        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

Quoted 92 lines

drivers/input/misc/xen-kbdfront.c +48 -0

+ 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);
+                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);

drivers/input/misc/xen-kbdfront.c +21 -2

@@ -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,

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 302

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c +7 -0

+                        1);
+        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"

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?

Quoted 52 lines

drivers/input/misc/xen-kbdfront.c +45 -0

+
+        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);
+
+        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)

Quoted 8 lines

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c +1 -0

+        input_unregister_device(info->mtouch);
      free_page((unsigned long)info->page);
      kfree(info);
      return 0;

Signature · 1 line

2.7.4

Thanks.

Quoted 4 lines

Thank you,
Oleksandr
[1] https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.12&id=e27c533dc4d0338266ccb6dab428150d4d629e6a

As all the dependencies are now merged into the kernel and *if* the above sounds reasonable for you can we please proceed with this patch?

Thank you,
Oleksandr

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Dmitry Torokhov

maintainer

2017-05-30 05:51 UTC #24 lore raw

In reply to Oleksandr Andrushchenko

Quoted 68 lines · Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 40 lines · Dmitry Torokhov

Hi Oleksandr,

Quoted 37 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
 drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +4 -0

index 01c27b4c3288..e5d064aaa237 100644
@@ -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,

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 59
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
 	"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

Quoted 16 lines

Quoted 5 lines

drivers/input/misc/xen-kbdfront.c +0 -0

 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 *);

drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118

Quoted 9 lines

drivers/input/misc/xen-kbdfront.c +6 -0

@@ -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?

Quoted 3 lines

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.

Quoted 8 lines

Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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.

Quoted 77 lines

drivers/input/misc/xen-kbdfront.c +56 -2

+				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;

Quoted 8 lines

Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 296
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+
+		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?

Quoted 22 lines

Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 302
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"

Quoted 7 lines

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.

Quoted 4 lines

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

Quoted 20 lines

drivers/input/misc/xen-kbdfront.c +20 -0

+
+		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);

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 330

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c +8 -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. 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.

Quoted 23 lines

drivers/input/misc/xen-kbdfront.c +16 -0

+
+		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);

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +2 -0
+	if (info->mtouch)
+		input_unregister_device(info->mtouch);
 	free_page((unsigned long)info->page);
 	kfree(info);
 	return 0;
Signature · 1 line
2.7.4

Thanks.

Signature · 1 line

Dmitry

Oleksandr Andrushchenko

author

2017-05-30 12:50 UTC #25 lore raw

Hi, Dmitry!

Quoted 68 lines · Dmitry Torokhov

Quoted 67 lines · Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 40 lines · Dmitry Torokhov

Hi Oleksandr,

Quoted 37 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +4 -0

index 01c27b4c3288..e5d064aaa237 100644
@@ -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,

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 58
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
  	"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

Quoted 15 lines

drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118

Quoted 13 lines

drivers/input/misc/xen-kbdfront.c +6 -0

  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?

Quoted 6 lines

Quoted 3 lines
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"

Quoted 9 lines

Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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)

Quoted 78 lines

drivers/input/misc/xen-kbdfront.c +57 -2

+				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;
+

Quoted 8 lines

Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 295
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+		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

Quoted 29 lines

Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 301
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"
Quoted 7 lines
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)

Quoted 8 lines

I see.
Quoted 3 lines
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)

Quoted 21 lines

drivers/input/misc/xen-kbdfront.c +21 -0

+
+		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,

Quoted 8 lines

Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 329
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+				     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

Quoted 3 lines

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

Quoted 25 lines

drivers/input/misc/xen-kbdfront.c +18 -0

+
+		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);

Quoted 9 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +0 -0
  	free_page((unsigned long)info->page);
  	kfree(info);
  	return 0;
Signature · 1 line
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

Quoted 1 line

From e76506c55846e2bb4ccbafa430642e368643e51d Mon Sep 17 00:00:00 2001

From: Oleksandr Andrushchenko <[email protected]>
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 <[email protected]>

---
 drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

drivers/input/misc/xen-kbdfront.c +10 ~~-11~~

index 8266ef948a06..273d786a19cd 100644
@@ -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);

Signature · 1 line

2.7.4

Dmitry Torokhov

maintainer

2017-05-30 16:37 UTC #26 lore raw

Quoted 87 lines · Oleksandr Andrushchenko

Hi, Dmitry!
Quoted 68 lines · Dmitry Torokhov
Quoted 67 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 40 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 37 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
 drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +4 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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,
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 58
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
 	"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
Quoted 15 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 13 lines
drivers/input/misc/xen-kbdfront.c +6 -0
 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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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.

Quoted 2 lines

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?

Quoted 1 line

(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.

Quoted 124 lines

Quoted 78 lines
Quoted 78 lines
Quoted 78 lines
Quoted 78 lines
drivers/input/misc/xen-kbdfront.c +57 -2
+				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;
+
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 295
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+		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
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 301
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"
Quoted 7 lines
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.
Quoted 3 lines
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?

Quoted 6 lines

Quoted 3 lines
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).

Quoted 10 lines

Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 311
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+		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.

Quoted 19 lines

Quoted 11 lines

drivers/input/misc/xen-kbdfront.c +11 -0

+
+		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,

Quoted 8 lines

Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 329
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+				     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.

Quoted 5 lines

done
Quoted 3 lines
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?

Thanks.

Quoted 107 lines

Quoted 25 lines

drivers/input/misc/xen-kbdfront.c +18 -0

+
+		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);

Quoted 9 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +0 -0
 	free_page((unsigned long)info->page);
 	kfree(info);
 	return 0;
Signature · 1 line
2.7.4
Thanks.

Thank you,
Oleksandr

From e76506c55846e2bb4ccbafa430642e368643e51d Mon Sep 17 00:00:00 2001
From: Oleksandr Andrushchenko <[email protected]>
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 <[email protected]>

---
 drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

drivers/input/misc/xen-kbdfront.c +10 ~~-11~~

index 8266ef948a06..273d786a19cd 100644
@@ -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);

Signature · 1 line

2.7.4

Signature · 1 line

Dmitry

Oleksandr Andrushchenko

author

2017-05-31 09:07 UTC #27 lore raw

Hi, Dmitry!

Quoted 88 lines · Dmitry Torokhov

Quoted 87 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 68 lines · Dmitry Torokhov
Quoted 67 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 40 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 37 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +4 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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,
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 58
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
  	"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
Quoted 15 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 13 lines
drivers/input/misc/xen-kbdfront.c +6 -0
  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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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.

Quoted 5 lines

Quoted 2 lines
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

Besides, that, if I am about to implement pen support (which I still not convinced we really need), how will I do that?
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?

Quoted 5 lines

Quoted 2 lines
(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.
So, no PALM/TOOL support is in place

Quoted 124 lines

Quoted 124 lines
Quoted 78 lines
Quoted 78 lines
Quoted 78 lines
Quoted 78 lines
drivers/input/misc/xen-kbdfront.c +57 -2
+				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;
+
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 295
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+		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
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 301
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"
Quoted 7 lines
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.
Quoted 3 lines
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?

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
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

Quoted 11 lines

Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 311
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+		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

Quoted 3 lines

		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
and drop all __set_bit()s.

done, thank you

Quoted 19 lines

Quoted 10 lines

drivers/input/misc/xen-kbdfront.c +10 -0

+
+		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);

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 329

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c +8 -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.

Quoted 7 lines

Quoted 5 lines
done
Quoted 3 lines
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?

Quoted 99 lines

Thanks.

Quoted 96 lines

Quoted 24 lines

drivers/input/misc/xen-kbdfront.c +17 -0

+
+		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)

Quoted 9 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+		input_unregister_device(info->mtouch);
  	free_page((unsigned long)info->page);
  	kfree(info);
  	return 0;
Signature · 1 line
2.7.4
Thanks.

Thank you,
Oleksandr
From e76506c55846e2bb4ccbafa430642e368643e51d Mon Sep 17 00:00:00 2001
From: Oleksandr Andrushchenko <[email protected]>
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 <[email protected]>

---
  drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
  1 file changed, 10 insertions(+), 11 deletions(-)

drivers/input/misc/xen-kbdfront.c +10 -9

index 8266ef948a06..273d786a19cd 100644
@@ -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;
+		}

Quoted 9 lines

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c +0 -2

-		mtouch_size[KPARAM_MT_X] = width;
-		mtouch_size[KPARAM_MT_Y] = height;
  		info->mtouch_cur_contact_id = -1;
 
  		ret = input_register_device(mtouch);

Signature · 1 line

2.7.4

Thank you,
Oleksandr

Oleksandr Andrushchenko

author

2017-06-07 07:15 UTC #28 lore raw

Hi, Dmitry!

I would appreciate your comments on the below

Quoted 417 lines · Oleksandr Andrushchenko

Hi, Dmitry!
Quoted 92 lines · Dmitry Torokhov
Quoted 91 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 73 lines · Dmitry Torokhov
Quoted 72 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 43 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 40 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 142 
+++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +5 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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 };
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 60
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +5 -0
+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
Quoted 17 lines
Quoted 5 lines
drivers/input/misc/xen-kbdfront.c +0 -0
  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 *);
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, · line 119
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +6 -0
@@ -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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+ 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);
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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
Besides, that, if I am about to implement pen support (which I still not convinced we really need), how will I do that?
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?
Quoted 5 lines
Quoted 2 lines
(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.
So, no PALM/TOOL support is in place
Quoted 127 lines
Quoted 127 lines
Quoted 81 lines
Quoted 81 lines
Quoted 81 lines
Quoted 81 lines
drivers/input/misc/xen-kbdfront.c +40 -0
+ 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);
drivers/input/misc/xen-kbdfront.c +17 -2
@@ -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;
+
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 296
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+        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
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 302
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+        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"
Quoted 7 lines
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.
Quoted 3 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 11 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 312
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+        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
Quoted 3 lines
        input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
and drop all __set_bit()s.
done, thank you
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+        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);
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 330
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -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.
Quoted 7 lines
Quoted 5 lines
done
Quoted 3 lines
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?
Quoted 100 lines
Thanks.
Quoted 97 lines
Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
drivers/input/misc/xen-kbdfront.c +17 -0
+
+        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)
Quoted 9 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+        input_unregister_device(info->mtouch);
      free_page((unsigned long)info->page);
      kfree(info);
      return 0;
Signature · 1 line
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 <[email protected]>
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 <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
  1 file changed, 10 insertions(+), 11 deletions(-)
drivers/input/misc/xen-kbdfront.c +2 -7
index 8266ef948a06..273d786a19cd 100644
@@ -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);
drivers/input/misc/xen-kbdfront.c +7 -0
@@ -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;
Quoted 9 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +1 -1
+        }
  -        mtouch_size[KPARAM_MT_X] = width;
-        mtouch_size[KPARAM_MT_Y] = height;
          info->mtouch_cur_contact_id = -1;
            ret = input_register_device(mtouch);
Signature · 1 line
2.7.4
Thank you,
Oleksandr

Oleksandr Andrushchenko

author

2017-06-07 07:15 UTC #29 lore raw

In reply to Oleksandr Andrushchenko

Hi, Dmitry!

I would appreciate your comments on the below

Quoted 415 lines · Oleksandr Andrushchenko

Hi, Dmitry!
Quoted 92 lines · Dmitry Torokhov
Quoted 91 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 73 lines · Dmitry Torokhov
Quoted 72 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 43 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 40 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 142 
+++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +5 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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 };
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 60
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +5 -0
+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
Quoted 17 lines
Quoted 5 lines
drivers/input/misc/xen-kbdfront.c +0 -0
  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 *);
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, · line 119
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +6 -0
@@ -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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+ 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);
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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
Besides, that, if I am about to implement pen support (which I still not convinced we really need), how will I do that?
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?
Quoted 5 lines
Quoted 2 lines
(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.
So, no PALM/TOOL support is in place
Quoted 127 lines
Quoted 127 lines
Quoted 81 lines
Quoted 81 lines
Quoted 81 lines
Quoted 81 lines
drivers/input/misc/xen-kbdfront.c +40 -0
+ 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);
drivers/input/misc/xen-kbdfront.c +17 -2
@@ -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;
+
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 296
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+        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
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 302
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+        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"
Quoted 7 lines
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.
Quoted 3 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 11 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 312
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+        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
Quoted 3 lines
        input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
and drop all __set_bit()s.
done, thank you
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+        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);
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 330
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -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.
Quoted 7 lines
Quoted 5 lines
done
Quoted 3 lines
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?
Quoted 100 lines
Thanks.
Quoted 97 lines
Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
drivers/input/misc/xen-kbdfront.c +17 -0
+
+        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)
Quoted 9 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+        input_unregister_device(info->mtouch);
      free_page((unsigned long)info->page);
      kfree(info);
      return 0;
Signature · 1 line
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 <[email protected]>
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 <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
  1 file changed, 10 insertions(+), 11 deletions(-)
drivers/input/misc/xen-kbdfront.c +2 -7
index 8266ef948a06..273d786a19cd 100644
@@ -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);
drivers/input/misc/xen-kbdfront.c +7 -0
@@ -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;
Quoted 9 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +1 -1
+        }
  -        mtouch_size[KPARAM_MT_X] = width;
-        mtouch_size[KPARAM_MT_Y] = height;
          info->mtouch_cur_contact_id = -1;
            ret = input_register_device(mtouch);
Signature · 1 line
2.7.4

Quoted 2 lines

Thank you,
Oleksandr

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Dmitry Torokhov

maintainer

2017-06-07 16:56 UTC #30 lore raw

In reply to Oleksandr Andrushchenko

Quoted 91 lines · Oleksandr Andrushchenko

Hi, Dmitry!
Quoted 88 lines · Dmitry Torokhov
Quoted 87 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 68 lines · Dmitry Torokhov
Quoted 67 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 40 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 37 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
 drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +4 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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,
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 58
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
 	"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
Quoted 15 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 13 lines
drivers/input/misc/xen-kbdfront.c +6 -0
 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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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.

Quoted 6 lines

Quoted 5 lines
Quoted 2 lines
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?

Quoted 4 lines

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.

Quoted 11 lines

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?
Quoted 1 line

Quoted 6 lines

Quoted 4 lines
Quoted 1 line
(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.

Quoted 1 line

So, no PALM/TOOL support is in place

OK, that is fair. The pen support is definitely not a hard requirement. I was just wondering if you considered or have plans for adding that. 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.

Quoted 86 lines

Quoted 77 lines

drivers/input/misc/xen-kbdfront.c +56 -2

+				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;

Quoted 8 lines

Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 295
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+
+		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?

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
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.

Quoted 82 lines

Quoted 34 lines
Quoted 34 lines
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 301
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"
Quoted 7 lines
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.
Quoted 3 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 11 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 311
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+		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
Quoted 3 lines
		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
and drop all __set_bit()s.
done, thank you
Quoted 23 lines
Quoted 23 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
drivers/input/misc/xen-kbdfront.c +11 -0
+
+		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,
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 329
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+				     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
Quoted 3 lines
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.

Quoted 7 lines

Quoted 3 lines
Quoted 1 line
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?

Thanks.

Quoted 106 lines

Quoted 95 lines

Thanks.

Quoted 92 lines

Quoted 24 lines

drivers/input/misc/xen-kbdfront.c +17 -0

+
+		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)

Quoted 9 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+		input_unregister_device(info->mtouch);
 	free_page((unsigned long)info->page);
 	kfree(info);
 	return 0;
Signature · 1 line
2.7.4
Thanks.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
 drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

drivers/input/misc/xen-kbdfront.c +9 -9

index 8266ef948a06..273d786a19cd 100644
@@ -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;

Quoted 9 lines

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c +1 -2

+		}
-		mtouch_size[KPARAM_MT_X] = width;
-		mtouch_size[KPARAM_MT_Y] = height;
 		info->mtouch_cur_contact_id = -1;
 		ret = input_register_device(mtouch);

Signature · 1 line

2.7.4

Thank you,
Oleksandr

Signature · 1 line

Dmitry

Oleksandr Andrushchenko

author

2017-06-08 06:45 UTC #31 lore raw

Hi, Dmitry!

Quoted 92 lines · Dmitry Torokhov

Quoted 91 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 88 lines · Dmitry Torokhov
Quoted 87 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 68 lines · Dmitry Torokhov
Quoted 67 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 40 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 37 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +4 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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,
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 58
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
  	"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
Quoted 15 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 13 lines
drivers/input/misc/xen-kbdfront.c +6 -0
  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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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.

Quoted 8 lines

Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
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

Quoted 6 lines

Quoted 3 lines
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

Quoted 10 lines

Quoted 10 lines
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?

Quoted 8 lines

Quoted 6 lines
Quoted 4 lines
Quoted 1 line
(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

Quoted 2 lines

Quoted 1 line
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?

Quoted 1 line

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

Quoted 4 lines

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

Quoted 86 lines

Quoted 77 lines

drivers/input/misc/xen-kbdfront.c +56 -2

+				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;

Quoted 8 lines

Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 295
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+
+		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?

Quoted 6 lines

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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

Quoted 83 lines

Quoted 83 lines
Quoted 34 lines
Quoted 34 lines
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 301
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"
Quoted 7 lines
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.
Quoted 3 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 11 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 311
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+		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
Quoted 3 lines
		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
and drop all __set_bit()s.
done, thank you
Quoted 24 lines
Quoted 24 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
drivers/input/misc/xen-kbdfront.c +11 -0
+
+		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,
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 329
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+				     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
Quoted 3 lines
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

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
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

Quoted 106 lines

Thanks.

Quoted 104 lines

Quoted 94 lines

Thanks.

Quoted 92 lines

Quoted 24 lines

drivers/input/misc/xen-kbdfront.c +17 -0

+
+		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)

Quoted 9 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+		input_unregister_device(info->mtouch);
  	free_page((unsigned long)info->page);
  	kfree(info);
  	return 0;
Signature · 1 line
2.7.4
Thanks.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
  drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
  1 file changed, 10 insertions(+), 11 deletions(-)

drivers/input/misc/xen-kbdfront.c +9 -9

index 8266ef948a06..273d786a19cd 100644
@@ -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;

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c +1 -2

+		}
-		mtouch_size[KPARAM_MT_X] = width;
-		mtouch_size[KPARAM_MT_Y] = height;
  		info->mtouch_cur_contact_id = -1;
  		ret = input_register_device(mtouch);

Signature · 1 line

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

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?)

Thank you,
Oleksandr

Oleksandr Andrushchenko

author

2017-06-19 10:00 UTC #32 lore raw

Ping

Quoted 475 lines · Oleksandr Andrushchenko

Hi, Dmitry!
Quoted 98 lines · Dmitry Torokhov
Quoted 97 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 94 lines · Dmitry Torokhov
Quoted 93 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 74 lines · Dmitry Torokhov
Quoted 73 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 44 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 41 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 142 
+++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +5 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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 };
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 61
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +5 -0
+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
Quoted 17 lines
Quoted 5 lines
drivers/input/misc/xen-kbdfront.c +0 -0
  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 *);
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, · line 119
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +6 -0
@@ -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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, · line 127
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+ 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.
Quoted 8 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
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
Quoted 6 lines
Quoted 3 lines
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
Quoted 10 lines
Quoted 10 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
(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
Quoted 2 lines
Quoted 1 line
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?
Quoted 1 line
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
Quoted 4 lines
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
Quoted 89 lines
Quoted 89 lines
Quoted 89 lines
Quoted 89 lines
Quoted 89 lines
Quoted 80 lines
Quoted 80 lines
Quoted 80 lines
drivers/input/misc/xen-kbdfront.c +40 -0
+ 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);
drivers/input/misc/xen-kbdfront.c +16 -2
@@ -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;
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 296
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+
+        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?
Quoted 6 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 83 lines
Quoted 83 lines
Quoted 34 lines
Quoted 34 lines
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 302
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+        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"
Quoted 7 lines
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.
Quoted 3 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 11 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 312
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+        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
Quoted 3 lines
        input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
and drop all __set_bit()s.
done, thank you
Quoted 24 lines
Quoted 24 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
drivers/input/misc/xen-kbdfront.c +11 -0
+
+        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,
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 330
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+                     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
Quoted 3 lines
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
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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
Quoted 113 lines
Thanks.
Quoted 111 lines
Quoted 101 lines
Thanks.
Quoted 99 lines
Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
drivers/input/misc/xen-kbdfront.c +17 -0
+
+        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)
Quoted 9 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+        input_unregister_device(info->mtouch);
      free_page((unsigned long)info->page);
      kfree(info);
      return 0;
Signature · 1 line
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 <[email protected]>
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 <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
  1 file changed, 10 insertions(+), 11 deletions(-)
drivers/input/misc/xen-kbdfront.c +0 -6
index 8266ef948a06..273d786a19cd 100644
@@ -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 *);
drivers/input/misc/xen-kbdfront.c +2 -2
@@ -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);
drivers/input/misc/xen-kbdfront.c +7 -1
@@ -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;
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +1 -2
+        }
-        mtouch_size[KPARAM_MT_X] = width;
-        mtouch_size[KPARAM_MT_Y] = height;
          info->mtouch_cur_contact_id = -1;
          ret = input_register_device(mtouch);
Signature · 1 line
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
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?)
Thank you,
Oleksandr

Oleksandr Andrushchenko

author

2017-06-19 10:00 UTC #33 lore raw

In reply to Oleksandr Andrushchenko

Ping

Quoted 469 lines · Oleksandr Andrushchenko

Hi, Dmitry!
Quoted 98 lines · Dmitry Torokhov
Quoted 97 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 94 lines · Dmitry Torokhov
Quoted 93 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 74 lines · Dmitry Torokhov
Quoted 73 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 44 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 41 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 142 
+++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +5 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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 };
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 61
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +5 -0
+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
Quoted 17 lines
Quoted 5 lines
drivers/input/misc/xen-kbdfront.c +0 -0
  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 *);
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, · line 119
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +6 -0
@@ -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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, · line 127
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+ 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.
Quoted 8 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
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
Quoted 6 lines
Quoted 3 lines
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
Quoted 10 lines
Quoted 10 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
(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
Quoted 2 lines
Quoted 1 line
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?
Quoted 1 line
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
Quoted 4 lines
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
Quoted 89 lines
Quoted 89 lines
Quoted 89 lines
Quoted 89 lines
Quoted 89 lines
Quoted 80 lines
Quoted 80 lines
Quoted 80 lines
drivers/input/misc/xen-kbdfront.c +40 -0
+ 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);
drivers/input/misc/xen-kbdfront.c +16 -2
@@ -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;
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 296
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+
+        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?
Quoted 6 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 83 lines
Quoted 83 lines
Quoted 34 lines
Quoted 34 lines
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 302
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+        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"
Quoted 7 lines
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.
Quoted 3 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 11 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 312
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+        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
Quoted 3 lines
        input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
and drop all __set_bit()s.
done, thank you
Quoted 24 lines
Quoted 24 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
drivers/input/misc/xen-kbdfront.c +11 -0
+
+        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,
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct · line 330
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+                     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
Quoted 3 lines
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
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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
Quoted 113 lines
Thanks.
Quoted 111 lines
Quoted 101 lines
Thanks.
Quoted 99 lines
Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
drivers/input/misc/xen-kbdfront.c +17 -0
+
+        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)
Quoted 9 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+        input_unregister_device(info->mtouch);
      free_page((unsigned long)info->page);
      kfree(info);
      return 0;
Signature · 1 line
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 <[email protected]>
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 <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
  1 file changed, 10 insertions(+), 11 deletions(-)
drivers/input/misc/xen-kbdfront.c +0 -6
index 8266ef948a06..273d786a19cd 100644
@@ -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 *);
drivers/input/misc/xen-kbdfront.c +2 -2
@@ -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);
drivers/input/misc/xen-kbdfront.c +7 -1
@@ -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;
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +1 -2
+        }
-        mtouch_size[KPARAM_MT_X] = width;
-        mtouch_size[KPARAM_MT_Y] = height;
          info->mtouch_cur_contact_id = -1;
          ret = input_register_device(mtouch);
Signature · 1 line
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

Quoted 6 lines

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?)
Thank you,
Oleksandr

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Dmitry Torokhov

maintainer

2017-06-21 07:24 UTC #34 lore raw

In reply to Oleksandr Andrushchenko

Quoted 143 lines · Oleksandr Andrushchenko

Hi, Dmitry!
Quoted 92 lines · Dmitry Torokhov
Quoted 91 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 88 lines · Dmitry Torokhov
Quoted 87 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 68 lines · Dmitry Torokhov
Quoted 67 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 40 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 37 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
 drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +4 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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,
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 58
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
 	"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
Quoted 15 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 13 lines
drivers/input/misc/xen-kbdfront.c +6 -0
 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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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.
Quoted 8 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
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
Quoted 6 lines
Quoted 3 lines
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
Quoted 10 lines
Quoted 10 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
(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
Quoted 2 lines
Quoted 1 line
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?
Quoted 1 line
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

Quoted 7 lines

Quoted 4 lines
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.

Quoted 90 lines

Quoted 78 lines

drivers/input/misc/xen-kbdfront.c +57 -2

+				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;
+

Quoted 8 lines

Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 295
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+		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?

Quoted 8 lines

Quoted 2 lines
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.

Quoted 199 lines

Quoted 83 lines
Quoted 83 lines
Quoted 34 lines
Quoted 34 lines
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 301
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"
Quoted 7 lines
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.
Quoted 3 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 11 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 311
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+		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
Quoted 3 lines
		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
and drop all __set_bit()s.
done, thank you
Quoted 24 lines
Quoted 24 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
drivers/input/misc/xen-kbdfront.c +11 -0
+
+		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,
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 329
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+				     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
Quoted 3 lines
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
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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
Quoted 106 lines
Thanks.
Quoted 104 lines
Quoted 94 lines
Thanks.
Quoted 92 lines
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
drivers/input/misc/xen-kbdfront.c +17 -0
+
+		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)
Quoted 9 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+		input_unregister_device(info->mtouch);
 	free_page((unsigned long)info->page);
 	kfree(info);
 	return 0;
Signature · 1 line
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 <[email protected]>
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 <[email protected]>
---
 drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)
drivers/input/misc/xen-kbdfront.c +9 -9
index 8266ef948a06..273d786a19cd 100644
@@ -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;
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +1 -2
+		}
-		mtouch_size[KPARAM_MT_X] = width;
-		mtouch_size[KPARAM_MT_Y] = height;
 		info->mtouch_cur_contact_id = -1;
 		ret = input_register_device(mtouch);
Signature · 1 line
2.7.4
Thank you,
Oleksandr

Quoted 5 lines

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.

Quoted 4 lines

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.

Signature · 1 line

Dmitry

Oleksandr Andrushchenko

author

2017-06-21 08:54 UTC #35 lore raw

Hi, Dmitry!

Quoted 453 lines · Dmitry Torokhov

Quoted 143 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 92 lines · Dmitry Torokhov
Quoted 91 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 88 lines · Dmitry Torokhov
Quoted 87 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 68 lines · Dmitry Torokhov
Quoted 67 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 40 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 37 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +4 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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,
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 58
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
  	"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
Quoted 15 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 13 lines
drivers/input/misc/xen-kbdfront.c +6 -0
  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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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.
Quoted 8 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
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
Quoted 6 lines
Quoted 3 lines
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
Quoted 10 lines
Quoted 10 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
(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
Quoted 2 lines
Quoted 1 line
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?
Quoted 1 line
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
Quoted 7 lines
Quoted 4 lines
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.
Quoted 90 lines
Quoted 90 lines
Quoted 90 lines
Quoted 90 lines
Quoted 90 lines
Quoted 78 lines
Quoted 78 lines
Quoted 78 lines
Quoted 78 lines
drivers/input/misc/xen-kbdfront.c +57 -2
+				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;
+
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 295
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+		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
Quoted 8 lines
Quoted 2 lines
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.
Quoted 199 lines
Quoted 83 lines
Quoted 83 lines
Quoted 34 lines
Quoted 34 lines
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 301
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"
Quoted 7 lines
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.
Quoted 3 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 11 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 311
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+		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
Quoted 3 lines
		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
and drop all __set_bit()s.
done, thank you
Quoted 24 lines
Quoted 24 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
drivers/input/misc/xen-kbdfront.c +11 -0
+
+		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,
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 329
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+				     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
Quoted 3 lines
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
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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
Quoted 106 lines
Thanks.
Quoted 104 lines
Quoted 94 lines
Thanks.
Quoted 92 lines
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
drivers/input/misc/xen-kbdfront.c +17 -0
+
+		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)
Quoted 9 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+		input_unregister_device(info->mtouch);
  	free_page((unsigned long)info->page);
  	kfree(info);
  	return 0;
Signature · 1 line
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 <[email protected]>
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 <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
  1 file changed, 10 insertions(+), 11 deletions(-)
drivers/input/misc/xen-kbdfront.c +9 -9
index 8266ef948a06..273d786a19cd 100644
@@ -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;
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +1 -2
+		}
-		mtouch_size[KPARAM_MT_X] = width;
-		mtouch_size[KPARAM_MT_Y] = height;
  		info->mtouch_cur_contact_id = -1;
  		ret = input_register_device(mtouch);
Signature · 1 line
2.7.4
Thank you,
Oleksandr

Quoted 6 lines

Quoted 5 lines
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

Quoted 6 lines

Quoted 4 lines
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

Quoted 2 lines

Thanks.

Oleksandr Andrushchenko

author

2017-06-21 08:54 UTC #36 lore raw

In reply to Dmitry Torokhov

Hi, Dmitry!

Quoted 453 lines · Dmitry Torokhov

Quoted 143 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 92 lines · Dmitry Torokhov
Quoted 91 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 88 lines · Dmitry Torokhov
Quoted 87 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 68 lines · Dmitry Torokhov
Quoted 67 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 40 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 37 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +4 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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,
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 58
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
  	"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
Quoted 15 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 13 lines
drivers/input/misc/xen-kbdfront.c +6 -0
  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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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.
Quoted 8 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
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
Quoted 6 lines
Quoted 3 lines
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
Quoted 10 lines
Quoted 10 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
(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
Quoted 2 lines
Quoted 1 line
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?
Quoted 1 line
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
Quoted 7 lines
Quoted 4 lines
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.
Quoted 90 lines
Quoted 90 lines
Quoted 90 lines
Quoted 90 lines
Quoted 90 lines
Quoted 78 lines
Quoted 78 lines
Quoted 78 lines
Quoted 78 lines
drivers/input/misc/xen-kbdfront.c +57 -2
+				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;
+
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 295
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+		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
Quoted 8 lines
Quoted 2 lines
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.
Quoted 199 lines
Quoted 83 lines
Quoted 83 lines
Quoted 34 lines
Quoted 34 lines
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 301
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"
Quoted 7 lines
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.
Quoted 3 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 11 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 311
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+		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
Quoted 3 lines
		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
and drop all __set_bit()s.
done, thank you
Quoted 24 lines
Quoted 24 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
drivers/input/misc/xen-kbdfront.c +11 -0
+
+		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,
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 329
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+				     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
Quoted 3 lines
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
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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
Quoted 106 lines
Thanks.
Quoted 104 lines
Quoted 94 lines
Thanks.
Quoted 92 lines
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
drivers/input/misc/xen-kbdfront.c +17 -0
+
+		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)
Quoted 9 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+		input_unregister_device(info->mtouch);
  	free_page((unsigned long)info->page);
  	kfree(info);
  	return 0;
Signature · 1 line
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 <[email protected]>
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 <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
  1 file changed, 10 insertions(+), 11 deletions(-)
drivers/input/misc/xen-kbdfront.c +9 -9
index 8266ef948a06..273d786a19cd 100644
@@ -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;
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +1 -2
+		}
-		mtouch_size[KPARAM_MT_X] = width;
-		mtouch_size[KPARAM_MT_Y] = height;
  		info->mtouch_cur_contact_id = -1;
  		ret = input_register_device(mtouch);
Signature · 1 line
2.7.4
Thank you,
Oleksandr

Quoted 6 lines

Quoted 5 lines
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

Quoted 6 lines

Quoted 4 lines
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

Quoted 2 lines

Thanks.

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Dmitry Torokhov

maintainer

2017-06-21 07:24 UTC #37 lore raw

In reply to Oleksandr Andrushchenko

Quoted 143 lines · Oleksandr Andrushchenko

Hi, Dmitry!
Quoted 92 lines · Dmitry Torokhov
Quoted 91 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 88 lines · Dmitry Torokhov
Quoted 87 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 68 lines · Dmitry Torokhov
Quoted 67 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 40 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 37 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
 drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +4 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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,
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 58
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
 	"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
Quoted 15 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 13 lines
drivers/input/misc/xen-kbdfront.c +6 -0
 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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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.
Quoted 8 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
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
Quoted 6 lines
Quoted 3 lines
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
Quoted 10 lines
Quoted 10 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
(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
Quoted 2 lines
Quoted 1 line
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?
Quoted 1 line
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

Quoted 7 lines

Quoted 4 lines
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.

Quoted 90 lines

Quoted 78 lines

drivers/input/misc/xen-kbdfront.c +57 -2

+				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;
+

Quoted 8 lines

Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 295
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+		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?

Quoted 8 lines

Quoted 2 lines
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.

Quoted 199 lines

Quoted 83 lines
Quoted 83 lines
Quoted 34 lines
Quoted 34 lines
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 301
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"
Quoted 7 lines
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.
Quoted 3 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 11 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 311
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+		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
Quoted 3 lines
		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
and drop all __set_bit()s.
done, thank you
Quoted 24 lines
Quoted 24 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
drivers/input/misc/xen-kbdfront.c +11 -0
+
+		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,
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 329
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+				     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
Quoted 3 lines
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
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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
Quoted 106 lines
Thanks.
Quoted 104 lines
Quoted 94 lines
Thanks.
Quoted 92 lines
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
drivers/input/misc/xen-kbdfront.c +17 -0
+
+		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)
Quoted 9 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+		input_unregister_device(info->mtouch);
 	free_page((unsigned long)info->page);
 	kfree(info);
 	return 0;
Signature · 1 line
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 <[email protected]>
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 <[email protected]>
---
 drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)
drivers/input/misc/xen-kbdfront.c +9 -9
index 8266ef948a06..273d786a19cd 100644
@@ -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;
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +1 -2
+		}
-		mtouch_size[KPARAM_MT_X] = width;
-		mtouch_size[KPARAM_MT_Y] = height;
 		info->mtouch_cur_contact_id = -1;
 		ret = input_register_device(mtouch);
Signature · 1 line
2.7.4
Thank you,
Oleksandr

Quoted 5 lines

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.

Quoted 4 lines

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.

Signature · 6 lines

Dmitry

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Oleksandr Andrushchenko

author

2017-06-08 06:45 UTC #38 lore raw

In reply to Dmitry Torokhov

Hi, Dmitry!

Quoted 92 lines · Dmitry Torokhov

Quoted 91 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 88 lines · Dmitry Torokhov
Quoted 87 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 68 lines · Dmitry Torokhov
Quoted 67 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 40 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 37 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +4 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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,
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 58
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
  	"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
Quoted 15 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 13 lines
drivers/input/misc/xen-kbdfront.c +6 -0
  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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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.

Quoted 8 lines

Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
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

Quoted 6 lines

Quoted 3 lines
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.

Quoted 10 lines

Quoted 10 lines
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?

Quoted 8 lines

Quoted 6 lines
Quoted 4 lines
Quoted 1 line
(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

Quoted 2 lines

Quoted 1 line
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?

Quoted 1 line

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

Quoted 4 lines

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

Quoted 86 lines

Quoted 77 lines

drivers/input/misc/xen-kbdfront.c +56 -2

+				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;

Quoted 8 lines

Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 295
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+
+		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?

Quoted 6 lines

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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.

Quoted 83 lines

Quoted 83 lines
Quoted 34 lines
Quoted 34 lines
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 301
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"
Quoted 7 lines
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.
Quoted 3 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 11 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 311
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+		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
Quoted 3 lines
		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
and drop all __set_bit()s.
done, thank you
Quoted 24 lines
Quoted 24 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
drivers/input/misc/xen-kbdfront.c +11 -0
+
+		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,
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 329
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+				     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
Quoted 3 lines
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

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
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

Quoted 106 lines

Thanks.

Quoted 104 lines

Quoted 94 lines

Thanks.

Quoted 92 lines

Quoted 24 lines

drivers/input/misc/xen-kbdfront.c +17 -0

+
+		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)

Quoted 9 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+		input_unregister_device(info->mtouch);
  	free_page((unsigned long)info->page);
  	kfree(info);
  	return 0;
Signature · 1 line
2.7.4
Thanks.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
  drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
  1 file changed, 10 insertions(+), 11 deletions(-)

drivers/input/misc/xen-kbdfront.c +9 -9

index 8266ef948a06..273d786a19cd 100644
@@ -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;

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c +1 -2

+		}
-		mtouch_size[KPARAM_MT_X] = width;
-		mtouch_size[KPARAM_MT_Y] = height;
  		info->mtouch_cur_contact_id = -1;
  		ret = input_register_device(mtouch);

Signature · 1 line

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

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?)

Thank you,
Oleksandr

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Dmitry Torokhov

maintainer

2017-06-07 16:56 UTC #39 lore raw

In reply to Oleksandr Andrushchenko

Quoted 91 lines · Oleksandr Andrushchenko

Hi, Dmitry!
Quoted 88 lines · Dmitry Torokhov
Quoted 87 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 68 lines · Dmitry Torokhov
Quoted 67 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 40 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 37 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
 drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +4 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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,
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 58
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
 	"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
Quoted 15 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 13 lines
drivers/input/misc/xen-kbdfront.c +6 -0
 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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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.

Quoted 6 lines

Quoted 5 lines
Quoted 2 lines
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?

Quoted 4 lines

Besides, that, if I am about to implement pen support (which I still not convinced we really need), how will I do that?

Quoted 11 lines

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?
Quoted 1 line

Quoted 6 lines

Quoted 4 lines
Quoted 1 line
(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.

Quoted 1 line

So, no PALM/TOOL support is in place

Quoted 86 lines

Quoted 77 lines

drivers/input/misc/xen-kbdfront.c +56 -2

+				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;

Quoted 8 lines

Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 295
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+
+		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?

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
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.

Quoted 82 lines

Quoted 34 lines
Quoted 34 lines
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 301
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"
Quoted 7 lines
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.
Quoted 3 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 11 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 311
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+		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
Quoted 3 lines
		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
and drop all __set_bit()s.
done, thank you
Quoted 23 lines
Quoted 23 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
drivers/input/misc/xen-kbdfront.c +11 -0
+
+		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,
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 329
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+				     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
Quoted 3 lines
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.

Quoted 7 lines

Quoted 3 lines
Quoted 1 line
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?

Thanks.

Quoted 106 lines

Quoted 95 lines

Thanks.

Quoted 92 lines

Quoted 24 lines

drivers/input/misc/xen-kbdfront.c +17 -0

+
+		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)

Quoted 9 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+		input_unregister_device(info->mtouch);
 	free_page((unsigned long)info->page);
 	kfree(info);
 	return 0;
Signature · 1 line
2.7.4
Thanks.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
 drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

drivers/input/misc/xen-kbdfront.c +9 -9

index 8266ef948a06..273d786a19cd 100644
@@ -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;

Quoted 9 lines

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c +1 -2

+		}
-		mtouch_size[KPARAM_MT_X] = width;
-		mtouch_size[KPARAM_MT_Y] = height;
 		info->mtouch_cur_contact_id = -1;
 		ret = input_register_device(mtouch);

Signature · 1 line

2.7.4

Thank you,
Oleksandr

Signature · 6 lines

Dmitry

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Oleksandr Andrushchenko

author

2017-05-31 09:07 UTC #40 lore raw

In reply to Dmitry Torokhov

Hi, Dmitry!

Quoted 88 lines · Dmitry Torokhov

Quoted 87 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 68 lines · Dmitry Torokhov
Quoted 67 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 40 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 37 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +4 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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,
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 58
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
  	"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
Quoted 15 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 13 lines
drivers/input/misc/xen-kbdfront.c +6 -0
  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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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.

Quoted 5 lines

Quoted 2 lines
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

Quoted 5 lines

Quoted 2 lines
(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.
So, no PALM/TOOL support is in place

Quoted 124 lines

Quoted 124 lines
Quoted 78 lines
Quoted 78 lines
Quoted 78 lines
Quoted 78 lines
drivers/input/misc/xen-kbdfront.c +57 -2
+				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;
+
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 295
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+		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
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 301
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"
Quoted 7 lines
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.
Quoted 3 lines
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?

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
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

Quoted 11 lines

Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 311
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+		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

Quoted 3 lines

		input_set_capability(mtouch, EV_KEY, BTN_TOUCH);
and drop all __set_bit()s.

done, thank you

Quoted 19 lines

Quoted 10 lines

drivers/input/misc/xen-kbdfront.c +10 -0

+
+		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);

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 329

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c +8 -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.

Quoted 7 lines

Quoted 5 lines
done
Quoted 3 lines
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?

Quoted 99 lines

Thanks.

Quoted 96 lines

Quoted 24 lines

drivers/input/misc/xen-kbdfront.c +17 -0

+
+		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)

Quoted 9 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+		input_unregister_device(info->mtouch);
  	free_page((unsigned long)info->page);
  	kfree(info);
  	return 0;
Signature · 1 line
2.7.4
Thanks.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
  drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
  1 file changed, 10 insertions(+), 11 deletions(-)

drivers/input/misc/xen-kbdfront.c +10 -9

index 8266ef948a06..273d786a19cd 100644
@@ -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;
+		}

Quoted 9 lines

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c +0 -2

-		mtouch_size[KPARAM_MT_X] = width;
-		mtouch_size[KPARAM_MT_Y] = height;
  		info->mtouch_cur_contact_id = -1;
 
  		ret = input_register_device(mtouch);

Signature · 1 line

2.7.4

Thank you,
Oleksandr

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Dmitry Torokhov

maintainer

2017-05-30 16:37 UTC #41 lore raw

In reply to Oleksandr Andrushchenko

Quoted 87 lines · Oleksandr Andrushchenko

Hi, Dmitry!
Quoted 68 lines · Dmitry Torokhov
Quoted 67 lines · Oleksandr Andrushchenko
Hi, Dmitry!
Quoted 40 lines · Dmitry Torokhov
Hi Oleksandr,
Quoted 37 lines · Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <[email protected]>
Extend xen_kbdfront to provide multi-touch support to unprivileged domains.
Signed-off-by Oleksandr Andrushchenko <[email protected]>
---
 drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 140 insertions(+), 2 deletions(-)
drivers/input/misc/xen-kbdfront.c +4 -0
index 01c27b4c3288..e5d064aaa237 100644
@@ -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,
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 58
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
 	"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
Quoted 15 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118
Quoted 13 lines
drivers/input/misc/xen-kbdfront.c +6 -0
 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?
Quoted 6 lines
Quoted 3 lines
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"
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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.

Quoted 2 lines

I think that for multi-touch MT_TOOL_FINGER is enough any reason we would also want MT_TOOL_PEN here?

Quoted 1 line

(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.

Quoted 124 lines

Quoted 78 lines
Quoted 78 lines
Quoted 78 lines
Quoted 78 lines
drivers/input/misc/xen-kbdfront.c +57 -2
+				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;
+
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 295
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+		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
Quoted 34 lines
Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 301
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"
Quoted 7 lines
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.
Quoted 3 lines
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?

Quoted 6 lines

Quoted 3 lines
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).

Quoted 10 lines

Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 311
Quoted 10 lines
drivers/input/misc/xen-kbdfront.c +10 -0
+
+		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.

Quoted 19 lines

Quoted 11 lines

drivers/input/misc/xen-kbdfront.c +11 -0

+
+		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,

Quoted 8 lines

Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 329
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+				     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.

Quoted 5 lines

done
Quoted 3 lines
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?

Thanks.

Quoted 107 lines

Quoted 25 lines

drivers/input/misc/xen-kbdfront.c +18 -0

+
+		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);

Quoted 9 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +0 -0
 	free_page((unsigned long)info->page);
 	kfree(info);
 	return 0;
Signature · 1 line
2.7.4
Thanks.

Thank you,
Oleksandr

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
 drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

drivers/input/misc/xen-kbdfront.c +10 ~~-11~~

index 8266ef948a06..273d786a19cd 100644
@@ -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);

Signature · 1 line

2.7.4

Signature · 6 lines

Dmitry

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Oleksandr Andrushchenko

author

2017-05-30 12:50 UTC #42 lore raw

In reply to Dmitry Torokhov

Hi, Dmitry!

Quoted 68 lines · Dmitry Torokhov

Quoted 67 lines · Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 40 lines · Dmitry Torokhov

Hi Oleksandr,

Quoted 37 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +4 -0

index 01c27b4c3288..e5d064aaa237 100644
@@ -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,

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 58
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
  	"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

Quoted 15 lines

drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118

Quoted 13 lines

drivers/input/misc/xen-kbdfront.c +6 -0

  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?

Quoted 6 lines

Quoted 3 lines
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"

Quoted 9 lines

Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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)

Quoted 78 lines

drivers/input/misc/xen-kbdfront.c +57 -2

+				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;
+

Quoted 8 lines

Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 295
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+		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?

Quoted 29 lines

Quoted 22 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 301
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"
Quoted 7 lines
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)

Quoted 8 lines

I see.
Quoted 3 lines
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)

Quoted 21 lines

drivers/input/misc/xen-kbdfront.c +21 -0

+
+		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,

Quoted 8 lines

Quoted 7 lines
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 329
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+				     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

Quoted 3 lines

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

Quoted 25 lines

drivers/input/misc/xen-kbdfront.c +18 -0

+
+		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);

Quoted 9 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +0 -0
  	free_page((unsigned long)info->page);
  	kfree(info);
  	return 0;
Signature · 1 line
2.7.4
Thanks.

Thank you,
Oleksandr

Quoted 1 line

From e76506c55846e2bb4ccbafa430642e368643e51d Mon Sep 17 00:00:00 2001

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
 drivers/input/misc/xen-kbdfront.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

drivers/input/misc/xen-kbdfront.c +10 ~~-11~~

index 8266ef948a06..273d786a19cd 100644
@@ -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);

Signature · 1 line

2.7.4

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Dmitry Torokhov

maintainer

2017-05-30 05:51 UTC #43 lore raw

In reply to Oleksandr Andrushchenko

Quoted 68 lines · Oleksandr Andrushchenko

Hi, Dmitry!

Quoted 40 lines · Dmitry Torokhov

Hi Oleksandr,

Quoted 37 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
 drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +4 -0

index 01c27b4c3288..e5d064aaa237 100644
@@ -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,

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 59
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +6 -0
 	"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

Quoted 16 lines

Quoted 5 lines

drivers/input/misc/xen-kbdfront.c +0 -0

 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 *);

drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118

Quoted 9 lines

drivers/input/misc/xen-kbdfront.c +6 -0

@@ -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?

Quoted 3 lines

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.

Quoted 8 lines

Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 126
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+				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.

Quoted 77 lines

drivers/input/misc/xen-kbdfront.c +56 -2

+				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;

Quoted 8 lines

Quoted 8 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 296
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +8 -0
+
+		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?

Quoted 22 lines

Quoted 7 lines
drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 302
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+		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"

Quoted 7 lines

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.

Quoted 4 lines

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

Quoted 20 lines

drivers/input/misc/xen-kbdfront.c +20 -0

+
+		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);

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 330

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c +8 -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. 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.

Quoted 23 lines

drivers/input/misc/xen-kbdfront.c +16 -0

+
+		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);

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
drivers/input/misc/xen-kbdfront.c +2 -0
+	if (info->mtouch)
+		input_unregister_device(info->mtouch);
 	free_page((unsigned long)info->page);
 	kfree(info);
 	return 0;
Signature · 1 line
2.7.4

Thanks.

Signature · 6 lines

Dmitry

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Oleksandr Andrushchenko

author

2017-04-21 06:40 UTC #44 lore raw

In reply to Dmitry Torokhov

Hi, Dmitry!

Quoted 44 lines · Dmitry Torokhov

Hi Oleksandr,

Quoted 41 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
  drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
  1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +4 -0

index 01c27b4c3288..e5d064aaa237 100644
@@ -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)");

Quoted 7 lines

drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 59
Quoted 6 lines
drivers/input/misc/xen-kbdfront.c +6 -0
+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

Quoted 16 lines

Quoted 5 lines

drivers/input/misc/xen-kbdfront.c +0 -0

  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 *);

drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118

Quoted 9 lines

drivers/input/misc/xen-kbdfront.c +6 -0

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

Quoted 95 lines

drivers/input/misc/xen-kbdfront.c +71 -2

+				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);
+				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,

Quoted 8 lines

drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 302
Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +7 -0
+						1);
+		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"

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?

Quoted 52 lines

drivers/input/misc/xen-kbdfront.c +45 -0

+
+		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);
+
+		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)

Quoted 8 lines

Quoted 7 lines
drivers/input/misc/xen-kbdfront.c +1 -0
+		input_unregister_device(info->mtouch);
  	free_page((unsigned long)info->page);
  	kfree(info);
  	return 0;
Signature · 1 line
2.7.4
Thanks.

Thank you,
Oleksandr
[1] https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.12&id=e27c533dc4d0338266ccb6dab428150d4d629e6a

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Dmitry Torokhov

maintainer

2017-04-21 02:10 UTC #45 lore raw

In reply to Oleksandr Andrushchenko

Hi Oleksandr,

Quoted 38 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
 drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +4 -0

index 01c27b4c3288..e5d064aaa237 100644
@@ -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 };

drivers/input/misc/xen-kbdfront.c module_param_array(ptr_size, int, NULL, 0444); · line 59

Quoted 9 lines

drivers/input/misc/xen-kbdfront.c +6 -0

@@ -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?

drivers/input/misc/xen-kbdfront.c static irqreturn_t input_handler(int rq, void *dev_id) · line 118

Quoted 13 lines

drivers/input/misc/xen-kbdfront.c +6 -0

 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?

Quoted 92 lines

drivers/input/misc/xen-kbdfront.c +68 -2

+				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);
+				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;

drivers/input/misc/xen-kbdfront.c static int xenkbd_probe(struct xenbus_device *dev, · line 302

Quoted 10 lines

drivers/input/misc/xen-kbdfront.c +10 -0

+
+		num_cont = xenbus_read_unsigned(info->xbdev->nodename,
+						XENKBD_FIELD_MT_NUM_CONTACTS,
+						1);
+		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...

Quoted 59 lines

drivers/input/misc/xen-kbdfront.c +46 -0

+
+		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);
+
+		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;

Signature · 1 line

2.7.4

Thanks.

Signature · 6 lines

Dmitry

_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel

Oleksandr Andrushchenko

author

2017-04-13 11:38 UTC #46 lore raw

PATCH 2/2 xen/input: add multi-touch support

In reply to Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

Extend xen_kbdfront to provide multi-touch support to unprivileged domains.

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
 drivers/input/misc/xen-kbdfront.c | 142 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 140 insertions(+), 2 deletions(-)

drivers/input/misc/xen-kbdfront.c +140 -2

index 01c27b4c3288..e5d064aaa237 100644
@@ -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)");
+
 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)) {
+				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);
+				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);
+		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);
+
+		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);
+
+		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;

Signature · 7 lines

2.7.4


_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel