[PATCH] HID: core: assign usbhid to handle EETI PID=0x0001 HID device

[PATCH] HID: core: assign usbhid to handle EETI PID=0x0001 HID device

[JamChen]

From: Jam Chen <jam.chen.egalax@gmail.com>

The vendor used the same PID(0x0001) for multiple touch IC controllers.
The newer ICs can support HID class and report the multitouch collection
in the descriptor. So they were handled by the hid-multitouch driver.
But some customized firmwares don't support multitouch protocol even if
driver have got the Win8 blob data.

Actually, those ICs only support the single touch function, and report
the mouse protocol by default. We can assign usbhid to handle them all.

Signed-off-by: Jam Chen <jam.chen.egalax@gmail.com>
---
 drivers/hid/hid-core.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 9017dcc14502..df4696022488 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -828,6 +828,10 @@ static int hid_scan_report(struct hid_device *hid)
 				 */
 				hid->group = HID_GROUP_RMI;
 		break;
+	case USB_VENDOR_ID_DWAV:
+		if (hid->product == USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER)
+			hid->group = HID_GROUP_GENERIC;
+		break;
 	}
 
 	/* fall back to generic driver in case specific driver doesn't exist */
-- 
2.11.0

Re: [PATCH] HID: core: assign usbhid to handle EETI PID=0x0001 HID device

[Boszormenyi Zoltan]

Hi,

it's a funny thing. Currently I can't reproduce the problem.

This was the situation that occurred previously:

At the first touch after X started, the pointer went to the correct location.
Moving the finger made the pointer move with the finger, the pointer
location was always good.

Then lifted the finger up and touched a different location.
Moving the finger made the pointer move with the finger, but the pointer
didn't match the finger location, the difference was the vector
between the last location in the first step and the first location in
this second step.

I was thinking that since the touchscreen is demoted to be a mouse,
it's the expected behaviour, since only relative motion is processed.

This was not a panel orientation problem which can be easily solved
by calibration.

But I was just after upgrading the system from libevdev 1.4.6 to 1.5.7
and from libinput 1.5.0 to 1.8.1 and it is possible that something still
referenced the old library versions even after restarting Xorg.
It's also possible that the ordering of the input devices influences things.

 From dmesg, there's no difference between boots:

[    3.718370] usb 1-1.1.4: new full-speed USB device number 8 using ehci-pci
[    3.810812] usb 1-1.1.4: New USB device found, idVendor=0eef, idProduct=0001
[    3.810815] usb 1-1.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    3.810818] usb 1-1.1.4: Product: USB TouchController
[    3.810819] usb 1-1.1.4: Manufacturer: eGalax Inc.
[    3.815502] input: eGalax Inc. USB TouchController as 
/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.1/1-1.1.4/1-1.1.4:1.0/0003:0EEF:0001.0003/input/input8
[    3.815712] input: eGalax Inc. USB TouchController as 
/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.1/1-1.1.4/1-1.1.4:1.0/0003:0EEF:0001.0003/input/input9
[    3.815888] input: eGalax Inc. USB TouchController as 
/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.1/1-1.1.4/1-1.1.4:1.0/0003:0EEF:0001.0003/input/input10
[    3.816008] input: eGalax Inc. USB TouchController as 
/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.1/1-1.1.4/1-1.1.4:1.0/0003:0EEF:0001.0003/input/input11
[    3.816297] hid-generic 0003:0EEF:0001.0003: input,hiddev96,hidraw2: USB HID v1.00 
Pointer [eGalax Inc. USB TouchController] on usb-0000:00:1d.0-1.1.4/input0

According to evtest, the 4 devices provide these features:

input8: EV_SYN, EV_ABS (ABS_X/ABS_Y), EV_KEY (BTN_LEFT/BTN_RIGHT),
         EV_MSC (MSC_SCAN)

input9: EV_SYN, EV_ABS (ABS_X/ABS_Y), EV_KEY (BTN_TOOL_PEN/BTN_TOUCH),
         EV_MSC (MSC_SCAN)

input10: EV_SYN

input11: EV_SYN, EV_ABS (ABS_X/ABS_Y/ABS_MISC), EV_KEY (BTN_TOOL_FINGER/BTN_TOUCH),
          EV_MSC (MSC_SCAN)

