[PATCH] input: mt: Introduce MT event slots (rev 3)

[PATCH] input: mt: Introduce MT event slots (rev 3)

[Henrik Rydberg]

With the rapidly increasing number of intelligent multi-contact and
multi-user devices, the need to send digested, filtered information
from a set of different sources within the same device is imminent.
This patch adds the concept of slots to the MT protocol. The slots
enumerate a set of identified sources, such that all MT events
can be passed independently and selectively per identified source.

The protocol works like this: Instead of sending a SYN_MT_REPORT
event immediately after the contact data, one sends a SYN_MT_SLOT
event immediately before the contact data. The input core will only
emit events for the slots corresponding to the contacts that have
changed. It is assumed that the same slot is used for the duration
of an initiated contact.

Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
---
 drivers/input/input.c |   88 +++++++++++++++++++++++++++++++++++++++++-------
 include/linux/input.h |   28 +++++++++++++++
 2 files changed, 103 insertions(+), 13 deletions(-)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index 9c79bd5..2007488 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -34,9 +34,9 @@ MODULE_LICENSE("GPL");
 #define INPUT_DEVICES	256
 
 /*
- * EV_ABS events which should not be cached are listed here.
+ * EV_ABS events which should be filtered on a per-slot basis are listed here.
  */
-static unsigned int input_abs_bypass_init_data[] __initdata = {
+static unsigned int input_mt_abs_map_init_data[] __initdata = {
 	ABS_MT_TOUCH_MAJOR,
 	ABS_MT_TOUCH_MINOR,
 	ABS_MT_WIDTH_MAJOR,
@@ -48,9 +48,8 @@ static unsigned int input_abs_bypass_init_data[] __initdata = {
 	ABS_MT_BLOB_ID,
 	ABS_MT_TRACKING_ID,
 	ABS_MT_PRESSURE,
-	0
 };
-static unsigned long input_abs_bypass[BITS_TO_LONGS(ABS_CNT)];
+static unsigned char input_mt_abs_map[ABS_CNT];
 
 static LIST_HEAD(input_dev_list);
 static LIST_HEAD(input_handler_list);
@@ -181,6 +180,26 @@ static void input_stop_autorepeat(struct input_dev *dev)
 #define INPUT_PASS_TO_DEVICE	2
 #define INPUT_PASS_TO_ALL	(INPUT_PASS_TO_HANDLERS | INPUT_PASS_TO_DEVICE)
 
+static void input_mt_handle_abs_event(struct input_dev *dev,
+				      unsigned int code, int value)
+{
+	if (dev->mt) {
+		struct input_mt_slot *mtslot = &dev->mt[dev->slot];
+		unsigned int mtcode = input_mt_abs_map[code] - 1;
+		int old = mtslot->abs[mtcode];
+		value = input_defuzz_abs_event(value, old, dev->absfuzz[code]);
+		if (value == old)
+			return;
+		mtslot->abs[mtcode] = value;
+	}
+	dev->sync = 0;
+	if (dev->slot != dev->last_slot) {
+		dev->last_slot = dev->slot;
+		input_pass_event(dev, EV_SYN, SYN_MT_SLOT, dev->slot);
+	}
+	input_pass_event(dev, EV_ABS, code, value);
+}
+
 static void input_handle_event(struct input_dev *dev,
 			       unsigned int type, unsigned int code, int value)
 {
@@ -204,6 +223,10 @@ static void input_handle_event(struct input_dev *dev,
 			dev->sync = 0;
 			disposition = INPUT_PASS_TO_HANDLERS;
 			break;
+		case SYN_MT_SLOT:
+			if (value >= 0 && value < dev->mtsize)
+				dev->slot = value;
+			break;
 		}
 		break;
 
@@ -235,9 +258,9 @@ static void input_handle_event(struct input_dev *dev,
 	case EV_ABS:
 		if (is_event_supported(code, dev->absbit, ABS_MAX)) {
 
-			if (test_bit(code, input_abs_bypass)) {
-				disposition = INPUT_PASS_TO_HANDLERS;
-				break;
+			if (input_mt_abs_map[code]) {
+				input_mt_handle_abs_event(dev, code, value);
+				return;
 			}
 
 			value = input_defuzz_abs_event(value,
@@ -1278,6 +1301,7 @@ static void input_dev_release(struct device *device)
 	struct input_dev *dev = to_input_dev(device);
 
 	input_ff_destroy(dev);
+	input_mt_destroy_slots(dev);
 	kfree(dev);
 
 	module_put(THIS_MODULE);
@@ -1518,6 +1542,43 @@ void input_free_device(struct input_dev *dev)
 EXPORT_SYMBOL(input_free_device);
 
 /**
+ * input_mt_create_slots() - create MT input slots
+ * @dev: input device supporting MT events and finger tracking
+ * @max_slots: maximum number of slots supported by the device
+ *
+ * This function allocates all necessary memory for MT slot handling
+ * in the input device.
+ */
+int input_mt_create_slots(struct input_dev *dev, int max_slots)
+{
+	struct input_mt_slot *mt;
+
+	mt = kzalloc(max_slots * sizeof(struct input_mt_slot), GFP_KERNEL);
+	if (!mt)
+		return -ENOMEM;
+
+	dev->mt = mt;
+	dev->mtsize = max_slots;
+	return 0;
+}
+EXPORT_SYMBOL(input_mt_create_slots);
+
+/**
+ * input_mt_destroy_slots() - frees the MT slots of the input device
+ * @dev: input device with allocated MT slots
+ *
+ * This function is only needed in error path as the input core will
+ * automatically free the MT slots when the device is destroyed.
+ */
+void input_mt_destroy_slots(struct input_dev *dev)
+{
+	kfree(dev->mt);
+	dev->mt = NULL;
+	dev->mtsize = 0;
+}
+EXPORT_SYMBOL(input_mt_destroy_slots);
+
+/**
  * input_set_capability - mark device as capable of a certain event
  * @dev: device that is capable of emitting or accepting event
  * @type: type of the event (EV_KEY, EV_REL, etc...)
@@ -1926,19 +1987,20 @@ static const struct file_operations input_fops = {
 	.open = input_open_file,
 };
 
-static void __init input_init_abs_bypass(void)
+static void __init input_mt_init_maps(void)
 {
-	const unsigned int *p;
-
-	for (p = input_abs_bypass_init_data; *p; p++)
-		input_abs_bypass[BIT_WORD(*p)] |= BIT_MASK(*p);
+	int i;
+	BUILD_BUG_ON(MT_ABS_SIZE != (typeof(input_mt_abs_map[0]))MT_ABS_SIZE);
+	BUILD_BUG_ON(ARRAY_SIZE(input_mt_abs_map_init_data) > MT_ABS_SIZE);
+	for (i = 0; i < ARRAY_SIZE(input_mt_abs_map_init_data); i++)
+		input_mt_abs_map[input_mt_abs_map_init_data[i]] = i + 1;
 }
 
 static int __init input_init(void)
 {
 	int err;
 
-	input_init_abs_bypass();
+	input_mt_init_maps();
 
 	err = class_register(&input_class);
 	if (err) {
diff --git a/include/linux/input.h b/include/linux/input.h
index 7ed2251..596ba29 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -108,6 +108,7 @@ struct input_absinfo {
 #define SYN_REPORT		0
 #define SYN_CONFIG		1
 #define SYN_MT_REPORT		2
+#define SYN_MT_SLOT		3
 
 /*
  * Keys and buttons
@@ -1080,6 +1081,10 @@ struct ff_effect {
  * @sync: set to 1 when there were no new events since last EV_SYNC
  * @abs: current values for reports from absolute axes
  * @rep: current values for autorepeat parameters (delay, rate)
+ * @mt: array of MT slots
+ * @mtsize: number of allocated MT slots
+ * @slot: current MT slot
+ * @last_slot: last MT slot reported
  * @key: reflects current state of device's keys/buttons
  * @led: reflects current state of device's LEDs
  * @snd: reflects current state of sound effects
@@ -1157,6 +1162,11 @@ struct input_dev {
 	int abs[ABS_MAX + 1];
 	int rep[REP_MAX + 1];
 
+	struct input_mt_slot *mt;
+	int mtsize;
+	int slot;
+	int last_slot;
+
 	unsigned long key[BITS_TO_LONGS(KEY_CNT)];
 	unsigned long led[BITS_TO_LONGS(LED_CNT)];
 	unsigned long snd[BITS_TO_LONGS(SND_CNT)];
@@ -1405,6 +1415,11 @@ static inline void input_mt_sync(struct input_dev *dev)
 	input_event(dev, EV_SYN, SYN_MT_REPORT, 0);
 }
 
+static inline void input_mt_slot(struct input_dev *dev, int slot)
+{
+	input_event(dev, EV_SYN, SYN_MT_SLOT, slot);
+}
+
 void input_set_capability(struct input_dev *dev, unsigned int type, unsigned int code);
 
 static inline void input_set_abs_params(struct input_dev *dev, int axis, int min, int max, int fuzz, int flat)
@@ -1484,5 +1499,18 @@ int input_ff_erase(struct input_dev *dev, int effect_id, struct file *file);
 int input_ff_create_memless(struct input_dev *dev, void *data,
 		int (*play_effect)(struct input_dev *, void *, struct ff_effect *));
 
+#define MT_ABS_SIZE 11
+
+/**
+ * struct input_mt_slot - represents the state of an input MT slot
+ * @abs: current values of ABS_MT axes for this slot
+ */
+struct input_mt_slot {
+	int abs[MT_ABS_SIZE];
+};
+
+int input_mt_create_slots(struct input_dev *dev, int max_slots);
+void input_mt_destroy_slots(struct input_dev *dev);
+
 #endif
 #endif
-- 
1.6.3.3

[PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Henrik Rydberg]

This patch adds documentation for the SYN_MT_SLOT event and gives
examples of how to use the event slot protocol.

Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
---
 Documentation/input/multi-touch-protocol.txt |  201 ++++++++++++++++++--------
 1 files changed, 137 insertions(+), 64 deletions(-)

diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt
index c0fc1c7..100aec0 100644
--- a/Documentation/input/multi-touch-protocol.txt
+++ b/Documentation/input/multi-touch-protocol.txt
@@ -6,31 +6,143 @@ Multi-touch (MT) Protocol
 Introduction
 ------------
 
-In order to utilize the full power of the new multi-touch devices, a way to
-report detailed finger data to user space is needed. This document
-describes the multi-touch (MT) protocol which allows kernel drivers to
-report details for an arbitrary number of fingers.
+In order to utilize the full power of the new multi-touch and multi-user
+devices, a way to report detailed data from multiple contacts, i.e.,
+objects in direct contact with the device surface, is needed.  This
+document describes the multi-touch (MT) protocol which allows kernel
+drivers to report details for an arbitrary number of contacts.
+
+The protocol is divided into two types, depending on the capabilities of the
+hardware. For devices handling anonymous contacts (type A), the protocol
+describes how to send the raw data for all contacts to the receiver. For
+devices capable of tracking identifiable contacts (type B), the protocol
+describes how to send updates for individual contacts via event slots.
+
+
+Protocol Usage
+--------------
+
+Contact details are sent sequentially as separate packets of ABS_MT
+events. Only the ABS_MT events are recognized as part of a contact
+packet. Since these events are ignored by current single-touch (ST)
+applications, the MT protocol can be implemented on top of the ST protocol
+in an existing driver.
+
+Drivers for type A devices mark the end of a packet by calling the
+input_mt_sync() function, which generates a SYN_MT_REPORT event. This
+instructs the receiver to accept the data for the current contact and
+prepare to receive another. Drivers for type B devices mark the beginning
+of a packet by calling the input_mt_slot() function with a slot as
+argument, which generates a SYN_MT_SLOT event. This instructs the receiver
+to prepare for updates of the given slot.
+
+The end of a multi-touch transfer is marked by calling the usual
+input_sync() function. This instructs the receiver to act upon events
+accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new set
+of events/packets.
 
+The main difference between the raw type A protocol and the higher level
+type B slot protocol lies in the usage of identifiable contacts. The slot
+protocol requires the use of the ABS_MT_TRACKING_ID, either provided by the
+hardware of computed from the raw data [5].
 
-Usage
------
+For type A devices, the kernel driver should generate an arbitrary
+enumeration of the set of anonymous contacts currently on the surface. The
+order in which the packets appear in the event stream is not important.
+Event filtering and finger tracking is left to user space [3].
 
-Anonymous finger details are sent sequentially as separate packets of ABS
-events. Only the ABS_MT events are recognized as part of a finger
-packet. The end of a packet is marked by calling the input_mt_sync()
-function, which generates a SYN_MT_REPORT event. This instructs the
-receiver to accept the data for the current finger and prepare to receive
-another. The end of a multi-touch transfer is marked by calling the usual
-input_sync() function. This instructs the receiver to act upon events
-accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new
-set of events/packets.
+For type B devices, the kernel driver should associate a slot with each
+identified contact, and use that slot to propagate changes for the contact.
+Creation, replacement and destruction of contacts is achieved by modifying
+the ABS_MT_TRACKING_ID of the associated slot.  Since only changes are
+propagated, the full state of each initiated contact has to reside in the
+receiving end.  Upon receiving an MT event, one simply updates the
+appropriate attribute of the active slot.
+
+
+Protocol Example A
+------------------
+
+Here is what a minimal event sequence for a two-contact touch would look
+like for a type A device:
+
+   ABS_MT_POSITION_X x[0]
+   ABS_MT_POSITION_Y y[0]
+   SYN_MT_REPORT
+   ABS_MT_POSITION_X x[1]
+   ABS_MT_POSITION_Y y[1]
+   SYN_MT_REPORT
+   SYN_REPORT
+
+The sequence after moving one of the contacts looks exactly the same; the
+raw data for all present contacts are sent between every synchronization
+with SYN_REPORT.
+
+Here is the sequence after lifting the first contact:
+
+   ABS_MT_POSITION_X x[1]
+   ABS_MT_POSITION_Y y[1]
+   SYN_MT_REPORT
+   SYN_REPORT
+
+And here is the sequence after lifting the second contact:
+
+   SYN_MT_REPORT
+   SYN_REPORT
+
+If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the
+ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the
+last SYN_REPORT will be dropped by the input core, resulting in no
+zero-contact event reaching userland.
+
+
+Protocol Example B
+------------------
+
+Here is what a minimal event sequence for a two-contact touch would look
+like for a type B device:
+
+   SYN_MT_SLOT 0
+   ABS_MT_TRACKING_ID 45
+   ABS_MT_POSITION_X x[0]
+   ABS_MT_POSITION_Y y[0]
+   SYN_MT_SLOT 1
+   ABS_MT_TRACKING_ID 46
+   ABS_MT_POSITION_X x[1]
+   ABS_MT_POSITION_Y y[1]
+   SYN_REPORT
+
+Here is the sequence after moving contact 45 in the x direction:
+
+   SYN_MT_SLOT 0
+   ABS_MT_POSITION_X x[0]
+   SYN_REPORT
+
+Here is the sequence after lifting the contact in slot 0:
+
+   ABS_MT_TRACKING_ID 0
+   SYN_REPORT
+
+The active slot is already 0, so the SYN_MT_SLOT is omitted.  The message
+removes the association of slot 0 with contact 45, thereby destroying
+contact 45 and freeing slot 0 to be reused for another contact.
+
+Finally, here is the sequence after lifting the second contact:
+
+   SYN_MT_SLOT 1
+   ABS_MT_TRACKING_ID 0
+   SYN_REPORT
+
+
+Event Usage
+-----------
 
 A set of ABS_MT events with the desired properties is defined. The events
 are divided into categories, to allow for partial implementation.  The
 minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which
-allows for multiple fingers to be tracked.  If the device supports it, the
+allows for multiple contacts to be tracked.  If the device supports it, the
 ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size
-of the contact area and approaching finger, respectively.
+of the contact area and approaching contact, respectively.
 
 The TOUCH and WIDTH parameters have a geometrical interpretation; imagine
 looking through a window at someone gently holding a finger against the
@@ -41,56 +153,26 @@ ABS_MT_TOUCH_MAJOR, the diameter of the outer region is
 ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder
 against the glass. The inner region will increase, and in general, the
 ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than
-unity, is related to the finger pressure. For pressure-based devices,
+unity, is related to the contact pressure. For pressure-based devices,
 ABS_MT_PRESSURE may be used to provide the pressure on the contact area
 instead.
 
-In addition to the MAJOR parameters, the oval shape of the finger can be
+In addition to the MAJOR parameters, the oval shape of the contact can be
 described by adding the MINOR parameters, such that MAJOR and MINOR are the
 major and minor axis of an ellipse. Finally, the orientation of the oval
 shape can be describe with the ORIENTATION parameter.
 
 The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a
-finger or a pen or something else.  Devices with more granular information
+contact or a pen or something else.  Devices with more granular information
 may specify general shapes as blobs, i.e., as a sequence of rectangular
 shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices
 that currently support it, the ABS_MT_TRACKING_ID event may be used to
-report finger tracking from hardware [5].
-
-Here is what a minimal event sequence for a two-finger touch would look
-like:
+report contact tracking from hardware [5].
 
-   ABS_MT_POSITION_X
-   ABS_MT_POSITION_Y
-   SYN_MT_REPORT
-   ABS_MT_POSITION_X
-   ABS_MT_POSITION_Y
-   SYN_MT_REPORT
-   SYN_REPORT
-
-Here is the sequence after lifting one of the fingers:
-
-   ABS_MT_POSITION_X
-   ABS_MT_POSITION_Y
-   SYN_MT_REPORT
-   SYN_REPORT
-
-And here is the sequence after lifting the remaining finger:
-
-   SYN_MT_REPORT
-   SYN_REPORT
-
-If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the
-ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the
-last SYN_REPORT will be dropped by the input core, resulting in no
-zero-finger event reaching userland.
 
 Event Semantics
 ---------------
 
-The word "contact" is used to describe a tool which is in direct contact
-with the surface. A finger, a pen or a rubber all classify as contacts.
-
 ABS_MT_TOUCH_MAJOR
 
 The length of the major axis of the contact. The length should be given in
@@ -192,20 +274,11 @@ finger along the X axis (1).
 Finger Tracking
 ---------------
 
-The kernel driver should generate an arbitrary enumeration of the set of
-anonymous contacts currently on the surface. The order in which the packets
-appear in the event stream is not important.
-
 The process of finger tracking, i.e., to assign a unique trackingID to each
-initiated contact on the surface, is left to user space; preferably the
-multi-touch X driver [3]. In that driver, the trackingID stays the same and
-unique until the contact vanishes (when the finger leaves the surface). The
-problem of assigning a set of anonymous fingers to a set of identified
-fingers is a euclidian bipartite matching problem at each event update, and
-relies on a sufficiently rapid update rate.
-
-There are a few devices that support trackingID in hardware. User space can
-make use of these native identifiers to reduce bandwidth and cpu usage.
+initiated contact on the surface, is a Euclidian Bipartite Matching
+problem.  At each event synchronization, the set of actual contacts are
+matched to the set of contacts from the previos synchronization. A full
+implementation can be found in [3].
 
 
 Gestures
-- 
1.6.3.3

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Peter Hutterer]

On Tue, May 18, 2010 at 10:10:29PM +0200, Henrik Rydberg wrote:
> This patch adds documentation for the SYN_MT_SLOT event and gives
> examples of how to use the event slot protocol.

thanks, this is really nice documentation! the approach seems good, though I
do have a few questions inline.

> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> ---
>  Documentation/input/multi-touch-protocol.txt |  201 ++++++++++++++++++--------
>  1 files changed, 137 insertions(+), 64 deletions(-)
> 
> diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt
> index c0fc1c7..100aec0 100644
> --- a/Documentation/input/multi-touch-protocol.txt
> +++ b/Documentation/input/multi-touch-protocol.txt
> @@ -6,31 +6,143 @@ Multi-touch (MT) Protocol
>  Introduction
>  ------------
>  
> -In order to utilize the full power of the new multi-touch devices, a way to
> -report detailed finger data to user space is needed. This document
> -describes the multi-touch (MT) protocol which allows kernel drivers to
> -report details for an arbitrary number of fingers.
> +In order to utilize the full power of the new multi-touch and multi-user
> +devices, a way to report detailed data from multiple contacts, i.e.,
> +objects in direct contact with the device surface, is needed.  This
> +document describes the multi-touch (MT) protocol which allows kernel
> +drivers to report details for an arbitrary number of contacts.
> +
> +The protocol is divided into two types, depending on the capabilities of the
> +hardware. For devices handling anonymous contacts (type A), the protocol
> +describes how to send the raw data for all contacts to the receiver. For
> +devices capable of tracking identifiable contacts (type B), the protocol
> +describes how to send updates for individual contacts via event slots.
> +
> +
> +Protocol Usage
> +--------------
> +
> +Contact details are sent sequentially as separate packets of ABS_MT
> +events. Only the ABS_MT events are recognized as part of a contact
> +packet. Since these events are ignored by current single-touch (ST)
> +applications, the MT protocol can be implemented on top of the ST protocol
> +in an existing driver.
> +
> +Drivers for type A devices mark the end of a packet by calling the
> +input_mt_sync() function, which generates a SYN_MT_REPORT event. This
> +instructs the receiver to accept the data for the current contact and
> +prepare to receive another. Drivers for type B devices mark the beginning
> +of a packet by calling the input_mt_slot() function with a slot as
> +argument, which generates a SYN_MT_SLOT event. This instructs the receiver
> +to prepare for updates of the given slot.
> +
> +The end of a multi-touch transfer is marked by calling the usual
> +input_sync() function. This instructs the receiver to act upon events
> +accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new set
> +of events/packets.
>  
> +The main difference between the raw type A protocol and the higher level
> +type B slot protocol lies in the usage of identifiable contacts. The slot
> +protocol requires the use of the ABS_MT_TRACKING_ID, either provided by the
> +hardware of computed from the raw data [5].
>  
> -Usage
> ------
> +For type A devices, the kernel driver should generate an arbitrary
> +enumeration of the set of anonymous contacts currently on the surface. The
> +order in which the packets appear in the event stream is not important.
> +Event filtering and finger tracking is left to user space [3].
>  
> -Anonymous finger details are sent sequentially as separate packets of ABS
> -events. Only the ABS_MT events are recognized as part of a finger
> -packet. The end of a packet is marked by calling the input_mt_sync()
> -function, which generates a SYN_MT_REPORT event. This instructs the
> -receiver to accept the data for the current finger and prepare to receive
> -another. The end of a multi-touch transfer is marked by calling the usual
> -input_sync() function. This instructs the receiver to act upon events
> -accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new
> -set of events/packets.
> +For type B devices, the kernel driver should associate a slot with each
> +identified contact, and use that slot to propagate changes for the contact.
> +Creation, replacement and destruction of contacts is achieved by modifying
> +the ABS_MT_TRACKING_ID of the associated slot.  Since only changes are
> +propagated, the full state of each initiated contact has to reside in the
> +receiving end.  Upon receiving an MT event, one simply updates the
> +appropriate attribute of the active slot.

Is there a limit on the number of slots?
Will all drivers with ABS_MT_TRACKING_ID use slots? if not, how can I know
in advance if a device may use slots or not?

[...]
> +
> +Protocol Example B
> +------------------
> +
> +Here is what a minimal event sequence for a two-contact touch would look
> +like for a type B device:
> +
> +   SYN_MT_SLOT 0
> +   ABS_MT_TRACKING_ID 45
> +   ABS_MT_POSITION_X x[0]
> +   ABS_MT_POSITION_Y y[0]
> +   SYN_MT_SLOT 1
> +   ABS_MT_TRACKING_ID 46
> +   ABS_MT_POSITION_X x[1]
> +   ABS_MT_POSITION_Y y[1]
> +   SYN_REPORT
> +
> +Here is the sequence after moving contact 45 in the x direction:
> +
> +   SYN_MT_SLOT 0
> +   ABS_MT_POSITION_X x[0]
> +   SYN_REPORT
> +
> +Here is the sequence after lifting the contact in slot 0:
> +
> +   ABS_MT_TRACKING_ID 0
> +   SYN_REPORT
> +
> +The active slot is already 0, so the SYN_MT_SLOT is omitted.  The message
> +removes the association of slot 0 with contact 45, thereby destroying
> +contact 45 and freeing slot 0 to be reused for another contact.

I'm probably missing something here, but how would a process know which one
is the active slot if it didn't get the previous event?

Cheers,
  Peter

> +
> +Finally, here is the sequence after lifting the second contact:
> +
> +   SYN_MT_SLOT 1
> +   ABS_MT_TRACKING_ID 0
> +   SYN_REPORT
> +
> +
> +Event Usage
> +-----------
>  
>  A set of ABS_MT events with the desired properties is defined. The events
>  are divided into categories, to allow for partial implementation.  The
>  minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which
> -allows for multiple fingers to be tracked.  If the device supports it, the
> +allows for multiple contacts to be tracked.  If the device supports it, the
>  ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size
> -of the contact area and approaching finger, respectively.
> +of the contact area and approaching contact, respectively.
>  
>  The TOUCH and WIDTH parameters have a geometrical interpretation; imagine
>  looking through a window at someone gently holding a finger against the
> @@ -41,56 +153,26 @@ ABS_MT_TOUCH_MAJOR, the diameter of the outer region is
>  ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder
>  against the glass. The inner region will increase, and in general, the
>  ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than
> -unity, is related to the finger pressure. For pressure-based devices,
> +unity, is related to the contact pressure. For pressure-based devices,
>  ABS_MT_PRESSURE may be used to provide the pressure on the contact area
>  instead.
>  
> -In addition to the MAJOR parameters, the oval shape of the finger can be
> +In addition to the MAJOR parameters, the oval shape of the contact can be
>  described by adding the MINOR parameters, such that MAJOR and MINOR are the
>  major and minor axis of an ellipse. Finally, the orientation of the oval
>  shape can be describe with the ORIENTATION parameter.
>  
>  The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a
> -finger or a pen or something else.  Devices with more granular information
> +contact or a pen or something else.  Devices with more granular information
>  may specify general shapes as blobs, i.e., as a sequence of rectangular
>  shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices
>  that currently support it, the ABS_MT_TRACKING_ID event may be used to
> -report finger tracking from hardware [5].
> -
> -Here is what a minimal event sequence for a two-finger touch would look
> -like:
> +report contact tracking from hardware [5].
>  
> -   ABS_MT_POSITION_X
> -   ABS_MT_POSITION_Y
> -   SYN_MT_REPORT
> -   ABS_MT_POSITION_X
> -   ABS_MT_POSITION_Y
> -   SYN_MT_REPORT
> -   SYN_REPORT
> -
> -Here is the sequence after lifting one of the fingers:
> -
> -   ABS_MT_POSITION_X
> -   ABS_MT_POSITION_Y
> -   SYN_MT_REPORT
> -   SYN_REPORT
> -
> -And here is the sequence after lifting the remaining finger:
> -
> -   SYN_MT_REPORT
> -   SYN_REPORT
> -
> -If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the
> -ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the
> -last SYN_REPORT will be dropped by the input core, resulting in no
> -zero-finger event reaching userland.
>  
>  Event Semantics
>  ---------------
>  
> -The word "contact" is used to describe a tool which is in direct contact
> -with the surface. A finger, a pen or a rubber all classify as contacts.
> -
>  ABS_MT_TOUCH_MAJOR
>  
>  The length of the major axis of the contact. The length should be given in
> @@ -192,20 +274,11 @@ finger along the X axis (1).
>  Finger Tracking
>  ---------------
>  
> -The kernel driver should generate an arbitrary enumeration of the set of
> -anonymous contacts currently on the surface. The order in which the packets
> -appear in the event stream is not important.
> -
>  The process of finger tracking, i.e., to assign a unique trackingID to each
> -initiated contact on the surface, is left to user space; preferably the
> -multi-touch X driver [3]. In that driver, the trackingID stays the same and
> -unique until the contact vanishes (when the finger leaves the surface). The
> -problem of assigning a set of anonymous fingers to a set of identified
> -fingers is a euclidian bipartite matching problem at each event update, and
> -relies on a sufficiently rapid update rate.
> -
> -There are a few devices that support trackingID in hardware. User space can
> -make use of these native identifiers to reduce bandwidth and cpu usage.
> +initiated contact on the surface, is a Euclidian Bipartite Matching
> +problem.  At each event synchronization, the set of actual contacts are
> +matched to the set of contacts from the previos synchronization. A full
> +implementation can be found in [3].
>  
>  
>  Gestures
> -- 
> 1.6.3.3
> 

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Henrik Rydberg]

Peter Hutterer wrote:
> On Tue, May 18, 2010 at 10:10:29PM +0200, Henrik Rydberg wrote:
>> This patch adds documentation for the SYN_MT_SLOT event and gives
>> examples of how to use the event slot protocol.
> 
> thanks, this is really nice documentation! the approach seems good, though I
> do have a few questions inline.
> 
[...]
> 
> Is there a limit on the number of slots?

The slots are dynamically allocated by the driver, so there is no practical
limit. Each slot currently takes 44 bytes, and allocating a few kilobytes of
kernel memory is not a problem.

> Will all drivers with ABS_MT_TRACKING_ID use slots? if not, how can I know
> in advance if a device may use slots or not?

Eventually, this might become true, but you are pointing at one of the weaker
points of the current setup. There is no bit field for the EV_SYN events, so
there is no way to know in advance if SYN_MT_SYNC or SYN_MT_SLOT is used. This
could quite possibly be added to the EVIO interface. Meanwhile, the method I use
is to detect the first SYN_MT_SLOT and select parser based on that information.

>> +
>> +Protocol Example B
>> +------------------
>> +
>> +Here is what a minimal event sequence for a two-contact touch would look
>> +like for a type B device:
>> +
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_TRACKING_ID 45
>> +   ABS_MT_POSITION_X x[0]
>> +   ABS_MT_POSITION_Y y[0]
>> +   SYN_MT_SLOT 1
>> +   ABS_MT_TRACKING_ID 46
>> +   ABS_MT_POSITION_X x[1]
>> +   ABS_MT_POSITION_Y y[1]
>> +   SYN_REPORT
>> +
>> +Here is the sequence after moving contact 45 in the x direction:
>> +
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_POSITION_X x[0]
>> +   SYN_REPORT
>> +
>> +Here is the sequence after lifting the contact in slot 0:
>> +
>> +   ABS_MT_TRACKING_ID 0
>> +   SYN_REPORT
>> +
>> +The active slot is already 0, so the SYN_MT_SLOT is omitted.  The message
>> +removes the association of slot 0 with contact 45, thereby destroying
>> +contact 45 and freeing slot 0 to be reused for another contact.
> 
> I'm probably missing something here, but how would a process know which one
> is the active slot if it didn't get the previous event?

I am assuming you are not talking about losing events in the stream, but simply
what information is available at the point of parsing it. The parser (the X
evdev driver for instance) keeps all attributes of all slots, plus a single
variable saying what slot is currently active, i.e, being modified.

If you are thinking of a setup where one program is already hooked up to the
device, and a new one comes in just as the message in question appears on the
wire, it just means the new program will have to spend some time catching up. If
this should ever become a problem, one could possibly add a send-full-state
method to the input layer, to be issued when the new program opens the device. I
doubt this will be needed in practice though, since contacts change all the time.

As a side note, the notion of a used slot depends on how the attributes of the
slot are interpreted. The method described in the document treats an
ABS_MT_TRACKING_ID value outside of the driver-specified value range as an
unused slot.

Cheers,
Henrik

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

Hi Henrik,

I am trying to link the protocol to the actual multi-touch devices in
my "mind". Hope it helps you to point out the mismatch between my
imagination and the protocol.  Please see details in line.

Ping

On Tue, May 18, 2010 at 1:10 PM, Henrik Rydberg <rydberg@euromail.se> wrote:
> This patch adds documentation for the SYN_MT_SLOT event and
> gives examples of how to use the event slot protocol.

Am I right in thinking that SYN_MT_SLOT represents to the actual touch
area/finger on the surface? There could be more than one (x,y) (a few
points that form an irregular shape) that represents one finger.  The
following example shows that slot 0 (finger 1) touched three points on
the surface while slot 1 (finger 2) only has one point reported:

+   SYN_MT_SLOT 0
+   ABS_MT_TRACKING_ID 45
+   ABS_MT_POSITION_X x[0]
+   ABS_MT_POSITION_Y y[0]
+   ABS_MT_TRACKING_ID 46
+   ABS_MT_POSITION_X x[1]
+   ABS_MT_POSITION_Y y[1]
+   ABS_MT_TRACKING_ID 47
+   ABS_MT_POSITION_X x[2]
+   ABS_MT_POSITION_Y y[2]
+   SYN_MT_SLOT 1
+   ABS_MT_TRACKING_ID 30
+   ABS_MT_POSITION_X x[3]
+   ABS_MT_POSITION_Y y[3]
+   SYN_REPORT

If my assumption is correct, i.e., one slot can have more than one
point, I would think ABS_MT_TRACKING_ID may not have to be a required
entry inside SYN_MT_SLOT.  To the user land clients/drivers,
SYN_MT_SLOT itself could serve as an ID. So, the following case is
also a type B ( we know there are two touch areas. But we don't keep
track of the points inside the areas):

+   SYN_MT_SLOT 0
+   ABS_MT_POSITION_X x[0]
+   ABS_MT_POSITION_Y y[0]
+   ABS_MT_POSITION_X x[1]
+   ABS_MT_POSITION_Y y[1]
+   ABS_MT_POSITION_X x[2]
+   ABS_MT_POSITION_Y y[2]
+   SYN_MT_SLOT 1
+   ABS_MT_POSITION_X x[3]
+   ABS_MT_POSITION_Y y[3]
+   SYN_REPORT

So, an EVIO for X driver to retrieve the number of SLOTs would be very
helpful.  Something like the following would do the work:

input_set_abs_params(input_dev, ABS_MT_SLOT, 0, 12, 0, 0);

which tells the user land clients that they can expect up to 13 touch areas.

> +The main difference between the raw type A protocol and the higher level
> +type B slot protocol lies in the usage of identifiable contacts. The slot
> +protocol requires the use of the ABS_MT_TRACKING_ID,

With what I said above, I think ABS_MT_TRACKING_ID is not the unique
identifier for type B protocol. It is the fact that we can identify
individual touch areas and use ABS_MT_SLOT to report them that makes
it a type B event.

> ABS_MT_TRACKING_ID, either provided by the
> +hardware of computed from the raw data [5].
                   ^^ or  (is it?)

I agree with this ABS_MT_TRACKING_ID definition.  I would think something like:

input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, 47, 0, 0);

which tells the clients that total of 48 points are tracked, would be helpful.

Another topic that may be irrelevant to this patch is the filter. With
the use of ABS_MT_TRACKING_ID, a filter can be applied to discard the
useless repeated points or less than a certain number of points
movement.

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Rafi Rubin]

My understanding is that it would be more like
+   SYN_MT_SLOT 0
+   ABS_MT_POSITION_X x
+   ABS_MT_POSITION_Y y
+   SYN_REPORT
+   SYN_MT_SLOT 0
+   ABS_MT_POSITION_X x
+   ABS_MT_POSITION_Y y
+   SYN_REPORT
+   SYN_MT_SLOT 0
+   ABS_MT_POSITION_X x
+   ABS_MT_POSITION_Y y
+   SYN_MT_SLOT 1
+   ABS_MT_POSITION_X x
+   ABS_MT_POSITION_Y y
+   SYN_REPORT


(2 events from 1 finger, followed by 1 event with both).


On 05/19/2010 06:43 PM, Ping Cheng wrote:
> Hi Henrik,
>
> I am trying to link the protocol to the actual multi-touch devices in
> my "mind". Hope it helps you to point out the mismatch between my
> imagination and the protocol.  Please see details in line.
>
> Ping
>
> On Tue, May 18, 2010 at 1:10 PM, Henrik Rydberg<rydberg@euromail.se>  wrote:
>> This patch adds documentation for the SYN_MT_SLOT event and
>> gives examples of how to use the event slot protocol.
>
> Am I right in thinking that SYN_MT_SLOT represents to the actual touch
> area/finger on the surface? There could be more than one (x,y) (a few
> points that form an irregular shape) that represents one finger.  The
> following example shows that slot 0 (finger 1) touched three points on
> the surface while slot 1 (finger 2) only has one point reported:
>
> +   SYN_MT_SLOT 0
> +   ABS_MT_TRACKING_ID 45
> +   ABS_MT_POSITION_X x[0]
> +   ABS_MT_POSITION_Y y[0]
> +   ABS_MT_TRACKING_ID 46
> +   ABS_MT_POSITION_X x[1]
> +   ABS_MT_POSITION_Y y[1]
> +   ABS_MT_TRACKING_ID 47
> +   ABS_MT_POSITION_X x[2]
> +   ABS_MT_POSITION_Y y[2]
> +   SYN_MT_SLOT 1
> +   ABS_MT_TRACKING_ID 30
> +   ABS_MT_POSITION_X x[3]
> +   ABS_MT_POSITION_Y y[3]
> +   SYN_REPORT
>
> If my assumption is correct, i.e., one slot can have more than one
> point, I would think ABS_MT_TRACKING_ID may not have to be a required
> entry inside SYN_MT_SLOT.  To the user land clients/drivers,
> SYN_MT_SLOT itself could serve as an ID. So, the following case is
> also a type B ( we know there are two touch areas. But we don't keep
> track of the points inside the areas):
>
> +   SYN_MT_SLOT 0
> +   ABS_MT_POSITION_X x[0]
> +   ABS_MT_POSITION_Y y[0]
> +   ABS_MT_POSITION_X x[1]
> +   ABS_MT_POSITION_Y y[1]
> +   ABS_MT_POSITION_X x[2]
> +   ABS_MT_POSITION_Y y[2]
> +   SYN_MT_SLOT 1
> +   ABS_MT_POSITION_X x[3]
> +   ABS_MT_POSITION_Y y[3]
> +   SYN_REPORT
>
> So, an EVIO for X driver to retrieve the number of SLOTs would be very
> helpful.  Something like the following would do the work:
>
> input_set_abs_params(input_dev, ABS_MT_SLOT, 0, 12, 0, 0);
>
> which tells the user land clients that they can expect up to 13 touch areas.
>
>> +The main difference between the raw type A protocol and the higher level
>> +type B slot protocol lies in the usage of identifiable contacts. The slot
>> +protocol requires the use of the ABS_MT_TRACKING_ID,
>
> With what I said above, I think ABS_MT_TRACKING_ID is not the unique
> identifier for type B protocol. It is the fact that we can identify
> individual touch areas and use ABS_MT_SLOT to report them that makes
> it a type B event.
>
>> ABS_MT_TRACKING_ID, either provided by the
>> +hardware of computed from the raw data [5].
>                     ^^ or  (is it?)
>
> I agree with this ABS_MT_TRACKING_ID definition.  I would think something like:
>
> input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, 47, 0, 0);
>
> which tells the clients that total of 48 points are tracked, would be helpful.
>
> Another topic that may be irrelevant to this patch is the filter. With
> the use of ABS_MT_TRACKING_ID, a filter can be applied to discard the
> useless repeated points or less than a certain number of points
> movement.
>

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Peter Hutterer]

On Wed, May 19, 2010 at 02:12:14PM +0200, Henrik Rydberg wrote:
> Peter Hutterer wrote:
> > On Tue, May 18, 2010 at 10:10:29PM +0200, Henrik Rydberg wrote:
> >> This patch adds documentation for the SYN_MT_SLOT event and gives
> >> examples of how to use the event slot protocol.
> > 
> > thanks, this is really nice documentation! the approach seems good, though I
> > do have a few questions inline.
> > 
> [...]
> > 
> > Is there a limit on the number of slots?
> 
> The slots are dynamically allocated by the driver, so there is no practical
> limit. Each slot currently takes 44 bytes, and allocating a few kilobytes of
> kernel memory is not a problem.
> 
> > Will all drivers with ABS_MT_TRACKING_ID use slots? if not, how can I know
> > in advance if a device may use slots or not?
> 
> Eventually, this might become true, but you are pointing at one of the weaker
> points of the current setup. There is no bit field for the EV_SYN events, so
> there is no way to know in advance if SYN_MT_SYNC or SYN_MT_SLOT is used. This
> could quite possibly be added to the EVIO interface. Meanwhile, the method I use
> is to detect the first SYN_MT_SLOT and select parser based on that information.

I'd really prefer if there was some way to detect this. While I'm not quite
sure how the matching X drivers would look like it's likely that the setups
will be different for drivers that support slots and those that don't.
e.g. those that don't have slots simply send events as valuators, those that
do may split into multiple devices.

Doing this at runtime - after the device has been set up is...tricky.

> >> +
> >> +Protocol Example B
> >> +------------------
> >> +
> >> +Here is what a minimal event sequence for a two-contact touch would look
> >> +like for a type B device:
> >> +
> >> +   SYN_MT_SLOT 0
> >> +   ABS_MT_TRACKING_ID 45
> >> +   ABS_MT_POSITION_X x[0]
> >> +   ABS_MT_POSITION_Y y[0]
> >> +   SYN_MT_SLOT 1
> >> +   ABS_MT_TRACKING_ID 46
> >> +   ABS_MT_POSITION_X x[1]
> >> +   ABS_MT_POSITION_Y y[1]
> >> +   SYN_REPORT
> >> +
> >> +Here is the sequence after moving contact 45 in the x direction:
> >> +
> >> +   SYN_MT_SLOT 0
> >> +   ABS_MT_POSITION_X x[0]
> >> +   SYN_REPORT
> >> +
> >> +Here is the sequence after lifting the contact in slot 0:
> >> +
> >> +   ABS_MT_TRACKING_ID 0
> >> +   SYN_REPORT
> >> +
> >> +The active slot is already 0, so the SYN_MT_SLOT is omitted.  The message
> >> +removes the association of slot 0 with contact 45, thereby destroying
> >> +contact 45 and freeing slot 0 to be reused for another contact.
> > 
> > I'm probably missing something here, but how would a process know which one
> > is the active slot if it didn't get the previous event?
> 
> I am assuming you are not talking about losing events in the stream, but simply
> what information is available at the point of parsing it. The parser (the X
> evdev driver for instance) keeps all attributes of all slots, plus a single
> variable saying what slot is currently active, i.e, being modified.
> 
> If you are thinking of a setup where one program is already hooked up to the
> device, and a new one comes in just as the message in question appears on the
> wire, it just means the new program will have to spend some time catching up. If
> this should ever become a problem, one could possibly add a send-full-state
> method to the input layer, to be issued when the new program opens the device. I
> doubt this will be needed in practice though, since contacts change all the time.

This was the case I was wondering about. While I agree with the last part
(contacts change all the time) the side-effect that you'll get from this is
that devices can seemingly be non-responsive for random periods of time.

If you have a finger down when the X server starts or after a VT switch (or
even a fast user switch), the driver will have to drop events. So you can
wriggle your finger around and nothing happens, but once you lift it goes
"well, now it works again". Since this happens only once in a while, it can
make the whole lot appear flaky.  Especially if one finger works and the
other one doesn't.

So I guess it comes down to whether sending SYN_MT_SLOT with every event
costs too much compared to these admittedly rare use-cases. They're not much
different to the current button events either, if you weren't there when a
button was pressed you won't know. So I'm somewhat indifferent about this
bit.

And yes, you could add it once we find it's an issue, but by then someone
has already spent time to work around this. And when you then start sending
slot events all the time, you admit that writing the workaround was just a
time waster :)

