[PATCH 2/2] Support for Stantum multitouch panel

[PATCH 2/2] Support for Stantum multitouch panel

[Stephane Chatty]

Added support for the Stantum multitouch panel.

Signed-off-by: Stephane Chatty <chatty@enac.fr>

diff -uprN a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
--- a/drivers/hid/hid-core.c	2009-12-08 22:32:21.000000000 +0100
+++ b/drivers/hid/hid-core.c	2009-12-08 22:36:19.000000000 +0100
@@ -1337,6 +1337,7 @@ static const struct hid_device_id hid_bl
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SAMSUNG, USB_DEVICE_ID_SAMSUNG_IR_REMOTE) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS3_CONTROLLER) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_STANTUM, USB_DEVICE_ID_MTP) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SUNPLUS, USB_DEVICE_ID_SUNPLUS_WDESKTOP) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb300) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb304) },
diff -uprN a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
--- a/drivers/hid/hid-ids.h	2009-12-03 04:51:21.000000000 +0100
+++ b/drivers/hid/hid-ids.h	2009-12-08 22:43:10.000000000 +0100
@@ -383,6 +383,9 @@
 #define USB_DEVICE_ID_SOUNDGRAPH_IMON_FIRST	0x0034
 #define USB_DEVICE_ID_SOUNDGRAPH_IMON_LAST	0x0046
 
+#define USB_VENDOR_ID_STANTUM		0x1f87
+#define USB_DEVICE_ID_MTP		0x0002
+
 #define USB_VENDOR_ID_SUN		0x0430
 #define USB_DEVICE_ID_RARITAN_KVM_DONGLE	0xcdab
 
diff -uprN a/drivers/hid/hid-stantum.c b/drivers/hid/hid-stantum.c
--- a/drivers/hid/hid-stantum.c	1970-01-01 01:00:00.000000000 +0100
+++ b/drivers/hid/hid-stantum.c	2009-12-08 22:41:12.000000000 +0100
@@ -0,0 +1,291 @@
+/*
+ *  HID driver for Stantum multitouch panels
+ *
+ *  Copyright (c) 2009 Stephane Chatty <chatty@enac.fr>
+ *
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include <linux/device.h>
+#include <linux/hid.h>
+#include <linux/module.h>
+
+MODULE_VERSION("1.0");
+MODULE_AUTHOR("Stephane Chatty <chatty@enac.fr>");
+MODULE_DESCRIPTION("Stantum HID multitouch panels");
+MODULE_LICENSE("GPL");
+
+static int emulate_touchscreen = 1;
+module_param_named(emulate_touchscreen, emulate_touchscreen, int, 0600);
+MODULE_PARM_DESC(emulate_touchscreen,
+		"Touchscreen emulation on Stantum multitouch panel (0=off, 1=on)");
+
+#include "hid-ids.h"
+
+struct stantum_data {
+	__s32 x, y, z, w, h;	/* x, y, pressure, width, height */
+	__u16 id;		/* touch id */
+	int valid:1;		/* valid finger data, or just placeholder? */
+	int first:1;		/* is this the first finger in the HID packet? */
+	int activity:1;		/* is there at least one active finger so far? */
+};
+
+static int stantum_input_mapping(struct hid_device *hdev, struct hid_input *hi,
+		struct hid_field *field, struct hid_usage *usage,
+		unsigned long **bit, int *max)
+{
+	switch (usage->hid & HID_USAGE_PAGE) {
+
+	case HID_UP_GENDESK:
+		switch (usage->hid) {
+		case HID_GD_X:
+			hid_map_usage(hi, usage, bit, max,
+					EV_ABS, ABS_MT_POSITION_X);
+			if (emulate_touchscreen)
+				input_set_abs_params(hi->input, ABS_X,
+						field->logical_minimum,
+						field->logical_maximum, 0, 0);
+			return 1;
+		case HID_GD_Y:
+			hid_map_usage(hi, usage, bit, max,
+					EV_ABS, ABS_MT_POSITION_Y);
+			if (emulate_touchscreen)
+				input_set_abs_params(hi->input, ABS_Y,
+						field->logical_minimum,
+						field->logical_maximum, 0, 0);
+			return 1;
+		}
+		return 0;
+
+	case HID_UP_DIGITIZER:
+		switch (usage->hid) {
+		case HID_DG_INRANGE:
+		case HID_DG_CONFIDENCE:
+		case HID_DG_INPUTMODE:
+		case HID_DG_DEVICEINDEX:
+		case HID_DG_CONTACTCOUNT:
+		case HID_DG_CONTACTMAX:
+		case HID_DG_TIPPRESSURE:
+			return -1;
+
+		case HID_DG_TIPSWITCH:
+			if (emulate_touchscreen) {
+				hid_map_usage(hi, usage, bit, max,
+					EV_KEY, BTN_TOUCH);
+				return 1;
+			} else
+				return -1;
+
+		case HID_DG_WIDTH:
+			hid_map_usage(hi, usage, bit, max,
+						EV_ABS, ABS_MT_TOUCH_MAJOR);
+			return 1;
+		case HID_DG_HEIGHT:
+			hid_map_usage(hi, usage, bit, max,
+					EV_ABS, ABS_MT_TOUCH_MINOR);
+			input_set_abs_params(hi->input,
+					ABS_MT_ORIENTATION,
+					1, 1, 0, 0);
+			return 1;
+		case HID_DG_CONTACTID:
+			hid_map_usage(hi, usage, bit, max,
+					EV_ABS, ABS_MT_TRACKING_ID);
+			return 1;
+
+		}
+		return 0;
+
+	case 0xff000000:
+		/* no input-oriented meaning */
+		return -1;
+	}
+
+	return 0;
+}
+
+static int stantum_input_mapped(struct hid_device *hdev, struct hid_input *hi,
+		struct hid_field *field, struct hid_usage *usage,
+		unsigned long **bit, int *max)
+{
+	if (usage->type == EV_KEY || usage->type == EV_REL
+			|| usage->type == EV_ABS)
+		clear_bit(usage->code, *bit);
+
+	return 0;
+}
+
+/*
+ * this function is called when a whole finger has been parsed,
+ * so that it can decide what to send to the input layer.
+ */
+static void stantum_filter_event (struct stantum_data *sd,
+					struct input_dev *input)
+{
+	int wide;
+	if (!sd->valid) {
+		/* if the first finger is not valid and there previously
+		 * was finger activity, this is a release */
+		if (emulate_touchscreen && sd->first && sd->activity) {
+			input_event(input, EV_KEY, BTN_TOUCH, 0);
+			sd->activity = 0;
+		}
+		return;
+	}
+
+	input_event(input, EV_ABS, ABS_MT_TRACKING_ID, sd->id);
+	input_event(input, EV_ABS, ABS_MT_POSITION_X, sd->x);
+	input_event(input, EV_ABS, ABS_MT_POSITION_Y, sd->y);
+
+	wide = (sd->w > sd->h);
+	input_event(input, EV_ABS, ABS_MT_ORIENTATION, wide);
+	input_event(input, EV_ABS, ABS_MT_TOUCH_MAJOR,
+				wide ? sd->w : sd->h);
+	input_event(input, EV_ABS, ABS_MT_TOUCH_MINOR,
+				wide ? sd->h : sd->w);
+
+#if 0
+	/* MT_PRESSURE does not exist yet */
+	input_event(input, EV_ABS, ABS_MT_PRESSURE, sd->z);
+#endif
+
+	if (emulate_touchscreen) {
+		if (sd->first) {
+			if (!sd->activity) {
+				input_event(input, EV_KEY, BTN_TOUCH, 1);
+				sd->activity = 1;
+			}
+			input_event(input, EV_ABS, ABS_X, sd->x);
+			input_event(input, EV_ABS, ABS_Y, sd->y);
+		}
+	}
+	input_mt_sync(input);
+	sd->valid = 0;
+	sd->first = 0;
+}
+
+
+static int stantum_event (struct hid_device *hid, struct hid_field *field,
+		                        struct hid_usage *usage, __s32 value)
+{
+	struct stantum_data *sd = hid_get_drvdata(hid);
+
+        if (hid->claimed & HID_CLAIMED_INPUT) {
+		struct input_dev *input = field->hidinput->input;
+		switch (usage->hid) {
+		case HID_DG_INRANGE:
+			/* this is the last field in a finger */
+			stantum_filter_event (sd, input);
+			break;
+		case HID_DG_WIDTH:
+			sd->w = value;
+			break;
+		case HID_DG_HEIGHT:
+			sd->h = value;
+			break;
+		case HID_GD_X:
+			sd->x = value;
+			break;
+		case HID_GD_Y:
+			sd->y = value;
+			break;
+		case HID_DG_TIPPRESSURE:
+			sd->z = value;
+			break;
+		case HID_DG_CONTACTID:
+			sd->id = value;
+			break;
+		case HID_DG_CONFIDENCE:
+			sd->valid = !!value;
+			break;
+		case 0xff000002:
+			/* this comes only before the first finger */
+			sd->first = 1;
+			break;
+
+		default:
+			/* ignore the others */
+                	return 1;
+		}
+	}
+
+	/* we have handled the hidinput part, now remains hiddev */
+        if (hid->claimed & HID_CLAIMED_HIDDEV && hid->hiddev_hid_event)
+                hid->hiddev_hid_event(hid, field, usage, value);
+
+	return 1;
+}
+
+static int stantum_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+	int ret;
+	struct stantum_data *sd;
+
+	sd = kmalloc(sizeof(struct stantum_data), GFP_KERNEL);
+	if (!sd) {
+		dev_err(&hdev->dev, "cannot allocate Stantum data\n");
+		return -ENOMEM;
+	}
+	sd->valid = 0;
+	sd->first = 0;
+	sd->activity = 0;
+	hid_set_drvdata(hdev, sd);
+
+	ret = hid_parse(hdev);
+	if (!ret)
+		ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+	else
+		printk ("STANTUM ERROR %d\n", ret);
+
+	if (ret)
+		kfree (sd);
+
+	return ret;
+}
+
+static void stantum_remove(struct hid_device *hdev)
+{
+	hid_hw_stop(hdev);
+	kfree(hid_get_drvdata(hdev));
+}
+
+static const struct hid_device_id stantum_devices[] = {
+	{ HID_USB_DEVICE(USB_VENDOR_ID_STANTUM, USB_DEVICE_ID_MTP) },
+	{ }
+};
+MODULE_DEVICE_TABLE(hid, stantum_devices);
+
+static const struct hid_usage_id stantum_grabbed_usages[] = {
+	{ HID_ANY_ID, HID_ANY_ID, HID_ANY_ID },
+	{ HID_ANY_ID - 1, HID_ANY_ID - 1, HID_ANY_ID - 1}
+};
+
+static struct hid_driver stantum_driver = {
+	.name = "stantum",
+	.id_table = stantum_devices,
+	.probe = stantum_probe,
+	.remove = stantum_remove,
+	.input_mapping = stantum_input_mapping,
+	.input_mapped = stantum_input_mapped,
+	.usage_table = stantum_grabbed_usages,
+	.event = stantum_event,
+};
+
+static int stantum_init(void)
+{
+	return hid_register_driver(&stantum_driver);
+}
+
+static void stantum_exit(void)
+{
+	hid_unregister_driver(&stantum_driver);
+}
+
+module_init(stantum_init);
+module_exit(stantum_exit);
+
diff -uprN a/drivers/hid/Kconfig b/drivers/hid/Kconfig
--- a/drivers/hid/Kconfig	2009-12-08 22:32:05.000000000 +0100
+++ b/drivers/hid/Kconfig	2009-12-08 22:34:42.000000000 +0100
@@ -241,6 +241,13 @@ config HID_SONY
 	---help---
 	Support for Sony PS3 controller.
 