Now, that it's working, the first device of the four emit events,
the one with the mouse buttons. The pointer behaves perfectly.

I remember that when it wasn't working properly, then some of the other
devices emitted the events and produced the above described behaviour.

It's probably a different kernel bug or the old libevdev/libinput were
doing something wrong that made the input devices work differently.

I have re-rested downgrading to the old libevdev / libinput libraries
but I still couldn't reproduce the problem.

Maybe it's gremlins in the machine. Sorry for the noise.

Best regards,
Zoltán Böszörményi

2017-08-17 13:08 keltezéssel, JiaMing Chen írta:
> Hi Zoltán,
> 
> Is it the panel orientation issue?
> If you run the position calibration using the tslib, can it be fixed?
> 
> Best regards,
> Jam Chen
> 
> 
> 2017-08-15 17:43 GMT+08:00 Boszormenyi Zoltan <zboszor@pr.hu <mailto:zboszor@pr.hu>>:
> 
>     Hi,
> 
> 
>     2017-08-11 09:42 keltezéssel, JamChen wrote:
> 
>         From: Jam Chen <jam.chen.egalax@gmail.com <mailto:jam.chen.egalax@gmail.com>>
> 
>         The vendor used the same PID(0x0001) for multiple touch IC controllers.
>         The newer ICs can support HID class and report the multitouch collection
>         in the descriptor. So they were handled by the hid-multitouch driver.
>         But some customized firmwares don't support multitouch protocol even if
>         driver have got the Win8 blob data.
> 
>         Actually, those ICs only support the single touch function, and report
>         the mouse protocol by default. We can assign usbhid to handle them all.
> 
>         Signed-off-by: Jam Chen <jam.chen.egalax@gmail.com <mailto:jam.chen.egalax@gmail.com>>
>         ---
>            drivers/hid/hid-core.c | 4 ++++
>            1 file changed, 4 insertions(+)
> 
>         diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>         index 9017dcc14502..df4696022488 100644
>         --- a/drivers/hid/hid-core.c
>         +++ b/drivers/hid/hid-core.c
>         @@ -828,6 +828,10 @@ static int hid_scan_report(struct hid_device *hid)
>                                           */
>                                          hid->group = HID_GROUP_RMI;
>                          break;
>         +       case USB_VENDOR_ID_DWAV:
>         +               if (hid->product == USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER)
>         +                       hid->group = HID_GROUP_GENERIC;
>         +               break;
>                  }
>                  /* fall back to generic driver in case specific driver doesn't exist */
> 
> 
>     I have tested this patch on 4.12.7 and unfortunately it doesn't work perfectly.
> 
>     Software versions:
> 
>     Xorg server 1.19.3
>     xf86-input-evdev 2.10.5
>     xf86-input-keyboard 1.9.0
>     xf86-input-libinput 0.25.1
>     xf86-input-mouse 1.9.2
>     xf86-input-synaptics 1.9.0
>     libinput 1.8.1
>     libevdev 1.5.7
> 
>     Because the device is now handled as a mouse, the pointer location
>     on the screen doesn't match the actual location of the finger.
>     Caused by this, touches can deliver clicks at the wrong location.
> 
>     Best regards,
>     Zoltán Böszörményi
> 
> 

Re: [PATCH] HID: core: assign usbhid to handle EETI PID=0x0001 HID device

[Benjamin Tissoires]

On Aug 11 2017 or thereabouts, JamChen wrote:
> From: Jam Chen <jam.chen.egalax@gmail.com>
> 
> The vendor used the same PID(0x0001) for multiple touch IC controllers.
> The newer ICs can support HID class and report the multitouch collection
> in the descriptor. So they were handled by the hid-multitouch driver.
> But some customized firmwares don't support multitouch protocol even if
> driver have got the Win8 blob data.
> 
> Actually, those ICs only support the single touch function, and report
> the mouse protocol by default. We can assign usbhid to handle them all.
> 
> Signed-off-by: Jam Chen <jam.chen.egalax@gmail.com>
> ---

Him

FYI, I'd rather see a full working solution such as the one presented here:
https://patchwork.kernel.org/patch/9876649/

Because this solution is half working as it regresses on some devices
while solving others.

Cheers,
Benjamin

