[PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Chris Ball]

The JooJoo tablet (http://thejoojoo.com/) contains an "eGalax Inc. USB
TouchController", and this patch hooks it up to the egalax-touch driver.
Without the patch we don't get any cursor motion, since it comes through
Z/RX rather than X/Y.

Signed-off-by: Chris Ball <cjb@laptop.org>
---
 drivers/hid/hid-egalax.c |    2 ++
 drivers/hid/hid-ids.h    |    1 +
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/hid/hid-egalax.c b/drivers/hid/hid-egalax.c
index f44bdc0..22e3b35 100644
--- a/drivers/hid/hid-egalax.c
+++ b/drivers/hid/hid-egalax.c
@@ -246,6 +246,8 @@ static void egalax_remove(struct hid_device *hdev)
 static const struct hid_device_id egalax_devices[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_DWAV,
 			USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_DWAV,
+			USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH1) },
 	{ }
 };
 MODULE_DEVICE_TABLE(hid, egalax_devices);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 6af77ed..01c3009 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -185,6 +185,7 @@
 #define USB_VENDOR_ID_DWAV		0x0eef
 #define USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER	0x0001
 #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH	0x480d
+#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH1	0x720c
 
 #define USB_VENDOR_ID_ELO		0x04E7
 #define USB_DEVICE_ID_ELO_TS2700	0x0020
-- 
1.6.6.1

-- 
Chris Ball   <cjb@laptop.org>
One Laptop Per Child

Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Jiri Kosina]

On Thu, 12 Aug 2010, Chris Ball wrote:

> The JooJoo tablet (http://thejoojoo.com/) contains an "eGalax Inc. USB
> TouchController", and this patch hooks it up to the egalax-touch driver.
> Without the patch we don't get any cursor motion, since it comes through
> Z/RX rather than X/Y.
> 
> Signed-off-by: Chris Ball <cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>
> ---
>  drivers/hid/hid-egalax.c |    2 ++
>  drivers/hid/hid-ids.h    |    1 +
>  2 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/hid/hid-egalax.c b/drivers/hid/hid-egalax.c
> index f44bdc0..22e3b35 100644
> --- a/drivers/hid/hid-egalax.c
> +++ b/drivers/hid/hid-egalax.c
> @@ -246,6 +246,8 @@ static void egalax_remove(struct hid_device *hdev)
>  static const struct hid_device_id egalax_devices[] = {
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_DWAV,
>  			USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH) },
> +	{ HID_USB_DEVICE(USB_VENDOR_ID_DWAV,
> +			USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH1) },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(hid, egalax_devices);
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 6af77ed..01c3009 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -185,6 +185,7 @@
>  #define USB_VENDOR_ID_DWAV		0x0eef
>  #define USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER	0x0001
>  #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH	0x480d
> +#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH1	0x720c
>  
>  #define USB_VENDOR_ID_ELO		0x04E7
>  #define USB_DEVICE_ID_ELO_TS2700	0x0020

Hi Chris,

has this patch been really tested?

I am almost certain that we need to have the device ID to be added to 
hid_blacklist[] in drivers/hid/hid-core.c as well. Otherwise the 
hid-egalax driver wouldn't bind to the device automatically in a proper 
way.

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Stéphane Chatty]

Le 13 août 10 à 01:15, Jiri Kosina a écrit :
> i Chris,
>
> has this patch been really tested?
>
> I am almost certain that we need to have the device ID to be added to
> hid_blacklist[] in drivers/hid/hid-core.c as well. Otherwise the
> hid-egalax driver wouldn't bind to the device automatically in a  
> proper
> way.
>

Guys,

I happen to have gathered information about this during the last five  
days:

  - Mathieu Virbel, author of PyMT, has reported that with the above  
patch (and probably the corresponding change to hid-core.c) the  
multitouch panel of the Joojoo kind of works, but with a strange  
behaviour: SYNC messages are inserted between fingers.

  - after checking HID report descriptors, it appears that the  