+config HID_STANTUM
+	tristate "Stantum" if EMBEDDED
+	depends on USB_HID
+	default !EMBEDDED
+	---help---
+	Support for Stantum multitouch panel.
+
 config HID_SUNPLUS
 	tristate "Sunplus" if EMBEDDED
 	depends on USB_HID
diff -uprN a/drivers/hid/Makefile b/drivers/hid/Makefile
--- a/drivers/hid/Makefile	2009-12-08 22:32:01.000000000 +0100
+++ b/drivers/hid/Makefile	2009-12-08 22:35:20.000000000 +0100
@@ -39,6 +39,7 @@ obj-$(CONFIG_HID_PETALYNX)	+= hid-petaly
 obj-$(CONFIG_HID_SAMSUNG)	+= hid-samsung.o
 obj-$(CONFIG_HID_SMARTJOYPLUS)	+= hid-sjoy.o
 obj-$(CONFIG_HID_SONY)		+= hid-sony.o
+obj-$(CONFIG_HID_STANTUM)	+= hid-stantum.o
 obj-$(CONFIG_HID_SUNPLUS)	+= hid-sunplus.o
 obj-$(CONFIG_HID_GREENASIA)	+= hid-gaff.o
 obj-$(CONFIG_HID_THRUSTMASTER)	+= hid-tmff.o

Re: [PATCH 2/2] Support for Stantum multitouch panel

[Dmitry Torokhov]

Hi Stephane,

On Wed, Dec 09, 2009 at 10:49:28PM +0100, Stephane Chatty wrote:
> +
> +	if (emulate_touchscreen) {
> +		if (sd->first) {
> +			if (!sd->activity) {
> +				input_event(input, EV_KEY, BTN_TOUCH, 1);
> +				sd->activity = 1;
> +			}
> +			input_event(input, EV_ABS, ABS_X, sd->x);
> +			input_event(input, EV_ABS, ABS_Y, sd->y);
> +		}
> +	}

Why are you doing the above conditionally? Just report it always - less
setup required for the user.

-- 
Dmitry

Re: [PATCH 2/2] Support for Stantum multitouch panel

[Stéphane Chatty]

Le 10 déc. 09 à 00:15, Dmitry Torokhov a écrit :

> Hi Stephane,
>
> On Wed, Dec 09, 2009 at 10:49:28PM +0100, Stephane Chatty wrote:
>> +
>> +	if (emulate_touchscreen) {
>> +		if (sd->first) {
>> +			if (!sd->activity) {
>> +				input_event(input, EV_KEY, BTN_TOUCH, 1);
>> +				sd->activity = 1;
>> +			}
>> +			input_event(input, EV_ABS, ABS_X, sd->x);
>> +			input_event(input, EV_ABS, ABS_Y, sd->y);
>> +		}
>> +	}
>
> Why are you doing the above conditionally? Just report it always -  
> less
> setup required for the user.