> As a side note, the notion of a used slot depends on how the attributes of the
> slot are interpreted. The method described in the document treats an
> ABS_MT_TRACKING_ID value outside of the driver-specified value range as an
> unused slot.

It's easier for a latecomer to guess a tracking ID since you can just
assign any random value to it, provided the kernel guarantees to only send
updates on the tracking ID for changes. This doesn't quite work for slots.

But I'm not sure what your last sentence means. Does this mean the kernel
will open a new slot for out-of-range tracking IDs? I'm missing something
here.

Cheers,
  Peter

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Wed, May 19, 2010 at 4:34 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
> My understanding is that it would be more like
> +   SYN_MT_SLOT 0
> +   ABS_MT_POSITION_X x
> +   ABS_MT_POSITION_Y y
> +   SYN_REPORT
> +   SYN_MT_SLOT 0
> +   ABS_MT_POSITION_X x
> +   ABS_MT_POSITION_Y y
> +   SYN_REPORT
> +   SYN_MT_SLOT 0
> +   ABS_MT_POSITION_X x
> +   ABS_MT_POSITION_Y y
> +   SYN_MT_SLOT 1
> +   ABS_MT_POSITION_X x
> +   ABS_MT_POSITION_Y y
> +   SYN_REPORT

You are right if one slot only has or is only allowed to have one
point. My scenario is that one slot can have more than one point.
Basically, my intention is to utilize the MT_SLOT and MT_TRACKING_ID
in such a way that it avoids as much overlap as possible.

