Re: [eGalax] no click events with touchscreen

Hi,


On Thu, Jan 8, 2015 at 5:20 PM, Gavin Lambert [off-list ref] wrote:

On 9 January 2015 04:17, you quoth:

quoted

So here, everything seems fine except for the tracking ID and the BTN_TOUCH.
The kernel does not sends the touch begin and touch end information, thus the
device is not working :(

Can you compile and install hid-recorder from http://bentiss.github.io/hid-
replay-docs/ ?
I would need a hid-record of your touchscreen so I can figure out why the
kernel does not handle it properly.

Attached.  (Sent off-list to avoid spamming uninterested parties with the file; please feel free to reply on-list if you prefer.)

During the recording, I made one touch and release to the centre of the screen, waited about three seconds, then did a staggered two-point multitouch (touch left, touch right, release left, release right).  Just in case both scenarios are useful to you.

Well, unfortunately, when I first read your bug report, I missed that
you are using one of the most buggy touchscreen available.
Egalax still tries to reuse the product id 0001 for *many* different
touchscreens. Some are multitouch, some are not.
With all this mess, it is impossible to figure out which way to go and
write something upstream about it :(

Anyway, given your hid outputs, if you run the following command
before plugging your touchscreen (at boot is a good idea), you should
be fine:
# echo 3 0eef 0001 16 > /sys/bus/hid/drivers/hid-multitouch/new_id

*BUT* the outputs show only _one_ touch when you said you made 2.

I must also say that this device presents itself as a Win8 certified
one whereas it is clearly not following the spec. So my best advice
would be to send it back to the store, and buy another one :(

Not sure if this is significant, but when it was asking for the hidraw device it only listed one device for the touchscreen; it did not have a second "Pen" device as exists at the /dev/input/eventN level.

Yeah, that's expected. The second input node is created by looking at
the report descriptors and the splitting is done in hid-multitouch.

Cheers,
Benjamin

On 9 January 2015 11:55, quoth Benjamin Tissoires:

On Thu, Jan 8, 2015 at 5:20 PM, Gavin Lambert [off-list ref] wrote:

quoted

On 9 January 2015 04:17, you quoth:

quoted

So here, everything seems fine except for the tracking ID and the

BTN_TOUCH.

quoted

quoted

The kernel does not sends the touch begin and touch end information,
thus the device is not working :(

Can you compile and install hid-recorder from
http://bentiss.github.io/hid- replay-docs/ ?
I would need a hid-record of your touchscreen so I can figure out why
the kernel does not handle it properly.

Attached.  (Sent off-list to avoid spamming uninterested parties with
the file; please feel free to reply on-list if you prefer.)

During the recording, I made one touch and release to the centre of the

screen, waited about three seconds, then did a staggered two-point multitouch
(touch left, touch right, release left, release right).  Just in case both
scenarios are useful to you.

quoted

Well, unfortunately, when I first read your bug report, I missed that you are
using one of the most buggy touchscreen available.
Egalax still tries to reuse the product id 0001 for *many* different
touchscreens. Some are multitouch, some are not.
With all this mess, it is impossible to figure out which way to go and write
something upstream about it :(

Buggy or not, it seems to be the most common kind of small panel commercially available for the Pi.  Two out of three touchscreens I've tried getting seem to be eGalax ones.

Anyway, given your hid outputs, if you run the following command before
plugging your touchscreen (at boot is a good idea), you should be fine:
# echo 3 0eef 0001 16 > /sys/bus/hid/drivers/hid-multitouch/new_id

I could probably add this to an init script somewhere, but I don't think there's any way I can do this before the touchscreen is physically connected.  Would it be sufficient to put it after mounting sys but before starting udev?

*BUT* the outputs show only _one_ touch when you said you made 2.

This doesn't really surprise me.  It's a resistive panel, so I was very surprised when it loaded the multitouch driver.  Maybe that's the real problem?

On Thu, Jan 8, 2015 at 6:19 PM, Gavin Lambert [off-list ref] wrote:

On 9 January 2015 11:55, quoth Benjamin Tissoires:

quoted

On Thu, Jan 8, 2015 at 5:20 PM, Gavin Lambert [off-list ref] wrote:

quoted

On 9 January 2015 04:17, you quoth:

quoted

So here, everything seems fine except for the tracking ID and the

BTN_TOUCH.

quoted

quoted

The kernel does not sends the touch begin and touch end information,
thus the device is not working :(

Can you compile and install hid-recorder from
http://bentiss.github.io/hid- replay-docs/ ?
I would need a hid-record of your touchscreen so I can figure out why
the kernel does not handle it properly.

Attached.  (Sent off-list to avoid spamming uninterested parties with
the file; please feel free to reply on-list if you prefer.)

During the recording, I made one touch and release to the centre of the

screen, waited about three seconds, then did a staggered two-point multitouch
(touch left, touch right, release left, release right).  Just in case both
scenarios are useful to you.

quoted

Well, unfortunately, when I first read your bug report, I missed that you are
using one of the most buggy touchscreen available.
Egalax still tries to reuse the product id 0001 for *many* different
touchscreens. Some are multitouch, some are not.
With all this mess, it is impossible to figure out which way to go and write
something upstream about it :(

Buggy or not, it seems to be the most common kind of small panel commercially available for the Pi.  Two out of three touchscreens I've tried getting seem to be eGalax ones.

quoted

Anyway, given your hid outputs, if you run the following command before
plugging your touchscreen (at boot is a good idea), you should be fine:
# echo 3 0eef 0001 16 > /sys/bus/hid/drivers/hid-multitouch/new_id

I could probably add this to an init script somewhere, but I don't think there's any way I can do this before the touchscreen is physically connected.  Would it be sufficient to put it after mounting sys but before starting udev?

You can also make an udev rule which write 1040 in
/sys/bus/hid/devices/0003\:0EEF\:0001.*/quirks on plug in an udev rule
(you should probably rely on the path given by the udev rule instead
of writing the wildcard).

quoted

*BUT* the outputs show only _one_ touch when you said you made 2.

This doesn't really surprise me.  It's a resistive panel, so I was very surprised when it loaded the multitouch driver.  Maybe that's the real problem?

Oh, that explains a lot. So they are trying to add a lot more of noise
by sharing the multitouch report descriptors with single touch only
devices... A big mess I told you :(

Cheers,
Benjamin

On 9 January 2015 13:08, quoth Benjamin Tissoires:

You can also make an udev rule which write 1040 in
/sys/bus/hid/devices/0003\:0EEF\:0001.*/quirks on plug in an udev rule (you
should probably rely on the path given by the udev rule instead of writing
the wildcard).

I get a "permission denied" error trying to write to that pseudo-file after boot, even with sudo.  (It currently contains 3088.)

I also tried writing the following udev rule and rebooting, but it had no effect; not sure if I'm doing it wrong or if it's having the same problem:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0eef", ATTRS{idProduct}=="0001", RUN+="echo 1040 > /sys/bus/hid/devices/0003\:0EEF\:0001.0002/quirks"

On Thu, Jan 8, 2015 at 9:58 PM, Gavin Lambert [off-list ref] wrote:

On 9 January 2015 13:08, quoth Benjamin Tissoires:

quoted

You can also make an udev rule which write 1040 in
/sys/bus/hid/devices/0003\:0EEF\:0001.*/quirks on plug in an udev rule (you
should probably rely on the path given by the udev rule instead of writing
the wildcard).

I get a "permission denied" error trying to write to that pseudo-file after boot, even with sudo.  (It currently contains 3088.)

You need root access, so you'll need a true root shell to be able to
write on the file.

I also tried writing the following udev rule and rebooting, but it had no effect; not sure if I'm doing it wrong or if it's having the same problem:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0eef", ATTRS{idProduct}=="0001", RUN+="echo 1040 > /sys/bus/hid/devices/0003\:0EEF\:0001.0002/quirks"

IIRC, plain redirection can not work anymore with recent udev/systemd
versions. Also, the .0002 at the end should not be encoded directly in
the udev rule. You can rely on %k, which is the name of the device
given by udev.

I think, you should use something like that:

DRIVER=="hid-multitouch",
ENV{MODALIAS}=="hid:b0003g0004v00000EEFp00000001", RUN+="/bin/sh
/etc/udev/fix_hid_multitouch.sh %k"

With /etc/udev/fix_hid_multitouch.sh being:

#> cat > /etc/udev/fix_hid_multitouch.sh << EOF
#!/bin/bash

DEVICE=$1

echo 1040 > "/sys/bus/hid/devices/${DEVICE}/quirks"
EOF

This is untested, but it should give you some more clues to go further
if it does not work directly.

Cheers,
Benjamin