As regards setup, the emulate_touchscreen parameter is 1 by default  
so that users don't have to care about it. But I felt compelled to  
have this parameter because the ongoing work on X.org suggests that  
there might be a problem in upper layers with having duplicate  
information flows. For instant, if we associate a slave pointer (MPX  
terminology) to every ABS_MT_X/ABS_MT_Y flow, the ABS_X/ABS_Y will  
come as an additional flow and we'll need to do something to ignore  
it. Benjamin, Peter, what do you think?

Also, some devices (especially the N-Trig) do not make it possible to  
implement a single touch emulation because they have no finger  
tracking (IDs change over time, you never know which finger to use  
and the cursor would jump from one to the other randomly). Therefore,  
I did not feel like creating a new "standard" behaviour that will be  
broken by such devices.

Actually, Rafi Rubin and I have started to discuss the idea of  
splitting this into two input nodes: a pure multitouch device and a  
pure single touch emulation. I'd like to have feedback on this idea  
too, even if I have no time to work on it yet.

St.

--
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] Support for Stantum multitouch panel

[Dmitry Torokhov]

On Thu, Dec 10, 2009 at 08:37:39AM +0100, Stéphane Chatty wrote:
>
> Le 10 déc. 09 à 00:15, Dmitry Torokhov a écrit :
>
>> Hi Stephane,
>>
>> On Wed, Dec 09, 2009 at 10:49:28PM +0100, Stephane Chatty wrote:
>>> +
>>> +	if (emulate_touchscreen) {
>>> +		if (sd->first) {
>>> +			if (!sd->activity) {
>>> +				input_event(input, EV_KEY, BTN_TOUCH, 1);
>>> +				sd->activity = 1;
>>> +			}
>>> +			input_event(input, EV_ABS, ABS_X, sd->x);
>>> +			input_event(input, EV_ABS, ABS_Y, sd->y);
>>> +		}
>>> +	}
>>
>> Why are you doing the above conditionally? Just report it always -  
>> less
>> setup required for the user.
>
> As regards setup, the emulate_touchscreen parameter is 1 by default so 
> that users don't have to care about it. But I felt compelled to have this 
> parameter because the ongoing work on X.org suggests that there might be 
> a problem in upper layers with having duplicate information flows. For 
> instant, if we associate a slave pointer (MPX terminology) to every 
> ABS_MT_X/ABS_MT_Y flow, the ABS_X/ABS_Y will come as an additional flow 
> and we'll need to do something to ignore it. Benjamin, Peter, what do you 
> think?

I thought Henrik's idea was that driver should use either classic or
multitouch events from the data stream but not both. This way users
could either use old, non-multitouch-aware drivers or newer ones without
issues.



>
> Also, some devices (especially the N-Trig) do not make it possible to  
> implement a single touch emulation because they have no finger tracking 
> (IDs change over time, you never know which finger to use and the cursor 
> would jump from one to the other randomly). Therefore, I did not feel 
> like creating a new "standard" behaviour that will be broken by such 
> devices.

If driver can't support something then it smply won't provide such
events at all and users that require certain capability will simply
ignore devices that don't provide it.

>
> Actually, Rafi Rubin and I have started to discuss the idea of splitting 
> this into two input nodes: a pure multitouch device and a pure single 
> touch emulation. I'd like to have feedback on this idea too, even if I 
> have no time to work on it yet.

If you create 2 devices basically supplying the same data then it will
be harder for consumers to select between them and drivers. I.e. if
single device transmits entire state then it is easy to write hotplug
policy for say X server (using udev/hal) such as:

	- this box always uses evdev for everything, or
	- devices with nultitouch capabilities use new multitouch
	  X driver, the rest use evdev.

This will be harder if there were 2 "copies" of multitouch devices
because we'd have to be able to recognize "siblings" and ignore one or
the other.

Does this make sense?

If there is a concern about too many unused events reaching userspace -
then we need to implement subscription model in evdev where consumer can
specify list of events it is interested in and have input core deliver
only those. I'll take patches ;)

-- 
Dmitry
--
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] Support for Stantum multitouch panel

[Rafi Rubin]

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

On 12/10/09 13:28, Dmitry Torokhov wrote:
> On Thu, Dec 10, 2009 at 08:37:39AM +0100, Stéphane Chatty wrote:
>>
>> Le 10 déc. 09 à 00:15, Dmitry Torokhov a écrit :
>>
>>> Hi Stephane,
>>>
>>> On Wed, Dec 09, 2009 at 10:49:28PM +0100, Stephane Chatty wrote:
>>>> +
>>>> +	if (emulate_touchscreen) {
>>>> +		if (sd->first) {
>>>> +			if (!sd->activity) {
>>>> +				input_event(input, EV_KEY, BTN_TOUCH, 1);
>>>> +				sd->activity = 1;
>>>> +			}
>>>> +			input_event(input, EV_ABS, ABS_X, sd->x);
>>>> +			input_event(input, EV_ABS, ABS_Y, sd->y);
>>>> +		}
>>>> +	}
>>>
>>> Why are you doing the above conditionally? Just report it always -  
>>> less
>>> setup required for the user.
>>
>> As regards setup, the emulate_touchscreen parameter is 1 by default so 
>> that users don't have to care about it. But I felt compelled to have this 
>> parameter because the ongoing work on X.org suggests that there might be 
>> a problem in upper layers with having duplicate information flows. For 
>> instant, if we associate a slave pointer (MPX terminology) to every 
>> ABS_MT_X/ABS_MT_Y flow, the ABS_X/ABS_Y will come as an additional flow 
>> and we'll need to do something to ignore it. Benjamin, Peter, what do you 
>> think?
> 
> I thought Henrik's idea was that driver should use either classic or
> multitouch events from the data stream but not both. This way users
> could either use old, non-multitouch-aware drivers or newer ones without
> issues.

How far are we from decent user-space support for multi-touch devices?  If we can expect that to solidify in the near future,
perhaps we'd be better off migrating away from conventional touchscreen/single point digitizer behavior.

>>
>> Also, some devices (especially the N-Trig) do not make it possible to  
>> implement a single touch emulation because they have no finger tracking 
>> (IDs change over time, you never know which finger to use and the cursor 
>> would jump from one to the other randomly). Therefore, I did not feel 
>> like creating a new "standard" behaviour that will be broken by such 
>> devices.
> 
> If driver can't support something then it smply won't provide such
> events at all and users that require certain capability will simply
> ignore devices that don't provide it.

In the case of the n-trig digitizer (with the latest firmware), single touch emulation can be reproduced by a relatively simple
tracking mechanism.  If we're talking about supporting dual mode drivers, would there be much objection to the cost of computation
in the kernel driver?

>>
>> Actually, Rafi Rubin and I have started to discuss the idea of splitting 
>> this into two input nodes: a pure multitouch device and a pure single 
>> touch emulation. I'd like to have feedback on this idea too, even if I 
>> have no time to work on it yet.
> 
> If you create 2 devices basically supplying the same data then it will
> be harder for consumers to select between them and drivers. I.e. if
> single device transmits entire state then it is easy to write hotplug
> policy for say X server (using udev/hal) such as:
> 
> 	- this box always uses evdev for everything, or
> 	- devices with nultitouch capabilities use new multitouch
> 	  X driver, the rest use evdev.
> 
> This will be harder if there were 2 "copies" of multitouch devices
> because we'd have to be able to recognize "siblings" and ignore one or
> the other.
> 
> Does this make sense?