And hopefully it makes sesne in the reality too.

> (2 events from 1 finger, followed by 1 event with both).
>
>
> On 05/19/2010 06:43 PM, Ping Cheng wrote:
>>
>> Hi Henrik,
>>
>> I am trying to link the protocol to the actual multi-touch devices in
>> my "mind". Hope it helps you to point out the mismatch between my
>> imagination and the protocol.  Please see details in line.
>>
>> Ping
>>
>> On Tue, May 18, 2010 at 1:10 PM, Henrik Rydberg<rydberg@euromail.se>
>>  wrote:
>>>
>>> This patch adds documentation for the SYN_MT_SLOT event and
>>> gives examples of how to use the event slot protocol.
>>
>> Am I right in thinking that SYN_MT_SLOT represents to the actual touch
>> area/finger on the surface? There could be more than one (x,y) (a few
>> points that form an irregular shape) that represents one finger.  The
>> following example shows that slot 0 (finger 1) touched three points on
>> the surface while slot 1 (finger 2) only has one point reported:
>>
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_TRACKING_ID 45
>> +   ABS_MT_POSITION_X x[0]
>> +   ABS_MT_POSITION_Y y[0]
>> +   ABS_MT_TRACKING_ID 46
>> +   ABS_MT_POSITION_X x[1]
>> +   ABS_MT_POSITION_Y y[1]
>> +   ABS_MT_TRACKING_ID 47
>> +   ABS_MT_POSITION_X x[2]
>> +   ABS_MT_POSITION_Y y[2]
>> +   SYN_MT_SLOT 1
>> +   ABS_MT_TRACKING_ID 30
>> +   ABS_MT_POSITION_X x[3]
>> +   ABS_MT_POSITION_Y y[3]
>> +   SYN_REPORT
>>
>> If my assumption is correct, i.e., one slot can have more than one
>> point, I would think ABS_MT_TRACKING_ID may not have to be a required
>> entry inside SYN_MT_SLOT.  To the user land clients/drivers,
>> SYN_MT_SLOT itself could serve as an ID. So, the following case is
>> also a type B ( we know there are two touch areas. But we don't keep
>> track of the points inside the areas):
>>
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_POSITION_X x[0]
>> +   ABS_MT_POSITION_Y y[0]
>> +   ABS_MT_POSITION_X x[1]
>> +   ABS_MT_POSITION_Y y[1]
>> +   ABS_MT_POSITION_X x[2]
>> +   ABS_MT_POSITION_Y y[2]
>> +   SYN_MT_SLOT 1
>> +   ABS_MT_POSITION_X x[3]
>> +   ABS_MT_POSITION_Y y[3]
>> +   SYN_REPORT
>>
>> So, an EVIO for X driver to retrieve the number of SLOTs would be very
>> helpful.  Something like the following would do the work:
>>
>> input_set_abs_params(input_dev, ABS_MT_SLOT, 0, 12, 0, 0);
>>
>> which tells the user land clients that they can expect up to 13 touch
>> areas.
>>
>>> +The main difference between the raw type A protocol and the higher level
>>> +type B slot protocol lies in the usage of identifiable contacts. The
>>> slot
>>> +protocol requires the use of the ABS_MT_TRACKING_ID,
>>
>> With what I said above, I think ABS_MT_TRACKING_ID is not the unique
>> identifier for type B protocol. It is the fact that we can identify
>> individual touch areas and use ABS_MT_SLOT to report them that makes
>> it a type B event.
>>
>>> ABS_MT_TRACKING_ID, either provided by the
>>> +hardware of computed from the raw data [5].
>>
>>                    ^^ or  (is it?)
>>
>> I agree with this ABS_MT_TRACKING_ID definition.  I would think something
>> like:
>>
>> input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, 47, 0, 0);
>>
>> which tells the clients that total of 48 points are tracked, would be
>> helpful.
>>
>> Another topic that may be irrelevant to this patch is the filter. With
>> the use of ABS_MT_TRACKING_ID, a filter can be applied to discard the
>> useless repeated points or less than a certain number of points
>> movement.
>>
>

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Wed, May 19, 2010 at 4:34 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
> My understanding is that it would be more like
> +   SYN_MT_SLOT 0
> +   ABS_MT_POSITION_X x
> +   ABS_MT_POSITION_Y y
> +   SYN_REPORT
> +   SYN_MT_SLOT 0
> +   ABS_MT_POSITION_X x
> +   ABS_MT_POSITION_Y y
> +   SYN_REPORT
> +   SYN_MT_SLOT 0
> +   ABS_MT_POSITION_X x
> +   ABS_MT_POSITION_Y y
> +   SYN_MT_SLOT 1
> +   ABS_MT_POSITION_X x
> +   ABS_MT_POSITION_Y y
> +   SYN_REPORT

You are right if one slot only has or is only allowed to have one
point. My scenario is that one slot can have more than one point.
Basically, my intention is to utilize the MT_SLOT and MT_TRACKING_ID
in such a way that it avoids as much overlap as possible.

And hopefully it makes sesne in the reality too.

> (2 events from 1 finger, followed by 1 event with both).
>
>
> On 05/19/2010 06:43 PM, Ping Cheng wrote:
>>
>> Hi Henrik,
>>
>> I am trying to link the protocol to the actual multi-touch devices in
>> my "mind". Hope it helps you to point out the mismatch between my
>> imagination and the protocol.  Please see details in line.
>>
>> Ping
>>
>> On Tue, May 18, 2010 at 1:10 PM, Henrik Rydberg<rydberg@euromail.se>
>>  wrote:
>>>
>>> This patch adds documentation for the SYN_MT_SLOT event and
>>> gives examples of how to use the event slot protocol.
>>
>> Am I right in thinking that SYN_MT_SLOT represents to the actual touch
>> area/finger on the surface? There could be more than one (x,y) (a few
>> points that form an irregular shape) that represents one finger.  The
>> following example shows that slot 0 (finger 1) touched three points on
>> the surface while slot 1 (finger 2) only has one point reported:
>>
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_TRACKING_ID 45
>> +   ABS_MT_POSITION_X x[0]
>> +   ABS_MT_POSITION_Y y[0]
>> +   ABS_MT_TRACKING_ID 46
>> +   ABS_MT_POSITION_X x[1]
>> +   ABS_MT_POSITION_Y y[1]
>> +   ABS_MT_TRACKING_ID 47
>> +   ABS_MT_POSITION_X x[2]
>> +   ABS_MT_POSITION_Y y[2]
>> +   SYN_MT_SLOT 1
>> +   ABS_MT_TRACKING_ID 30
>> +   ABS_MT_POSITION_X x[3]
>> +   ABS_MT_POSITION_Y y[3]
>> +   SYN_REPORT
>>
>> If my assumption is correct, i.e., one slot can have more than one
>> point, I would think ABS_MT_TRACKING_ID may not have to be a required
>> entry inside SYN_MT_SLOT.  To the user land clients/drivers,
>> SYN_MT_SLOT itself could serve as an ID. So, the following case is
>> also a type B ( we know there are two touch areas. But we don't keep
>> track of the points inside the areas):
>>
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_POSITION_X x[0]
>> +   ABS_MT_POSITION_Y y[0]
>> +   ABS_MT_POSITION_X x[1]
>> +   ABS_MT_POSITION_Y y[1]
>> +   ABS_MT_POSITION_X x[2]
>> +   ABS_MT_POSITION_Y y[2]
>> +   SYN_MT_SLOT 1
>> +   ABS_MT_POSITION_X x[3]
>> +   ABS_MT_POSITION_Y y[3]
>> +   SYN_REPORT
>>
>> So, an EVIO for X driver to retrieve the number of SLOTs would be very
>> helpful.  Something like the following would do the work:
>>
>> input_set_abs_params(input_dev, ABS_MT_SLOT, 0, 12, 0, 0);
>>
>> which tells the user land clients that they can expect up to 13 touch
>> areas.
>>
>>> +The main difference between the raw type A protocol and the higher level
>>> +type B slot protocol lies in the usage of identifiable contacts. The
>>> slot
>>> +protocol requires the use of the ABS_MT_TRACKING_ID,
>>
>> With what I said above, I think ABS_MT_TRACKING_ID is not the unique
>> identifier for type B protocol. It is the fact that we can identify
>> individual touch areas and use ABS_MT_SLOT to report them that makes
>> it a type B event.
>>
>>> ABS_MT_TRACKING_ID, either provided by the
>>> +hardware of computed from the raw data [5].
>>
>>                    ^^ or  (is it?)
>>
>> I agree with this ABS_MT_TRACKING_ID definition.  I would think something
>> like:
>>
>> input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, 47, 0, 0);
>>
>> which tells the clients that total of 48 points are tracked, would be
>> helpful.
>>
>> Another topic that may be irrelevant to this patch is the filter. With
>> the use of ABS_MT_TRACKING_ID, a filter can be applied to discard the
>> useless repeated points or less than a certain number of points
>> movement.
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Peter Hutterer]

On Wed, May 19, 2010 at 07:34:04PM -0400, Rafi Rubin wrote:
> My understanding is that it would be more like
> +   SYN_MT_SLOT 0
> +   ABS_MT_POSITION_X x
> +   ABS_MT_POSITION_Y y
> +   SYN_REPORT
> +   SYN_MT_SLOT 0
> +   ABS_MT_POSITION_X x
> +   ABS_MT_POSITION_Y y
> +   SYN_REPORT
> +   SYN_MT_SLOT 0
> +   ABS_MT_POSITION_X x
> +   ABS_MT_POSITION_Y y
> +   SYN_MT_SLOT 1
> +   ABS_MT_POSITION_X x
> +   ABS_MT_POSITION_Y y
> +   SYN_REPORT
> 
> 
> (2 events from 1 finger, followed by 1 event with both).

where does the ABS_MT_BLOB_ID come in then? I thought this was the use-case
it was added for. With the example above, you're updating the position for
the finger three times, not specifying that there are 3 _simultaneous_ but
disparate touches of the same finger.

I'm thinking of a palm touch which may (for some hand shapes) gives you two
blobs right next to each other but separated by a thin line.
So palm + finger gives you three blobs in three slots, two of them linked by
contact ID?

Cheers,
  Peter

> On 05/19/2010 06:43 PM, Ping Cheng wrote:
> >Hi Henrik,
> >
> >I am trying to link the protocol to the actual multi-touch devices in
> >my "mind". Hope it helps you to point out the mismatch between my
> >imagination and the protocol.  Please see details in line.
> >
> >Ping
> >
> >On Tue, May 18, 2010 at 1:10 PM, Henrik Rydberg<rydberg@euromail.se>  wrote:
> >>This patch adds documentation for the SYN_MT_SLOT event and
> >>gives examples of how to use the event slot protocol.
> >
> >Am I right in thinking that SYN_MT_SLOT represents to the actual touch
> >area/finger on the surface? There could be more than one (x,y) (a few
> >points that form an irregular shape) that represents one finger.  The
> >following example shows that slot 0 (finger 1) touched three points on
> >the surface while slot 1 (finger 2) only has one point reported:
> >
> >+   SYN_MT_SLOT 0
> >+   ABS_MT_TRACKING_ID 45
> >+   ABS_MT_POSITION_X x[0]
> >+   ABS_MT_POSITION_Y y[0]
> >+   ABS_MT_TRACKING_ID 46
> >+   ABS_MT_POSITION_X x[1]
> >+   ABS_MT_POSITION_Y y[1]
> >+   ABS_MT_TRACKING_ID 47
> >+   ABS_MT_POSITION_X x[2]
> >+   ABS_MT_POSITION_Y y[2]
> >+   SYN_MT_SLOT 1
> >+   ABS_MT_TRACKING_ID 30
> >+   ABS_MT_POSITION_X x[3]
> >+   ABS_MT_POSITION_Y y[3]
> >+   SYN_REPORT
> >
> >If my assumption is correct, i.e., one slot can have more than one
> >point, I would think ABS_MT_TRACKING_ID may not have to be a required
> >entry inside SYN_MT_SLOT.  To the user land clients/drivers,
> >SYN_MT_SLOT itself could serve as an ID. So, the following case is
> >also a type B ( we know there are two touch areas. But we don't keep
> >track of the points inside the areas):
> >
> >+   SYN_MT_SLOT 0
> >+   ABS_MT_POSITION_X x[0]
> >+   ABS_MT_POSITION_Y y[0]
> >+   ABS_MT_POSITION_X x[1]
> >+   ABS_MT_POSITION_Y y[1]
> >+   ABS_MT_POSITION_X x[2]
> >+   ABS_MT_POSITION_Y y[2]
> >+   SYN_MT_SLOT 1
> >+   ABS_MT_POSITION_X x[3]
> >+   ABS_MT_POSITION_Y y[3]
> >+   SYN_REPORT
> >
> >So, an EVIO for X driver to retrieve the number of SLOTs would be very
> >helpful.  Something like the following would do the work:
> >
> >input_set_abs_params(input_dev, ABS_MT_SLOT, 0, 12, 0, 0);
> >
> >which tells the user land clients that they can expect up to 13 touch areas.
> >
> >>+The main difference between the raw type A protocol and the higher level
> >>+type B slot protocol lies in the usage of identifiable contacts. The slot
> >>+protocol requires the use of the ABS_MT_TRACKING_ID,
> >
> >With what I said above, I think ABS_MT_TRACKING_ID is not the unique
> >identifier for type B protocol. It is the fact that we can identify
> >individual touch areas and use ABS_MT_SLOT to report them that makes
> >it a type B event.
> >
> >>ABS_MT_TRACKING_ID, either provided by the
> >>+hardware of computed from the raw data [5].
> >                    ^^ or  (is it?)
> >
> >I agree with this ABS_MT_TRACKING_ID definition.  I would think something like:
> >
> >input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, 47, 0, 0);
> >
> >which tells the clients that total of 48 points are tracked, would be helpful.
> >
> >Another topic that may be irrelevant to this patch is the filter. With
> >the use of ABS_MT_TRACKING_ID, a filter can be applied to discard the
> >useless repeated points or less than a certain number of points
> >movement.
> >

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Rafi Rubin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/19/10 20:13, Ping Cheng wrote:
> On Wed, May 19, 2010 at 4:34 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
>> My understanding is that it would be more like
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_POSITION_X x
>> +   ABS_MT_POSITION_Y y
>> +   SYN_REPORT
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_POSITION_X x
>> +   ABS_MT_POSITION_Y y
>> +   SYN_REPORT
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_POSITION_X x
>> +   ABS_MT_POSITION_Y y
>> +   SYN_MT_SLOT 1
>> +   ABS_MT_POSITION_X x
>> +   ABS_MT_POSITION_Y y
>> +   SYN_REPORT
> 
> You are right if one slot only has or is only allowed to have one
> point. My scenario is that one slot can have more than one point.
> Basically, my intention is to utilize the MT_SLOT and MT_TRACKING_ID
> in such a way that it avoids as much overlap as possible.
> 
> And hopefully it makes sesne in the reality too.