protocol used by this device is fairly different from that of the  
eGalax found in the T101MT. Basically, it uses what Microsoft  
describes as 'serial' multitouch events instead of the 'parallel'  
multitouch events we ususally see. This means that each finger is  
reported in a message of its own.

  - after checking with the maker of these panels, it appears that  
they have two independent product lines. One, with product IDs 48xx,  
is resistive and has a classical 'parallel' protocol. The other, with  
product IDs 72xx, is capacitive and has an unusual 'serial' protocol.  
The Joojoo has the latter.

In summary this is a new kind of panel with an unusual HID prototol  
and the hid-egalax driver fails at producing a proper event sequence.  
The major issue here is that the key to resolving the problem does  
*not* lie in the driver: SYNC messages are produced in hid-input.c  
and drivers cannot block them. To address this, one would need to  
make the <HID event> -> <input event> + <sync> mapping less  
systematic. This could converge with the efforts required if we were  
to have a more generic management of multitouch devices (we need one  
driver for each device because hid-core.c was not designed with this  
kind of device in mind).

My suggestions:
  - accept the patch, after adding a few comments in the code about  
this device requiring future care for its 'serial' protocol.
  - start thinking about what changes are required in hid-input and/ 
or hid-core for a more generic management of multitouch devices.

Cheers,

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 RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Chris Ball]

Hi,

Jiri wrote:
   > has this patch been really tested?
   >
   > I am almost certain that we need to have the device ID to be added to
   > hid_blacklist[] in drivers/hid/hid-core.c as well. Otherwise the
   > hid-egalax driver wouldn't bind to the device automatically in a
   > proper way.

Thanks for noticing that; you're right, it's necessary.  I only tested
CONFIG_HID_EGALAX=y, which doesn't seem to require the blacklist entry.
I've tested that using the blacklist with =m works now.

Stéphane wrote:
   > My suggestions:
   >   - accept the patch, after adding a few comments in the code about
   > this device requiring future care for its 'serial' protocol.
   >   - start thinking about what changes are required in hid-input and/
   > or hid-core for a more generic management of multitouch devices.

I've added a comment, feel free to reword it if you'd like to.  Thanks
for the excellent research!


From: Chris Ball <cjb@laptop.org>
Subject: [PATCH] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

The JooJoo tablet (http://thejoojoo.com/) contains an "eGalax Inc. USB
TouchController", and this patch hooks it up to the egalax-touch driver.
Without the patch we don't get any cursor motion, since it comes through
Z/RX rather than X/Y.

(The egalax-touch driver does not yet generate a correct event sequence
for the "serial" protocol used by this device, though -- see the note
added to the code, which comes from research by Stéphane Chatty.)

Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Stéphane Chatty <chatty@enac.fr>
Signed-off-by: Chris Ball <cjb@laptop.org>
---
 drivers/hid/hid-core.c   |    1 +
 drivers/hid/hid-egalax.c |    9 +++++++++
 drivers/hid/hid-ids.h    |    1 +
 3 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index e635199..0c52899 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1299,6 +1299,7 @@ static const struct hid_device_id hid_blacklist[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_MOUSE) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, 0x0006) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_DWAV, USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_DWAV, USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH1) },
 	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM, USB_DEVICE_ID_ELECOM_BM084) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_EZKEY, USB_DEVICE_ID_BTC_8193) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_GAMERON, USB_DEVICE_ID_GAMERON_DUAL_PSX_ADAPTOR) },