At the moment, the evdev and wacom drivers (the only two that I've used for a digitizer), require specifying which device to use.  I
also have the memory (and I might just be miss-remembering) that the synaptics driver finds an event dev on its own.  So as far as I
see it a single driver should be smart enough to select the device that it prefers.

If we're worried about a discovery tool identifying both devs and assigning appropriate drivers to each, could we not just export
names that indicate they are in fact the same device and let the tools select which to prefer?  It should be trivial for such tools
to select sanely.


That being said, I did at some point have a touchpad that was configured such that I got events from both mice and an event dev, and
it was really annoying.

> If there is a concern about too many unused events reaching userspace -
> then we need to implement subscription model in evdev where consumer can
> specify list of events it is interested in and have input core deliver
> only those. I'll take patches ;)

While that sounds tempting, it also could introduce a bit of a hazard.  Programmer A masks out events he doesn't need, then
programmer B starts coding up support for more features and is confounded by the lack of response, and yet a hexdump of the dev
indicates the events are streaming.


On that note, how does one convince the input or hid core to emit an event when the state hasn't actually changed?  I ran into that
when I was trying to inject device swaps for interleaved streams of touch and pen events.  Clearly I was attacking a symptom and
ignoring the real problem, but I'm still curious.

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

iEYEARECAAYFAkshS8kACgkQwuRiAT9o60/G1ACgjYOiBoO4G/7aQqGM5I242+qL
nqEAmQHITeJrjaWPNZltwh/pQZV5IjEj
=X3Jl
-----END PGP SIGNATURE-----
--
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] Support for Stantum multitouch panel

[Peter Hutterer]

On Thu, Dec 10, 2009 at 02:28:10PM -0500, Rafi Rubin wrote:
> >> Actually, Rafi Rubin and I have started to discuss the idea of splitting 
> >> this into two input nodes: a pure multitouch device and a pure single 
> >> touch emulation. I'd like to have feedback on this idea too, even if I 
> >> have no time to work on it yet.
> > 
> > If you create 2 devices basically supplying the same data then it will
> > be harder for consumers to select between them and drivers. I.e. if
> > single device transmits entire state then it is easy to write hotplug
> > policy for say X server (using udev/hal) such as:
> > 
> > 	- this box always uses evdev for everything, or
> > 	- devices with nultitouch capabilities use new multitouch
> > 	  X driver, the rest use evdev.
> > 
> > This will be harder if there were 2 "copies" of multitouch devices
> > because we'd have to be able to recognize "siblings" and ignore one or
> > the other.
> > 
> > Does this make sense?
> 
> At the moment, the evdev and wacom drivers (the only two that I've used
> for a digitizer), require specifying which device to use.  I
> also have the memory (and I might just be miss-remembering) that the
> synaptics driver finds an event dev on its own.  So as far as I see it a
> single driver should be smart enough to select the device that it prefers.

synaptics does a simple 
for device in /dev/input/eventX
        open device
        if device is a synaptics device
                woohoo, found it

if not found
        write angry letter to editor


That used to be common for those configured in the xorg.conf but these days
HAL (udev, in the future) will provide the device file anyway.
the same approach could be used for any driver, the problem with it is that
you'd put the policy of which devices are ok to use into the driver and
there are overlapping ranges (evdev can deal with most touchpads and tablets
for example).

> If we're worried about a discovery tool identifying both devs and
> assigning appropriate drivers to each, could we not just export names that
> indicate they are in fact the same device and let the tools select which
> to prefer?  It should be trivial for such tools
> to select sanely.
> 
> 
> That being said, I did at some point have a touchpad that was configured
> such that I got events from both mice and an event dev, and it was really
> annoying.

by default, synaptics grabs the event device so you don't get the same
event twice. evdev doesn't to avoid things like rfkill and the mac mouse
button emulation breaking.
we've tried hard to DTRT in most configurations but there are some corner
cases where the only exit is fixing the user's configuration.
e.g. if you set up evdev on the event device and synaptics on
/dev/input/mice, then you can still get duplicate events.

> > If there is a concern about too many unused events reaching userspace -
> > then we need to implement subscription model in evdev where consumer can
> > specify list of events it is interested in and have input core deliver
> > only those. I'll take patches ;)
> 
> While that sounds tempting, it also could introduce a bit of a hazard.
> Programmer A masks out events he doesn't need, then programmer B starts
> coding up support for more features and is confounded by the lack of
> response, and yet a hexdump of the dev indicates the events are streaming.

from most input driver's POV it's easier to just ignore events that can't be
handled by the driver than to mask them out. Having them masked out can make
some debugging paths harder. it also ensures that the drivers are more
robust at dealing with unexpected events.
So I don't really have a need for this feature in X, though I can see how
others may find it useful.

Cheers,
  Peter

Re: [PATCH 2/2] Support for Stantum multitouch panel

[Peter Hutterer]

On Thu, Dec 10, 2009 at 10:28:44AM -0800, Dmitry Torokhov wrote:
> On Thu, Dec 10, 2009 at 08:37:39AM +0100, Stéphane Chatty wrote:
> >
> > Le 10 déc. 09 à 00:15, Dmitry Torokhov a écrit :
> >
> >> Hi Stephane,
> >>
> >> On Wed, Dec 09, 2009 at 10:49:28PM +0100, Stephane Chatty wrote:
> >>> +
> >>> +	if (emulate_touchscreen) {
> >>> +		if (sd->first) {
> >>> +			if (!sd->activity) {
> >>> +				input_event(input, EV_KEY, BTN_TOUCH, 1);
> >>> +				sd->activity = 1;
> >>> +			}
> >>> +			input_event(input, EV_ABS, ABS_X, sd->x);
> >>> +			input_event(input, EV_ABS, ABS_Y, sd->y);
> >>> +		}
> >>> +	}
> >>
> >> Why are you doing the above conditionally? Just report it always -  
> >> less
> >> setup required for the user.
> >
> > As regards setup, the emulate_touchscreen parameter is 1 by default so 
> > that users don't have to care about it. But I felt compelled to have this 
> > parameter because the ongoing work on X.org suggests that there might be 
> > a problem in upper layers with having duplicate information flows. For 
> > instant, if we associate a slave pointer (MPX terminology) to every 
> > ABS_MT_X/ABS_MT_Y flow, the ABS_X/ABS_Y will come as an additional flow 
> > and we'll need to do something to ignore it. Benjamin, Peter, what do you 
> > think?
> 
> I thought Henrik's idea was that driver should use either classic or
> multitouch events from the data stream but not both. This way users
> could either use old, non-multitouch-aware drivers or newer ones without
> issues.

are we talking about kernel drivers or userspace drivers here?

not handling ABS_MT_X, ABS_MT_Y properly in evdev is a bug (well,
not-yet-implemented feature) but if the kernel hands out both ABS_X and
ABS_MT_X that makes it difficult to determine which event is a valid one and
which one can be ignored.

> > Actually, Rafi Rubin and I have started to discuss the idea of splitting 
> > this into two input nodes: a pure multitouch device and a pure single 
> > touch emulation. I'd like to have feedback on this idea too, even if I 
> > have no time to work on it yet.
> 
> If you create 2 devices basically supplying the same data then it will
> be harder for consumers to select between them and drivers. I.e. if
> single device transmits entire state then it is easy to write hotplug
> policy for say X server (using udev/hal) such as:
> 
> 	- this box always uses evdev for everything, or
> 	- devices with nultitouch capabilities use new multitouch
> 	  X driver, the rest use evdev.
> 
> This will be harder if there were 2 "copies" of multitouch devices
> because we'd have to be able to recognize "siblings" and ignore one or
> the other.