Please clarify by what you mean by more than one point.

I may be misunderstanding, but I thought that these slots are basically a
superior replacement to tracking id.

one finger -> one slot

But with slots we can use the filtering that input provides, which we've been
by-passing with the existing MT protocol (at least that's what I think Henrik's
goal is).

Rafi

>> (2 events from 1 finger, followed by 1 event with both).
>>
>>
>> On 05/19/2010 06:43 PM, Ping Cheng wrote:
>>>
>>> Hi Henrik,
>>>
>>> I am trying to link the protocol to the actual multi-touch devices in
>>> my "mind". Hope it helps you to point out the mismatch between my
>>> imagination and the protocol.  Please see details in line.
>>>
>>> Ping
>>>
>>> On Tue, May 18, 2010 at 1:10 PM, Henrik Rydberg<rydberg@euromail.se>
>>>  wrote:
>>>>
>>>> This patch adds documentation for the SYN_MT_SLOT event and
>>>> gives examples of how to use the event slot protocol.
>>>
>>> Am I right in thinking that SYN_MT_SLOT represents to the actual touch
>>> area/finger on the surface? There could be more than one (x,y) (a few
>>> points that form an irregular shape) that represents one finger.  The
>>> following example shows that slot 0 (finger 1) touched three points on
>>> the surface while slot 1 (finger 2) only has one point reported:
>>>
>>> +   SYN_MT_SLOT 0
>>> +   ABS_MT_TRACKING_ID 45
>>> +   ABS_MT_POSITION_X x[0]
>>> +   ABS_MT_POSITION_Y y[0]
>>> +   ABS_MT_TRACKING_ID 46
>>> +   ABS_MT_POSITION_X x[1]
>>> +   ABS_MT_POSITION_Y y[1]
>>> +   ABS_MT_TRACKING_ID 47
>>> +   ABS_MT_POSITION_X x[2]
>>> +   ABS_MT_POSITION_Y y[2]
>>> +   SYN_MT_SLOT 1
>>> +   ABS_MT_TRACKING_ID 30
>>> +   ABS_MT_POSITION_X x[3]
>>> +   ABS_MT_POSITION_Y y[3]
>>> +   SYN_REPORT
>>>
>>> If my assumption is correct, i.e., one slot can have more than one
>>> point, I would think ABS_MT_TRACKING_ID may not have to be a required
>>> entry inside SYN_MT_SLOT.  To the user land clients/drivers,
>>> SYN_MT_SLOT itself could serve as an ID. So, the following case is
>>> also a type B ( we know there are two touch areas. But we don't keep
>>> track of the points inside the areas):
>>>
>>> +   SYN_MT_SLOT 0
>>> +   ABS_MT_POSITION_X x[0]
>>> +   ABS_MT_POSITION_Y y[0]
>>> +   ABS_MT_POSITION_X x[1]
>>> +   ABS_MT_POSITION_Y y[1]
>>> +   ABS_MT_POSITION_X x[2]
>>> +   ABS_MT_POSITION_Y y[2]
>>> +   SYN_MT_SLOT 1
>>> +   ABS_MT_POSITION_X x[3]
>>> +   ABS_MT_POSITION_Y y[3]
>>> +   SYN_REPORT
>>>
>>> So, an EVIO for X driver to retrieve the number of SLOTs would be very
>>> helpful.  Something like the following would do the work:
>>>
>>> input_set_abs_params(input_dev, ABS_MT_SLOT, 0, 12, 0, 0);
>>>
>>> which tells the user land clients that they can expect up to 13 touch
>>> areas.
>>>
>>>> +The main difference between the raw type A protocol and the higher level
>>>> +type B slot protocol lies in the usage of identifiable contacts. The
>>>> slot
>>>> +protocol requires the use of the ABS_MT_TRACKING_ID,
>>>
>>> With what I said above, I think ABS_MT_TRACKING_ID is not the unique
>>> identifier for type B protocol. It is the fact that we can identify
>>> individual touch areas and use ABS_MT_SLOT to report them that makes
>>> it a type B event.
>>>
>>>> ABS_MT_TRACKING_ID, either provided by the
>>>> +hardware of computed from the raw data [5].
>>>
>>>                    ^^ or  (is it?)
>>>
>>> I agree with this ABS_MT_TRACKING_ID definition.  I would think something
>>> like:
>>>
>>> input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, 47, 0, 0);
>>>
>>> which tells the clients that total of 48 points are tracked, would be
>>> helpful.
>>>
>>> Another topic that may be irrelevant to this patch is the filter. With
>>> the use of ABS_MT_TRACKING_ID, a filter can be applied to discard the
>>> useless repeated points or less than a certain number of points
>>> movement.
>>>
>>
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkv0gZgACgkQwuRiAT9o60/v5QCguYH/eGD4R12cIPGc/AF3Xz6Y
RXgAoIfEYSVqekbLRU4NXHo0bnG323vA
=OUmf
-----END PGP SIGNATURE-----

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Rafi Rubin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/19/10 20:21, Peter Hutterer wrote:
> On Wed, May 19, 2010 at 07:34:04PM -0400, Rafi Rubin wrote:
>> My understanding is that it would be more like
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_POSITION_X x
>> +   ABS_MT_POSITION_Y y
>> +   SYN_REPORT
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_POSITION_X x
>> +   ABS_MT_POSITION_Y y
>> +   SYN_REPORT
>> +   SYN_MT_SLOT 0
>> +   ABS_MT_POSITION_X x
>> +   ABS_MT_POSITION_Y y
>> +   SYN_MT_SLOT 1
>> +   ABS_MT_POSITION_X x
>> +   ABS_MT_POSITION_Y y
>> +   SYN_REPORT
>>
>>
>> (2 events from 1 finger, followed by 1 event with both).
> 
> where does the ABS_MT_BLOB_ID come in then? I thought this was the use-case
> it was added for. With the example above, you're updating the position for
> the finger three times, not specifying that there are 3 _simultaneous_ but
> disparate touches of the same finger.
> 
> I'm thinking of a palm touch which may (for some hand shapes) gives you two
> blobs right next to each other but separated by a thin line.
> So palm + finger gives you three blobs in three slots, two of them linked by
> contact ID?
> 
> Cheers,
>   Peter

Once again, I'm interpreting, perhaps with bias towards what I'd like it to mean.

I think blobs are spatially localized contacts.  It all the contacts which would
most likely represent one hand.  If you have two hands operating a screen
(whether one or two people (hopefully not three)), you should have two blobs
(I've been thinking about this concept in terms of "group" or "cluster") each
with one of more contact.


I think that gets interesting when you start thinking about larger scale
environments where you will be using multiple hands, and multiple people.  I
think each blob should be allocated its own master pointer.  And if you can bind
a master keyboard to the blob too (perhaps an on screen keyboard), its trivial
to imagine using that for a large table like surface where multiple people are
using a single desktop independently.

> 
>> On 05/19/2010 06:43 PM, Ping Cheng wrote:
>>> Hi Henrik,
>>>
>>> I am trying to link the protocol to the actual multi-touch devices in
>>> my "mind". Hope it helps you to point out the mismatch between my
>>> imagination and the protocol.  Please see details in line.
>>>
>>> Ping
>>>
>>> On Tue, May 18, 2010 at 1:10 PM, Henrik Rydberg<rydberg@euromail.se>  wrote:
>>>> This patch adds documentation for the SYN_MT_SLOT event and
>>>> gives examples of how to use the event slot protocol.
>>>
>>> Am I right in thinking that SYN_MT_SLOT represents to the actual touch
>>> area/finger on the surface? There could be more than one (x,y) (a few
>>> points that form an irregular shape) that represents one finger.  The
>>> following example shows that slot 0 (finger 1) touched three points on
>>> the surface while slot 1 (finger 2) only has one point reported:
>>>
>>> +   SYN_MT_SLOT 0
>>> +   ABS_MT_TRACKING_ID 45
>>> +   ABS_MT_POSITION_X x[0]
>>> +   ABS_MT_POSITION_Y y[0]
>>> +   ABS_MT_TRACKING_ID 46
>>> +   ABS_MT_POSITION_X x[1]
>>> +   ABS_MT_POSITION_Y y[1]
>>> +   ABS_MT_TRACKING_ID 47
>>> +   ABS_MT_POSITION_X x[2]
>>> +   ABS_MT_POSITION_Y y[2]
>>> +   SYN_MT_SLOT 1
>>> +   ABS_MT_TRACKING_ID 30
>>> +   ABS_MT_POSITION_X x[3]
>>> +   ABS_MT_POSITION_Y y[3]
>>> +   SYN_REPORT
>>>
>>> If my assumption is correct, i.e., one slot can have more than one
>>> point, I would think ABS_MT_TRACKING_ID may not have to be a required
>>> entry inside SYN_MT_SLOT.  To the user land clients/drivers,
>>> SYN_MT_SLOT itself could serve as an ID. So, the following case is
>>> also a type B ( we know there are two touch areas. But we don't keep
>>> track of the points inside the areas):
>>>
>>> +   SYN_MT_SLOT 0
>>> +   ABS_MT_POSITION_X x[0]
>>> +   ABS_MT_POSITION_Y y[0]
>>> +   ABS_MT_POSITION_X x[1]
>>> +   ABS_MT_POSITION_Y y[1]
>>> +   ABS_MT_POSITION_X x[2]
>>> +   ABS_MT_POSITION_Y y[2]
>>> +   SYN_MT_SLOT 1
>>> +   ABS_MT_POSITION_X x[3]
>>> +   ABS_MT_POSITION_Y y[3]
>>> +   SYN_REPORT
>>>
>>> So, an EVIO for X driver to retrieve the number of SLOTs would be very
>>> helpful.  Something like the following would do the work:
>>>
>>> input_set_abs_params(input_dev, ABS_MT_SLOT, 0, 12, 0, 0);
>>>
>>> which tells the user land clients that they can expect up to 13 touch areas.
>>>
>>>> +The main difference between the raw type A protocol and the higher level
>>>> +type B slot protocol lies in the usage of identifiable contacts. The slot
>>>> +protocol requires the use of the ABS_MT_TRACKING_ID,
>>>
>>> With what I said above, I think ABS_MT_TRACKING_ID is not the unique
>>> identifier for type B protocol. It is the fact that we can identify
>>> individual touch areas and use ABS_MT_SLOT to report them that makes
>>> it a type B event.
>>>
>>>> ABS_MT_TRACKING_ID, either provided by the
>>>> +hardware of computed from the raw data [5].
>>>                    ^^ or  (is it?)
>>>
>>> I agree with this ABS_MT_TRACKING_ID definition.  I would think something like:
>>>
>>> input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, 47, 0, 0);
>>>
>>> which tells the clients that total of 48 points are tracked, would be helpful.
>>>
>>> Another topic that may be irrelevant to this patch is the filter. With
>>> the use of ABS_MT_TRACKING_ID, a filter can be applied to discard the
>>> useless repeated points or less than a certain number of points
>>> movement.
>>>
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkv0g6UACgkQwuRiAT9o60927ACguoocWebY+/FxOvZ51Dx1WsAD
sa0AoJjiLuuQG1/kcx8k/D1O4TeiTa1k
=N7EH
-----END PGP SIGNATURE-----

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Wed, May 19, 2010 at 5:26 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/19/10 20:13, Ping Cheng wrote:
>> On Wed, May 19, 2010 at 4:34 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
>>> My understanding is that it would be more like
>>> +   SYN_MT_SLOT 0
>>> +   ABS_MT_POSITION_X x
>>> +   ABS_MT_POSITION_Y y
>>> +   SYN_REPORT
>>> +   SYN_MT_SLOT 0
>>> +   ABS_MT_POSITION_X x
>>> +   ABS_MT_POSITION_Y y
>>> +   SYN_REPORT
>>> +   SYN_MT_SLOT 0
>>> +   ABS_MT_POSITION_X x
>>> +   ABS_MT_POSITION_Y y
>>> +   SYN_MT_SLOT 1
>>> +   ABS_MT_POSITION_X x
>>> +   ABS_MT_POSITION_Y y
>>> +   SYN_REPORT
>>
>> You are right if one slot only has or is only allowed to have one
>> point. My scenario is that one slot can have more than one point.
>> Basically, my intention is to utilize the MT_SLOT and MT_TRACKING_ID
>> in such a way that it avoids as much overlap as possible.
>>
>> And hopefully it makes sesne in the reality too.
>
> Please clarify by what you mean by more than one point.

I might have been confused myself by ABS_MT_BLOB_ID and SYN_MT_SLOT
here.  What I meant by "more than one point" is a contact (or touch, I
am not sure which one is the right term :) is represented by a few
(x,y) coordinates. Maybe we should use SYN_MT_SLOT for my case?

> I may be misunderstanding, but I thought that these slots are basically a
> superior replacement to tracking id.
>
> one finger -> one slot

This is what I needed to understand. Is slot for one (x,y) only or can
it also be used for more than one set of (x,y)?

> But with slots we can use the filtering that input provides, which we've been
> by-passing with the existing MT protocol (at least that's what I think Henrik's
> goal is).

Good to know that filtering has already been considered. I know I must
be out of sync with Henrik's goal.  That's why I wanted to show my
ignorance :).

Ping

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Wed, May 19, 2010 at 5:26 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/19/10 20:13, Ping Cheng wrote:
>> On Wed, May 19, 2010 at 4:34 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
>>> My understanding is that it would be more like
>>> +   SYN_MT_SLOT 0
>>> +   ABS_MT_POSITION_X x
>>> +   ABS_MT_POSITION_Y y
>>> +   SYN_REPORT
>>> +   SYN_MT_SLOT 0
>>> +   ABS_MT_POSITION_X x
>>> +   ABS_MT_POSITION_Y y
>>> +   SYN_REPORT
>>> +   SYN_MT_SLOT 0
>>> +   ABS_MT_POSITION_X x
>>> +   ABS_MT_POSITION_Y y
>>> +   SYN_MT_SLOT 1
>>> +   ABS_MT_POSITION_X x
>>> +   ABS_MT_POSITION_Y y
>>> +   SYN_REPORT
>>
>> You are right if one slot only has or is only allowed to have one
>> point. My scenario is that one slot can have more than one point.
>> Basically, my intention is to utilize the MT_SLOT and MT_TRACKING_ID
>> in such a way that it avoids as much overlap as possible.
>>
>> And hopefully it makes sesne in the reality too.
>
> Please clarify by what you mean by more than one point.

I might have been confused myself by ABS_MT_BLOB_ID and SYN_MT_SLOT
here.  What I meant by "more than one point" is a contact (or touch, I
am not sure which one is the right term :) is represented by a few
(x,y) coordinates. Maybe we should use SYN_MT_SLOT for my case?

> I may be misunderstanding, but I thought that these slots are basically a
> superior replacement to tracking id.
>
> one finger -> one slot

This is what I needed to understand. Is slot for one (x,y) only or can
it also be used for more than one set of (x,y)?

> But with slots we can use the filtering that input provides, which we've been
> by-passing with the existing MT protocol (at least that's what I think Henrik's
> goal is).

Good to know that filtering has already been considered. I know I must
be out of sync with Henrik's goal.  That's why I wanted to show my
ignorance :).

Ping
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Rafi Rubin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/19/10 20:51, Ping Cheng wrote:
> On Wed, May 19, 2010 at 5:26 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 05/19/10 20:13, Ping Cheng wrote:
>>> On Wed, May 19, 2010 at 4:34 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
>>>> My understanding is that it would be more like
>>>> +   SYN_MT_SLOT 0
>>>> +   ABS_MT_POSITION_X x
>>>> +   ABS_MT_POSITION_Y y
>>>> +   SYN_REPORT
>>>> +   SYN_MT_SLOT 0
>>>> +   ABS_MT_POSITION_X x
>>>> +   ABS_MT_POSITION_Y y
>>>> +   SYN_REPORT
>>>> +   SYN_MT_SLOT 0
>>>> +   ABS_MT_POSITION_X x
>>>> +   ABS_MT_POSITION_Y y
>>>> +   SYN_MT_SLOT 1
>>>> +   ABS_MT_POSITION_X x
>>>> +   ABS_MT_POSITION_Y y
>>>> +   SYN_REPORT
>>>
>>> You are right if one slot only has or is only allowed to have one
>>> point. My scenario is that one slot can have more than one point.
>>> Basically, my intention is to utilize the MT_SLOT and MT_TRACKING_ID
>>> in such a way that it avoids as much overlap as possible.
>>>
>>> And hopefully it makes sesne in the reality too.
>>
>> Please clarify by what you mean by more than one point.
> 
> I might have been confused myself by ABS_MT_BLOB_ID and SYN_MT_SLOT
> here.  What I meant by "more than one point" is a contact (or touch, I
> am not sure which one is the right term :) is represented by a few
> (x,y) coordinates. Maybe we should use SYN_MT_SLOT for my case?
> 
>> I may be misunderstanding, but I thought that these slots are basically a
>> superior replacement to tracking id.
>>
>> one finger -> one slot
> 
> This is what I needed to understand. Is slot for one (x,y) only or can
> it also be used for more than one set of (x,y)?
> 
>> But with slots we can use the filtering that input provides, which we've been
>> by-passing with the existing MT protocol (at least that's what I think Henrik's
>> goal is).
> 
> Good to know that filtering has already been considered. I know I must
> be out of sync with Henrik's goal.  That's why I wanted to show my
> ignorance :).
> 
> Ping
> 

Hey, sometimes Mark Twain's old advice is good, and sometimes its not.