diff --git a/drivers/hid/hid-egalax.c b/drivers/hid/hid-egalax.c
index f44bdc0..a852e31 100644
--- a/drivers/hid/hid-egalax.c
+++ b/drivers/hid/hid-egalax.c
@@ -159,6 +159,13 @@ static int egalax_event(struct hid_device *hid, struct hid_field *field,
 {
 	struct egalax_data *td = hid_get_drvdata(hid);
 
+	/* Note, eGalax has two product lines: the first is resistive and
+	 * uses a standard parallel multitouch protocol (product ID ==
+	 * 48xx).  The second is capacitive and uses an unusual "serial"
+	 * protocol with a different message for each multitouch finger
+	 * (product ID == 72xx).  We do not yet generate a correct event
+	 * sequence for the capacitive/serial protocol.
+	 */
 	if (hid->claimed & HID_CLAIMED_INPUT) {
 		struct input_dev *input = field->hidinput->input;
 
@@ -246,6 +253,8 @@ static void egalax_remove(struct hid_device *hdev)
 static const struct hid_device_id egalax_devices[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_DWAV,
 			USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_DWAV,
+			USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH1) },
 	{ }
 };
 MODULE_DEVICE_TABLE(hid, egalax_devices);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index d3fc13a..85c6d13 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -188,6 +188,7 @@
 #define USB_VENDOR_ID_DWAV		0x0eef
 #define USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER	0x0001
 #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH	0x480d
+#define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH1	0x720c
 
 #define USB_VENDOR_ID_ELECOM		0x056e
 #define USB_DEVICE_ID_ELECOM_BM084	0x0061
-- 
1.6.2.5
--
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 RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Jiri Kosina]

On Fri, 13 Aug 2010, Stéphane Chatty wrote:

> In summary this is a new kind of panel with an unusual HID prototol and the
> hid-egalax driver fails at producing a proper event sequence. The major issue
> here is that the key to resolving the problem does *not* lie in the driver:
> SYNC messages are produced in hid-input.c and drivers cannot block them. To
> address this, one would need to make the <HID event> -> <input event> + <sync>
> mapping less systematic. This could converge with the efforts required if we
> were to have a more generic management of multitouch devices (we need one
> driver for each device because hid-core.c was not designed with this kind of
> device in mind).
> 
> My suggestions:
> - accept the patch, after adding a few comments in the code about this device
> requiring future care for its 'serial' protocol.
> - start thinking about what changes are required in hid-input and/or hid-core
> for a more generic management of multitouch devices.

Hi Stephane,

thanks for the analysis. How do devices in their report descriptor 
describe the fact whether the events should be interleaved by sync or not?

We definitely could create a specialized version of 
hidinput_report_event() for certain reports, which wouldn't issue the 
input_sync() call, but I wonder what is the distinguishing factor.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--
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 RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Jiri Kosina]

On Fri, 13 Aug 2010, Chris Ball wrote:

>    > has this patch been really tested?
>    >
>    > I am almost certain that we need to have the device ID to be added to
>    > hid_blacklist[] in drivers/hid/hid-core.c as well. Otherwise the
>    > hid-egalax driver wouldn't bind to the device automatically in a
>    > proper way.
> 
> Thanks for noticing that; you're right, it's necessary.  I only tested
> CONFIG_HID_EGALAX=y, which doesn't seem to require the blacklist entry.
> I've tested that using the blacklist with =m works now.
> 
> Stéphane wrote:
>    > My suggestions:
>    >   - accept the patch, after adding a few comments in the code about
>    > this device requiring future care for its 'serial' protocol.
>    >   - start thinking about what changes are required in hid-input and/
>    > or hid-core for a more generic management of multitouch devices.
> 
> I've added a comment, feel free to reword it if you'd like to.  Thanks
> for the excellent research!

Thanks indeed.

I have now applied the patch.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--
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 RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Stéphane Chatty]

Le 16 août 10 à 15:58, Jiri Kosina a écrit :

>
>
> thanks for the analysis. How do devices in their report descriptor
> describe the fact whether the events should be interleaved by sync  
> or not?

As far as I know, they don't. I know of two multitouch devices that  
send groups of fingers over several HID messages:
  - the 3M 22" panel, when there are more than 6 fingers on the  
panel. You know there are more messages coming when the number of  
fingers (reported through ContactCount in the first message) is  
greater than 6.
  - the eGalax 72xx series, that adds a second message whenever there  
are two fingers; I am not sure yet how one knows when to wait  for a  
second message. Mathieu might be able to tell us.


The short term solution could be to add a .sync hook similar  
to .event. Each specific driver could override the call to input_sync 
() based on its knowledge of the device.

