Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[PATCH] HID: add multi-input quirk for eGalax Touchcontroller

26 views
Skip to first unread message

Peter Hutterer

unread,
Feb 1, 2010, 10:50:01 PM2/1/10
to
Signed-off-by: Peter Hutterer <peter.h...@who-t.net>
---
I've got one of these devices on my desk and it seems that it suffers from
the ABS_Z/ABS_RX issue that we've seen in other devices before. This patch
uses the same reasoning as 9db630b48a99adb4156e205b812fba8959644280.

Nonetheless, I'm not sure about whether that's the right thing to do. With
this patch applied, it gives me two devices, one mute, the other one
announces BTN_PEN and BTN_TOUCH + abs axes, though only BTN_TOUCH is ever
triggered. Loading usbtouchscreen instead of usbhid for this device makes
the device look more sane BTN_TOUCH + abs axes but the actual data is
random. So I'm not quite sure what the fix is supposed to be, any hints are
appreciated if it's not the patch below.

Cheers,
Peter


drivers/hid/hid-ids.h | 3 +++
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index f5144b8..2e698a2 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -158,6 +158,9 @@

#define USB_VENDOR_ID_DRAGONRISE 0x0079

+#define USB_VENDOR_ID_EGALAX 0x0EEF
+#define USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER 0x0001
+
#define USB_VENDOR_ID_ELO 0x04E7
#define USB_DEVICE_ID_ELO_TS2700 0x0020

diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index e987562..dc27d74 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -32,6 +32,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_AASHIMA, USB_DEVICE_ID_AASHIMA_PREDATOR, HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_ALPS, USB_DEVICE_ID_IBM_GAMEPAD, HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_CHIC, USB_DEVICE_ID_CHIC_GAMEPAD, HID_QUIRK_BADPAD },
+ { USB_VENDOR_ID_EGALAX, USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER, HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_DRIVING, HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FLYING, HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_HAPP, USB_DEVICE_ID_UGCI_FIGHTING, HID_QUIRK_BADPAD | HID_QUIRK_MULTI_INPUT },
--
1.6.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jiri Kosina

unread,
Feb 2, 2010, 4:50:02 PM2/2/10
to
On Tue, 2 Feb 2010, Peter Hutterer wrote:

> Nonetheless, I'm not sure about whether that's the right thing to do. With
> this patch applied, it gives me two devices, one mute, the other one
> announces BTN_PEN and BTN_TOUCH + abs axes, though only BTN_TOUCH is ever
> triggered. Loading usbtouchscreen instead of usbhid for this device makes
> the device look more sane BTN_TOUCH + abs axes but the actual data is
> random. So I'm not quite sure what the fix is supposed to be, any hints are
> appreciated if it's not the patch below.

The data could also be mis-interpreted because of some bug in the HID
descriptor.

Does looking at the HID report descriptor and looking at the actual
raw HID reports coming out from the device give any clue? (in recent
kernels, you can just use 'hid' directory in debugfs to gather all this
information).

Thanks,

--
Jiri Kosina
SUSE Labs, Novell Inc.

Peter Hutterer

unread,
Feb 2, 2010, 10:50:02 PM2/2/10
to
On Tue, Feb 02, 2010 at 10:44:35PM +0100, Jiri Kosina wrote:
> On Tue, 2 Feb 2010, Peter Hutterer wrote:
>
> > Nonetheless, I'm not sure about whether that's the right thing to do. With
> > this patch applied, it gives me two devices, one mute, the other one
> > announces BTN_PEN and BTN_TOUCH + abs axes, though only BTN_TOUCH is ever
> > triggered. Loading usbtouchscreen instead of usbhid for this device makes
> > the device look more sane BTN_TOUCH + abs axes but the actual data is
> > random. So I'm not quite sure what the fix is supposed to be, any hints are
> > appreciated if it's not the patch below.
>
> The data could also be mis-interpreted because of some bug in the HID
> descriptor.
>
> Does looking at the HID report descriptor and looking at the actual
> raw HID reports coming out from the device give any clue? (in recent
> kernels, you can just use 'hid' directory in debugfs to gather all this
> information).

Thanks. The hid descriptor table is attached, but tbh I'm not well-versed
enough in the HID protocol to even tell what format I can give you. I've
attached a simple hexdump of two presses, one with a finger, one with the
stylus. Let me know what format you need or what how I can start to decypher
this myself (are there any parsing tools around?).

Cheers,
Peter

events.hexdump
eGalax-hid-descriptor

Jiri Kosina

unread,
Feb 3, 2010, 6:00:02 AM2/3/10
to
On Wed, 3 Feb 2010, Peter Hutterer wrote:

> > Does looking at the HID report descriptor and looking at the actual
> > raw HID reports coming out from the device give any clue? (in recent
> > kernels, you can just use 'hid' directory in debugfs to gather all
> > this information).
>
> Thanks. The hid descriptor table is attached, but tbh I'm not well-versed
> enough in the HID protocol to even tell what format I can give you. I've
> attached a simple hexdump of two presses, one with a finger, one with the
> stylus. Let me know what format you need or what how I can start to decypher
> this myself (are there any parsing tools around?).