It's better to keep your mouth shut and be thought a fool than to open it and
leave no doubt. --Mark Twain


I think this is definitely a case where he's wrong.  We need to sync up so that
we're all implementing the same protocol, and can move on to the next
interesting problem.

Rafi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkv0ik4ACgkQwuRiAT9o608XmQCdFiTOymC+OEVyQ+atbEdpCiDd
RRYAoIsNpOZpI0Yxr4BG1uEj7Fja2Fyo
=lK01
-----END PGP SIGNATURE-----

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Wed, May 19, 2010 at 6:03 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/19/10 20:51, Ping Cheng wrote:
>> On Wed, May 19, 2010 at 5:26 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 05/19/10 20:13, Ping Cheng wrote:
>>>> On Wed, May 19, 2010 at 4:34 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
>>>>> My understanding is that it would be more like
>>>>> +   SYN_MT_SLOT 0
>>>>> +   ABS_MT_POSITION_X x
>>>>> +   ABS_MT_POSITION_Y y
>>>>> +   SYN_REPORT
>>>>> +   SYN_MT_SLOT 0
>>>>> +   ABS_MT_POSITION_X x
>>>>> +   ABS_MT_POSITION_Y y
>>>>> +   SYN_REPORT
>>>>> +   SYN_MT_SLOT 0
>>>>> +   ABS_MT_POSITION_X x
>>>>> +   ABS_MT_POSITION_Y y
>>>>> +   SYN_MT_SLOT 1
>>>>> +   ABS_MT_POSITION_X x
>>>>> +   ABS_MT_POSITION_Y y
>>>>> +   SYN_REPORT
>>>>
>>>> You are right if one slot only has or is only allowed to have one
>>>> point. My scenario is that one slot can have more than one point.
>>>> Basically, my intention is to utilize the MT_SLOT and MT_TRACKING_ID
>>>> in such a way that it avoids as much overlap as possible.
>>>>
>>>> And hopefully it makes sesne in the reality too.
>>>
>>> Please clarify by what you mean by more than one point.
>>
>> I might have been confused myself by ABS_MT_BLOB_ID and SYN_MT_SLOT
>> here.  What I meant by "more than one point" is a contact (or touch, I
>> am not sure which one is the right term :) is represented by a few
>> (x,y) coordinates. Maybe we should use SYN_MT_SLOT for my case?

The last sentence above should be "Maybe we should NOT use SYN_MT_SLOT
for my case?" or "Maybe I should use MT_BLOB_ID for that case?". A
typical typo for those whose hands are slower than their brains :).

>>> I may be misunderstanding, but I thought that these slots are basically a
>>> superior replacement to tracking id.
>>>
>>> one finger -> one slot
>>
>> This is what I needed to understand. Is slot for one (x,y) only or can
>> it also be used for more than one set of (x,y)?
>>
>>> But with slots we can use the filtering that input provides, which we've been
>>> by-passing with the existing MT protocol (at least that's what I think Henrik's
>>> goal is).
>>
>> Good to know that filtering has already been considered. I know I must
>> be out of sync with Henrik's goal.  That's why I wanted to show my
>> ignorance :).
>>
>> Ping
>>
>
> Hey, sometimes Mark Twain's old advice is good, and sometimes its not.
>
> It's better to keep your mouth shut and be thought a fool than to open it and
> leave no doubt. --Mark Twain
>
>
> I think this is definitely a case where he's wrong.  We need to sync up so that
> we're all implementing the same protocol, and can move on to the next
> interesting problem.

I hope this is the common goal for everyone who has been involved in
the _MT_ support.

Ping

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Wed, May 19, 2010 at 6:03 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/19/10 20:51, Ping Cheng wrote:
>> On Wed, May 19, 2010 at 5:26 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 05/19/10 20:13, Ping Cheng wrote:
>>>> On Wed, May 19, 2010 at 4:34 PM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
>>>>> My understanding is that it would be more like
>>>>> +   SYN_MT_SLOT 0
>>>>> +   ABS_MT_POSITION_X x
>>>>> +   ABS_MT_POSITION_Y y
>>>>> +   SYN_REPORT
>>>>> +   SYN_MT_SLOT 0
>>>>> +   ABS_MT_POSITION_X x
>>>>> +   ABS_MT_POSITION_Y y
>>>>> +   SYN_REPORT
>>>>> +   SYN_MT_SLOT 0
>>>>> +   ABS_MT_POSITION_X x
>>>>> +   ABS_MT_POSITION_Y y
>>>>> +   SYN_MT_SLOT 1
>>>>> +   ABS_MT_POSITION_X x
>>>>> +   ABS_MT_POSITION_Y y
>>>>> +   SYN_REPORT
>>>>
>>>> You are right if one slot only has or is only allowed to have one
>>>> point. My scenario is that one slot can have more than one point.
>>>> Basically, my intention is to utilize the MT_SLOT and MT_TRACKING_ID
>>>> in such a way that it avoids as much overlap as possible.
>>>>
>>>> And hopefully it makes sesne in the reality too.
>>>
>>> Please clarify by what you mean by more than one point.
>>
>> I might have been confused myself by ABS_MT_BLOB_ID and SYN_MT_SLOT
>> here.  What I meant by "more than one point" is a contact (or touch, I
>> am not sure which one is the right term :) is represented by a few
>> (x,y) coordinates. Maybe we should use SYN_MT_SLOT for my case?

The last sentence above should be "Maybe we should NOT use SYN_MT_SLOT
for my case?" or "Maybe I should use MT_BLOB_ID for that case?". A
typical typo for those whose hands are slower than their brains :).

>>> I may be misunderstanding, but I thought that these slots are basically a
>>> superior replacement to tracking id.
>>>
>>> one finger -> one slot
>>
>> This is what I needed to understand. Is slot for one (x,y) only or can
>> it also be used for more than one set of (x,y)?
>>
>>> But with slots we can use the filtering that input provides, which we've been
>>> by-passing with the existing MT protocol (at least that's what I think Henrik's
>>> goal is).
>>
>> Good to know that filtering has already been considered. I know I must
>> be out of sync with Henrik's goal.  That's why I wanted to show my
>> ignorance :).
>>
>> Ping
>>
>
> Hey, sometimes Mark Twain's old advice is good, and sometimes its not.
>
> It's better to keep your mouth shut and be thought a fool than to open it and
> leave no doubt. --Mark Twain
>
>
> I think this is definitely a case where he's wrong.  We need to sync up so that
> we're all implementing the same protocol, and can move on to the next
> interesting problem.

I hope this is the common goal for everyone who has been involved in
the _MT_ support.

Ping
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Henrik Rydberg]

Ping Cheng wrote:
> Hi Henrik,
> 
> I am trying to link the protocol to the actual multi-touch devices in
> my "mind". Hope it helps you to point out the mismatch between my
> imagination and the protocol.  Please see details in line.
> 
> Ping

Hi Ping,

first out, thank you for your detailed analysis, it aids in removing ambiguities
 and defining the borders of the protocol.

> Am I right in thinking that SYN_MT_SLOT represents to the actual touch
> area/finger on the surface? There could be more than one (x,y) (a few
> points that form an irregular shape) that represents one finger.  The
> following example shows that slot 0 (finger 1) touched three points on
> the surface while slot 1 (finger 2) only has one point reported:
> 
> +   SYN_MT_SLOT 0
> +   ABS_MT_TRACKING_ID 45
> +   ABS_MT_POSITION_X x[0]
> +   ABS_MT_POSITION_Y y[0]
> +   ABS_MT_TRACKING_ID 46
> +   ABS_MT_POSITION_X x[1]
> +   ABS_MT_POSITION_Y y[1]
> +   ABS_MT_TRACKING_ID 47
> +   ABS_MT_POSITION_X x[2]
> +   ABS_MT_POSITION_Y y[2]
> +   SYN_MT_SLOT 1
> +   ABS_MT_TRACKING_ID 30
> +   ABS_MT_POSITION_X x[3]
> +   ABS_MT_POSITION_Y y[3]
> +   SYN_REPORT
> 

It helps to think of both TRACKING_ID and BLOB_ID as labels of a single
identified contact which occupies one slot. To represent a set of contacts as an
entity, one needs to add a label to the slot, representing that entity. As
pointed out in a later reply by Peter, the BLOB_ID serves this purpose well. The
name is slightly unfortunate, being a bit too generic. Let us use this
discussion to pin down a more exact definition:

ABS_MT_BLOB_ID is a label which groups contacts in close relation to each other,
such as a hand.

With this in mind, the sequence becomes

SYN_MT_SLOT 0
ABS_MT_BLOB_ID 11
ABS_MT_TRACKING_ID 45
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
SYN_MT_SLOT 1
ABS_MT_BLOB_ID 11
ABS_MT_TRACKING_ID 46
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]
SYN_MT_SLOT 2
ABS_MT_BLOB_ID 11
ABS_MT_TRACKING_ID 47
ABS_MT_POSITION_X x[2]
ABS_MT_POSITION_Y y[2]
SYN_MT_SLOT 3
ABS_MT_BLOB_ID 89
ABS_MT_TRACKING_ID 30
ABS_MT_POSITION_X x[3]
ABS_MT_POSITION_Y y[3]
SYN_REPORT

Here, we are looking at one blob (11) consisting of three contacts (45, 46, 47),
and another blob (89) consisting of one contact (30).

[...]
> So, an EVIO for X driver to retrieve the number of SLOTs would be very
> helpful.  Something like the following would do the work:
> 
> input_set_abs_params(input_dev, ABS_MT_SLOT, 0, 12, 0, 0);
> 
> which tells the user land clients that they can expect up to 13 touch areas.

The SYN_MT_SLOT is a synchronization control event (EV_SYN), so it would require
a different way to report value ranges, but the idea is sound. I will think
about how to achieve this.

>> +The main difference between the raw type A protocol and the higher level
>> +type B slot protocol lies in the usage of identifiable contacts. The slot
>> +protocol requires the use of the ABS_MT_TRACKING_ID,
> 
> With what I said above, I think ABS_MT_TRACKING_ID is not the unique
> identifier for type B protocol. It is the fact that we can identify
> individual touch areas and use ABS_MT_SLOT to report them that makes
> it a type B event.

This is correct, but the TRACKING_ID is strong evidence that the device is
capable of identifying contacts.

>> ABS_MT_TRACKING_ID, either provided by the
>> +hardware of computed from the raw data [5].
>                    ^^ or  (is it?)
> 
> I agree with this ABS_MT_TRACKING_ID definition.  I would think something like:
> 
> input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, 47, 0, 0);
> 
> which tells the clients that total of 48 points are tracked, would be helpful.

Agreed.

> Another topic that may be irrelevant to this patch is the filter. With
> the use of ABS_MT_TRACKING_ID, a filter can be applied to discard the
> useless repeated points or less than a certain number of points
> movement.

As pointed out by Rafi in a later post, this is indeed one of the major points
of the slot protocol. The filtering details can be found in the patch
accompanying this documentation.

Cheers,
Henrik

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Dmitry Torokhov]

On Thu, May 20, 2010 at 10:13:24AM +1000, Peter Hutterer wrote:
> On Wed, May 19, 2010 at 02:12:14PM +0200, Henrik Rydberg wrote:
> > Peter Hutterer wrote:
> > > On Tue, May 18, 2010 at 10:10:29PM +0200, Henrik Rydberg wrote:
> > >> This patch adds documentation for the SYN_MT_SLOT event and gives
> > >> examples of how to use the event slot protocol.
> > > 
> > > thanks, this is really nice documentation! the approach seems good, though I
> > > do have a few questions inline.
> > > 
> > [...]
> > > 
> > > Is there a limit on the number of slots?
> > 
> > The slots are dynamically allocated by the driver, so there is no practical
> > limit. Each slot currently takes 44 bytes, and allocating a few kilobytes of
> > kernel memory is not a problem.
> > 
> > > Will all drivers with ABS_MT_TRACKING_ID use slots? if not, how can I know
> > > in advance if a device may use slots or not?
> > 
> > Eventually, this might become true, but you are pointing at one of the weaker
> > points of the current setup. There is no bit field for the EV_SYN events, so
> > there is no way to know in advance if SYN_MT_SYNC or SYN_MT_SLOT is used. This
> > could quite possibly be added to the EVIO interface. Meanwhile, the method I use
> > is to detect the first SYN_MT_SLOT and select parser based on that information.
> 
> I'd really prefer if there was some way to detect this. While I'm not quite
> sure how the matching X drivers would look like it's likely that the setups
> will be different for drivers that support slots and those that don't.
> e.g. those that don't have slots simply send events as valuators, those that
> do may split into multiple devices.
> 
> Doing this at runtime - after the device has been set up is...tricky.
> 

Right, I think we should try our hardest to allow userspace base
protocol decoding decisions on device capabilities and not the event
datastream. What about moving from SYN_MT_SLOT to ABS_MT_SLOT? I think
it makes more sense since it is not a simple marker but carries data
(slot number).

-- 
Dmitry

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Henrik Rydberg]

Peter Hutterer wrote:
[...]
>>> Will all drivers with ABS_MT_TRACKING_ID use slots? if not, how can I know
>>> in advance if a device may use slots or not?
>> Eventually, this might become true, but you are pointing at one of the weaker
>> points of the current setup. There is no bit field for the EV_SYN events, so
>> there is no way to know in advance if SYN_MT_SYNC or SYN_MT_SLOT is used. This
>> could quite possibly be added to the EVIO interface. Meanwhile, the method I use
>> is to detect the first SYN_MT_SLOT and select parser based on that information.
> 
> I'd really prefer if there was some way to detect this. While I'm not quite
> sure how the matching X drivers would look like it's likely that the setups
> will be different for drivers that support slots and those that don't.
> e.g. those that don't have slots simply send events as valuators, those that
> do may split into multiple devices.
> 
> Doing this at runtime - after the device has been set up is...tricky.

Changing SYN_MT_SLOT to ABS_MT_SLOT will take care of this.

>> If you are thinking of a setup where one program is already hooked up to the
>> device, and a new one comes in just as the message in question appears on the
>> wire, it just means the new program will have to spend some time catching up. If
>> this should ever become a problem, one could possibly add a send-full-state
>> method to the input layer, to be issued when the new program opens the device. I
>> doubt this will be needed in practice though, since contacts change all the time.
> 
> This was the case I was wondering about. While I agree with the last part
> (contacts change all the time) the side-effect that you'll get from this is
> that devices can seemingly be non-responsive for random periods of time.
> 
> If you have a finger down when the X server starts or after a VT switch (or
> even a fast user switch), the driver will have to drop events. So you can
> wriggle your finger around and nothing happens, but once you lift it goes
> "well, now it works again". Since this happens only once in a while, it can
> make the whole lot appear flaky.  Especially if one finger works and the
> other one doesn't.
>
> So I guess it comes down to whether sending SYN_MT_SLOT with every event
> costs too much compared to these admittedly rare use-cases. They're not much
> different to the current button events either, if you weren't there when a
> button was pressed you won't know. So I'm somewhat indifferent about this
> bit.

Yes, it is a inherent property of the input protocol between the kernel and user
space. A different problem, in other words.

> And yes, you could add it once we find it's an issue, but by then someone
> has already spent time to work around this. And when you then start sending
> slot events all the time, you admit that writing the workaround was just a
> time waster :)

Work around what, exactly?

>> As a side note, the notion of a used slot depends on how the attributes of the
>> slot are interpreted. The method described in the document treats an
>> ABS_MT_TRACKING_ID value outside of the driver-specified value range as an
>> unused slot.
> 
> It's easier for a latecomer to guess a tracking ID since you can just
> assign any random value to it, provided the kernel guarantees to only send
> updates on the tracking ID for changes. This doesn't quite work for slots.
> 
> But I'm not sure what your last sentence means. Does this mean the kernel
> will open a new slot for out-of-range tracking IDs? I'm missing something
> here.

I am referring to the notion of create-move-destroy from earlier discussions,
and the question of how it is implemented using slots. The document is a bit
unclear on this point, so I will add a note stating something like this:

* Every slot with a tracking id within the value range represents a contact.

* Tracking ids not previously present are considered new.

* Tracking ids no longer present are considered removed.

Cheers,
Henrik

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Henrik Rydberg]

Dmitry Torokhov wrote:
>>>> Will all drivers with ABS_MT_TRACKING_ID use slots? if not, how can I know
>>>> in advance if a device may use slots or not?
>>> Eventually, this might become true, but you are pointing at one of the weaker
>>> points of the current setup. There is no bit field for the EV_SYN events, so
>>> there is no way to know in advance if SYN_MT_SYNC or SYN_MT_SLOT is used. This
>>> could quite possibly be added to the EVIO interface. Meanwhile, the method I use
>>> is to detect the first SYN_MT_SLOT and select parser based on that information.
>> I'd really prefer if there was some way to detect this. While I'm not quite
>> sure how the matching X drivers would look like it's likely that the setups
>> will be different for drivers that support slots and those that don't.
>> e.g. those that don't have slots simply send events as valuators, those that
>> do may split into multiple devices.
>>
>> Doing this at runtime - after the device has been set up is...tricky.
>>
> 
> Right, I think we should try our hardest to allow userspace base
> protocol decoding decisions on device capabilities and not the event
> datastream. What about moving from SYN_MT_SLOT to ABS_MT_SLOT? I think
> it makes more sense since it is not a simple marker but carries data
> (slot number).

I agree, it both makes sense and resolves two issues. Will change.

Cheers,
Henrik

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Thu, May 20, 2010 at 12:08 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> Hi Ping,
>
> first out, thank you for your detailed analysis, it aids in removing ambiguities
>  and defining the borders of the protocol.

Glad to hear from you directly this time :). I have more questions.

> It helps to think of both TRACKING_ID and BLOB_ID as labels of a single
> identified contact which occupies one slot.

I need double check with you although I think I know the answer. From
your explanation and examples so far, I see MT_SLOT is only associated
with one (x,y). Is this true?  If yes, can we eliminate the
requirement for TRACKING_ID? If you think the requirement is
necessary, can you give me an example where missing the TRACKING_ID
would bring issue or confusion?

>To represent a set of contacts as an
> entity, one needs to add a label to the slot, representing that entity.

Doesn't MT_SLOT itself serves as a label? It has a value.  May be
ABS_MT_SLOT_ID fits the term more closely.

> As pointed out in a later reply by Peter, the BLOB_ID serves this purpose well. The
> name is slightly unfortunate, being a bit too generic. Let us use this
> discussion to pin down a more exact definition:
>
> ABS_MT_BLOB_ID is a label which groups contacts in close relation to each other,
> such as a hand.

I think I get this part.  However, (too late to regret that you've
replied to me :)

> With this in mind, the sequence becomes
>
> SYN_MT_SLOT 0
> ABS_MT_BLOB_ID 11
> ABS_MT_TRACKING_ID 45
> ABS_MT_POSITION_X x[0]
> ABS_MT_POSITION_Y y[0]
> SYN_MT_SLOT 1
> ABS_MT_BLOB_ID 11
> ABS_MT_TRACKING_ID 46
> ABS_MT_POSITION_X x[1]
> ABS_MT_POSITION_Y y[1]
> SYN_MT_SLOT 2
> ABS_MT_BLOB_ID 11
> ABS_MT_TRACKING_ID 47
> ABS_MT_POSITION_X x[2]
> ABS_MT_POSITION_Y y[2]
> SYN_MT_SLOT 3
> ABS_MT_BLOB_ID 89
> ABS_MT_TRACKING_ID 30
> ABS_MT_POSITION_X x[3]
> ABS_MT_POSITION_Y y[3]
> SYN_REPORT