not only that, but it's now quite easy to create devices as-needed within
the X driver and control creation/deletion of these devices as required by
underlying physical device. If the driver does that, it has knowledge of the
other devices it created and thus better control of the features these
provide.

having multiple devices provided by the kernel removes this ability, you'd
have to manually link them together.

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] Support for Stantum multitouch panel

[Dmitry Torokhov]

On Thu, Dec 10, 2009 at 02:28:10PM -0500, Rafi Rubin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 12/10/09 13:28, Dmitry Torokhov wrote:
> > On Thu, Dec 10, 2009 at 08:37:39AM +0100, Stéphane Chatty wrote:
> >>
> >> Le 10 déc. 09 à 00:15, Dmitry Torokhov a écrit :
> >>
> >>> Hi Stephane,
> >>>
> >>> On Wed, Dec 09, 2009 at 10:49:28PM +0100, Stephane Chatty wrote:
> >>>> +
> >>>> +	if (emulate_touchscreen) {
> >>>> +		if (sd->first) {
> >>>> +			if (!sd->activity) {
> >>>> +				input_event(input, EV_KEY, BTN_TOUCH, 1);
> >>>> +				sd->activity = 1;
> >>>> +			}
> >>>> +			input_event(input, EV_ABS, ABS_X, sd->x);
> >>>> +			input_event(input, EV_ABS, ABS_Y, sd->y);
> >>>> +		}
> >>>> +	}
> >>>
> >>> Why are you doing the above conditionally? Just report it always -  
> >>> less
> >>> setup required for the user.
> >>
> >> As regards setup, the emulate_touchscreen parameter is 1 by default so 
> >> that users don't have to care about it. But I felt compelled to have this 
> >> parameter because the ongoing work on X.org suggests that there might be 
> >> a problem in upper layers with having duplicate information flows. For 
> >> instant, if we associate a slave pointer (MPX terminology) to every 
> >> ABS_MT_X/ABS_MT_Y flow, the ABS_X/ABS_Y will come as an additional flow 
> >> and we'll need to do something to ignore it. Benjamin, Peter, what do you 
> >> think?
> > 
> > I thought Henrik's idea was that driver should use either classic or
> > multitouch events from the data stream but not both. This way users
> > could either use old, non-multitouch-aware drivers or newer ones without
> > issues.
> 
> How far are we from decent user-space support for multi-touch devices?
> If we can expect that to solidify in the near future, perhaps we'd be
> better off migrating away from conventional touchscreen/single point
> digitizer behavior.

I do not think would be wise. World is bigger than X.

> 
> >>
> >> Also, some devices (especially the N-Trig) do not make it possible to  
> >> implement a single touch emulation because they have no finger tracking 
> >> (IDs change over time, you never know which finger to use and the cursor 
> >> would jump from one to the other randomly). Therefore, I did not feel 
> >> like creating a new "standard" behaviour that will be broken by such 
> >> devices.
> > 
> > If driver can't support something then it smply won't provide such
> > events at all and users that require certain capability will simply
> > ignore devices that don't provide it.
> 

> In the case of the n-trig digitizer (with the latest firmware), single
> touch emulation can be reproduced by a relatively simple tracking
> mechanism.  If we're talking about supporting dual mode drivers, would
> there be much objection to the cost of computation in the kernel
> driver?
> 

It really depends on the cost, but I don't think there would be much
objection.

> >>
> >> Actually, Rafi Rubin and I have started to discuss the idea of splitting 
> >> this into two input nodes: a pure multitouch device and a pure single 
> >> touch emulation. I'd like to have feedback on this idea too, even if I 
> >> have no time to work on it yet.
> > 
> > If you create 2 devices basically supplying the same data then it will
> > be harder for consumers to select between them and drivers. I.e. if
> > single device transmits entire state then it is easy to write hotplug
> > policy for say X server (using udev/hal) such as:
> > 
> > 	- this box always uses evdev for everything, or
> > 	- devices with nultitouch capabilities use new multitouch
> > 	  X driver, the rest use evdev.
> > 
> > This will be harder if there were 2 "copies" of multitouch devices
> > because we'd have to be able to recognize "siblings" and ignore one or
> > the other.
> > 
> > Does this make sense?
>
 
> At the moment, the evdev and wacom drivers (the only two that I've
> used for a digitizer), require specifying which device to use.  I also
> have the memory (and I might just be miss-remembering) that the
> synaptics driver finds an event dev on its own.

I think this is only true in non-hotplug case.  I am running without
xorg.conf at the moment and X input hotplug seems to be working well
properly selecting the drivers and making sure that alps is driven by
Synaptics X driver while all the rest are driven by evdev.

> So as far as I see it
> a single driver should be smart enough to select the device that it
> prefers.

Right, but we are dealing with 2+ drivers. You need to somehow signal
evdev that it should not touch devices whose siblings are driven by
other drivers. But not always since sometimes siblings are to be driven
by different devices (ALPS touchpad is driven by Synaptics, sibling
representing trackpoint is driven legitimately by evdev).

> 
> If we're worried about a discovery tool identifying both devs and
> assigning appropriate drivers to each, could we not just export names
> that indicate they are in fact the same device and let the tools
> select which to prefer?  It should be trivial for such tools to select
> sanely.
> 

Too fragile IMO.

> 
> That being said, I did at some point have a touchpad that was
> configured such that I got events from both mice and an event dev, and
> it was really annoying.
>

Yep.
 
> > If there is a concern about too many unused events reaching userspace -
> > then we need to implement subscription model in evdev where consumer can
> > specify list of events it is interested in and have input core deliver
> > only those. I'll take patches ;)
> 
> While that sounds tempting, it also could introduce a bit of a hazard.
> Programmer A masks out events he doesn't need, then programmer B
> starts coding up support for more features and is confounded by the
> lack of response, and yet a hexdump of the dev indicates the events
> are streaming.
> 

I think you are stretching it a bit here. Yes, it is possible but people
should really be familiar with the codebase.

> 
> On that note, how does one convince the input or hid core to emit an
> event when the state hasn't actually changed?  I ran into that when I
> was trying to inject device swaps for interleaved streams of touch and
> pen events.  Clearly I was attacking a symptom and ignoring the real
> problem, but I'm still curious.
>

There isn't. It is a feature - if state did not change there is no
reason to transmit it.

-- 
Dmitry
--
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] Support for Stantum multitouch panel

[Dmitry Torokhov]

