Signed-off-by: Peter Hutterer <[email protected]>
---
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
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.
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
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.
--
Jiri Kosina
SUSE Labs, Novell Inc.
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