>  drivers/hid/hid-core.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 9017dcc14502..df4696022488 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -828,6 +828,10 @@ static int hid_scan_report(struct hid_device *hid)
>  				 */
>  				hid->group = HID_GROUP_RMI;
>  		break;
> +	case USB_VENDOR_ID_DWAV:
> +		if (hid->product == USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER)
> +			hid->group = HID_GROUP_GENERIC;
> +		break;
>  	}
>  
>  	/* fall back to generic driver in case specific driver doesn't exist */
> -- 
> 2.11.0
> 

Re: [PATCH] HID: core: assign usbhid to handle EETI PID=0x0001 HID device

[Boszormenyi Zoltan]

Hi,

On 2017-08-22 11:33, Benjamin Tissoires wrote:
> On Aug 11 2017 or thereabouts, JamChen wrote:
>> From: Jam Chen <jam.chen.egalax@gmail.com>
>>
>> The vendor used the same PID(0x0001) for multiple touch IC controllers.
>> The newer ICs can support HID class and report the multitouch collection
>> in the descriptor. So they were handled by the hid-multitouch driver.
>> But some customized firmwares don't support multitouch protocol even if
>> driver have got the Win8 blob data.
>>
>> Actually, those ICs only support the single touch function, and report
>> the mouse protocol by default. We can assign usbhid to handle them all.
>>
>> Signed-off-by: Jam Chen <jam.chen.egalax@gmail.com>
>> ---
> 
> Him
> 
> FYI, I'd rather see a full working solution such as the one presented here:
> https://patchwork.kernel.org/patch/9876649/
> 
> Because this solution is half working as it regresses on some devices
> while solving others.
> 
> Cheers,
> Benjamin

is there any news about resolving this issue in the upstream kernel?

Thanks in advance,
Zoltán Böszörményi

> 
>>   drivers/hid/hid-core.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>> index 9017dcc14502..df4696022488 100644
>> --- a/drivers/hid/hid-core.c
>> +++ b/drivers/hid/hid-core.c
>> @@ -828,6 +828,10 @@ static int hid_scan_report(struct hid_device *hid)
>>   				 */
>>   				hid->group = HID_GROUP_RMI;
>>   		break;
>> +	case USB_VENDOR_ID_DWAV:
>> +		if (hid->product == USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER)
>> +			hid->group = HID_GROUP_GENERIC;
>> +		break;
>>   	}
>>   
>>   	/* fall back to generic driver in case specific driver doesn't exist */
>> -- 
>> 2.11.0
>>
> 

Re: HID: core: assign usbhid to handle EETI PID=0x0001 HID device

[Kirill Esipov]

Hi

On 08/11/2017 10:42 AM, JamChen wrote:
> From: Jam Chen <jam.chen.egalax@gmail.com>
>
> The vendor used the same PID(0x0001) for multiple touch IC controllers.
> The newer ICs can support HID class and report the multitouch collection
> in the descriptor. So they were handled by the hid-multitouch driver.
> But some customized firmwares don't support multitouch protocol even if
> driver have got the Win8 blob data.
>
> Actually, those ICs only support the single touch function, and report
> the mouse protocol by default. We can assign usbhid to handle them all.
>
> Signed-off-by: Jam Chen <jam.chen.egalax@gmail.com>
> ---
>   drivers/hid/hid-core.c | 4 ++++
>   1 file changed, 4 insertions(+)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 9017dcc14502..df4696022488 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -828,6 +828,10 @@ static int hid_scan_report(struct hid_device *hid)
>   */
>   hid->group = HID_GROUP_RMI;
>   break;
> + case USB_VENDOR_ID_DWAV:
> + if (hid->product == USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER)
> + hid->group = HID_GROUP_GENERIC;
> + break;
>   }
>
>   /* fall back to generic driver in case specific driver doesn't exist */
>
>

I've tested this patch and got the same problem as Zoltán Böszörményi did:
- on finger touch: pointer doesn't change its position;
- on finger move: pointer is moving and it's behavior looks like
touchscreen is working as touchpad;

My test environments:
linux kernel 4.1.18 (armv7 ti am335x)
weston - 1.9.0
libinput - 1.1.4
libevdev - 1.2.99.901

Also I've tested this patch
https://patchwork.kernel.org/patch/9876649/ - and it works fine.



-- 
Kirill Esipov