On Fri, Dec 11, 2009 at 10:03:18AM +1000, Peter Hutterer wrote:
> On Thu, Dec 10, 2009 at 10:28:44AM -0800, Dmitry Torokhov wrote:
> > On Thu, Dec 10, 2009 at 08:37:39AM +0100, Stéphane Chatty wrote:
> > >
> > > Le 10 déc. 09 à 00:15, Dmitry Torokhov a écrit :
> > >
> > >> Hi Stephane,
> > >>
> > >> On Wed, Dec 09, 2009 at 10:49:28PM +0100, Stephane Chatty wrote:
> > >>> +
> > >>> +	if (emulate_touchscreen) {
> > >>> +		if (sd->first) {
> > >>> +			if (!sd->activity) {
> > >>> +				input_event(input, EV_KEY, BTN_TOUCH, 1);
> > >>> +				sd->activity = 1;
> > >>> +			}
> > >>> +			input_event(input, EV_ABS, ABS_X, sd->x);
> > >>> +			input_event(input, EV_ABS, ABS_Y, sd->y);
> > >>> +		}
> > >>> +	}
> > >>
> > >> Why are you doing the above conditionally? Just report it always -  
> > >> less
> > >> setup required for the user.
> > >
> > > As regards setup, the emulate_touchscreen parameter is 1 by default so 
> > > that users don't have to care about it. But I felt compelled to have this 
> > > parameter because the ongoing work on X.org suggests that there might be 
> > > a problem in upper layers with having duplicate information flows. For 
> > > instant, if we associate a slave pointer (MPX terminology) to every 
> > > ABS_MT_X/ABS_MT_Y flow, the ABS_X/ABS_Y will come as an additional flow 
> > > and we'll need to do something to ignore it. Benjamin, Peter, what do you 
> > > think?
> > 
> > I thought Henrik's idea was that driver should use either classic or
> > multitouch events from the data stream but not both. This way users
> > could either use old, non-multitouch-aware drivers or newer ones without
> > issues.
> 
> are we talking about kernel drivers or userspace drivers here?
> 
> not handling ABS_MT_X, ABS_MT_Y properly in evdev is a bug (well,
> not-yet-implemented feature) but if the kernel hands out both ABS_X and
> ABS_MT_X that makes it difficult to determine which event is a valid one and
> which one can be ignored.
> 

No, it is pretty simple - all events are valid, otherwise it is kernel
driver bug. Now, as userspace consumer, if you know how to handle
multitouch protocol then use it, ignore ABS_X/ABS_Y. Otherwise you'd be
dropping ABS_MT_* events and naturally handling ABS_X/ABS_Y.

-- 
Dmitry
--
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] Support for Stantum multitouch panel

[Peter Hutterer]

On Thu, Dec 10, 2009 at 04:19:22PM -0800, Dmitry Torokhov wrote:
> > are we talking about kernel drivers or userspace drivers here?
> > 
> > not handling ABS_MT_X, ABS_MT_Y properly in evdev is a bug (well,
> > not-yet-implemented feature) but if the kernel hands out both ABS_X and
> > ABS_MT_X that makes it difficult to determine which event is a valid one and
> > which one can be ignored.
> > 
> 
> No, it is pretty simple - all events are valid, otherwise it is kernel
> driver bug. Now, as userspace consumer, if you know how to handle
> multitouch protocol then use it, ignore ABS_X/ABS_Y. Otherwise you'd be
> dropping ABS_MT_* events and naturally handling ABS_X/ABS_Y.

Thanks, that's the answer I hoped for - if ABS_MT_X is available, we can
ignore ABS_X.

The tricky part would have been if both were equally valid _at the same
time_ but refer to different inputs. at which point you'd have to find out
which one to map to which pointer axis, etc. We already have a problem with
REL_X and ABS_X on the same device, adding the ABS_MT_X to that mess
wouldn't have helped the situation.

Cheers,
  Peter

Re: [PATCH 2/2] Support for Stantum multitouch panel

[Dmitry Torokhov]

On Fri, Dec 11, 2009 at 10:35:04AM +1000, Peter Hutterer wrote:
> On Thu, Dec 10, 2009 at 04:19:22PM -0800, Dmitry Torokhov wrote:
> > > are we talking about kernel drivers or userspace drivers here?
> > > 
> > > not handling ABS_MT_X, ABS_MT_Y properly in evdev is a bug (well,
> > > not-yet-implemented feature) but if the kernel hands out both ABS_X and
> > > ABS_MT_X that makes it difficult to determine which event is a valid one and
> > > which one can be ignored.
> > > 
> > 
> > No, it is pretty simple - all events are valid, otherwise it is kernel
> > driver bug. Now, as userspace consumer, if you know how to handle
> > multitouch protocol then use it, ignore ABS_X/ABS_Y. Otherwise you'd be
> > dropping ABS_MT_* events and naturally handling ABS_X/ABS_Y.
> 
> Thanks, that's the answer I hoped for - if ABS_MT_X is available, we can
> ignore ABS_X.
> 
> The tricky part would have been if both were equally valid _at the same
> time_ but refer to different inputs. at which point you'd have to find out
> which one to map to which pointer axis, etc. We already have a problem with
> REL_X and ABS_X on the same device, adding the ABS_MT_X to that mess
> wouldn't have helped the situation.

What devices report both ABS_X and REL_X events?

-- 
Dmitry

Re: [PATCH 2/2] Support for Stantum multitouch panel

[Peter Hutterer]

On Thu, Dec 10, 2009 at 04:47:20PM -0800, Dmitry Torokhov wrote:
> On Fri, Dec 11, 2009 at 10:35:04AM +1000, Peter Hutterer wrote:
> > On Thu, Dec 10, 2009 at 04:19:22PM -0800, Dmitry Torokhov wrote:
> > > > are we talking about kernel drivers or userspace drivers here?
> > > > 
> > > > not handling ABS_MT_X, ABS_MT_Y properly in evdev is a bug (well,
> > > > not-yet-implemented feature) but if the kernel hands out both ABS_X and
> > > > ABS_MT_X that makes it difficult to determine which event is a valid one and
> > > > which one can be ignored.
> > > > 
> > > 
> > > No, it is pretty simple - all events are valid, otherwise it is kernel
> > > driver bug. Now, as userspace consumer, if you know how to handle
> > > multitouch protocol then use it, ignore ABS_X/ABS_Y. Otherwise you'd be
> > > dropping ABS_MT_* events and naturally handling ABS_X/ABS_Y.
> > 
> > Thanks, that's the answer I hoped for - if ABS_MT_X is available, we can
> > ignore ABS_X.
> > 
> > The tricky part would have been if both were equally valid _at the same
> > time_ but refer to different inputs. at which point you'd have to find out
> > which one to map to which pointer axis, etc. We already have a problem with
> > REL_X and ABS_X on the same device, adding the ABS_MT_X to that mess
> > wouldn't have helped the situation.
> 
> What devices report both ABS_X and REL_X events?

Xen Virtual Pointer
AlpsPS/2 ALPS GlidePoint
WALTOP International Corp. Slim Tablet
MS Optical Desktop 2000

are the ones I've got evtest outputs for and that I found in a 2 minute
search. There's quite a few of them around, tablets, touchscreens and IIRC
even some mice.

This is valid from the kernel's perspective and it makes sense too.
The problem is solely within X where we're not flexible enough yet to switch
between rel and abs after the initial setup. We end up ignoring one of the
two axes depending on what the device is but there are always corner cases.

Cheers,
  Peter

Re: [PATCH 2/2] Support for Stantum multitouch panel

[Dmitry Torokhov]

