* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet @ 2010-08-16 15:30 Henrik Rydberg 2010-08-17 7:49 ` Stéphane Chatty 0 siblings, 1 reply; 18+ messages in thread From: Henrik Rydberg @ 2010-08-16 15:30 UTC (permalink / raw) To: Stéphane Chatty; +Cc: linux-input 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet 2010-08-16 15:30 [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet Henrik Rydberg @ 2010-08-17 7:49 ` Stéphane Chatty 2010-08-17 9:56 ` Henrik Rydberg 2010-08-17 10:55 ` Chase Douglas 0 siblings, 2 replies; 18+ messages in thread From: Stéphane Chatty @ 2010-08-17 7:49 UTC (permalink / raw) To: Henrik Rydberg; +Cc: linux-input 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet 2010-08-17 7:49 ` Stéphane Chatty @ 2010-08-17 9:56 ` Henrik Rydberg 2010-08-19 21:45 ` Stéphane Chatty 2010-08-17 10:55 ` Chase Douglas 1 sibling, 1 reply; 18+ messages in thread From: Henrik Rydberg @ 2010-08-17 9:56 UTC (permalink / raw) To: Stéphane Chatty; +Cc: linux-input 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet 2010-08-17 9:56 ` Henrik Rydberg @ 2010-08-19 21:45 ` Stéphane Chatty 2010-08-19 21:59 ` Henrik Rydberg 0 siblings, 1 reply; 18+ messages in thread From: Stéphane Chatty @ 2010-08-19 21:45 UTC (permalink / raw) To: Henrik Rydberg; +Cc: linux-input 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet 2010-08-19 21:45 ` Stéphane Chatty @ 2010-08-19 21:59 ` Henrik Rydberg 0 siblings, 0 replies; 18+ messages in thread From: Henrik Rydberg @ 2010-08-19 21:59 UTC (permalink / raw) To: Stéphane Chatty; +Cc: linux-input 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet 2010-08-17 7:49 ` Stéphane Chatty 2010-08-17 9:56 ` Henrik Rydberg @ 2010-08-17 10:55 ` Chase Douglas 2010-08-17 11:33 ` Stéphane Chatty 2010-08-17 11:34 ` Stéphane Chatty 1 sibling, 2 replies; 18+ messages in thread From: Chase Douglas @ 2010-08-17 10:55 UTC (permalink / raw) To: Stéphane Chatty; +Cc: Henrik Rydberg, linux-input 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet 2010-08-17 10:55 ` Chase Douglas @ 2010-08-17 11:33 ` Stéphane Chatty 2010-08-17 11:44 ` Chase Douglas 2010-08-17 11:34 ` Stéphane Chatty 1 sibling, 1 reply; 18+ messages in thread From: Stéphane Chatty @ 2010-08-17 11:33 UTC (permalink / raw) To: Chase Douglas; +Cc: Henrik Rydberg, linux-input 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet 2010-08-17 11:33 ` Stéphane Chatty @ 2010-08-17 11:44 ` Chase Douglas 0 siblings, 0 replies; 18+ messages in thread From: Chase Douglas @ 2010-08-17 11:44 UTC (permalink / raw) To: Stéphane Chatty; +Cc: Henrik Rydberg, linux-input 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet 2010-08-17 10:55 ` Chase Douglas 2010-08-17 11:33 ` Stéphane Chatty @ 2010-08-17 11:34 ` Stéphane Chatty 1 sibling, 0 replies; 18+ messages in thread From: Stéphane Chatty @ 2010-08-17 11:34 UTC (permalink / raw) To: Chase Douglas; +Cc: Henrik Rydberg, linux-input 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <m339wl2ug6.fsf@pullcord.laptop.org>]
* [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet [not found] <m339wl2ug6.fsf@pullcord.laptop.org> @ 2010-08-12 23:10 ` Chris Ball [not found] ` <m3hbiz8m11.fsf-0VGQAjvlmrQzNDMTQreKSUB+6BGkLq7r@public.gmane.org> 0 siblings, 1 reply; 18+ messages in thread From: Chris Ball @ 2010-08-12 23:10 UTC (permalink / raw) To: linux-usb; +Cc: linux-input, Jiri Kosina, Stephane Chatty 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 ^ permalink raw reply related [flat|nested] 18+ messages in thread
[parent not found: <m3hbiz8m11.fsf-0VGQAjvlmrQzNDMTQreKSUB+6BGkLq7r@public.gmane.org>]
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet [not found] ` <m3hbiz8m11.fsf-0VGQAjvlmrQzNDMTQreKSUB+6BGkLq7r@public.gmane.org> @ 2010-08-12 23:15 ` Jiri Kosina 2010-08-13 10:47 ` Stéphane Chatty 0 siblings, 1 reply; 18+ messages in thread From: Jiri Kosina @ 2010-08-12 23:15 UTC (permalink / raw) To: Chris Ball Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, linux-input-u79uwXL29TY76Z2rM5mHXA, Stephane Chatty 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet 2010-08-12 23:15 ` Jiri Kosina @ 2010-08-13 10:47 ` Stéphane Chatty 2010-08-14 2:33 ` Chris Ball 2010-08-16 13:58 ` Jiri Kosina 0 siblings, 2 replies; 18+ messages in thread From: Stéphane Chatty @ 2010-08-13 10:47 UTC (permalink / raw) To: Jiri Kosina; +Cc: Chris Ball, linux-usb, linux-input, tito 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet 2010-08-13 10:47 ` Stéphane Chatty @ 2010-08-14 2:33 ` Chris Ball 2010-08-16 14:03 ` Jiri Kosina 2010-08-16 13:58 ` Jiri Kosina 1 sibling, 1 reply; 18+ messages in thread From: Chris Ball @ 2010-08-14 2:33 UTC (permalink / raw) To: Stéphane Chatty; +Cc: Jiri Kosina, linux-usb, linux-input, tito 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 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet 2010-08-14 2:33 ` Chris Ball @ 2010-08-16 14:03 ` Jiri Kosina 0 siblings, 0 replies; 18+ messages in thread From: Jiri Kosina @ 2010-08-16 14:03 UTC (permalink / raw) To: Chris Ball; +Cc: Stéphane Chatty, linux-usb, linux-input, tito 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet 2010-08-13 10:47 ` Stéphane Chatty 2010-08-14 2:33 ` Chris Ball @ 2010-08-16 13:58 ` Jiri Kosina 2010-08-16 15:17 ` Stéphane Chatty 1 sibling, 1 reply; 18+ messages in thread From: Jiri Kosina @ 2010-08-16 13:58 UTC (permalink / raw) To: Stéphane Chatty; +Cc: Chris Ball, linux-usb, linux-input, tito 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet 2010-08-16 13:58 ` Jiri Kosina @ 2010-08-16 15:17 ` Stéphane Chatty 2010-08-16 15:37 ` Stéphane Chatty [not found] ` <F35B802E-C47A-47BF-A350-8F57250D4394-rXV5z7KbLFk@public.gmane.org> 0 siblings, 2 replies; 18+ messages in thread From: Stéphane Chatty @ 2010-08-16 15:17 UTC (permalink / raw) To: Jiri Kosina; +Cc: Chris Ball, linux-usb, linux-input, tito 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet 2010-08-16 15:17 ` Stéphane Chatty @ 2010-08-16 15:37 ` Stéphane Chatty [not found] ` <F35B802E-C47A-47BF-A350-8F57250D4394-rXV5z7KbLFk@public.gmane.org> 1 sibling, 0 replies; 18+ messages in thread From: Stéphane Chatty @ 2010-08-16 15:37 UTC (permalink / raw) To: Stéphane Chatty Cc: Jiri Kosina, Chris Ball, linux-usb, linux-input, tito 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <F35B802E-C47A-47BF-A350-8F57250D4394-rXV5z7KbLFk@public.gmane.org>]
* Re: [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet [not found] ` <F35B802E-C47A-47BF-A350-8F57250D4394-rXV5z7KbLFk@public.gmane.org> @ 2010-08-18 9:33 ` Mathieu Virbel 0 siblings, 0 replies; 18+ messages in thread From: Mathieu Virbel @ 2010-08-18 9:33 UTC (permalink / raw) To: Stéphane Chatty Cc: Jiri Kosina, Chris Ball, linux-usb-u79uwXL29TY76Z2rM5mHXA, linux-input-u79uwXL29TY76Z2rM5mHXA [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2010-08-19 21:59 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-08-16 15:30 [PATCH RESEND] USB HID: Add ID for eGalax Multitouch used in JooJoo tablet Henrik Rydberg 2010-08-17 7:49 ` Stéphane Chatty 2010-08-17 9:56 ` Henrik Rydberg 2010-08-19 21:45 ` Stéphane Chatty 2010-08-19 21:59 ` Henrik Rydberg 2010-08-17 10:55 ` Chase Douglas 2010-08-17 11:33 ` Stéphane Chatty 2010-08-17 11:44 ` Chase Douglas 2010-08-17 11:34 ` Stéphane Chatty [not found] <m339wl2ug6.fsf@pullcord.laptop.org> 2010-08-12 23:10 ` Chris Ball [not found] ` <m3hbiz8m11.fsf-0VGQAjvlmrQzNDMTQreKSUB+6BGkLq7r@public.gmane.org> 2010-08-12 23:15 ` Jiri Kosina 2010-08-13 10:47 ` Stéphane Chatty 2010-08-14 2:33 ` Chris Ball 2010-08-16 14:03 ` Jiri Kosina 2010-08-16 13:58 ` Jiri Kosina 2010-08-16 15:17 ` Stéphane Chatty 2010-08-16 15:37 ` Stéphane Chatty [not found] ` <F35B802E-C47A-47BF-A350-8F57250D4394-rXV5z7KbLFk@public.gmane.org> 2010-08-18 9:33 ` Mathieu Virbel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).