>
> We definitely could create a specialized version of
> hidinput_report_event() for certain reports, which wouldn't issue the
> input_sync() call, but I wonder what is the distinguishing factor.

Yes, for months now I have wondered what the generic multitouch HID  
driver in Windows 7 might look like :-) I suspect that we now have a  
sufficient sample of devices (about 10 different ones, all claiming  
to be Win7 compliant) to extrapolate from their behaviour.

Cheers

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 RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Henrik Rydberg]

Stéphane, Jiri,

Regarding the several-hid-packets-per-actual-input-packet problem, what do you
think about constructing a special MT HID device, using raw_event? It could
encapsulate the current protocol a bit better and use the full HID extension.

Henrik
--
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 RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Stéphane Chatty]

Le 16 août 10 à 17:17, Stéphane Chatty a écrit :

>
> Le 16 août 10 à 15:58, Jiri Kosina a écrit :
>
>>
>>
>> thanks for the analysis. How do devices in their report descriptor
>> describe the fact whether the events should be interleaved by sync  
>> or not?
>
> As far as I know, they don't. I know of two multitouch devices that  
> send groups of fingers over several HID messages:
>  - the 3M 22" panel, when there are more than 6 fingers on the  
> panel. You know there are more messages coming when the number of  
> fingers (reported through ContactCount in the first message) is  
> greater than 6.
>  - the eGalax 72xx series, that adds a second message whenever  
> there are two fingers; I am not sure yet how one knows when to  
> wait  for a second message. Mathieu might be able to tell us.
>

Oops... as usual, publishing an opinion is a good way of finding out  
how it be can wrong :-) I just figured that if ContactMax is  
available for all devices as well as ContactCount, then there is a  
way of knowing:
  - if ContactMax is greater than the number of fingers in the report  
descriptors, then you know that sometimes you'll get multiple messages.
  - if ContactCount in a message is greater than the number of  
fingers in the report descriptors, then you know you'll need to read  
more messages after this one.

We'll need to check this with all the known devices...

Cheers,

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 RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Stéphane Chatty]

Le 16 août 10 à 17:30, Henrik Rydberg a écrit :

> Stéphane, Jiri,
>
> Regarding the several-hid-packets-per-actual-input-packet problem,  
> what do you
> think about constructing a special MT HID device, using raw_event?  
> It could
> encapsulate the current protocol a bit better and use the full HID  
> extension.
>

Hi Henrik

This sounds like as a interesting direction for building a generic  
driver for MT devices. However, there still are device specificities  
that we need to deal with:
  - the serial/parallel/hybrid issue, for which we have ideas but  
still nothing firm;
  - some devices need to be set in multitouch mode; we need some  
research to find out if this can be determined automatically from the  
report descriptors;
  - the single touch emulation is highly device dependent. I was (and  
still am) pretty proud of my choice of tracking the 'oldest' finger  
on the panel: this turns multitouch panels into single touch panels  
that are impervious to parasite touches. But the drawback is that  
currently there is no generic method for this tracking: I used  
whatever device-specific information I could use (order of fingers in  
a message, tracking id, etc).

As long as these issues are here, we still need a system for  
implementing device-specific behaviour. I must admit I was tempted to  
keep benefitting from the blacklist in hid-core.c until they are  
resolved.

An additional question is: how do we decide that a device is a  
multitouch one? Do we keep a list of devices? Or do we rely on a  
pattern found in the report descriptors? In my view it would be great  
to have a pattern matching system for identifying classes of input  
devices from report descriptors, but then it would reacher farther  
than multitouch only.

Cheers,

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 RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Henrik Rydberg]

On 08/17/2010 09:49 AM, Stéphane Chatty wrote:

> 
> Le 16 août 10 à 17:30, Henrik Rydberg a écrit :
> 
>> Stéphane, Jiri,
>>
>> Regarding the several-hid-packets-per-actual-input-packet problem,
>> what do you
>> think about constructing a special MT HID device, using raw_event? It
>> could
>> encapsulate the current protocol a bit better and use the full HID
>> extension.
>>
> 
> Hi Henrik
> 
> This sounds like as a interesting direction for building a generic
> driver for MT devices. However, there still are device specificities
> that we need to deal with:
>  - the serial/parallel/hybrid issue, for which we have ideas but still
> nothing firm;