On Fri, Dec 11, 2009 at 10:58:31AM +1000, Peter Hutterer wrote:
> On Thu, Dec 10, 2009 at 04:47:20PM -0800, Dmitry Torokhov wrote:
> > On Fri, Dec 11, 2009 at 10:35:04AM +1000, Peter Hutterer wrote:
> > > On Thu, Dec 10, 2009 at 04:19:22PM -0800, Dmitry Torokhov wrote:
> > > > > are we talking about kernel drivers or userspace drivers here?
> > > > > 
> > > > > not handling ABS_MT_X, ABS_MT_Y properly in evdev is a bug (well,
> > > > > not-yet-implemented feature) but if the kernel hands out both ABS_X and
> > > > > ABS_MT_X that makes it difficult to determine which event is a valid one and
> > > > > which one can be ignored.
> > > > > 
> > > > 
> > > > No, it is pretty simple - all events are valid, otherwise it is kernel
> > > > driver bug. Now, as userspace consumer, if you know how to handle
> > > > multitouch protocol then use it, ignore ABS_X/ABS_Y. Otherwise you'd be
> > > > dropping ABS_MT_* events and naturally handling ABS_X/ABS_Y.
> > > 
> > > Thanks, that's the answer I hoped for - if ABS_MT_X is available, we can
> > > ignore ABS_X.
> > > 
> > > The tricky part would have been if both were equally valid _at the same
> > > time_ but refer to different inputs. at which point you'd have to find out
> > > which one to map to which pointer axis, etc. We already have a problem with
> > > REL_X and ABS_X on the same device, adding the ABS_MT_X to that mess
> > > wouldn't have helped the situation.
> > 
> > What devices report both ABS_X and REL_X events?
> 
> Xen Virtual Pointer
> AlpsPS/2 ALPS GlidePoint

Hmm, ALPS should not be reporting REL_X/REL_Y on touchpad device, only
on the secondary device. I will fix it, thank you for the report.

-- 
Dmitry

Re: [PATCH 2/2] Support for Stantum multitouch panel

[Stephane Chatty]

Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

>
> > Dmitry
>
Added support for the Stantum multitouch panel.

Signed-off-by: Stephane Chatty <chatty@enac.fr>

diff -rupN a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
--- a/drivers/hid/hid-core.c	2009-12-08 22:32:21.000000000 +0100
+++ b/drivers/hid/hid-core.c	2009-12-08 22:36:19.000000000 +0100
@@ -1337,6 +1337,7 @@ static const struct hid_device_id hid_bl
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SAMSUNG, USB_DEVICE_ID_SAMSUNG_IR_REMOTE) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS3_CONTROLLER) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_STANTUM, USB_DEVICE_ID_MTP) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SUNPLUS, USB_DEVICE_ID_SUNPLUS_WDESKTOP) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb300) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb304) },
diff -rupN a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
--- a/drivers/hid/hid-ids.h	2009-12-03 04:51:21.000000000 +0100
+++ b/drivers/hid/hid-ids.h	2009-12-08 22:43:10.000000000 +0100
@@ -383,6 +383,9 @@
 #define USB_DEVICE_ID_SOUNDGRAPH_IMON_FIRST	0x0034
 #define USB_DEVICE_ID_SOUNDGRAPH_IMON_LAST	0x0046
 
+#define USB_VENDOR_ID_STANTUM		0x1f87
+#define USB_DEVICE_ID_MTP		0x0002
+
 #define USB_VENDOR_ID_SUN		0x0430
 #define USB_DEVICE_ID_RARITAN_KVM_DONGLE	0xcdab
 