It shouldn't be necesarry to run hexdump on the 'events' node, the data
coming from it are supposed to already be parsed and human-readable.

Peter Hutterer

unread,
Feb 3, 2010, 6:50:02 PM2/3/10
to
On Wed, Feb 03, 2010 at 11:53:20AM +0100, Jiri Kosina wrote:
> On Wed, 3 Feb 2010, Peter Hutterer wrote:
>
> > > Does looking at the HID report descriptor and looking at the actual
> > > raw HID reports coming out from the device give any clue? (in recent
> > > kernels, you can just use 'hid' directory in debugfs to gather all
> > > this information).
> >
> > Thanks. The hid descriptor table is attached, but tbh I'm not well-versed
> > enough in the HID protocol to even tell what format I can give you. I've
> > attached a simple hexdump of two presses, one with a finger, one with the
> > stylus. Let me know what format you need or what how I can start to decypher
> > this myself (are there any parsing tools around?).
>
> It shouldn't be necesarry to run hexdump on the 'events' node, the data
> coming from it are supposed to already be parsed and human-readable.

aah, don't we love a good brown paper bag moment...

events are below, if I read this correctly the hardware might need a quirk
for the permanently-set InRange bits.

report (size 6) (numbered)
report 2 (size 6) = 02 03 69 0e c4 03
Digitizers.TipSwitch = 1
Digitizers.InRange = 1
GenericDesktop.X = 3689
GenericDesktop.Y = 964

report (size 6) (numbered)
report 2 (size 6) = 02 03 6f 0e bb 03
Digitizers.TipSwitch = 1
Digitizers.InRange = 1
GenericDesktop.X = 3695
GenericDesktop.Y = 955

[...]

report (size 6) (numbered)
report 2 (size 6) = 02 02 71 0e a9 03
Digitizers.TipSwitch = 0
Digitizers.InRange = 1
GenericDesktop.X = 3697
GenericDesktop.Y = 937

report (size 6) (numbered)
report 2 (size 6) = 02 03 68 0e d1 03
Digitizers.TipSwitch = 1
Digitizers.InRange = 1
GenericDesktop.X = 3688
GenericDesktop.Y = 977

report (size 6) (numbered)
report 2 (size 6) = 02 03 67 0e d1 03
Digitizers.TipSwitch = 1
Digitizers.InRange = 1
GenericDesktop.X = 3687

[...]

report (size 6) (numbered)
report 2 (size 6) = 02 02 7b 0e dd 03
Digitizers.TipSwitch = 0
Digitizers.InRange = 1
GenericDesktop.X = 3707
GenericDesktop.Y = 989

Peter Hutterer

unread,
May 10, 2010, 1:10:02 AM5/10/10
to
Hi Jiri,

On Tue, Feb 02, 2010 at 01:40:40PM +1000, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer <peter.h...@who-t.net>
> ---
> I've got one of these devices on my desk and it seems that it suffers from
> the ABS_Z/ABS_RX issue that we've seen in other devices before. This patch
> uses the same reasoning as 9db630b48a99adb4156e205b812fba8959644280.
>
> Nonetheless, I'm not sure about whether that's the right thing to do. With
> this patch applied, it gives me two devices, one mute, the other one
> announces BTN_PEN and BTN_TOUCH + abs axes, though only BTN_TOUCH is ever
> triggered. Loading usbtouchscreen instead of usbhid for this device makes
> the device look more sane BTN_TOUCH + abs axes but the actual data is
> random. So I'm not quite sure what the fix is supposed to be, any hints are
> appreciated if it's not the patch below.

See https://patchwork.kernel.org/patch/76210/ for the original thread.
This patch never got merged, were you waiting on me or did it just drop
under the table?

I'm getting positive reports from users that this indeed fixes the issues
for their device.
https://bugzilla.redhat.com/show_bug.cgi?id=473144

Jiri Kosina

unread,
May 10, 2010, 3:00:03 AM5/10/10
to
On Mon, 10 May 2010, Peter Hutterer wrote:

> > I've got one of these devices on my desk and it seems that it suffers from
> > the ABS_Z/ABS_RX issue that we've seen in other devices before. This patch
> > uses the same reasoning as 9db630b48a99adb4156e205b812fba8959644280.
>

> See https://patchwork.kernel.org/patch/76210/ for the original thread.
> This patch never got merged, were you waiting on me or did it just drop
> under the table?
>
> I'm getting positive reports from users that this indeed fixes the issues
> for their device.
> https://bugzilla.redhat.com/show_bug.cgi?id=473144

Sorry, I have lost the original thread. I have applied the patch now.

Thanks,

--
Jiri Kosina
SUSE Labs, Novell Inc.

0 new messages