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 <redacted>
---
drivers/hid/hid-egalax.c | 2 ++
drivers/hid/hid-ids.h | 1 +
2 files changed, 3 insertions(+), 0 deletions(-)
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
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
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
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
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