I would think something like the following would make sense too:

ABS_MT_BLOB_ID 11
ABS_MT_TRACKING_ID 45
ABS_MT_SLOT_ID 0
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
ABS_MT_SLOT_ID 1
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]
ABS_MT_SLOT_ID 2
ABS_MT_POSITION_X x[2]
ABS_MT_POSITION_Y y[2]
SYN_MT_BLOB
ABS_MT_BLOB_ID 89
ABS_MT_SLOT_ID 3
ABS_MT_TRACKING_ID 30
ABS_MT_POSITION_X x[3]
ABS_MT_POSITION_Y y[3]
SYN_MT_BLOB
SYN_REPORT

where we have two blob of data. They represent finger 1 and finger 2.
Finger 1 has a tracking number 11 while finger 2 has 30.  We do not
track the three contacts inside the blob since they all belong to the
same finger.  We could even combine type A and B as:

ABS_MT_TRACKING_ID 0      # indicates first finger or hand
ABS_MT_BLOB 3                     # indicates 3 contacts in the blob
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
SYN_MT_REPORT
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]
SYN_MT_REPORT
ABS_MT_POSITION_X x[2]
ABS_MT_POSITION_Y y[2]
SYN_MT_REPORT
ABS_MT_TRACKING_ID 1      # indicates second finger or hand
ABS_MT_BLOB_ID 1               # indicates 1 contact in the blob
ABS_MT_POSITION_X x[3]
ABS_MT_POSITION_Y y[3]
SYN_REPORT

where SYN_MT_BLOB is unnecessary since we know how many contacts we
are going to get. I would expect this approach complicates the
implementation in the kernel. So I am not sure if it makes sense to
use it or not.  Just to share some random thoughts with you.

Ping

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Thu, May 20, 2010 at 12:08 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> Hi Ping,
>
> first out, thank you for your detailed analysis, it aids in removing ambiguities
>  and defining the borders of the protocol.

Glad to hear from you directly this time :). I have more questions.

> It helps to think of both TRACKING_ID and BLOB_ID as labels of a single
> identified contact which occupies one slot.

I need double check with you although I think I know the answer. From
your explanation and examples so far, I see MT_SLOT is only associated
with one (x,y). Is this true?  If yes, can we eliminate the
requirement for TRACKING_ID? If you think the requirement is
necessary, can you give me an example where missing the TRACKING_ID
would bring issue or confusion?

>To represent a set of contacts as an
> entity, one needs to add a label to the slot, representing that entity.

Doesn't MT_SLOT itself serves as a label? It has a value.  May be
ABS_MT_SLOT_ID fits the term more closely.

> As pointed out in a later reply by Peter, the BLOB_ID serves this purpose well. The
> name is slightly unfortunate, being a bit too generic. Let us use this
> discussion to pin down a more exact definition:
>
> ABS_MT_BLOB_ID is a label which groups contacts in close relation to each other,
> such as a hand.

I think I get this part.  However, (too late to regret that you've
replied to me :)

> With this in mind, the sequence becomes
>
> SYN_MT_SLOT 0
> ABS_MT_BLOB_ID 11
> ABS_MT_TRACKING_ID 45
> ABS_MT_POSITION_X x[0]
> ABS_MT_POSITION_Y y[0]
> SYN_MT_SLOT 1
> ABS_MT_BLOB_ID 11
> ABS_MT_TRACKING_ID 46
> ABS_MT_POSITION_X x[1]
> ABS_MT_POSITION_Y y[1]
> SYN_MT_SLOT 2
> ABS_MT_BLOB_ID 11
> ABS_MT_TRACKING_ID 47
> ABS_MT_POSITION_X x[2]
> ABS_MT_POSITION_Y y[2]
> SYN_MT_SLOT 3
> ABS_MT_BLOB_ID 89
> ABS_MT_TRACKING_ID 30
> ABS_MT_POSITION_X x[3]
> ABS_MT_POSITION_Y y[3]
> SYN_REPORT

I would think something like the following would make sense too:

ABS_MT_BLOB_ID 11
ABS_MT_TRACKING_ID 45
ABS_MT_SLOT_ID 0
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
ABS_MT_SLOT_ID 1
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]
ABS_MT_SLOT_ID 2
ABS_MT_POSITION_X x[2]
ABS_MT_POSITION_Y y[2]
SYN_MT_BLOB
ABS_MT_BLOB_ID 89
ABS_MT_SLOT_ID 3
ABS_MT_TRACKING_ID 30
ABS_MT_POSITION_X x[3]
ABS_MT_POSITION_Y y[3]
SYN_MT_BLOB
SYN_REPORT

where we have two blob of data. They represent finger 1 and finger 2.
Finger 1 has a tracking number 11 while finger 2 has 30.  We do not
track the three contacts inside the blob since they all belong to the
same finger.  We could even combine type A and B as:

ABS_MT_TRACKING_ID 0      # indicates first finger or hand
ABS_MT_BLOB 3                     # indicates 3 contacts in the blob
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
SYN_MT_REPORT
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]
SYN_MT_REPORT
ABS_MT_POSITION_X x[2]
ABS_MT_POSITION_Y y[2]
SYN_MT_REPORT
ABS_MT_TRACKING_ID 1      # indicates second finger or hand
ABS_MT_BLOB_ID 1               # indicates 1 contact in the blob
ABS_MT_POSITION_X x[3]
ABS_MT_POSITION_Y y[3]
SYN_REPORT

where SYN_MT_BLOB is unnecessary since we know how many contacts we
are going to get. I would expect this approach complicates the
implementation in the kernel. So I am not sure if it makes sense to
use it or not.  Just to share some random thoughts with you.

Ping
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Henrik Rydberg]

Ping Cheng wrote:
> On Thu, May 20, 2010 at 12:08 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
>> Hi Ping,
>>
>> first out, thank you for your detailed analysis, it aids in removing ambiguities
>>  and defining the borders of the protocol.
> 
> Glad to hear from you directly this time :). I have more questions.
> 
>> It helps to think of both TRACKING_ID and BLOB_ID as labels of a single
>> identified contact which occupies one slot.
> 
> I need double check with you although I think I know the answer. From
> your explanation and examples so far, I see MT_SLOT is only associated
> with one (x,y). Is this true?  If yes, can we eliminate the
> requirement for TRACKING_ID? If you think the requirement is
> necessary, can you give me an example where missing the TRACKING_ID
> would bring issue or confusion?

Yes, each slot can only be associated with one (x, y) pair. No, we cannot
disregard the tracking id. A slot tracks a single contact for its entire
lifetime, during which the tracking id serves no purpose, but the slot cannot
tell us when the contact is replaced by a new one. This information is carried
by the tracking id.

> 
>> To represent a set of contacts as an
>> entity, one needs to add a label to the slot, representing that entity.
> 
> Doesn't MT_SLOT itself serves as a label? It has a value.  May be
> ABS_MT_SLOT_ID fits the term more closely.

The slot id tells which slot is currently being modified, and carries no
information about the slot itself. To represent a relation between different
contacts, a value representing that relation needs to be added to the event
stream, there is no doubt about that. The BLOB_ID is such a label, and there
will likely be others in the future as well.

> 
>> As pointed out in a later reply by Peter, the BLOB_ID serves this purpose well. The
>> name is slightly unfortunate, being a bit too generic. Let us use this
>> discussion to pin down a more exact definition:
>>
>> ABS_MT_BLOB_ID is a label which groups contacts in close relation to each other,
>> such as a hand.
> 
> I think I get this part.  However, (too late to regret that you've
> replied to me :)
> 
>> With this in mind, the sequence becomes
>>
>> SYN_MT_SLOT 0
>> ABS_MT_BLOB_ID 11
>> ABS_MT_TRACKING_ID 45
>> ABS_MT_POSITION_X x[0]
>> ABS_MT_POSITION_Y y[0]
>> SYN_MT_SLOT 1
>> ABS_MT_BLOB_ID 11
>> ABS_MT_TRACKING_ID 46
>> ABS_MT_POSITION_X x[1]
>> ABS_MT_POSITION_Y y[1]
>> SYN_MT_SLOT 2
>> ABS_MT_BLOB_ID 11
>> ABS_MT_TRACKING_ID 47
>> ABS_MT_POSITION_X x[2]
>> ABS_MT_POSITION_Y y[2]
>> SYN_MT_SLOT 3
>> ABS_MT_BLOB_ID 89
>> ABS_MT_TRACKING_ID 30
>> ABS_MT_POSITION_X x[3]
>> ABS_MT_POSITION_Y y[3]
>> SYN_REPORT
> 
> I would think something like the following would make sense too:
> 
> ABS_MT_BLOB_ID 11
> ABS_MT_TRACKING_ID 45
> ABS_MT_SLOT_ID 0
> ABS_MT_POSITION_X x[0]
> ABS_MT_POSITION_Y y[0]
> ABS_MT_SLOT_ID 1
> ABS_MT_POSITION_X x[1]
> ABS_MT_POSITION_Y y[1]
> ABS_MT_SLOT_ID 2
> ABS_MT_POSITION_X x[2]
> ABS_MT_POSITION_Y y[2]
> SYN_MT_BLOB
> ABS_MT_BLOB_ID 89
> ABS_MT_SLOT_ID 3
> ABS_MT_TRACKING_ID 30
> ABS_MT_POSITION_X x[3]
> ABS_MT_POSITION_Y y[3]
> SYN_MT_BLOB
> SYN_REPORT
> 
> where we have two blob of data. They represent finger 1 and finger 2.
> Finger 1 has a tracking number 11 while finger 2 has 30.  We do not
> track the three contacts inside the blob since they all belong to the
> same finger.  We could even combine type A and B as:

Well, the way the protocol is defined, SYN_MT_BLOB does not exist, and any
attribute change outside the slot id context simply has no meaning.

> 
> ABS_MT_TRACKING_ID 0      # indicates first finger or hand
> ABS_MT_BLOB 3                     # indicates 3 contacts in the blob
> ABS_MT_POSITION_X x[0]
> ABS_MT_POSITION_Y y[0]
> SYN_MT_REPORT
> ABS_MT_POSITION_X x[1]
> ABS_MT_POSITION_Y y[1]
> SYN_MT_REPORT
> ABS_MT_POSITION_X x[2]
> ABS_MT_POSITION_Y y[2]
> SYN_MT_REPORT
> ABS_MT_TRACKING_ID 1      # indicates second finger or hand
> ABS_MT_BLOB_ID 1               # indicates 1 contact in the blob
> ABS_MT_POSITION_X x[3]
> ABS_MT_POSITION_Y y[3]
> SYN_REPORT
> 
> where SYN_MT_BLOB is unnecessary since we know how many contacts we
> are going to get. I would expect this approach complicates the
> implementation in the kernel. So I am not sure if it makes sense to
> use it or not.  Just to share some random thoughts with you.

Thank you for your random suggestions.

Henrik

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Thu, May 20, 2010 at 3:48 PM, Henrik Rydberg <rydberg@euromail.se> wrote:
>> I need double check with you although I think I know the answer. From
>> your explanation and examples so far, I see MT_SLOT is only associated
>> with one (x,y). Is this true?  If yes, can we eliminate the
>> requirement for TRACKING_ID? If you think the requirement is
>> necessary, can you give me an example where missing the TRACKING_ID
>> would bring issue or confusion?
>
> Yes, each slot can only be associated with one (x, y) pair. No, we cannot
> disregard the tracking id. A slot tracks a single contact for its entire
> lifetime, during which the tracking id serves no purpose, but the slot cannot
> tell us when the contact is replaced by a new one. This information is carried
> by the tracking id.

Ok, I've made enough noise in this thread. If we change SYN_MT_SLOT to
ABS_MT_SLOT_ID (or something starting with ABS_ of your choice), I
have no more questions.

You can put my reviewed-by in the patch if that counts for anything:

Reviewed-by: Ping Cheng <pingc@wacom.com>

Ping

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Thu, May 20, 2010 at 3:48 PM, Henrik Rydberg <rydberg@euromail.se> wrote:
>> I need double check with you although I think I know the answer. From
>> your explanation and examples so far, I see MT_SLOT is only associated
>> with one (x,y). Is this true?  If yes, can we eliminate the
>> requirement for TRACKING_ID? If you think the requirement is
>> necessary, can you give me an example where missing the TRACKING_ID
>> would bring issue or confusion?
>
> Yes, each slot can only be associated with one (x, y) pair. No, we cannot
> disregard the tracking id. A slot tracks a single contact for its entire
> lifetime, during which the tracking id serves no purpose, but the slot cannot
> tell us when the contact is replaced by a new one. This information is carried
> by the tracking id.

Ok, I've made enough noise in this thread. If we change SYN_MT_SLOT to
ABS_MT_SLOT_ID (or something starting with ABS_ of your choice), I
have no more questions.

You can put my reviewed-by in the patch if that counts for anything:

Reviewed-by: Ping Cheng <pingc@wacom.com>

Ping
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Rafi Rubin]

> ABS_MT_BLOB_ID 11
> ABS_MT_TRACKING_ID 45
> ABS_MT_SLOT_ID 0
> ABS_MT_POSITION_X x[0]
> ABS_MT_POSITION_Y y[0]
> ABS_MT_SLOT_ID 1
> ABS_MT_POSITION_X x[1]
> ABS_MT_POSITION_Y y[1]
> ABS_MT_SLOT_ID 2
> ABS_MT_POSITION_X x[2]
> ABS_MT_POSITION_Y y[2]
> SYN_MT_BLOB
> ABS_MT_BLOB_ID 89
> ABS_MT_SLOT_ID 3
> ABS_MT_TRACKING_ID 30
> ABS_MT_POSITION_X x[3]
> ABS_MT_POSITION_Y y[3]
> SYN_MT_BLOB
> SYN_REPORT
>
> where we have two blob of data. They represent finger 1 and finger 2.
> Finger 1 has a tracking number 11 while finger 2 has 30.  We do not
> track the three contacts inside the blob since they all belong to the
> same finger.  We could even combine type A and B as:

???

Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions?

Rafi

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Rafi Rubin]

> ABS_MT_BLOB_ID 11
> ABS_MT_TRACKING_ID 45
> ABS_MT_SLOT_ID 0
> ABS_MT_POSITION_X x[0]
> ABS_MT_POSITION_Y y[0]
> ABS_MT_SLOT_ID 1
> ABS_MT_POSITION_X x[1]
> ABS_MT_POSITION_Y y[1]
> ABS_MT_SLOT_ID 2
> ABS_MT_POSITION_X x[2]
> ABS_MT_POSITION_Y y[2]
> SYN_MT_BLOB
> ABS_MT_BLOB_ID 89
> ABS_MT_SLOT_ID 3
> ABS_MT_TRACKING_ID 30
> ABS_MT_POSITION_X x[3]
> ABS_MT_POSITION_Y y[3]
> SYN_MT_BLOB
> SYN_REPORT
>
> where we have two blob of data. They represent finger 1 and finger 2.
> Finger 1 has a tracking number 11 while finger 2 has 30.  We do not
> track the three contacts inside the blob since they all belong to the
> same finger.  We could even combine type A and B as:

???

Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions?

Rafi
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Fri, May 21, 2010 at 8:19 AM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
>> ABS_MT_BLOB_ID 11
>> ABS_MT_TRACKING_ID 45
>> ABS_MT_SLOT_ID 0
>> ABS_MT_POSITION_X x[0]
>> ABS_MT_POSITION_Y y[0]
>> ABS_MT_SLOT_ID 1
>> ABS_MT_POSITION_X x[1]
>> ABS_MT_POSITION_Y y[1]
>> ABS_MT_SLOT_ID 2
>> ABS_MT_POSITION_X x[2]
>> ABS_MT_POSITION_Y y[2]
>> SYN_MT_BLOB
>> ABS_MT_BLOB_ID 89
>> ABS_MT_SLOT_ID 3
>> ABS_MT_TRACKING_ID 30
>> ABS_MT_POSITION_X x[3]
>> ABS_MT_POSITION_Y y[3]
>> SYN_MT_BLOB
>> SYN_REPORT
>>
>> where we have two blob of data. They represent finger 1 and finger 2.
>> Finger 1 has a tracking number 11 while finger 2 has 30.  We do not
>> track the three contacts inside the blob since they all belong to the
>> same finger.  We could even combine type A and B as:
>
> ???
>
> Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions?

You are definitely on the right track.  The fingers/touch objects can
be represented two-dimensionally (x,y) instead of one-dimensionally
(ABS_MT_TRACKING_ID).  I think we can survive with the current MT_BLOB
definition although some optimization would be helpful, especially for
filtering. For the sake of Henrik great effort, I'd like to see his
current patchset gets in the tree before we start another round of
"suggestions".

Thank you for asking.

Ping

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Fri, May 21, 2010 at 8:19 AM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
>> ABS_MT_BLOB_ID 11
>> ABS_MT_TRACKING_ID 45
>> ABS_MT_SLOT_ID 0
>> ABS_MT_POSITION_X x[0]
>> ABS_MT_POSITION_Y y[0]
>> ABS_MT_SLOT_ID 1
>> ABS_MT_POSITION_X x[1]
>> ABS_MT_POSITION_Y y[1]
>> ABS_MT_SLOT_ID 2
>> ABS_MT_POSITION_X x[2]
>> ABS_MT_POSITION_Y y[2]
>> SYN_MT_BLOB
>> ABS_MT_BLOB_ID 89
>> ABS_MT_SLOT_ID 3
>> ABS_MT_TRACKING_ID 30
>> ABS_MT_POSITION_X x[3]
>> ABS_MT_POSITION_Y y[3]
>> SYN_MT_BLOB
>> SYN_REPORT
>>
>> where we have two blob of data. They represent finger 1 and finger 2.
>> Finger 1 has a tracking number 11 while finger 2 has 30.  We do not
>> track the three contacts inside the blob since they all belong to the
>> same finger.  We could even combine type A and B as:
>
> ???
>
> Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions?

You are definitely on the right track.  The fingers/touch objects can
be represented two-dimensionally (x,y) instead of one-dimensionally
(ABS_MT_TRACKING_ID).  I think we can survive with the current MT_BLOB
definition although some optimization would be helpful, especially for
filtering. For the sake of Henrik great effort, I'd like to see his
current patchset gets in the tree before we start another round of
"suggestions".

Thank you for asking.

Ping
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Henrik Rydberg]

Ping Cheng wrote:
> On Fri, May 21, 2010 at 8:19 AM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
[...]
>> Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions?
> 
> You are definitely on the right track.  The fingers/touch objects can
> be represented two-dimensionally (x,y) instead of one-dimensionally
> (ABS_MT_TRACKING_ID).  I think we can survive with the current MT_BLOB
> definition although some optimization would be helpful, especially for
> filtering. For the sake of Henrik great effort, I'd like to see his
> current patchset gets in the tree before we start another round of
> "suggestions".
> 
> Thank you for asking.

Regarding blobs, I confused myself yesterday. The original intention of the blob
 id was in fact to be able to "paint" more generic contact forms. However, no
driver has come close to doing this yet, so it has gotten close to no attention.
Now, to address the question of how to communicate more elaborate contact forms,
it seems one can combine the two goals "one position per slot" and "multiple
positions per contact" by simply repeating the same tracking id for a set of
slots, like this:

ABS_SLOT 0
ABS_MT_TRACKING_ID 14
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
ABS_SLOT 1
ABS_MT_TRACKING_ID 14
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]
ABS_SLOT 2
ABS_MT_TRACKING_ID 14
ABS_MT_POSITION_X x[2]
ABS_MT_POSITION_Y y[2]

Not all too different from what you suggested, and there is no blob id involved
at all. And yes, it would require additional parsing power at the user end.
Something for later.

Cheers,
Henrik

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Fri, May 21, 2010 at 2:25 PM, Henrik Rydberg <rydberg@euromail.se> wrote:
> Ping Cheng wrote:
>> On Fri, May 21, 2010 at 8:19 AM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
> [...]
>>> Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions?
>>
>> You are definitely on the right track.  The fingers/touch objects can
>> be represented two-dimensionally (x,y) instead of one-dimensionally
>> (ABS_MT_TRACKING_ID).  I think we can survive with the current MT_BLOB
>> definition although some optimization would be helpful, especially for
>> filtering. For the sake of Henrik great effort, I'd like to see his
>> current patchset gets in the tree before we start another round of
>> "suggestions".
>>
>> Thank you for asking.
>
> Regarding blobs, I confused myself yesterday. The original intention of the blob
>  id was in fact to be able to "paint" more generic contact forms. However, no
> driver has come close to doing this yet, so it has gotten close to no attention.
> Now, to address the question of how to communicate more elaborate contact forms,
> it seems one can combine the two goals "one position per slot" and "multiple
> positions per contact" by simply repeating the same tracking id for a set of
> slots, like this:
>
> ABS_SLOT 0
> ABS_MT_TRACKING_ID 14
> ABS_MT_POSITION_X x[0]
> ABS_MT_POSITION_Y y[0]
> ABS_SLOT 1
> ABS_MT_TRACKING_ID 14
> ABS_MT_POSITION_X x[1]
> ABS_MT_POSITION_Y y[1]
> ABS_SLOT 2
> ABS_MT_TRACKING_ID 14
> ABS_MT_POSITION_X x[2]
> ABS_MT_POSITION_Y y[2]

This solution matches with my imagination more closely.  Let's stay
with it for now.  I may come up with other suggestions once I have
time to do real testing with the protocol.

Thank you, Henrik, for your continuous effort.

Ping

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Peter Hutterer]

On Thu, May 20, 2010 at 12:40:08PM +0200, Henrik Rydberg wrote:
> Peter Hutterer wrote:
> [...]
> >>> Will all drivers with ABS_MT_TRACKING_ID use slots? if not, how can I know
> >>> in advance if a device may use slots or not?
> >> Eventually, this might become true, but you are pointing at one of the weaker
> >> points of the current setup. There is no bit field for the EV_SYN events, so
> >> there is no way to know in advance if SYN_MT_SYNC or SYN_MT_SLOT is used. This
> >> could quite possibly be added to the EVIO interface. Meanwhile, the method I use
> >> is to detect the first SYN_MT_SLOT and select parser based on that information.
> > 
> > I'd really prefer if there was some way to detect this. While I'm not quite
> > sure how the matching X drivers would look like it's likely that the setups
> > will be different for drivers that support slots and those that don't.
> > e.g. those that don't have slots simply send events as valuators, those that
> > do may split into multiple devices.
> > 
> > Doing this at runtime - after the device has been set up is...tricky.
> 
> Changing SYN_MT_SLOT to ABS_MT_SLOT will take care of this.
> 
> >> If you are thinking of a setup where one program is already hooked up to the
> >> device, and a new one comes in just as the message in question appears on the
> >> wire, it just means the new program will have to spend some time catching up. If
> >> this should ever become a problem, one could possibly add a send-full-state
> >> method to the input layer, to be issued when the new program opens the device. I
> >> doubt this will be needed in practice though, since contacts change all the time.
> > 
> > This was the case I was wondering about. While I agree with the last part
> > (contacts change all the time) the side-effect that you'll get from this is
> > that devices can seemingly be non-responsive for random periods of time.
> > 
> > If you have a finger down when the X server starts or after a VT switch (or
> > even a fast user switch), the driver will have to drop events. So you can
> > wriggle your finger around and nothing happens, but once you lift it goes
> > "well, now it works again". Since this happens only once in a while, it can
> > make the whole lot appear flaky.  Especially if one finger works and the
> > other one doesn't.
> >
> > So I guess it comes down to whether sending SYN_MT_SLOT with every event
> > costs too much compared to these admittedly rare use-cases. They're not much
> > different to the current button events either, if you weren't there when a
> > button was pressed you won't know. So I'm somewhat indifferent about this
> > bit.
> 
> Yes, it is a inherent property of the input protocol between the kernel and user
> space. A different problem, in other words.
> 
> > And yes, you could add it once we find it's an issue, but by then someone
> > has already spent time to work around this. And when you then start sending
> > slot events all the time, you admit that writing the workaround was just a
> > time waster :)
> 
> Work around what, exactly?

I was referring to having a protocol where processes has to ignore contacts
already down until they've been there when a contact was pressed (and your
comment that if this becomes an issue it could be added lateron). 
Now, the ignoring part needs to be written (this is the "workaround"
referred to above). if you're planning to add it later, we need to cater for
that part as well then, having two implementations depending on the kernel
versions.

but this is just for clarification, it's a moot point anyway given that
button events have the same behaviour. so, nevermind, I think we can just
ignore it and get on with life.

Cheers,
  Peter

> >> As a side note, the notion of a used slot depends on how the attributes of the
> >> slot are interpreted. The method described in the document treats an
> >> ABS_MT_TRACKING_ID value outside of the driver-specified value range as an
> >> unused slot.
> > 
> > It's easier for a latecomer to guess a tracking ID since you can just
> > assign any random value to it, provided the kernel guarantees to only send
> > updates on the tracking ID for changes. This doesn't quite work for slots.
> > 
> > But I'm not sure what your last sentence means. Does this mean the kernel
> > will open a new slot for out-of-range tracking IDs? I'm missing something
> > here.
> 
> I am referring to the notion of create-move-destroy from earlier discussions,
> and the question of how it is implemented using slots. The document is a bit
> unclear on this point, so I will add a note stating something like this:
> 
> * Every slot with a tracking id within the value range represents a contact.
> 
> * Tracking ids not previously present are considered new.
> 
> * Tracking ids no longer present are considered removed.
> 
> Cheers,
> Henrik
> 

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Peter Hutterer]

On Fri, May 21, 2010 at 11:25:41PM +0200, Henrik Rydberg wrote:
> Ping Cheng wrote:
> > On Fri, May 21, 2010 at 8:19 AM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
> [...]
> >> Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions?
> > 
> > You are definitely on the right track.  The fingers/touch objects can
> > be represented two-dimensionally (x,y) instead of one-dimensionally
> > (ABS_MT_TRACKING_ID).  I think we can survive with the current MT_BLOB
> > definition although some optimization would be helpful, especially for
> > filtering. For the sake of Henrik great effort, I'd like to see his
> > current patchset gets in the tree before we start another round of
> > "suggestions".
> > 
> > Thank you for asking.
> 
> Regarding blobs, I confused myself yesterday. The original intention of the blob
>  id was in fact to be able to "paint" more generic contact forms. However, no
> driver has come close to doing this yet, so it has gotten close to no attention.
> Now, to address the question of how to communicate more elaborate contact forms,
> it seems one can combine the two goals "one position per slot" and "multiple
> positions per contact" by simply repeating the same tracking id for a set of
> slots, like this:
> 
> ABS_SLOT 0
> ABS_MT_TRACKING_ID 14
> ABS_MT_POSITION_X x[0]
> ABS_MT_POSITION_Y y[0]
> ABS_SLOT 1
> ABS_MT_TRACKING_ID 14
> ABS_MT_POSITION_X x[1]
> ABS_MT_POSITION_Y y[1]
> ABS_SLOT 2
> ABS_MT_TRACKING_ID 14
> ABS_MT_POSITION_X x[2]
> ABS_MT_POSITION_Y y[2]
> 
> Not all too different from what you suggested, and there is no blob id involved
> at all. And yes, it would require additional parsing power at the user end.
> Something for later.

This is confusing me now :)

How would a device get multiple x/y coordinates for a single contact? I
could understand a range of coordinates but that's what we have the
ABS_MT_WIDTH_MAJOR/MINOR for. If a touchpoint sends two different x/y
coordinates, wouldn't that be two touchpoints, tracked individually and thus
with a different tracking ID?

I read the example above as _the_ example for using blob IDs to combine
multiple contacts into one semantic contact.

Cheers,
  Peter

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Sun, May 23, 2010 at 10:25 PM, Peter Hutterer
<peter.hutterer@who-t.net> wrote:
> On Fri, May 21, 2010 at 11:25:41PM +0200, Henrik Rydberg wrote:
>> Ping Cheng wrote:
>> > On Fri, May 21, 2010 at 8:19 AM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
>> [...]
>> >> Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions?
>> >
>> > You are definitely on the right track.  The fingers/touch objects can
>> > be represented two-dimensionally (x,y) instead of one-dimensionally
>> > (ABS_MT_TRACKING_ID).  I think we can survive with the current MT_BLOB
>> > definition although some optimization would be helpful, especially for
>> > filtering. For the sake of Henrik great effort, I'd like to see his
>> > current patchset gets in the tree before we start another round of
>> > "suggestions".
>> >
>> > Thank you for asking.
>>
>> Regarding blobs, I confused myself yesterday. The original intention of the blob
>>  id was in fact to be able to "paint" more generic contact forms. However, no
>> driver has come close to doing this yet, so it has gotten close to no attention.
>> Now, to address the question of how to communicate more elaborate contact forms,
>> it seems one can combine the two goals "one position per slot" and "multiple
>> positions per contact" by simply repeating the same tracking id for a set of
>> slots, like this:
>>
>> ABS_SLOT 0
>> ABS_MT_TRACKING_ID 14
>> ABS_MT_POSITION_X x[0]
>> ABS_MT_POSITION_Y y[0]
>> ABS_SLOT 1
>> ABS_MT_TRACKING_ID 14
>> ABS_MT_POSITION_X x[1]
>> ABS_MT_POSITION_Y y[1]
>> ABS_SLOT 2
>> ABS_MT_TRACKING_ID 14
>> ABS_MT_POSITION_X x[2]
>> ABS_MT_POSITION_Y y[2]
>>
>> Not all too different from what you suggested, and there is no blob id involved
>> at all. And yes, it would require additional parsing power at the user end.
>> Something for later.
>
> This is confusing me now :)
>
> How would a device get multiple x/y coordinates for a single contact? I
> could understand a range of coordinates but that's what we have the
> ABS_MT_WIDTH_MAJOR/MINOR for. If a touchpoint sends two different x/y
> coordinates, wouldn't that be two touchpoints, tracked individually and thus
> with a different tracking ID?
>
> I read the example above as _the_ example for using blob IDs to combine
> multiple contacts into one semantic contact.

As Henrik pointed out, the current BLOB format is for "more generic
contact forms", such as rectangles or ellipses.  They are special
blobs. A generic (true) blob doesn't have to have a regular shape.  It
is most likely in an irregular shape. They would be represented in an
array of points/contacts/(x,y)s,  whichever term works for you :).

tbh, I don't know what exact format we are going to use.  But, I feel
we can live with Henrik's current format, at least for a while.

Ping

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Sun, May 23, 2010 at 10:25 PM, Peter Hutterer
<peter.hutterer@who-t.net> wrote:
> On Fri, May 21, 2010 at 11:25:41PM +0200, Henrik Rydberg wrote:
>> Ping Cheng wrote:
>> > On Fri, May 21, 2010 at 8:19 AM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
>> [...]
>> >> Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions?
>> >
>> > You are definitely on the right track.  The fingers/touch objects can
>> > be represented two-dimensionally (x,y) instead of one-dimensionally
>> > (ABS_MT_TRACKING_ID).  I think we can survive with the current MT_BLOB
>> > definition although some optimization would be helpful, especially for
>> > filtering. For the sake of Henrik great effort, I'd like to see his
>> > current patchset gets in the tree before we start another round of
>> > "suggestions".
>> >
>> > Thank you for asking.
>>
>> Regarding blobs, I confused myself yesterday. The original intention of the blob
>>  id was in fact to be able to "paint" more generic contact forms. However, no
>> driver has come close to doing this yet, so it has gotten close to no attention.
>> Now, to address the question of how to communicate more elaborate contact forms,
>> it seems one can combine the two goals "one position per slot" and "multiple
>> positions per contact" by simply repeating the same tracking id for a set of
>> slots, like this:
>>
>> ABS_SLOT 0
>> ABS_MT_TRACKING_ID 14
>> ABS_MT_POSITION_X x[0]
>> ABS_MT_POSITION_Y y[0]
>> ABS_SLOT 1
>> ABS_MT_TRACKING_ID 14
>> ABS_MT_POSITION_X x[1]
>> ABS_MT_POSITION_Y y[1]
>> ABS_SLOT 2
>> ABS_MT_TRACKING_ID 14
>> ABS_MT_POSITION_X x[2]
>> ABS_MT_POSITION_Y y[2]
>>
>> Not all too different from what you suggested, and there is no blob id involved
>> at all. And yes, it would require additional parsing power at the user end.
>> Something for later.
>
> This is confusing me now :)
>
> How would a device get multiple x/y coordinates for a single contact? I
> could understand a range of coordinates but that's what we have the
> ABS_MT_WIDTH_MAJOR/MINOR for. If a touchpoint sends two different x/y
> coordinates, wouldn't that be two touchpoints, tracked individually and thus
> with a different tracking ID?
>
> I read the example above as _the_ example for using blob IDs to combine
> multiple contacts into one semantic contact.

As Henrik pointed out, the current BLOB format is for "more generic
contact forms", such as rectangles or ellipses.  They are special
blobs. A generic (true) blob doesn't have to have a regular shape.  It
is most likely in an irregular shape. They would be represented in an
array of points/contacts/(x,y)s,  whichever term works for you :).

tbh, I don't know what exact format we are going to use.  But, I feel
we can live with Henrik's current format, at least for a while.

Ping
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Sun, May 23, 2010 at 9:58 PM, Peter Hutterer
<peter.hutterer@who-t.net> wrote:
>> > And yes, you could add it once we find it's an issue, but by then someone
>> > has already spent time to work around this. And when you then start sending
>> > slot events all the time, you admit that writing the workaround was just a
>> > time waster :)
>>
>> Work around what, exactly?
>
> I was referring to having a protocol where processes has to ignore contacts
> already down until they've been there when a contact was pressed (and your
> comment that if this becomes an issue it could be added lateron).
> Now, the ignoring part needs to be written (this is the "workaround"
> referred to above). if you're planning to add it later, we need to cater for
> that part as well then, having two implementations depending on the kernel
> versions.
>
> but this is just for clarification, it's a moot point anyway given that
> button events have the same behaviour.

This topic is outside of the _MT_ protocol discussion.

However, it is indeed an issue with all filtered input events, both
for MT and regular ones.

I think we need to add an ioctl to enable user land driver/client to
signal the kernel driver to send all events without filtering, just
once. Hot-plugged devices and X driver starts after user has contacted
with the device are two examples that the client would miss filtered
events.

Dmitry, do you think it is a valid suggestion?

I've had this issue for ages (but never had time to work on it :(.

Ping

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Peter Hutterer]

On Sun, May 23, 2010 at 10:48:35PM -0700, Ping Cheng wrote:
> On Sun, May 23, 2010 at 10:25 PM, Peter Hutterer
> <peter.hutterer@who-t.net> wrote:
> > On Fri, May 21, 2010 at 11:25:41PM +0200, Henrik Rydberg wrote:
> >> Ping Cheng wrote:
> >> > On Fri, May 21, 2010 at 8:19 AM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
> >> [...]
> >> >> Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions?
> >> >
> >> > You are definitely on the right track.  The fingers/touch objects can
> >> > be represented two-dimensionally (x,y) instead of one-dimensionally
> >> > (ABS_MT_TRACKING_ID).  I think we can survive with the current MT_BLOB
> >> > definition although some optimization would be helpful, especially for
> >> > filtering. For the sake of Henrik great effort, I'd like to see his
> >> > current patchset gets in the tree before we start another round of
> >> > "suggestions".
> >> >
> >> > Thank you for asking.
> >>
> >> Regarding blobs, I confused myself yesterday. The original intention of the blob
> >>  id was in fact to be able to "paint" more generic contact forms. However, no
> >> driver has come close to doing this yet, so it has gotten close to no attention.
> >> Now, to address the question of how to communicate more elaborate contact forms,
> >> it seems one can combine the two goals "one position per slot" and "multiple
> >> positions per contact" by simply repeating the same tracking id for a set of
> >> slots, like this:
> >>
> >> ABS_SLOT 0
> >> ABS_MT_TRACKING_ID 14
> >> ABS_MT_POSITION_X x[0]
> >> ABS_MT_POSITION_Y y[0]
> >> ABS_SLOT 1
> >> ABS_MT_TRACKING_ID 14
> >> ABS_MT_POSITION_X x[1]
> >> ABS_MT_POSITION_Y y[1]
> >> ABS_SLOT 2
> >> ABS_MT_TRACKING_ID 14
> >> ABS_MT_POSITION_X x[2]
> >> ABS_MT_POSITION_Y y[2]
> >>
> >> Not all too different from what you suggested, and there is no blob id involved
> >> at all. And yes, it would require additional parsing power at the user end.
> >> Something for later.
> >
> > This is confusing me now :)
> >
> > How would a device get multiple x/y coordinates for a single contact? I
> > could understand a range of coordinates but that's what we have the
> > ABS_MT_WIDTH_MAJOR/MINOR for. If a touchpoint sends two different x/y
> > coordinates, wouldn't that be two touchpoints, tracked individually and thus
> > with a different tracking ID?
> >
> > I read the example above as _the_ example for using blob IDs to combine
> > multiple contacts into one semantic contact.
> 
> As Henrik pointed out, the current BLOB format is for "more generic
> contact forms", such as rectangles or ellipses.  They are special
> blobs. A generic (true) blob doesn't have to have a regular shape.  It
> is most likely in an irregular shape. They would be represented in an
> array of points/contacts/(x,y)s,  whichever term works for you :).

Hmm. I always assumed blob is for irregular shapes, and rectangles or others
are just subsets of irregular shapes (with slightly less 'ir', maybe).
So what would be the difference between these two event streams?

ABS_SLOT 0
ABS_MT_TRACKING_ID 14
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
ABS_SLOT 1
ABS_MT_TRACKING_ID 14
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]


ABS_SLOT 0
ABS_MT_TRACKING_ID 14
ABS_MT_BLOB_ID 1
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
ABS_SLOT 1
ABS_MT_BLOB_ID 1
ABS_MT_TRACKING_ID 15
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]

Cheers,
  Peter

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Peter Hutterer]