diff -rupN a/drivers/hid/hid-stantum.c b/drivers/hid/hid-stantum.c
--- a/drivers/hid/hid-stantum.c	1970-01-01 01:00:00.000000000 +0100
+++ b/drivers/hid/hid-stantum.c	2009-12-23 11:05:11.000000000 +0100
@@ -0,0 +1,283 @@
+/*
+ *  HID driver for Stantum multitouch panels
+ *
+ *  Copyright (c) 2009 Stephane Chatty <chatty@enac.fr>
+ *
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include <linux/device.h>
+#include <linux/hid.h>
+#include <linux/module.h>
+
+MODULE_VERSION("0.6");
+MODULE_AUTHOR("Stephane Chatty <chatty@enac.fr>");
+MODULE_DESCRIPTION("Stantum HID multitouch panels");
+MODULE_LICENSE("GPL");
+
+#include "hid-ids.h"
+
+struct stantum_data {
+	__s32 x, y, z, w, h;	/* x, y, pressure, width, height */
+	__u16 id;		/* touch id */
+	bool valid;		/* valid finger data, or just placeholder? */
+	bool first;		/* first finger in the HID packet? */
+	bool activity;		/* at least one active finger so far? */
+};
+
+static int stantum_input_mapping(struct hid_device *hdev, struct hid_input *hi,
+		struct hid_field *field, struct hid_usage *usage,
+		unsigned long **bit, int *max)
+{
+	switch (usage->hid & HID_USAGE_PAGE) {
+
+	case HID_UP_GENDESK:
+		switch (usage->hid) {
+		case HID_GD_X:
+			hid_map_usage(hi, usage, bit, max,
+					EV_ABS, ABS_MT_POSITION_X);
+			/* touchscreen emulation */
+			input_set_abs_params(hi->input, ABS_X,
+						field->logical_minimum,
+						field->logical_maximum, 0, 0);
+			return 1;
+		case HID_GD_Y:
+			hid_map_usage(hi, usage, bit, max,
+					EV_ABS, ABS_MT_POSITION_Y);
+			/* touchscreen emulation */
+			input_set_abs_params(hi->input, ABS_Y,
+						field->logical_minimum,
+						field->logical_maximum, 0, 0);
+			return 1;
+		}
+		return 0;
+
+	case HID_UP_DIGITIZER:
+		switch (usage->hid) {
+		case HID_DG_INRANGE:
+		case HID_DG_CONFIDENCE:
+		case HID_DG_INPUTMODE:
+		case HID_DG_DEVICEINDEX:
+		case HID_DG_CONTACTCOUNT:
+		case HID_DG_CONTACTMAX:
+		case HID_DG_TIPPRESSURE:
+			return -1;
+
+		case HID_DG_TIPSWITCH:
+			/* touchscreen emulation */
+			hid_map_usage(hi, usage, bit, max, EV_KEY, BTN_TOUCH);
+			return 1;
+
+		case HID_DG_WIDTH:
+			hid_map_usage(hi, usage, bit, max,
+					EV_ABS, ABS_MT_TOUCH_MAJOR);
+			return 1;
+		case HID_DG_HEIGHT:
+			hid_map_usage(hi, usage, bit, max,
+					EV_ABS, ABS_MT_TOUCH_MINOR);
+			input_set_abs_params(hi->input, ABS_MT_ORIENTATION,
+					1, 1, 0, 0);
+			return 1;
+		case HID_DG_CONTACTID:
+			hid_map_usage(hi, usage, bit, max,
+					EV_ABS, ABS_MT_TRACKING_ID);
+			return 1;
+
+		}
+		return 0;
+
+	case 0xff000000:
+		/* no input-oriented meaning */
+		return -1;
+	}
+
+	return 0;
+}
+
+static int stantum_input_mapped(struct hid_device *hdev, struct hid_input *hi,
+		struct hid_field *field, struct hid_usage *usage,
+		unsigned long **bit, int *max)
+{
+	if (usage->type == EV_KEY || usage->type == EV_ABS)
+		clear_bit(usage->code, *bit);
+
+	return 0;
+}
+
+/*
+ * this function is called when a whole finger has been parsed,
+ * so that it can decide what to send to the input layer.
+ */
+static void stantum_filter_event(struct stantum_data *sd,
+					struct input_dev *input)
+{
+	bool wide;
+
+	if (!sd->valid) {
+		/*
+		 * touchscreen emulation: if the first finger is not valid and
+		 * there previously was finger activity, this is a release
+		 */
+		if (sd->first && sd->activity) {
+			input_event(input, EV_KEY, BTN_TOUCH, 0);
+			sd->activity = false;
+		}
+		return;
+	}
+
+	input_event(input, EV_ABS, ABS_MT_TRACKING_ID, sd->id);
+	input_event(input, EV_ABS, ABS_MT_POSITION_X, sd->x);
+	input_event(input, EV_ABS, ABS_MT_POSITION_Y, sd->y);
+
+	wide = (sd->w > sd->h);
+	input_event(input, EV_ABS, ABS_MT_ORIENTATION, wide);
+	input_event(input, EV_ABS, ABS_MT_TOUCH_MAJOR, wide ? sd->w : sd->h);
+	input_event(input, EV_ABS, ABS_MT_TOUCH_MINOR, wide ? sd->h : sd->w);
+
+#if 0
+	/* MT_PRESSURE does not exist yet */
+	input_event(input, EV_ABS, ABS_MT_PRESSURE, sd->z);
+#endif
+
+	input_mt_sync(input);
+	sd->valid = false;
+	sd->first = false;
+
+	/* touchscreen emulation */
+	if (sd->first) {
+		if (!sd->activity) {
+			input_event(input, EV_KEY, BTN_TOUCH, 1);
+			sd->activity = true;
+		}
+		input_event(input, EV_ABS, ABS_X, sd->x);
+		input_event(input, EV_ABS, ABS_Y, sd->y);
+	}
+}
+
+
+static int stantum_event(struct hid_device *hid, struct hid_field *field,
+				struct hid_usage *usage, __s32 value)
+{
+	struct stantum_data *sd = hid_get_drvdata(hid);
+
+	if (hid->claimed & HID_CLAIMED_INPUT) {
+		struct input_dev *input = field->hidinput->input;
+
+		switch (usage->hid) {
+		case HID_DG_INRANGE:
+			/* this is the last field in a finger */
+			stantum_filter_event(sd, input);
+			break;
+		case HID_DG_WIDTH:
+			sd->w = value;
+			break;
+		case HID_DG_HEIGHT:
+			sd->h = value;
+			break;
+		case HID_GD_X:
+			sd->x = value;
+			break;
+		case HID_GD_Y:
+			sd->y = value;
+			break;
+		case HID_DG_TIPPRESSURE:
+			sd->z = value;
+			break;
+		case HID_DG_CONTACTID:
+			sd->id = value;
+			break;
+		case HID_DG_CONFIDENCE:
+			sd->valid = !!value;
+			break;
+		case 0xff000002:
+			/* this comes only before the first finger */
+			sd->first = true;
+			break;
+
+		default:
+			/* ignore the others */
+			return 1;
+		}
+	}
+
+	/* we have handled the hidinput part, now remains hiddev */
+	if (hid->claimed & HID_CLAIMED_HIDDEV && hid->hiddev_hid_event)
+		hid->hiddev_hid_event(hid, field, usage, value);
+
+	return 1;
+}
+
+static int stantum_probe(struct hid_device *hdev,
+				const struct hid_device_id *id)
+{
+	int ret;
+	struct stantum_data *sd;
+
+	sd = kmalloc(sizeof(struct stantum_data), GFP_KERNEL);
+	if (!sd) {
+		dev_err(&hdev->dev, "cannot allocate Stantum data\n");
+		return -ENOMEM;
+	}
+	sd->valid = false;
+	sd->first = false;
+	sd->activity = false;
+	hid_set_drvdata(hdev, sd);
+
+	ret = hid_parse(hdev);
+	if (!ret)
+		ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+
+	if (ret)
+		kfree(sd);
+
+	return ret;
+}
+
+static void stantum_remove(struct hid_device *hdev)
+{
+	hid_hw_stop(hdev);
+	kfree(hid_get_drvdata(hdev));
+	hid_set_drvdata(hdev, NULL);
+}
+
+static const struct hid_device_id stantum_devices[] = {
+	{ HID_USB_DEVICE(USB_VENDOR_ID_STANTUM, USB_DEVICE_ID_MTP) },
+	{ }
+};
+MODULE_DEVICE_TABLE(hid, stantum_devices);
+
+static const struct hid_usage_id stantum_grabbed_usages[] = {
+	{ HID_ANY_ID, HID_ANY_ID, HID_ANY_ID },
+	{ HID_ANY_ID - 1, HID_ANY_ID - 1, HID_ANY_ID - 1}
+};
+
+static struct hid_driver stantum_driver = {
+	.name = "stantum",
+	.id_table = stantum_devices,
+	.probe = stantum_probe,
+	.remove = stantum_remove,
+	.input_mapping = stantum_input_mapping,
+	.input_mapped = stantum_input_mapped,
+	.usage_table = stantum_grabbed_usages,
+	.event = stantum_event,
+};
+
+static int __init stantum_init(void)
+{
+	return hid_register_driver(&stantum_driver);
+}
+
+static void __exit stantum_exit(void)
+{
+	hid_unregister_driver(&stantum_driver);
+}
+
+module_init(stantum_init);
+module_exit(stantum_exit);
+
diff -rupN a/drivers/hid/Kconfig b/drivers/hid/Kconfig
--- a/drivers/hid/Kconfig	2009-12-08 22:32:05.000000000 +0100
+++ b/drivers/hid/Kconfig	2009-12-23 11:02:12.000000000 +0100
@@ -241,6 +241,12 @@ config HID_SONY
 	---help---
 	Support for Sony PS3 controller.
 
+config HID_STANTUM
+	tristate "Stantum" if EMBEDDED
+	depends on USB_HID
+	---help---
+	Support for Stantum multitouch panel.
+
 config HID_SUNPLUS
 	tristate "Sunplus" if EMBEDDED
 	depends on USB_HID
diff -rupN a/drivers/hid/Makefile b/drivers/hid/Makefile
--- a/drivers/hid/Makefile	2009-12-08 22:32:01.000000000 +0100
+++ b/drivers/hid/Makefile	2009-12-08 22:35:20.000000000 +0100
@@ -39,6 +39,7 @@ obj-$(CONFIG_HID_PETALYNX)	+= hid-petaly
 obj-$(CONFIG_HID_SAMSUNG)	+= hid-samsung.o
 obj-$(CONFIG_HID_SMARTJOYPLUS)	+= hid-sjoy.o
 obj-$(CONFIG_HID_SONY)		+= hid-sony.o
+obj-$(CONFIG_HID_STANTUM)	+= hid-stantum.o
 obj-$(CONFIG_HID_SUNPLUS)	+= hid-sunplus.o
 obj-$(CONFIG_HID_GREENASIA)	+= hid-gaff.o
 obj-$(CONFIG_HID_THRUSTMASTER)	+= hid-tmff.o

Re: [PATCH 2/2] Support for Stantum multitouch panel

[Jiri Kosina]

On Wed, 23 Dec 2009, Stephane Chatty wrote:

> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> >
> > > Dmitry
> >
> Added support for the Stantum multitouch panel.

I have applied the patch, thanks Stephane.

(I have removed the dependency on CONFIG_EMBEDDED, the same way we 
discussed this for 3M driver already).

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.