Not quite firm, but not too far from it either, IMO. Given that the hid-mt
device and its drivers handle all input device interaction, the idea is to
implement the details of the digitizer extension, such as hybrid mode, in the
hid-mt device.

>  - some devices need to be set in multitouch mode; we need some research
> to find out if this can be determined automatically from the report
> descriptors;


We could start off assuming all devices are different in this regard, and slowly
work our way towards unification.

>  - the single touch emulation is highly device dependent. I was (and
> still am) pretty proud of my choice of tracking the 'oldest' finger on
> the panel: this turns multitouch panels into single touch panels that
> are impervious to parasite touches. But the drawback is that currently
> there is no generic method for this tracking: I used whatever
> device-specific information I could use (order of fingers in a message,
> tracking id, etc).


Ah yes, the pointer emulation via ABS_X/Y. My personal view is that pointer
emulation is a gesture, and thus best implemented in userspace. During
multi-finger gestures, the pointer should either not move, or be hidden. The
majority of kernel drivers emit a BTN_TOUCH==1 when the first finger lands on
the surface, and a BTN_TOUCH==0 when the last finger leaves the surface. In
userspace, for touchscreens, the BTN_TOUCH event is traditionally mapped to a
button press, which is not what you want during a gesture. Thus, the pointer
emulation logic has to be remapped in userspace, anyways.

For new drivers, it would be best not to implement BTN_TOUCH/ABS_X/Y at all.
Since most MT devices support legacy mouse mode out-of-the-box via HID, perhaps
one can even argue that hid-mt does not _have_ to support ABS_X/Y. Or, to keep
compatibility, we could provide emulation code in hid-mt.

> As long as these issues are here, we still need a system for
> implementing device-specific behaviour. I must admit I was tempted to
> keep benefitting from the blacklist in hid-core.c until they are resolved.


I agree. The implementation details I have in mind are to take the extra
complexity involved using raw_event _once_, implement it in hid-mt, and then
pass the digested events on to the specialized drivers. If done carefully, I
imagine the changes to each individual driver to be fairly simple.

> An additional question is: how do we decide that a device is a
> multitouch one? Do we keep a list of devices? Or do we rely on a pattern
> found in the report descriptors? In my view it would be great to have a
> pattern matching system for identifying classes of input devices from
> report descriptors, but then it would reacher farther than multitouch only.


This sounds like an interesting idea for future development, but I would say we
can continue to rely on the device list for now.

Cheers,
Henrik
--
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 RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Chase Douglas]

On Tue, 2010-08-17 at 09:49 +0200, Stéphane Chatty wrote:
> Le 16 août 10 à 17:30, Henrik Rydberg a écrit :
> 
>   - the single touch emulation is highly device dependent. I was (and  
> still am) pretty proud of my choice of tracking the 'oldest' finger  
> on the panel: this turns multitouch panels into single touch panels  
> that are impervious to parasite touches. But the drawback is that  
> currently there is no generic method for this tracking: I used  
> whatever device-specific information I could use (order of fingers in  
> a message, tracking id, etc).

Stéphan,

Can you explain in more detail why you chose an 'oldest' finger approach
for single touch emulation? I wonder if it's the best mechanism. Take
the following example:

1. User touches with one finger and intends to drag an object on screen
2. User touches another finger down, either accidentally or
intentionally, while dragging the first finger
3. User releases first finger to end the drag
4. Object suddenly is dragged under the second finger

As I'm implementing support for the Magic Trackpad right now, I'm having
to figure out the best way to do single-touch emulation. What I'm
currently doing is converting the first finger touched for single-touch
emulation, and when that finger is released no single-touch emulation
can occur until all fingers have left the screen again.

This should hopefully become a moot point once everyone understands MT
input, but sadly we have to deal with the reality of X not being MT
aware quite yet :).