On Sun, May 23, 2010 at 10:48:35PM -0700, Ping Cheng wrote:
> On Sun, May 23, 2010 at 10:25 PM, Peter Hutterer
> <peter.hutterer@who-t.net> wrote:
> > On Fri, May 21, 2010 at 11:25:41PM +0200, Henrik Rydberg wrote:
> >> Ping Cheng wrote:
> >> > On Fri, May 21, 2010 at 8:19 AM, Rafi Rubin <rafi@seas.upenn.edu> wrote:
> >> [...]
> >> >> Ping: please confirm, are you actually talking about each finger simultaneously sending multiple positions?
> >> >
> >> > You are definitely on the right track.  The fingers/touch objects can
> >> > be represented two-dimensionally (x,y) instead of one-dimensionally
> >> > (ABS_MT_TRACKING_ID).  I think we can survive with the current MT_BLOB
> >> > definition although some optimization would be helpful, especially for
> >> > filtering. For the sake of Henrik great effort, I'd like to see his
> >> > current patchset gets in the tree before we start another round of
> >> > "suggestions".
> >> >
> >> > Thank you for asking.
> >>
> >> Regarding blobs, I confused myself yesterday. The original intention of the blob
> >>  id was in fact to be able to "paint" more generic contact forms. However, no
> >> driver has come close to doing this yet, so it has gotten close to no attention.
> >> Now, to address the question of how to communicate more elaborate contact forms,
> >> it seems one can combine the two goals "one position per slot" and "multiple
> >> positions per contact" by simply repeating the same tracking id for a set of
> >> slots, like this:
> >>
> >> ABS_SLOT 0
> >> ABS_MT_TRACKING_ID 14
> >> ABS_MT_POSITION_X x[0]
> >> ABS_MT_POSITION_Y y[0]
> >> ABS_SLOT 1
> >> ABS_MT_TRACKING_ID 14
> >> ABS_MT_POSITION_X x[1]
> >> ABS_MT_POSITION_Y y[1]
> >> ABS_SLOT 2
> >> ABS_MT_TRACKING_ID 14
> >> ABS_MT_POSITION_X x[2]
> >> ABS_MT_POSITION_Y y[2]
> >>
> >> Not all too different from what you suggested, and there is no blob id involved
> >> at all. And yes, it would require additional parsing power at the user end.
> >> Something for later.
> >
> > This is confusing me now :)
> >
> > How would a device get multiple x/y coordinates for a single contact? I
> > could understand a range of coordinates but that's what we have the
> > ABS_MT_WIDTH_MAJOR/MINOR for. If a touchpoint sends two different x/y
> > coordinates, wouldn't that be two touchpoints, tracked individually and thus
> > with a different tracking ID?
> >
> > I read the example above as _the_ example for using blob IDs to combine
> > multiple contacts into one semantic contact.
> 
> As Henrik pointed out, the current BLOB format is for "more generic
> contact forms", such as rectangles or ellipses.  They are special
> blobs. A generic (true) blob doesn't have to have a regular shape.  It
> is most likely in an irregular shape. They would be represented in an
> array of points/contacts/(x,y)s,  whichever term works for you :).

Hmm. I always assumed blob is for irregular shapes, and rectangles or others
are just subsets of irregular shapes (with slightly less 'ir', maybe).
So what would be the difference between these two event streams?

ABS_SLOT 0
ABS_MT_TRACKING_ID 14
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
ABS_SLOT 1
ABS_MT_TRACKING_ID 14
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]


ABS_SLOT 0
ABS_MT_TRACKING_ID 14
ABS_MT_BLOB_ID 1
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
ABS_SLOT 1
ABS_MT_BLOB_ID 1
ABS_MT_TRACKING_ID 15
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]

Cheers,
  Peter

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Henrik Rydberg]

Peter Hutterer wrote:
[...]
>>> This is confusing me now :)
>>>
>>> How would a device get multiple x/y coordinates for a single contact? I
>>> could understand a range of coordinates but that's what we have the
>>> ABS_MT_WIDTH_MAJOR/MINOR for. If a touchpoint sends two different x/y
>>> coordinates, wouldn't that be two touchpoints, tracked individually and thus
>>> with a different tracking ID?
>>>
>>> I read the example above as _the_ example for using blob IDs to combine
>>> multiple contacts into one semantic contact.
>> As Henrik pointed out, the current BLOB format is for "more generic
>> contact forms", such as rectangles or ellipses.  They are special
>> blobs. A generic (true) blob doesn't have to have a regular shape.  It
>> is most likely in an irregular shape. They would be represented in an
>> array of points/contacts/(x,y)s,  whichever term works for you :).
> 
> Hmm. I always assumed blob is for irregular shapes, and rectangles or others
> are just subsets of irregular shapes (with slightly less 'ir', maybe).
> So what would be the difference between these two event streams?
> 
> ABS_SLOT 0
> ABS_MT_TRACKING_ID 14
> ABS_MT_POSITION_X x[0]
> ABS_MT_POSITION_Y y[0]
> ABS_SLOT 1
> ABS_MT_TRACKING_ID 14
> ABS_MT_POSITION_X x[1]
> ABS_MT_POSITION_Y y[1]
> 
> 
> ABS_SLOT 0
> ABS_MT_TRACKING_ID 14
> ABS_MT_BLOB_ID 1
> ABS_MT_POSITION_X x[0]
> ABS_MT_POSITION_Y y[0]
> ABS_SLOT 1
> ABS_MT_BLOB_ID 1
> ABS_MT_TRACKING_ID 15
> ABS_MT_POSITION_X x[1]
> ABS_MT_POSITION_Y y[1]

I, for one, prefer a third example, but for some other time. I know, the first
example is my fault, but it was created to illustrate that it is possible, not
that it is a particularly good idea. :-)

For type A devices, in the absence of identifiable contacts, there is room for
geometrical groupings of different kinds. Since all data is transferred between
synchronization points, the ABS_MT_BLOB_ID serves this purpose well.

However, for type B devices, seeking to reduce bandwidth by adding the concept
of identifiable contacts, it does not make sense to send overly detailed data.
If anything, the shape of a contact should be communicated in a simpler way,
maybe by extending the ABS_MT_TOOL_TYPE list.

Here is an attempt to capture the above constraints in the documentation:

@@ -244,15 +244,16 @@ MT_TOOL_PEN [2].
 ABS_MT_BLOB_ID

 The BLOB_ID groups several packets together into one arbitrarily shaped
-contact. This is a low-level anonymous grouping, and should not be confused
-with the high-level trackingID [5]. Most kernel drivers will not have blob
-capability, and can safely omit the event.
+contact. This is a low-level anonymous grouping for type A devices, and
+should not be confused with the high-level trackingID [5]. Most type A
+devices do not have blob capability, so drivers can safely omit this event.

 ABS_MT_TRACKING_ID

 The TRACKING_ID identifies an initiated contact throughout its life cycle
-[5]. There are currently only a few devices that support it, so this event
-should normally be omitted.
+[5]. This event is mandatory for type B devices. The value range of the
+TRACKING_ID should be large enough to ensure unique identification of a
+contact maintained over an extended period of time.

Henrik

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Henrik Rydberg]

Ping Cheng wrote:
[...]
> This topic is outside of the _MT_ protocol discussion.
> 
> However, it is indeed an issue with all filtered input events, both
> for MT and regular ones.
> 
> I think we need to add an ioctl to enable user land driver/client to
> signal the kernel driver to send all events without filtering, just
> once. Hot-plugged devices and X driver starts after user has contacted
> with the device are two examples that the client would miss filtered
> events.
> 
> Dmitry, do you think it is a valid suggestion?
> 
> I've had this issue for ages (but never had time to work on it :(.

It would be easy to initialize a catch-up when opening the device for a new
client (evdev_open()).

Henrik

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Dmitry Torokhov]

On Sun, May 23, 2010 at 11:07:27PM -0700, Ping Cheng wrote:
> On Sun, May 23, 2010 at 9:58 PM, Peter Hutterer
> <peter.hutterer@who-t.net> wrote:
> >> > And yes, you could add it once we find it's an issue, but by then someone
> >> > has already spent time to work around this. And when you then start sending
> >> > slot events all the time, you admit that writing the workaround was just a
> >> > time waster :)
> >>
> >> Work around what, exactly?
> >
> > I was referring to having a protocol where processes has to ignore contacts
> > already down until they've been there when a contact was pressed (and your
> > comment that if this becomes an issue it could be added lateron).
> > Now, the ignoring part needs to be written (this is the "workaround"
> > referred to above). if you're planning to add it later, we need to cater for
> > that part as well then, having two implementations depending on the kernel
> > versions.
> >
> > but this is just for clarification, it's a moot point anyway given that
> > button events have the same behaviour.
> 
> This topic is outside of the _MT_ protocol discussion.
> 
> However, it is indeed an issue with all filtered input events, both
> for MT and regular ones.
> 
> I think we need to add an ioctl to enable user land driver/client to
> signal the kernel driver to send all events without filtering, just
> once. Hot-plugged devices and X driver starts after user has contacted
> with the device are two examples that the client would miss filtered
> events.
> 
> Dmitry, do you think it is a valid suggestion?
>

What about using EVIOCGKEY/EVIOCGSW/EVIOCGABS?

-- 
Dmitry

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Mon, May 24, 2010 at 8:59 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Sun, May 23, 2010 at 11:07:27PM -0700, Ping Cheng wrote:
>> On Sun, May 23, 2010 at 9:58 PM, Peter Hutterer
>> <peter.hutterer@who-t.net> wrote:
>> >> > And yes, you could add it once we find it's an issue, but by then someone
>> >> > has already spent time to work around this. And when you then start sending
>> >> > slot events all the time, you admit that writing the workaround was just a
>> >> > time waster :)
>> >>
>> >> Work around what, exactly?
>> >
>> > I was referring to having a protocol where processes has to ignore contacts
>> > already down until they've been there when a contact was pressed (and your
>> > comment that if this becomes an issue it could be added lateron).
>> > Now, the ignoring part needs to be written (this is the "workaround"
>> > referred to above). if you're planning to add it later, we need to cater for
>> > that part as well then, having two implementations depending on the kernel
>> > versions.
>> >
>> > but this is just for clarification, it's a moot point anyway given that
>> > button events have the same behaviour.
>>
>> This topic is outside of the _MT_ protocol discussion.
>>
>> However, it is indeed an issue with all filtered input events, both
>> for MT and regular ones.
>>
>> I think we need to add an ioctl to enable user land driver/client to
>> signal the kernel driver to send all events without filtering, just
>> once. Hot-plugged devices and X driver starts after user has contacted
>> with the device are two examples that the client would miss filtered
>> events.
>>
>> Dmitry, do you think it is a valid suggestion?
>>
>
> What about using EVIOCGKEY/EVIOCGSW/EVIOCGABS?

Those EVIOCs only give us the static values (max/min/supported keys,
etc.).  We need their dynamic input data here, the actual x, y,
button, pressure, etc. Am I missing something about those EVIOs?

Ping

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Dmitry Torokhov]

On Monday 24 May 2010 10:06:15 am Ping Cheng wrote:
> On Mon, May 24, 2010 at 8:59 AM, Dmitry Torokhov
> 
> <dmitry.torokhov@gmail.com> wrote:
> > On Sun, May 23, 2010 at 11:07:27PM -0700, Ping Cheng wrote:
> >> On Sun, May 23, 2010 at 9:58 PM, Peter Hutterer
> >> 
> >> <peter.hutterer@who-t.net> wrote:
> >> >> > And yes, you could add it once we find it's an issue, but by then
> >> >> > someone has already spent time to work around this. And when you
> >> >> > then start sending slot events all the time, you admit that
> >> >> > writing the workaround was just a time waster :)
> >> >> 
> >> >> Work around what, exactly?
> >> > 
> >> > I was referring to having a protocol where processes has to ignore
> >> > contacts already down until they've been there when a contact was
> >> > pressed (and your comment that if this becomes an issue it could be
> >> > added lateron). Now, the ignoring part needs to be written (this is
> >> > the "workaround" referred to above). if you're planning to add it
> >> > later, we need to cater for that part as well then, having two
> >> > implementations depending on the kernel versions.
> >> > 
> >> > but this is just for clarification, it's a moot point anyway given
> >> > that button events have the same behaviour.
> >> 
> >> This topic is outside of the _MT_ protocol discussion.
> >> 
> >> However, it is indeed an issue with all filtered input events, both
> >> for MT and regular ones.
> >> 
> >> I think we need to add an ioctl to enable user land driver/client to
> >> signal the kernel driver to send all events without filtering, just
> >> once. Hot-plugged devices and X driver starts after user has contacted
> >> with the device are two examples that the client would miss filtered
> >> events.
> >> 
> >> Dmitry, do you think it is a valid suggestion?
> > 
> > What about using EVIOCGKEY/EVIOCGSW/EVIOCGABS?
> 
> Those EVIOCs only give us the static values (max/min/supported keys,
> etc.).  We need their dynamic input data here, the actual x, y,
> button, pressure, etc. Am I missing something about those EVIOs?
> 

Yes you are ;) Supported events are reported via EVIOCGBIT, EVIOCGKEY and
EVIOCGSW will return current state of keys/switches. As far as EVIOCGABS
goes, it also returns, besides min/max/etc, last reported _values_ of the
ABS_* events.

-- 
Dmitry

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Mon, May 24, 2010 at 10:21 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Monday 24 May 2010 10:06:15 am Ping Cheng wrote:
>> >> This topic is outside of the _MT_ protocol discussion.
>> >>
>> >> However, it is indeed an issue with all filtered input events, both
>> >> for MT and regular ones.
>> >>
>> >> I think we need to add an ioctl to enable user land driver/client to
>> >> signal the kernel driver to send all events without filtering, just
>> >> once. Hot-plugged devices and X driver starts after user has contacted
>> >> with the device are two examples that the client would miss filtered
>> >> events.
>> >>
>> >> Dmitry, do you think it is a valid suggestion?
>> >
>> > What about using EVIOCGKEY/EVIOCGSW/EVIOCGABS?
>>
>> Those EVIOCs only give us the static values (max/min/supported keys,
>> etc.).  We need their dynamic input data here, the actual x, y,
>> button, pressure, etc. Am I missing something about those EVIOs?
>>
>
> Yes you are ;) Supported events are reported via EVIOCGBIT, EVIOCGKEY and
> EVIOCGSW will return current state of keys/switches. As far as EVIOCGABS
> goes, it also returns, besides min/max/etc, last reported _values_ of the
> ABS_* events.

Oh, My God! I should have listened to Mark Twain :).

Ping

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Ping Cheng]

On Mon, May 24, 2010 at 10:21 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Monday 24 May 2010 10:06:15 am Ping Cheng wrote:
>> >> This topic is outside of the _MT_ protocol discussion.
>> >>
>> >> However, it is indeed an issue with all filtered input events, both
>> >> for MT and regular ones.
>> >>
>> >> I think we need to add an ioctl to enable user land driver/client to
>> >> signal the kernel driver to send all events without filtering, just
>> >> once. Hot-plugged devices and X driver starts after user has contacted
>> >> with the device are two examples that the client would miss filtered
>> >> events.
>> >>
>> >> Dmitry, do you think it is a valid suggestion?
>> >
>> > What about using EVIOCGKEY/EVIOCGSW/EVIOCGABS?
>>
>> Those EVIOCs only give us the static values (max/min/supported keys,
>> etc.).  We need their dynamic input data here, the actual x, y,
>> button, pressure, etc. Am I missing something about those EVIOs?
>>
>
> Yes you are ;) Supported events are reported via EVIOCGBIT, EVIOCGKEY and
> EVIOCGSW will return current state of keys/switches. As far as EVIOCGABS
> goes, it also returns, besides min/max/etc, last reported _values_ of the
> ABS_* events.

Oh, My God! I should have listened to Mark Twain :).

Ping
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Henrik Rydberg]

Dmitry Torokhov wrote:
[...]
>>>> I think we need to add an ioctl to enable user land driver/client to
>>>> signal the kernel driver to send all events without filtering, just
>>>> once. Hot-plugged devices and X driver starts after user has contacted
>>>> with the device are two examples that the client would miss filtered
>>>> events.
>>>>
>>>> Dmitry, do you think it is a valid suggestion?
>>> What about using EVIOCGKEY/EVIOCGSW/EVIOCGABS?
>> Those EVIOCs only give us the static values (max/min/supported keys,
>> etc.).  We need their dynamic input data here, the actual x, y,
>> button, pressure, etc. Am I missing something about those EVIOs?
>>
> 
> Yes you are ;) Supported events are reported via EVIOCGBIT, EVIOCGKEY and
> EVIOCGSW will return current state of keys/switches. As far as EVIOCGABS
> goes, it also returns, besides min/max/etc, last reported _values_ of the
> ABS_* events.
> 

Ping is not alone. :-)

But it does not work for MT events -- yet.

Henrik

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Dmitry Torokhov]

On Mon, May 24, 2010 at 07:48:00PM +0200, Henrik Rydberg wrote:
> Dmitry Torokhov wrote:
> [...]
> >>>> I think we need to add an ioctl to enable user land driver/client to
> >>>> signal the kernel driver to send all events without filtering, just
> >>>> once. Hot-plugged devices and X driver starts after user has contacted
> >>>> with the device are two examples that the client would miss filtered
> >>>> events.
> >>>>
> >>>> Dmitry, do you think it is a valid suggestion?
> >>> What about using EVIOCGKEY/EVIOCGSW/EVIOCGABS?
> >> Those EVIOCs only give us the static values (max/min/supported keys,
> >> etc.).  We need their dynamic input data here, the actual x, y,
> >> button, pressure, etc. Am I missing something about those EVIOs?
> >>
> > 
> > Yes you are ;) Supported events are reported via EVIOCGBIT, EVIOCGKEY and
> > EVIOCGSW will return current state of keys/switches. As far as EVIOCGABS
> > goes, it also returns, besides min/max/etc, last reported _values_ of the
> > ABS_* events.
> > 
> 
> Ping is not alone. :-)
> 
> But it does not work for MT events -- yet.
> 

Yes, this is true.

I think the most interesting is the switch data, since they may not change
at all. The rest is transient and should refresh "fairly quickly".

-- 
Dmitry

Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)

[Henrik Rydberg]

Dmitry Torokhov wrote:
> On Mon, May 24, 2010 at 07:48:00PM +0200, Henrik Rydberg wrote:
>> Dmitry Torokhov wrote:
>> [...]
>>>>>> I think we need to add an ioctl to enable user land driver/client to
>>>>>> signal the kernel driver to send all events without filtering, just
>>>>>> once. Hot-plugged devices and X driver starts after user has contacted
>>>>>> with the device are two examples that the client would miss filtered
>>>>>> events.
>>>>>>
>>>>>> Dmitry, do you think it is a valid suggestion?
>>>>> What about using EVIOCGKEY/EVIOCGSW/EVIOCGABS?
>>>> Those EVIOCs only give us the static values (max/min/supported keys,
>>>> etc.).  We need their dynamic input data here, the actual x, y,
>>>> button, pressure, etc. Am I missing something about those EVIOs?
>>>>
>>> Yes you are ;) Supported events are reported via EVIOCGBIT, EVIOCGKEY and
>>> EVIOCGSW will return current state of keys/switches. As far as EVIOCGABS
>>> goes, it also returns, besides min/max/etc, last reported _values_ of the
>>> ABS_* events.
>>>
>> Ping is not alone. :-)
>>
>> But it does not work for MT events -- yet.
>>
> 
> Yes, this is true.
> 
> I think the most interesting is the switch data, since they may not change
> at all. The rest is transient and should refresh "fairly quickly".
> 

Still, if one allows EVIOCSABS(ABS_MT_SLOT) to set a slot state in evdev instead
of modifying the input_dev, one could extract all ABS_MT events in sequence via
EVIOCGABS.

Henrik