Thanks,

-- Chase

--
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 RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Stéphane Chatty]

Le 17 août 10 à 12:55, Chase Douglas a écrit :

> On Tue, 2010-08-17 at 09:49 +0200, Stéphane Chatty wrote:
>> Le 16 août 10 à 17:30, Henrik Rydberg a écrit :
>>
>>   - the single touch emulation is highly device dependent. I was (and
>> still am) pretty proud of my choice of tracking the 'oldest' finger
>> on the panel: this turns multitouch panels into single touch panels
>> that are impervious to parasite touches. But the drawback is that
>> currently there is no generic method for this tracking: I used
>> whatever device-specific information I could use (order of fingers in
>> a message, tracking id, etc).
>
> Stéphan,
>
> Can you explain in more detail why you chose an 'oldest' finger  
> approach
> for single touch emulation? I wonder if it's the best mechanism. Take
> the following example:
>
> 1. User touches with one finger and intends to drag an object on  
> screen
> 2. User touches another finger down, either accidentally or
> intentionally, while dragging the first finger
> 3. User releases first finger to end the drag
> 4. Object suddenly is dragged under the second finger
>
> As I'm implementing support for the Magic Trackpad right now, I'm  
> having
> to figure out the best way to do single-touch emulation. What I'm
> currently doing is converting the first finger touched for single- 
> touch
> emulation, and when that finger is released no single-touch emulation
> can occur until all fingers have left the screen again.

Yes, the debate is what to do when the 'actual oldest' finger is  
released: should the 'second oldest' take its place or should this be  
a release or should somthing else occur.

Some arguments in favour of the first option:
- My experience is that 'accidental' touches are transient.  
Therefore, the conjunction of having an accidental touch and a  
release is not very frequent.
  - At the opposite, on very large screens, it may sometimes be  
comfortable to "replace one finger with another", thus 'moving' the  
dragged object from one hand to the other.

More or less, the debate is about statistics and user experience  
design...

Cheers,

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 RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Stéphane Chatty]

Le 17 août 10 à 12:55, Chase Douglas a écrit :

> On Tue, 2010-08-17 at 09:49 +0200, Stéphane Chatty wrote:
>> Le 16 août 10 à 17:30, Henrik Rydberg a écrit :
>>
>>   - the single touch emulation is highly device dependent. I was (and
>> still am) pretty proud of my choice of tracking the 'oldest' finger
>> on the panel: this turns multitouch panels into single touch panels
>> that are impervious to parasite touches. But the drawback is that
>> currently there is no generic method for this tracking: I used
>> whatever device-specific information I could use (order of fingers in
>> a message, tracking id, etc).
>
> Stéphan,
>
> Can you explain in more detail why you chose an 'oldest' finger  
> approach
> for single touch emulation? I wonder if it's the best mechanism. Take
> the following example:
>
> 1. User touches with one finger and intends to drag an object on  
> screen
> 2. User touches another finger down, either accidentally or
> intentionally, while dragging the first finger
> 3. User releases first finger to end the drag
> 4. Object suddenly is dragged under the second finger
>
> As I'm implementing support for the Magic Trackpad right now, I'm  
> having
> to figure out the best way to do single-touch emulation. What I'm
> currently doing is converting the first finger touched for single- 
> touch
> emulation, and when that finger is released no single-touch emulation
> can occur until all fingers have left the screen again.

Yes, the debate is what to do when the 'actual oldest' finger is  
released: should the 'second oldest' take its place or should this be  
a release or should somthing else occur.

Some arguments in favour of the first option:
- My experience is that 'accidental' touches are transient.  
Therefore, the conjunction of having an accidental touch and a  
release is not very frequent.
  - At the opposite, on very large screens, it may sometimes be  
comfortable to "replace one finger with another", thus 'moving' the  
dragged object from one hand to the other.

More or less, the debate is about statistics and user experience  
design...

Cheers,

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 RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Chase Douglas]

On Tue, 2010-08-17 at 13:33 +0200, Stéphane Chatty wrote:
> Yes, the debate is what to do when the 'actual oldest' finger is  
> released: should the 'second oldest' take its place or should this be  
> a release or should somthing else occur.
> 
> Some arguments in favour of the first option:
> - My experience is that 'accidental' touches are transient.  
> Therefore, the conjunction of having an accidental touch and a  
> release is not very frequent.
>   - At the opposite, on very large screens, it may sometimes be  
> comfortable to "replace one finger with another", thus 'moving' the  
> dragged object from one hand to the other.
> 
> More or less, the debate is about statistics and user experience  
> design...

Thanks for the explanation! Since this comes down to what the user
intends with multiple touches on the screen, I'll trust your experience
over mine :).

However, while your 'eldest' method may be good for touchscreens, I
think it's a moot point for touchpads since they are relative devices
(even if they are really absolute in the driver). The user won't be able
to continuously drag across the screen by using multiple fingers because
each switch of coordinates from the eldest to the next eldest will
generate a relative motion that will just shift the object back where we
started a drag.

I'll probably leave my current implementation for the trackpad as is,
since it's easier than the 'eldest' method and provides just as much
functionality.

-- Chase

--
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 RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Mathieu Virbel]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

Hi everyone,

* Stéphane Chatty <chatty-rXV5z7KbLFk@public.gmane.org> [2010-08-16 17:17:52]:

> 
> Le 16 août 10 à 15:58, Jiri Kosina a écrit :
> 
> >
> >
> >thanks for the analysis. How do devices in their report descriptor
> >describe the fact whether the events should be interleaved by sync
> >or not?
> 
> As far as I know, they don't. I know of two multitouch devices that
> send groups of fingers over several HID messages:
>  - the 3M 22" panel, when there are more than 6 fingers on the
> panel. You know there are more messages coming when the number of
> fingers (reported through ContactCount in the first message) is
> greater than 6.
>  - the eGalax 72xx series, that adds a second message whenever there
> are two fingers; I am not sure yet how one knows when to wait  for a
> second message. Mathieu might be able to tell us.

Well, i've actually the problem, i can't known :)
So for my case, i dispatch event - 1, not current event, and doing the
merge on userland size by checking old event contact id. Since i known
that the screen is doing only one or two touches, it's kind of easy to
do the "sync" ourself... except when touch UP. With event - 1, i can't
known if it's finished or not...

It cannot be resolved until the kernel send correct sync message...


> The short term solution could be to add a .sync hook similar to
> .event. Each specific driver could override the call to input_sync()
> based on its knowledge of the device.

That would solve this case :)


Mathieu

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Stéphane Chatty]

Le 17 août 10 à 11:56, Henrik Rydberg a écrit :

>
> Ah yes, the pointer emulation via ABS_X/Y. My personal view is that  
> pointer
> emulation is a gesture, and thus best implemented in userspace.

I agree 100% with you on this (well, I'd rather say that gestures and  
single touch emulation are two cases of input interpretation, but  
that's just my academical bias).

However this issue was discussed last year on this list and as far as  
I understood it was decided that single touch emulation was required  
in the kernel for some time...

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 RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet

[Henrik Rydberg]

On 08/19/2010 11:45 PM, Stéphane Chatty wrote:

> 
> Le 17 août 10 à 11:56, Henrik Rydberg a écrit :
> 
>>
>> Ah yes, the pointer emulation via ABS_X/Y. My personal view is that
>> pointer
>> emulation is a gesture, and thus best implemented in userspace.
> 
> I agree 100% with you on this (well, I'd rather say that gestures and
> single touch emulation are two cases of input interpretation, but that's
> just my academical bias).
> 
> However this issue was discussed last year on this list and as far as I
> understood it was decided that single touch emulation was required in
> the kernel for some time...


At that time, maybe the alternatives were not as clear as they are now. :-) I
think what it all means is that over time, we will see less and less of the
ABS_X/Y, since we will eventually stop adding it, and hardware inevitably ages.

Cheers,
Henrik
--
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