Bug 120181 - Touchpad not recognized
Summary: Touchpad not recognized
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: Other Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
: 178271 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-06-13 21:28 UTC by mdv1994
Modified: 2018-08-07 13:56 UTC (History)
46 users (show)

See Also:
Kernel Version: 4.4.0-24-generic
Tree: Mainline
Regression: No


Attachments
My hardware config (20.31 KB, text/plain)
2016-06-13 21:28 UTC, mdv1994
Details
attachment-28121-0.html (1.01 KB, text/html)
2016-11-05 22:44 UTC, u.r.qoou
Details
TouchPad photo (2.48 MB, image/jpeg)
2016-11-07 16:50 UTC, Victor Vlasenko
Details
attachment-11073-0.html (1.09 KB, text/html)
2016-11-15 15:03 UTC, singerng
Details

Description mdv1994 2016-06-13 21:28:29 UTC
Created attachment 219811 [details]
My hardware config

My pc model is ASUS-X540LA. There are more details in attachment.


(From /proc/bus/input/devices this is the touchpad recognized as mouse)

I: Bus=0018 Vendor=0b05 Product=0101 Version=0100
N: Name="FTE1001:00 0B05:0101"
P: Phys=i2c-FTE1001:00
S: Sysfs=/devices/pci0000:00/INT33C3:00/i2c-1/i2c-FTE1001:00/0018:0B05:0101.0004/input/input6
U: Uniq=
H: Handlers=mouse1 event6 
B: PROP=0
B: EV=17
B: KEY=30000 0 0 0 0
B: REL=103
B: MSC=10
Comment 1 cjrao 2016-07-17 12:07:28 UTC
On ASUS UX501 with kernel 4.6.4, syslog entries show the following:

kernel: [    8.997193] i2c_hid i2c-FTE1001:00: failed to reset device.
kernel: [   10.027423] i2c_hid i2c-FTE1001:00: error in i2c_hid_init_report size:633 / ret_size:0
kernel: [   10.030796] i2c_hid i2c-FTE1001:00: error in i2c_hid_init_report size:131 / ret_size:0
kernel: [   10.030846] input: FTE1001:00 0B05:0101 as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/i2c-FTE1001:00/0018:0B05:0101.0002/input/input15
kernel: [   10.031115] hid-generic 0018:0B05:0101.0002: input,hidraw1: I2C HID v1.00 Mouse [FTE1001:00 0B05:0101] on i2c-FTE1001:00

Any help to fix this problem?
Comment 2 John Doe 2016-07-29 17:00:40 UTC
I have the same problem on ASUS X540SA (with the exact same touchpad device "FTE1001:00 0B05:0101") with kernel 4.7.0.
Comment 3 kah0922 2016-08-05 01:56:47 UTC
The same thing happens here on openSUSE Tumbleweed with Kernel 4.7.0. The touchpad is recognized as a "pointer" rather than a touchpad.
Comment 4 u.r.qoou 2016-08-10 22:59:54 UTC
Also happens on Ubuntu 16.04, ASUS X556U (kernel 4.4.0)
Comment 5 singerng 2016-08-22 20:13:07 UTC
And ASUS K501U, Ubuntu 16.04, kernel 4.4.0.
Comment 6 cjrao 2016-08-24 11:30:42 UTC
This seems to work fine in Kernel 4.3.5 see 
https://www.marclewis.com/2016/04/25/installing-ubuntu-16-04-lts-on-asus-zenbook-ux501vw/#comment-878

Is this a bug in the newer versions of does this need configuration changes to make it work?
Comment 7 Dmytro 2016-08-24 17:25:41 UTC
I have the same problem on ASUS UX501VW with kernel 4.7.2

cjrao@yahoo.com, it's not for all UX501VW. Some submodels have different touchpads
Comment 8 Dmytro 2016-08-24 22:40:13 UTC
Laptops with Elan touchpad works, but with Focaltech (assume) doesn't.

A part of kern.log (may be helpful):

Aug 24 22:07:41 photon-laptop kernel: [   13.794626] i2c_hid i2c-FTE1001:00: failed to reset device.
...
Aug 24 22:07:41 photon-laptop kernel: [   14.845165] i2c_hid i2c-FTE1001:00: error in i2c_hid_init_report size:633 / ret_size:0
Aug 24 22:07:41 photon-laptop kernel: [   14.848551] i2c_hid i2c-FTE1001:00: error in i2c_hid_init_report size:131 / ret_size:0
Aug 24 22:07:41 photon-laptop kernel: [   14.848608] input: FTE1001:00 0B05:0101 as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/i2c-FTE1001:00/0018:0B05:0101.0001/input/input12
Aug 24 22:07:41 photon-laptop kernel: [   14.848922] hid-generic 0018:0B05:0101.0001: input,hidraw0: I2C HID v1.00 Mouse [FTE1001:00 0B05:0101] on i2c-FTE1001:00
Comment 9 maokei 2016-08-30 20:05:52 UTC
Asus Zenbook UX501VW-Fy062T Has the same problem with the focaltech touchpad tested with ubuntu 16.04 kernel 4.4 and 4.7:

I: Bus=0018 Vendor=0b05 Product=0101 Version=0100
N: Name="FTE1001:00 0B05:0101"
P: Phys=i2c-FTE1001:00
S: Sysfs=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/i2c-FTE1001:00/0018:0B05:0101.0004/input/input16
U: Uniq=
H: Handlers=mouse1 event16 
B: PROP=0
B: EV=17
B: KEY=30000 0 0 0 0
B: REL=103
B: MSC=10
Comment 10 Egor 2016-09-03 04:18:06 UTC
Same problem with Asus K501UW, Linux Mint 18, kernel 4.4
Comment 11 Idham 2016-09-06 04:13:48 UTC
Same problem with Asus A456U, Ubuntu 16.04, kernel 4.4.0

I: Bus=0018 Vendor=0b05 Product=0101 Version=0100
N: Name="FTE1001:00 0B05:0101"
P: Phys=i2c-FTE1001:00
S: Sysfs=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-FTE1001:00/0018:0B05:0101.0003/input/input9
U: Uniq=
H: Handlers=mouse1 event9 
B: PROP=0
B: EV=17
B: KEY=30000 0 0 0 0
B: REL=103
B: MSC=10
Comment 12 cderungs 2016-09-09 12:45:04 UTC
Same problem with Asus UX501VW-FY102R, Ubuntu 16.04, kernel 4.6.0

 Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ FTE1001:00 0B05:0101                    	id=11	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Asus Wireless Radio Control             	id=7	[slave  keyboard (3)]
    ↳ Video Bus                               	id=8	[slave  keyboard (3)]
    ↳ Video Bus                               	id=9	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=10	[slave  keyboard (3)]
    ↳ Asus WMI hotkeys                        	id=12	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=13	[slave  keyboard (3)]
    ↳ USB2.0 HD UVC WebCam                    	id=14	[slave  keyboard (3)]
Comment 13 blanks.media 2016-09-09 21:06:37 UTC
Also have the same problem with my ASUS X540SA, Ubuntu 16.04.1 LTS, Kernal 4.4.0-36-generic

laptop@laptop-X540SA:~$ xinput
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ FTE1001:00 0B05:0101                    	id=10	[slave  pointer  (2)]
Comment 14 Serge Skripchuk 2016-09-11 08:09:44 UTC
I have the same problem on ASUS UX501VW-FY145R, tried Ubuntu 16.04.1 LTS (kernel 4.4.0-36-generic), Ubuntu 16.10 beta. openSUSE Leap 42.1 didn't recognize touchpad at all.

tarzanych@tarzanych-N501VW:~$ xinput
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ FTE1001:00 0B05:0101                    	id=11	[slave  pointer  (2)]
Comment 15 freefal67 2016-09-18 18:48:17 UTC
Same exact issue here on Asus Zenbook ux501vw.
Any better fixes than downgrading to the 4.3 kernel are very welcome.
Comment 16 Thomas 2016-09-21 06:06:46 UTC
Same issue with Asus Vivobook E200HA. Touchpad recognized as mouse, so no way to configure any touchpad-specific settings. "error in i2c_hid_init_report size" errors during boot.
Comment 17 kah0922 2016-09-21 17:11:09 UTC
Apparently Arch Linux might have a solution here: https://wiki.archlinux.org/index.php/Touchpad_Synaptics#ASUS_Touchpads_only_recognised_as_PS.2F2_FocalTech_emulated_mouse

Problem is, those drivers are for kernel 3.19; They don't work on Kernel 4.7.
Comment 18 singerng 2016-09-21 18:34:41 UTC
I tried the same thing, along with basically every proposed solution I could find on the internet.
Comment 19 Peter 2016-09-22 09:11:28 UTC
FYI: I suspect that this is not a FocalTech since they use PNPid FTS [1]. Instead FTE indicates "Frontline Test Equipment Inc."


1: http://www.uefi.org/sites/default/files/resources/PNPID_List.pdf
Comment 20 Peter 2016-09-23 07:58:45 UTC
To followup; I've asked FrontLine support and they reject that it's theirs. Now I'm curious.

I've asked FocalTech to confirm the model id is theirs. No response as of yet. 

I've also asked Asus (mine's a UX501VW) but their tech support follows tight scripts and won't give me a clear answer. Note that under Windows, the only vendor identification apart from FTE1001 and VEN_FTE is "Asus". But that could be due to anything and still hide the original manufacturer.

Pending their responses, where else might I confirm the vendor? If FTE is not a clue and none of the inspection results I've seen in linux gives me shows this (or I missed it) then how are you supposed to find out who created what?
Comment 21 Dmitry Tunin 2016-09-23 20:59:01 UTC
@Peter,

It does not matter what is the vendor of this touchpad device. Asus never tells it.
Anyway the only way to get it working on Linux is to get a device and try to reverse engineer the protocol. The device supports i2c, but initialization is needed to switch the protocol.
Comment 22 Leir 2016-09-27 10:07:31 UTC
Hi, I dont know if it helps, but I got same issue.

Asus F556UQ, Ubuntu 16.04.1, Kernel 4.7.0-040700-generic. 

@freefal67@gmail.com,

Have you tried downgrade to version 4.3? Did it helped? Thanks
Comment 23 Dmitry Tunin 2016-09-27 10:15:03 UTC
This touchpad will not work on any Linux kernel until a new driver is made.
Comment 24 Egor 2016-09-27 15:31:38 UTC
Surprisingly, Asus support got back to me and told that's an AZWAVE/Azurewave touchpad, AW-TP242. (I didn't even know Azurewave is producing touchpads.) That's at least on my K501UW, but I assume we're all dealing with the same touchpad here.

I emailed Azurewave support asking about driver or some documentation that would be helpful in writing one.
Comment 25 u.r.qoou 2016-09-27 15:41:45 UTC
(In reply to Egor from comment #24)
> That's at least on my K501UW, but I assume we're all
> dealing with the same touchpad here.
Why do you assume this? There was trouble with other vendors as well (focaltech, elan...)

> I emailed Azurewave support asking about driver or some documentation that
> would be helpful in writing one.

Thanks :)
Comment 26 Egor 2016-09-27 15:56:47 UTC
(In reply to u.r.qoou from comment #25)
> (In reply to Egor from comment #24)
> > That's at least on my K501UW, but I assume we're all
> > dealing with the same touchpad here.
> Why do you assume this? There was trouble with other vendors as well
> (focaltech, elan...)
I don't think elans have been a problem in this thread. 
The main problem is with FTE1001:00 0B05:0101 (which I also have), which was assumed to be Focaltech. However, this is an i2c touchpad while all focaltech devices are ps/2 (and working fine). Further, as discovered by Peter, focaltech's pnpid is FTS and not FTE. So we settled at this touchpad not being focaltech.

According to what Asus support told me, this FTE1001:00 0B05:0101 is actually Azurewave AW-TP242. That's the new twist of the story that I meant to convey, sorry for imprecision.
Comment 27 nvsl 2016-10-24 12:46:38 UTC
Having the same problem with my ASUS Zenbook Pro UX501VW - FY102T. 
The touchpad is detected as an emulated mouse and it's almost usable. The right click is too sensitive, scrolling does not work..
Problem seems to be related here:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/1587913
http://askubuntu.com/questions/823068/touch-pad-not-detected-correctly-asus-x540sa
https://www.debian-fr.xyz/viewtopic.php?t=367
https://forums.linuxmint.com/viewtopic.php?t=229029

Affected laptop: (from this post and googling)

- Asus G501
- Asus X540SA
- Asus K501UW
- Asus F556UQ
- ASUS-X540LA
- ASUS X540SA
- ASUS X556U
- Asus K501UW
- Asus F556UQ
- ASUS UX501VW-FY145R
- ASUS UX501VW-FY102T PRO

Can we may use the elantech drivers after adding FTE into supported HW and change signature mouse event? It should be enough,no?

(In reply to Egor from comment #26)
> (In reply to u.r.qoou from comment #25)
> > (In reply to Egor from comment #24)
> > > That's at least on my K501UW, but I assume we're all
> > > dealing with the same touchpad here.
> > Why do you assume this? There was trouble with other vendors as well
> > (focaltech, elan...)
> I don't think elans have been a problem in this thread. 
> The main problem is with FTE1001:00 0B05:0101 (which I also have), which was
> assumed to be Focaltech. However, this is an i2c touchpad while all
> focaltech devices are ps/2 (and working fine). Further, as discovered by
> Peter, focaltech's pnpid is FTS and not FTE. So we settled at this touchpad
> not being focaltech.
> 
> According to what Asus support told me, this FTE1001:00 0B05:0101 is
> actually Azurewave AW-TP242. That's the new twist of the story that I meant
> to convey, sorry for imprecision.

Do you have any news from Azurewave?
Comment 28 Egor 2016-10-24 15:23:40 UTC
(In reply to nvsl from comment #27)
> (In reply to Egor from comment #26)
> > (In reply to u.r.qoou from comment #25)
> > > (In reply to Egor from comment #24)
> > > > That's at least on my K501UW, but I assume we're all
> > > > dealing with the same touchpad here.
> > > Why do you assume this? There was trouble with other vendors as well
> > > (focaltech, elan...)
> > I don't think elans have been a problem in this thread. 
> > The main problem is with FTE1001:00 0B05:0101 (which I also have), which
> was
> > assumed to be Focaltech. However, this is an i2c touchpad while all
> > focaltech devices are ps/2 (and working fine). Further, as discovered by
> > Peter, focaltech's pnpid is FTS and not FTE. So we settled at this touchpad
> > not being focaltech.
> > 
> > According to what Asus support told me, this FTE1001:00 0B05:0101 is
> > actually Azurewave AW-TP242. That's the new twist of the story that I meant
> > to convey, sorry for imprecision.
> 
> Do you have any news from Azurewave?

Nope, no response from Azurewave.
Comment 29 Kemal Ilgar Eroğlu 2016-10-29 12:07:09 UTC
My ASUS TP200SA has a FTE1000:00 0B05:0101 touchpad device. This bug report probably applies to that one, too.
Comment 30 nvsl 2016-10-29 12:12:04 UTC
(In reply to Kemal Ilgar Eroğlu from comment #29)
> My ASUS TP200SA has a FTE1000:00 0B05:0101 touchpad device. This bug report
> probably applies to that one, too.

I update the list:

Affected laptop: (from this post and googling)

- Asus G501
- Asus X540SA
- Asus K501UW
- Asus F556UQ
- ASUS-X540LA
- ASUS X540SA
- ASUS X556U
- Asus K501UW
- Asus F556UQ
- ASUS UX501VW-FY145R
- ASUS UX501VW-FY102T PRO
- ASUS TP200SA

We need to wait someone makes a new driver for that touchpad. Hope this will not take too long.
Comment 31 Axeman 2016-11-01 09:58:16 UTC
I can confirm this issue on ASUS VIVOBOOK R301UA-FN115T.
Comment 32 Victor Vlasenko 2016-11-03 14:11:53 UTC
(In reply to nvsl from comment #27)
> Affected laptop: (from this post and googling)
> 
> - Asus G501
> - Asus X540SA
> - Asus K501UW
> - Asus F556UQ
> - ASUS-X540LA
> - ASUS X540SA
> - ASUS X556U
> - Asus K501UW
> - Asus F556UQ
> - ASUS UX501VW-FY145R
> - ASUS UX501VW-FY102T PRO
> 
> Can we may use the elantech drivers after adding FTE into supported HW and
> change signature mouse event? It should be enough,no?
Opinionated answer here.

I have the device FTE1001:00 0B05:0101. I have tried to dig through kernel sources and make some experiments. What I have figured out is that simply adding FTE1001 to ElanTech driver leads to nowhere, because this device is different. It is exposed by default as mouse and not TouchPad. To switch this device into TouchPad mode we should know proper I2C commands sequence, which is not guessable, we need to know it. After switching into TouchPad mode I believe the device will use one of standard touchpad protocols, I'm not sure, but it is so for many devices out there. The problem is usually only this init sequence. There are two ways to get this I2C commands sequence:
1. From device manufacturer. We should find out who has manufactured the device and ask for documentation to write Linux driver for it. I don't believe that AzureWave is manufacturer. They are producing wireless devices, why would they produce touchpads? Nothing on their website indicates that they produce touchpads.
2. The only other way is to reverse-engineer Asus SmartGuesture Window driver using Window Kernel Debugging facilities.

I don't think that silently waiting until someone writes the driver will help this happen. Actually we have very low chances for having the driver for this device if our position is passive. Egor was actually on a right track - pursuing ASUS I think, but they need more pressure.

One another point, is that posting laptop models into this ticket is actually USELESS. I have bought two identical ASUS UX501VW-FY145T laptops from Amazon.de, that was sent to me from Poland. And one laptop came with ELAN1000 Touchpad that was perfectly recognized by Linux kernel and another laptop came with FTE1001. So Asus places these TouchPads at Random. If you have received yours with FTE1001 you can try your luck asking for replacement.

Victor
Comment 33 nvsl 2016-11-03 14:24:33 UTC
Thanks for your clarifications about identifying the touchpad by the kernel. You are probably right, we have to push that problem in a higher level. Anyway, I am developper but never develop into linux kernel. I've taken a look into elantech modules, it does not seem very complicated. As you said, the most difficult part is to make identifying the touchpad by the kernel (given the right sequence or anything else). I'll try to develop a simple version (identification, multitouch detection, right + left click), any help would be appreciated.
Comment 34 Victor Vlasenko 2016-11-03 14:35:44 UTC
(In reply to nvsl from comment #33)
> Thanks for your clarifications about identifying the touchpad by the kernel.
> You are probably right, we have to push that problem in a higher level.
> Anyway, I am developper but never develop into linux kernel. I've taken a
> look into elantech modules, it does not seem very complicated. As you said,
> the most difficult part is to make identifying the touchpad by the kernel
> (given the right sequence or anything else). I'll try to develop a simple
> version (identification, multitouch detection, right + left click), any help
> would be appreciated.
Nope, you got me wrong. The problem is not in identification of the device by the kernel. The problem is that device is able to expose several versions of the API. 


After power up it exposes Mouse API. To make device expose Touchpad API you need to send proper sequence of bytes to the device to switch it to Touchpad mode. The main problem is to know this proprietary sequence of bytes. You can't just guess it you need to know it. You need to get it from somewhere. By reverse-engineering Windows driver, for example, or by getting documentation from manufacturer.

Just hacking kernel will not help. You need to know this proprietary initialization byte sequence.

Victor
Comment 35 cjrao 2016-11-03 14:54:20 UTC
Thank you Victor..

Found this interesting article.. I will check this out and see if I can figure that magical sequence of bytes.

http://blog.forshee.me/2011/11/touchpad-protocol-reverse-engineering.html

-- Jitendra.
Comment 36 Victor Vlasenko 2016-11-03 14:58:04 UTC
(In reply to cjrao from comment #35)
> Thank you Victor..
> 
> Found this interesting article.. I will check this out and see if I can
> figure that magical sequence of bytes.
> 
> http://blog.forshee.me/2011/11/touchpad-protocol-reverse-engineering.html
> 
> -- Jitendra.
Jitendra,

Nope this won't work. This touchpad is an PCI I2C device, communication with touchpad happens on PCI bus. Intercepting PCI bus communication is way more difficult then sniffing PS/2 or I2C. 

Victor
Comment 37 Victor Vlasenko 2016-11-03 14:59:22 UTC
Then sniffing PS/2 or USB, I meant, sorry for typo.
Comment 38 Victor Vlasenko 2016-11-05 09:21:19 UTC
I think Asus Support provided false information to Egor, claiming that FTE1001 is an AzureWave device. Nothing in Asus TouchPad Drivers for Windows points to AzureWave. Nothing indicates on AzureWave website that they produce any touchpads.

Looking at the strings inside Asus Smart Guesture Windows 7 drivers I see that FTE1001 is a FocalTech I2C device. Linux Kernel has support for FocalTech PS/2 FLT* devices only, not FocalTech I2C FTE* devices. I2C devices should have completely different driver. I think that the main problem in writing FocalTech I2C driver is to know proprietary init sequence to switch I2C device from Mouse mode into TouchPad mode. 

I think we should write email to FocalTech, asking for help with documentation, to write Linux Kernel Driver for their I2C touchpad devices.

Thoughts?

Regards,
Victor
Comment 39 cjrao 2016-11-05 10:00:40 UTC
Victor, FYI: Looks like Dmitry Tunin is looking into this already,

https://lkml.org/lkml/2016/10/17/747

-- Jitendra.
Comment 40 Victor Vlasenko 2016-11-05 10:28:10 UTC
Jitendra,

This is of course nice, that several people are looking into this, but it doesn't change the fact, that we need to either reverse engineer the device protocol or get documentation from manufacturer. I think getting documentation from FocalTech is the first thing we should try. And anyone on this list can help with this. Documentation can help big time with writing Linux driver for people who are "already looking into this". Without documentation writing the driver might still be doable, but equal possibility is that it might take ages or never happens at all, despite the fact that someone is looking into this right now.

Victor
Comment 41 u.r.qoou 2016-11-05 15:49:48 UTC
FWIW, asus Israel also said it's azwave:

>Thank you for contacting us 
>
>The touch pad manufacture is 
>
>AZWAVE
>MODEL:
>AW-TP242
Comment 42 nvsl 2016-11-05 15:58:18 UTC
It seems to be this one:

https://www.ipc-computer.de/notebook-ersatzteile/platinen/-04060-00780000

Maybe this seller could provide more details/documentation on the HW.
Comment 43 Victor Vlasenko 2016-11-05 17:08:26 UTC
FYI, Windows drivers for this TouchPad, one of the files AsusSupportList.ini, which is used by check_hwid.exe to identify whether machine has supported hardware.

AsusSupportList.ini:
----------------------------------------
[PREINSTALL]
2,T100CHI
2,T300CHI
2,T300CHIA
2,T301CA
2,T302CHI

[CHECK HEADER]
ACPI
HID

[VENDOR_ELAN_PS2]
ETD0105
ETD0107
ETD0108
ETD0109
ETD010A
ETD010B
ETD010D
ETD010E
ETD0110
ETD0111
ETD1000
ETD0116

[VENDOR_SYNA_SMB]
SYN0A2D
SYN0A18

[VENDOR_ELAN_I2C]
ELAN0
ELAN1

[VENDOR_FOCALTECH_I2C]
FTE1

[VENDOR_FOCALTECH_PS2]
FLT

[VENDOR_ELAN_PTP]
ELAN2

[VENDOR_FOCALTECH_PTP]
FTE2

[WIRELESS_DOCK_FULL_INFO]
VID_0B05&PID_1823&MI_01&COL02

[WIRELESS_DOCK_PART_INFO]
VID_0B05&PID_17E0&MI_02&COL02
VID_0B05&PID_17EE&MI_02&COL02
VID_0B05&PID_1807&MI_02&COL02
{00001124-0000-1000-8000-00805F9B34FB}_VID&00020B05_PID&8502&COL08

[VID_TP]
2,0x04f3
2,0x0413
3,0x0b05
----------------------------------------

FTE1* is FOCALTECH_I2C. FLT* is FOCALTECH_PS2.
Comment 44 Victor Vlasenko 2016-11-05 17:13:52 UTC
Another file of Windows drivers that support this touchpad is FocalTech_i2c/AsusHID.inf:
[ASUSMfg.NTx86]
;NB platform
%HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\FTE1000&Col01
%HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\FTE1001&Col01
%HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\FTE1002&Col01
%HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\ELAN1000&Col01
%HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\ELAN0100&Col01
;wireless docking
%HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\Vid_0B05&Pid_1823&MI_01&Col01
%HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\Vid_0B05&Pid_17E0&MI_02&Col01
%HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\Vid_0B05&Pid_17EE&MI_02&Col01
%HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\Vid_0B05&Pid_1807&MI_02&Col01


Neither AzureWave nor AW-TP, nor TP242 mentions present in the Windows drivers for this TouchPad.
Comment 45 Egor 2016-11-05 18:27:36 UTC
Victor, thank you for your effort.

I emailed Focaltech asking for documentation or at least the I2C commands. I'll tell if I hear anything from them.

Egor
Comment 46 Victor Vlasenko 2016-11-05 18:47:25 UTC
Thank you Egor,

I'm going to ask FocalTech for documentation as well at Monday, to show our interest.

Victor
Comment 47 u.r.qoou 2016-11-05 22:44:39 UTC
Created attachment 243721 [details]
attachment-28121-0.html

Me three.
http://www.focaltech-systems.com/En/feedback.aspx
Enjoy

On Nov 5, 2016 20:47, <bugzilla-daemon@bugzilla.kernel.org> wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=120181
>
> --- Comment #46 from Victor Vlasenko <vitek.vlasenko@gmail.com> ---
> Thank you Egor,
>
> I'm going to ask FocalTech for documentation as well at Monday, to show our
> interest.
>
> Victor
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>
Comment 48 cjrao 2016-11-06 13:27:57 UTC
Thank you all.. me four (sent one two weeks ago) and five (another e-mail yesterday).

Thank you
Jitendra.
Comment 49 nvsl 2016-11-06 13:59:02 UTC
(In reply to Victor Vlasenko from comment #44)
> Another file of Windows drivers that support this touchpad is
> FocalTech_i2c/AsusHID.inf:
> [ASUSMfg.NTx86]
> ;NB platform
> %HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\FTE1000&Col01
> %HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\FTE1001&Col01
> %HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\FTE1002&Col01
> %HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\ELAN1000&Col01
> %HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\ELAN0100&Col01
> ;wireless docking
> %HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\Vid_0B05&Pid_1823&MI_01&Col01
> %HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\Vid_0B05&Pid_17E0&MI_02&Col01
> %HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\Vid_0B05&Pid_17EE&MI_02&Col01
> %HID_INPUT_DEVICE.DeviceDesc%=AsusHID_Inst, HID\Vid_0B05&Pid_1807&MI_02&Col01
> 
> 
> Neither AzureWave nor AW-TP, nor TP242 mentions present in the Windows
> drivers for this TouchPad.

The switch mode you are talking about should be:

 * Some ASUS devices were shipped with firmware that requires
	 * touchpads to be woken up first, before attempting to switch
	 * them into absolute reporting mode.
	 */
	if (elan_check_ASUS_special_fw(data)) {
		error = data->ops->sleep_control(client, false);
		if (error) {
			dev_err(&client->dev,
				"failed to wake device up: %d\n", error);
			return error;
		}

		msleep(200);
		woken_up = true;
	}

	data->mode |= ETP_ENABLE_ABS;
	error = data->ops->set_mode(client, data->mode);
	if (error) {
		dev_err(&client->dev,
			"failed to switch to absolute mode: %d\n", error);
		return error;
	}

(from linux i2c elantech driver).

From elan_i2c windows driver: (AsusSGDrv.inf)

[ASUSMfg.NTx86]
;Interface : I2C
;NB platform
%ASUS_INPUT_DEVICE.DeviceDesc%=AsusSGDrv_Inst, HID\FTE1000&Col01
%ASUS_INPUT_DEVICE.DeviceDesc%=AsusSGDrv_Inst, HID\FTE1001&Col01
%ASUS_INPUT_DEVICE.DeviceDesc%=AsusSGDrv_Inst, HID\FTE1002&Col01
%ASUS_INPUT_DEVICE.DeviceDesc%=AsusSGDrv_Inst, HID\ELAN1000&Col01
%ASUS_INPUT_DEVICE.DeviceDesc%=AsusSGDrv_Inst, HID\ELAN1005&Col01
%ASUS_INPUT_DEVICE.DeviceDesc%=AsusSGDrv_Inst, HID\ELAN0100&Col01
%ASUS_INPUT_DEVICE.DeviceDesc%=AsusSGDrv_Inst, HID\ELAN0101&Col01

From focaltech i2c windows driver:

%ASUS_INPUT_DEVICE.DeviceDesc%=AsusSGDrv_Inst, HID\FTE1000&Col01
%ASUS_INPUT_DEVICE.DeviceDesc%=AsusSGDrv_Inst, HID\FTE1001&Col01
%ASUS_INPUT_DEVICE.DeviceDesc%=AsusSGDrv_Inst, HID\FTE1002&Col01
%ASUS_INPUT_DEVICE.DeviceDesc%=AsusSGDrv_Inst, HID\ELAN1000&Col01
%ASUS_INPUT_DEVICE.DeviceDesc%=AsusSGDrv_Inst, HID\ELAN1005&Col01
%ASUS_INPUT_DEVICE.DeviceDesc%=AsusSGDrv_Inst, HID\ELAN0100&Col01
%ASUS_INPUT_DEVICE.DeviceDesc%=AsusSGDrv_Inst, HID\ELAN0101&Col01

So I am not sure about the conclusion, either the both drivers support the FTE touchpad or the files are not up-to-date.

The current kernel provides an elantech i2c + ps/2 and a focaltech ps/2.

Given the windows specifications files, the i2c elantech drivers should support our FTE touchpad. What do you think?
Comment 50 Victor Vlasenko 2016-11-06 15:29:57 UTC
(In reply to nvsl from comment #49)
> The switch mode you are talking about should be:
> 
>  * Some ASUS devices were shipped with firmware that requires
>        * touchpads to be woken up first, before attempting to switch
>        * them into absolute reporting mode.
>        */
>       if (elan_check_ASUS_special_fw(data)) {
>               error = data->ops->sleep_control(client, false);
>               if (error) {
>                       dev_err(&client->dev,
>                               "failed to wake device up: %d\n", error);
>                       return error;
>               }
> 
>               msleep(200);
>               woken_up = true;
>       }
> 
>       data->mode |= ETP_ENABLE_ABS;
>       error = data->ops->set_mode(client, data->mode);
>       if (error) {
>               dev_err(&client->dev,
>                       "failed to switch to absolute mode: %d\n", error);
>               return error;
>       }
> 
> (from linux i2c elantech driver).
Nope. This is unrelated. This is switching of ElantTech I2C devices ELAN* to Absolute Positioning mode. This is not an ElanTech I2C device, this is FocalTech I2C device, FTE*. This code doesn't work on FTE1001, device doesn't react on initialization code and driver hangs when trying to query device after initialization. I have tried it. You can try it too and make sure this driver is not working for FTE1001 at all.
 
> So I am not sure about the conclusion, either the both drivers support the
> FTE touchpad or the files are not up-to-date.
> 
> The current kernel provides an elantech i2c + ps/2 and a focaltech ps/2.
> 
> Given the windows specifications files, the i2c elantech drivers should
> support our FTE touchpad. What do you think?
If it was the case then device would have reacted somehow to Linux Kernal ElanTech I2C driver code, when you add FTE1001 to the list of recognized PCI ids. But this is not the case, device doesn't react on this initialization code. Because of this I think that this is FocalTech I2C device that does not have Linux Kernel Driver at all at the moment.

Victor
Comment 51 mateubruno 2016-11-07 15:07:43 UTC
Got the same problem... i've just send an email to FocalTech to ask them anything that could help us.
Comment 52 Victor Vlasenko 2016-11-07 15:59:15 UTC
Has anyone tried to disassemble the laptop and taking the photo of the TouchPad chips to identify ID of the TouchPad chip? It should not be too hard, the TouchPad is right under the battery. I have disassembled mine laptop some time ago, but didn't take the photo of the TouchPad chips and they were visible if I remember right...
Comment 53 Victor Vlasenko 2016-11-07 16:50:45 UTC
Created attachment 243821 [details]
TouchPad photo
Comment 54 Victor Vlasenko 2016-11-07 16:51:28 UTC
So, I've disassembled my laptop again and took the photo of TouchPad chip. Chip id is FT5346DQQ. If you Google a bit, you will be able to find Documentation in public access for this chip as well as Open Source Drivers for this chip at: https://github.com/focaltech-systems/drivers-input-touchscreen-FTS_driver. From whatever reason looks like only the part of this source code made into Linux Kernel. So, actually, WE ALREADY HAVE EVERYTHING TO WRITE LINUX DRIVERS for this TouchPad, we need to only adapt this FocalTech code for FT5346-based devices. We might have one obstacle though, if this device has proprietary firmware, but if it's not the case we should succeed.

Photo of the touchpad is attached to this issue.
Comment 55 Olivier Mouren 2016-11-07 20:12:02 UTC
The driver on github is not already for the FT5346? They are talking about "FT5x46" chip in the readme. We need to try this driver.
Comment 56 pbelt 2016-11-08 14:54:58 UTC
My laptop model is not exactly listed in comment 27. There are some Asus F556xx. Mine is ASUS F556UJ but the issue is the same.

I've written to Asus asking for the touchpad model:
ELAN/SA473I-12A2, with part number 04060-00760000AC15501HA0067
Comment 58 nvsl 2016-11-09 00:23:01 UTC
(In reply to ain from comment #57)
> I ’ve tried to compile the github thing
> (https://github.com/focaltech-systems/drivers-input-touchscreen-FTS_driver),
> but stuff is missing. 
> Googled for some of it and found things.
> 
> // ft5x06 driver in linux kernel !
> https://github.com/torvalds/linux/blob/v4.5/Documentation/devicetree/
> bindings/input/touchscreen/edt-ft5x06.txt
> https://github.com/torvalds/linux/blob/v4.5/drivers/input/touchscreen/edt-
> ft5x06.c
> 
> // chinese driver + doku
> http://blog.csdn.net/tigerlau225/article/category/1541655
> 
> // various stuff from phone roms
> https://github.com/suribi/Thunder-Kernel/blob/master/mediatek/custom/common/
> kernel/touchpanel/ft5336/ft5336_driver.c
> http://pastebin.com/8ykhQ7H6
> https://github.com/Pillar1989/sprd_project/blob/master/sc7731_kernel/drivers/
> input/touchscreen/focaltech/focaltech_ex_fun.c
> https://github.com/phenomx4/android_kernel_zte_msm8226/blob/master/drivers/
> input/touchscreen/ft5x06_ex_fun.h
> https://github.com/phenomx4/android_kernel_zte_msm8226/blob/master/drivers/
> input/touchscreen/ft5x06_ex_fun.c
> https://github.com/kirananto/ZENFONE2/blob/master/drivers/input/touchscreen/
> ftxxxx_ex_fun.h
> https://github.com/JujuXIII/android_kernel_acer_v370_KK/blob/master/mediatek/
> custom/common/kernel/touchpanel/focaltech/focaltech_ex_fun.h

Thanks. I've tried to compile + load ft5x06 module but it did not recognized the touchpad.
Comment 59 ain 2016-11-09 19:32:29 UTC
I think the ft5x06 driver from the kernel is a dead end.
https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a25/Documentation/input/edt-ft5x06.txt
> The edt-ft5x06 driver is useful for the EDT "Polytouch" family of capacitive
> touch screens. Note that it is *not* suitable for other devices based on the
> focaltec ft5x06 devices, since they contain vendor-specific firmware.

So we are back to the non compiling thing plus phone roms https://github.com/focaltech-systems/drivers-input-touchscreen-FTS_driver.
And the chinese stuff.
Comment 60 u.r.qoou 2016-11-10 22:02:40 UTC
After requesting ASUS to help with the driver:

>Thank you for your paitiance 
>Unfortunately after consulting with HQ it is not possible to create a driver
>as Linux is not officially supported for the PC
Comment 61 ain 2016-11-12 03:01:28 UTC
I will try to get something out of the focaltech repo.
my fork:
https://github.com/ain101/drivers-input-touchscreen-FTS_driver

Please tell me if somebody is working on this already.
I have no experience in kernel stuff yet. Feedback is appreciated.
Comment 64 Olivier Mouren 2016-11-12 12:54:38 UTC
We need to have a documentation like this : http://www.newhavendisplay.com/appnotes/datasheets/touchpanel/FT5x06_registers.pdf
But for the FT5x46

Just a note for who want to know :
To see i2c data from the touchpad : https://linuxtv.org/wiki/index.php/Bus_snooping/sniffing#i2c
It works but I don't know how to interpret the results (we just can see that some values change if we touch and slide on the touchpad)
Comment 65 ain 2016-11-13 20:17:03 UTC
// Soldered some wires, sniffed some I2C:

// something happens on boot until login prompt
https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/win%20boot%20after%20grub%202.csv

// then again something is sent
https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/win%20login%202.csv

You need saleae software to view *.logicdata (https://www.saleae.com/downloads)

I will try to replay the sniffed data under linux with i2cset. (https://web.archive.org/web/20150907093853/http://www.lm-sensors.org/wiki/i2cToolsDocumentation)

Does anybody know where the initialization of touchpads happen in kernel code?
Maybe it would be easier to change something there and recompile the module.

https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/hid%20restart
When I restart i2c_hid the touchpad seems to send something which isn't pure touch data like in normal operation. I have no idea how i2c_hid works.

I am grateful for any help.
Comment 66 Victor Vlasenko 2016-11-14 06:17:04 UTC
Hey, cool stuff!

Thanks!

This is HID initialization sequence. The 0x01 0x00 is a get HID descriptor command, then it reads HID descriptor, the first two bytes of HID descriptor is it's length in little-endian. The 0x02 0x00 is a get Report Descriptor command, after it reads Report descriptor, again the first two bytes is the length of Report Descriptor in little-endian.

I have done some playground for playing with this TouchPad using HID I2C commands in userspace in Node.js here:
https://github.com/vlasenko/zenbook-touchpad-i2c

If we will have full initialization sequence from Windows, we should be able to understand how it switches TouchPad from Mouse mode into MultiTouch mode. I think it uses HID commands for that, just a bit non-standard. The standard HID over I2C protocol definition is here:
http://download.microsoft.com/download/7/d/d/7dd44bb7-2a7a-4505-ac1c-7227d3d96d5b/hid-over-i2c-protocol-spec-v1-0.docx

Regarding Linux Kernel, all the initialization is inside drivers/hid/i2c-hid.c, right now this driver is used to communicate with TouchPad. But if all goes well, perhaps we will be able to make drivers/hid/hid-multitouch.c instead, it's not trivial though. We should completely figure out, how to switch this touchpad in MultiTouch mode first using HID commands.

Regards,
Victor

(In reply to ain from comment #65)
> // Soldered some wires, sniffed some I2C:
> 
> // something happens on boot until login prompt
> https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/
> doc/sniff/logic%20analyzer/win%20boot%20after%20grub%202.csv
> 
> // then again something is sent
> https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/
> doc/sniff/logic%20analyzer/win%20login%202.csv
> 
> You need saleae software to view *.logicdata
> (https://www.saleae.com/downloads)
> 
> I will try to replay the sniffed data under linux with i2cset.
> (https://web.archive.org/web/20150907093853/http://www.lm-sensors.org/wiki/
> i2cToolsDocumentation)
> 
> Does anybody know where the initialization of touchpads happen in kernel
> code?
> Maybe it would be easier to change something there and recompile the module.
> 
> https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/
> doc/sniff/hid%20restart
> When I restart i2c_hid the touchpad seems to send something which isn't pure
> touch data like in normal operation. I have no idea how i2c_hid works.
> 
> I am grateful for any help.
Comment 67 Victor Vlasenko 2016-11-14 06:29:54 UTC
Could you also move your finger a little bit on TouchPad surface after login screen appears, and intercept the protocol starting from boot to moving your finger inclusive? I think this must be the most relevant data for us and we will be sure, it is complete, because we will have all initialization sequences as well as touch sequence.

Regards,
Victor
Comment 68 Thomas 2016-11-14 08:18:55 UTC
I think the Asus E200HA may have this touchpad as well. At least, I get these same issues on it.
Comment 69 Victor Vlasenko 2016-11-14 14:37:12 UTC
(In reply to ain from comment #65)

@ain

So, I have decoded sequences from your CSVs. Unfortunately I have not been able to switch device to MultiTouch mode yet.

MultiTouch events are preset in some of your CSV files, but not in all the files. You could look for Read sequence [0x1e, 0x00, 0x5d] to determine whether there were MultiTouch events. 0x1e - is the size of the packet, 0x1e - is the MAXIMUM size of Input packet as specified by this Device Report Descriptor. 0x5d - is the type and ID of Input Report.

The most interesting file is "win boot 1 finger drag". It meant to be complete protocol interception from intialization to MultiTouch input and includes [0x1e, 0x00, 0x5d] MultiTouch events at the end. But I'm afraid it is still incomplete from these two reasons:
1. There is a weird part at the start:
0.114540750000000,,0xFF,,Read,NAK
0.114720083333333,8,0xFF,0xFF,Read,NAK
0.114844750000000,8,0xFF,0xFF,Read,NAK
0.114886333333333,8,0xFF,0xFF,Read,NAK
0.115022916666667,8,0xFF,0xFF,Read,NAK
0.115223916666667,8,0xFF,0xFF,Read,NAK
0.115942333333333,8,0xFF,0xFF,Read,NAK
0.116034000000000,8,0xFF,0xFF,Read,NAK
0.116163083333333,8,0xFF,0xFF,Read,NAK
0.116284000000000,8,0xFF,0xFF,Read,NAK
0.116338583333333,8,0xFF,0xFF,Read,NAK
0.116483666666667,8,0xFF,0xFF,Read,NAK
0.116710916666667,8,0xFF,0xFF,Read,NAK
This should not happen, maybe it's some analyzer connection issue?
2. There is a big delay in the middle of the file, when nothing happens:
7.918967916666666,36,0x2A,0x00,Write,ACK
10.342419083333333,37,0x2B,0x1E,Read,ACK
Maybe it's okay, or maybe it's some analyzer connection issue.

Could you record again this "win boot 1 finger drag" sequence one or two more times for comparison?

Aside from that the Win 10 driver, seems to use only one non-standard command sequence:
05 00 3D 03 ... - SET REPORT - Feature Report Type, Report ID: 13 (0xd)
Hopefully, these might be the key commands to switch device to MultiTouch mode... All the other commands are pretty standard, like these:
01 00 - READ HID DESCRIPTOR
05 00 00 08 - POWER ON
05 00 00 01 - RESET
02 00 - READ REPORT DESCRIPTOR

One another unfortunate possibility is, if Windows 10 uses completely different connection to the device, not the one used for HID protocol, to switch the device to MultiTouch mode. How do you think is this possible? Are you listening on all the info wires to the device?

Thanks,
Victor
Comment 70 Victor Vlasenko 2016-11-14 15:35:21 UTC
(In reply to ain from comment #65)
@ain

It would be great if you could boot into Linux first, then attach logic analyzer and reboot and wait until Windows boots, then do two finger touch and upload CSV. This scenario should produce the most complete init sequence, because Windows might switch TouchPad to MultiTouch mode only if it is not in this mode already, so booting into Linux first, guarantees that the device is not in MultiTouch mode and Windows has to fully init it.

Makes sense?
Victor
Comment 71 Victor Vlasenko 2016-11-14 15:54:09 UTC
(In reply to ain from comment #65)
@ain

Nevermind. I have succeeded to put the device into MultiTouch mode, hurray!!!!
This doesn't mean we have the driver. We just have all the pieces now to write the driver!

The code to put the device into multi-touch mode will be here, in couple of hours:
https://github.com/vlasenko/zenbook-touchpad-i2c

@Ain Thank you very much for your sniffing work. This was of enormous help!

Regards,
Victor
Comment 72 ain 2016-11-14 16:22:23 UTC
@ Victor Vlasenko

This turned out great. Thanks.
My sniffing setup had a ground issue. I figured it out already and uploaded more sniffed data.
When the screen got redrawn or keyboard got pressed there where quit a few naks.
Comment 73 Victor Vlasenko 2016-11-14 16:29:24 UTC
Its okay. I'm 90% sure we are fine with the data we already have and don't need anything else. We can switch the device into MultiTouch mode now. The "magic" command sequence to turn MultiTouch on is:
[0x05,0x00,0x3D,0x03,0x06,0x00,0x07,0x00,0x0D,0x00,0x03,0x01,0x00]

It is a 5 point MultiTouch device. Looks like ft_5x06 which is inside the kernel also supports 5 point FocalTech MultiTouch device. The issue though, the driver inside the kernel is not using HID, I think. Hid-multitouch uses HID and supports devices with proper HID Report Descriptor. But this device's HID Report Descriptor is a piece of shit.

Victor
Comment 74 Victor Vlasenko 2016-11-14 16:54:26 UTC
I think the good way to write Linux driver for this TouchPad would be to force driver/hid/hid-multitouch.c to work with this device by fixing device HID Report Descriptor, as it is done in most drivers located in drivers/hid/*

Victor
Comment 75 ain 2016-11-14 17:39:52 UTC
@ Victor Vlasenko

I'm unable to run your code https://github.com/vlasenko/zenbook-touchpad-i2c
http://pastebin.com/rfy44jcX
> sh: 1: scripts/run.sh: not found

Is run.sh missing or was it not generated?
Comment 76 Victor Vlasenko 2016-11-14 17:43:30 UTC
@ain

Try now, I've uploaded all the code. Use GitHub issues if you face any problem.

Thanks,
Victor
Comment 77 ain 2016-11-14 17:52:43 UTC
@ Victor Vlasenko

Working great now. Love it.

Thanks
Comment 78 Urko Masse 2016-11-15 08:57:02 UTC
@ain and @Victor Vlasenko:
Thank you guys for all your work!!
I have more than 30 Asus E205HA at my school, some with Elan touchpads, but a lot of them with these Focaltech, and I really want to run Linux on them.
Let me know if you get to the stage where you need more testers!
Comment 79 Victor Vlasenko 2016-11-15 09:10:17 UTC
Sure @Urko Masse, thank you for encouragement!

At this stage we know how to get MultiTouch packets from the device and know that this is 5 point MultiTouch TouchPad. 

This TouchPad is produced by ASUS, it has FocalTech FTE5436 hardware and has ASUS firmware that implements Microsoft HID over I2C protocol with ASUS proprietary extensions. It does not implement Microsoft MultiTouch for HID protocol though. So we have to use ASUS proprietary HID protocol extensions to switch device into MultiTouch mode, which we have done already, thanks to @ain great sniffing work. 

I think we are close to having the driver, but it takes some more time to teach hid-multitouch to understand meaning of MultiTouch packets of this device.

Stay tuned :)

Regards,
Victor

(In reply to Urko Masse from comment #78)
> @ain and @Victor Vlasenko:
> Thank you guys for all your work!!
> I have more than 30 Asus E205HA at my school, some with Elan touchpads, but
> a lot of them with these Focaltech, and I really want to run Linux on them.
> Let me know if you get to the stage where you need more testers!
Comment 80 redmcg 2016-11-15 09:36:40 UTC
Yes - thank-you very much @Victor Vlasenko and @ain!

Using your traces and the tools you provided I was able to put together a proof of concept user-space driver. You can find it here:
https://github.com/redmcg/FTE1001

I believe the format of the 0x5d INPUT report (which is used once the device is in multi-touch mode) is as follows:
Byte 0, bits 7-3 - Each bit represents the presence of an individual contact (bit 3 for the first contact, then bit 4 and so on)
Byte 0, bit 0    - Is the button pressed

So five contacts are available. A new contact can be recognised by a switch in value from 0 to 1. And the end of the contact can be recognised by a switch from 1 to 0.

Each contact has five bytes of information.
Byte 0, bits 7-4 - The most significant part of ABS_X
Byte 0, bits 3-0 - The most significant part of ABS_Y
Byte 1           - The least significant part of ABS_X
Byte 2           - The least significant part of ABS_Y
Byte 3, bits 7   - Type of contact!? 0 - Touch, 1 - Palm?
Byte 3, bits 6-4 - Width of the touch? (all ones if Palm)
Byte 3, bits 3-0 - All ones if Palm - otherwise zero?
Byte 4, bits 7   - Type of contact!? 0 - Touch, 1 - Palm?
Byte 4, bits 6-0 - Proximity?

I'm not 100% about byte 3 and 4 - I'll need to keep playing. These are not currently used in the proof of concept driver.

The location of the contact information is in the left most bytes. So the first contact is in the first five, the second contact in the next five and so on.

If the first contact is lifted before the second, the bitmap at the beginning of the report will indicate as much - and the first five bytes will now represent the (continuing) second contact.
Comment 81 Victor Vlasenko 2016-11-15 09:50:38 UTC
@redmcg, wow that was FAST!

Thank you very much! Your userspace driver is working for me, I can finally use scroll on my TouchPad.

Victor
Comment 82 u.r.qoou 2016-11-15 10:08:09 UTC
@redmcg, Thanks!

scrolling works (with hidraw2), palm detection doesn't yet.
God I love to see the community in action.
Comment 83 singerng 2016-11-15 15:03:36 UTC
Created attachment 244661 [details]
attachment-11073-0.html

Scrolling works with hidraw0 for me, this is great!

Noah Singer

On Tue, Nov 15, 2016 at 5:08 AM, <bugzilla-daemon@bugzilla.kernel.org>
wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=120181
>
> --- Comment #82 from u.r.qoou@gmail.com ---
> @redmcg, Thanks!
>
> scrolling works (with hidraw2), palm detection doesn't yet.
> God I love to see the community in action.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>
Comment 84 nvsl 2016-11-15 15:11:45 UTC
It does not work well for me :/
Comment 85 nvsl 2016-11-15 15:14:52 UTC
(In reply to nvsl from comment #84)
> It does not work well for me :/

In fact multitouch seems to be activated anyway, even if the result is quite weird :)

Great job guys
Comment 86 Benjamin Tissoires 2016-11-15 15:47:52 UTC
Just a quick note (as the hid-multitouch maintainer).
This device won't fit into hid-multitouch because of its protocol (explained in comment #80) is not compatible.

So I suggest to start a new driver on the basis of hid-magicmouse.c. This device is close enough to what you want to achieve here (send a feature request during probe, change the input device node and parse the raw events).

You will need to remove all of the oddities of the magicmouse driver: all the module parameters, and the hid_register_report() calls (unless the used multitouch report is not declared in the DSDT).

Anyway, thanks for the hard work and congrats on finding the magic packet!
Comment 87 Victor Vlasenko 2016-11-15 16:12:14 UTC
Hi Benjamin,

Thank you for your help and showing us the right road :)

Victor
Comment 88 serguitus 2016-11-15 16:19:44 UTC
You guys rock!!!!
I would love to be right now on your side to see U in action
I'm relatively new to linux but have done some hardware drivers before (but having docs on my hands :D) I will try to test in my K501UW to post results.
I think that having some sort of training with you could benefit the community as more people would be able to contribute actively (I would be the first) Have any suggestions on how to get info?
Thanks for the great job, you, oh real masters :-)
Comment 89 Victor Vlasenko 2016-11-16 08:20:50 UTC
Hi Guys,

I have put a boilerplate for DKMS ASUS FTE* TouchPad driver here:
https://github.com/vlasenko/hid-asus-fte-dkms

For now, it just has magic mouse driver code and compiles itself as hid-asus-fte kernel module. The idea is to write kernel driver as DKMS module, test it and then submit this code into main Linux kernel tree.

I'm going to port great @redmcg userspace driver code into this repository. 

If anyone wants to help me with this, Pull Requests are very welcome! I will let you know, when @redmcg code will be ported there. 

Thanks,
Victor
Comment 90 redmcg 2016-11-16 08:28:40 UTC
Looks good Victor. I'm currently in the process of porting the userspace driver myself. (I think) I am almost done. I'll send you a pull request once it's ready.
Comment 91 Victor Vlasenko 2016-11-16 08:30:24 UTC
Oh, cool! Awesome work @redmcg! 

Thanks,
Victor
Comment 92 Victor Vlasenko 2016-11-16 20:46:53 UTC
Hi Guys,

Here we go, Brendan McGrath (@redmcg) keeps surprising us again. He truly rocks several past days. Today he has ported his userspace driver to kernel space. I've added couple minor fixes too, with resuming from sleep and enabling driver on boot.

So, the DKMS driver is available now for early beta-testers. You can download and install it from source code here:
https://github.com/vlasenko/hid-asus-fte-dkms

Please keep in mind that this is still work in progress. But the input about driver issues would be very helpful at this stage. Please use GitHub issue tracker of the project to report found bugs.

Regards,
Victor
Comment 93 John Doe 2016-11-16 21:07:23 UTC
Thank you Victor, thank you Brendan, and everybody who helped!

I installed the driver on my Asus X540SA, Xubuntu 16.4,  kernel v. 4.8.1. It seems to work perfectly for now. I will report any problems or bugs I may find.
Comment 94 Victor Vlasenko 2016-11-16 21:19:23 UTC
@ain We would like to credit you in the driver source code for your awesome sniffing work, which enabled us to do the rest. Could you send pull request please with your details? Because all that I see about you is ain101 :)

Thanks,
Victor
Comment 95 Szőgyényi Gábor 2016-11-16 21:31:12 UTC
Question:
Why are we implement a touchpad handling module in the kernel? 
An user-space driver for a touchpad why isn't enough?

Less code --> less bug
Less code in the kernel --> less bug in the kernel
Comment 96 Victor Vlasenko 2016-11-16 21:35:38 UTC
@Szőgyényi Gábor 

Because we want to have the driver working out of the box with future Linux Kernel versions. And the TouchPad is the thing you expect to work with full capabilities out of the box even during Linux installation. If it will work without scroll during installation it will be not nice. 

Regards,
Victor
Comment 97 Miku Laitinen 2016-11-17 12:11:59 UTC
Thank you so much Victor, Brendan and others! The DKMS driver works amazingly well.

My setup: Asus Zenbook Pro UX501VW(-FJ044T), elementary OS 0.4 Loki, kernel 4.4.0-47.
Comment 98 cjrao 2016-11-17 14:37:53 UTC
Thank you Victor and Brendhan and the whole team who supported this.. 

I am new to compiling drivers on my laptop.. can some one please point me to per-requisites to enable me compile this driver.

I am running kubuntu with kernel image 4.8.3

Thank you,
Jitendra.
Comment 99 John Doe 2016-11-17 15:00:09 UTC
I think a "sudo apt install build-essential" is the only necessary prerequisite. After that, just follow the instructions on the project's github page.
Comment 100 nvsl 2016-11-17 16:43:36 UTC
It still does not work for me. I am thinking about a conflict between modules. Some of you have an idea about how to fix that and making this file working for me?
Here my lsmod: 

lsmod 
Module                  Size  Used by
rfcomm                 55936  12
bnep                   13597  2
hid_generic             1385  0
hid_asus_fte            3319  0
btusb                  32441  0
btrtl                   4832  1 btusb
i2c_designware_platform     4674  0
i2c_designware_core     8582  1 i2c_designware_platform
asus_nb_wmi            13264  0
asus_wmi               17456  1 asus_nb_wmi
mxm_wmi                 1571  0
iwlmvm                252163  0
nvidia_drm             36977  0
nvidia_modeset        754552  1 nvidia_drm
nvidia              11800821  1 nvidia_modeset
iwlwifi               176315  1 iwlmvm
x86_pkg_temp_thermal     7735  0
serio_raw               5041  0
i2c_i801               18922  0
i2c_smbus               3617  1 i2c_i801
intel_lpss_pci          4622  0
processor_thermal_device     6122  0
intel_soc_dts_iosf      4926  1 processor_thermal_device
elan_i2c               22413  0
i2c_hid                11884  0
int3403_thermal         2536  0
wmi                     6996  2 asus_wmi,mxm_wmi
pinctrl_sunrisepoint    15059  0
pinctrl_intel          10374  1 pinctrl_sunrisepoint
intel_lpss_acpi         2449  0
int3402_thermal         1720  0
intel_lpss              4829  2 intel_lpss_pci,intel_lpss_acpi
int3400_thermal         4070  0
int340x_thermal_zone     3204  3 int3402_thermal,int3403_thermal,processor_thermal_device
acpi_thermal_rel        4330  1 int3400_thermal
efivarfs                5351  1

I don't use dkms because I compiles my own kernel( Gentoo dist).
I've followed the steps defined into the github:
1) rmmod hid_asus_fte i2c_hid hid_generic
2) insmod src/hid-asus-fte.ko 
3) modprobe i2c_hid
Comment 101 redmcg 2016-11-18 00:22:00 UTC
@nvsl I can see you are missing the 'hid' module. So try running modprobe 'hid' between your steps 1 and 2. But if you continue to have issues please raise an issue at the GitHub repository:
https://github.com/vlasenko/hid-asus-fte-dkms
Comment 102 cjrao 2016-11-18 00:30:48 UTC
Cool was able to install and its working great.. great job. Thank you all for your efforts.

My setup Kubuntu 16.04 kernel 4.8.3..

--Jitendra.
Comment 103 Chris Robinson 2016-11-18 08:35:25 UTC
Hi,

Just want to add my thanks as someone without much in the way of programming skills. I've been hoping for a fix for this for a while.

I've tested on my Asus X540S running Linux Mint 17.3 with KDE with a build from 23.00 GMT on 17th November. What I've found is that the touchpad works fine from boot for a while and the multitouch features work as expected. At some point though, the pointer stops responding/moving although I can still scroll a page up and down using the touchpad and use the buttons to click.
If I then switch to a console (e.g. ctrl-alt-f7) and then back (ctrl-alt-f8) the touchpad functionality is fully restored until the next time it stops responding.

That's still preferable to the mouse pointer mode we had before but I'm sure somebody will want to look into that. I'm happy to do more testing. If I'm doing something wrong please point it out.

thanks,
Chris
Comment 104 Victor Vlasenko 2016-11-18 08:37:48 UTC
Hi Chris,

Please submit your issue here:
https://github.com/vlasenko/hid-asus-fte-dkms/issues

Thanks,
Victor
Comment 105 david jeanneteau 2016-11-20 23:13:23 UTC
Hi,

Victor's driver solved the touchpad issues on my asus r558u laptop.

Thanks ;)
Comment 106 Victor Vlasenko 2016-11-21 06:29:10 UTC
@david jeanneteau,

The driver has been written by Brendan McGrath.

Frederik Wenigwieser did the ground work of sniffing Windows 7 driver communication with TouchPad and opened the possibility to writing the driver.

I was working on decoding protocol data published by Frederik and finding magic packet which switches TouchPad into mutli touch mode. I was not aware that Brendan is writing userspace driver at the same time. 

Regards,
Victor
Comment 107 david jeanneteau 2016-11-21 16:36:51 UTC
Ok, thanks to all, though ;)
Comment 108 Mario 2016-11-23 20:02:04 UTC
Solved my touchpad problems on ASUS ZenBook UX305UA.

Thanks Victor.
Comment 109 Benjamin Tissoires 2016-11-23 20:45:31 UTC
Thinking about this a little bit more. It looks like the currently upstream driver elan_i2c.ko should drive this touchpad (same activation sequence and same protocol from what I can guess).

Can someone test if binding FTE1001 to elan_i2c instead of i2c_hid makes the touchpad happy?

If so, we really should start thinking at how this should be properly handled.
Comment 110 redmcg 2016-11-23 22:23:55 UTC
I tried the following:
# echo i2c-FTE1001:00 > /sys/bus/i2c/drivers/i2c_hid/unbind
# echo i2c-FTE1001:00 > /sys/bus/i2c/drivers/elan_i2c/bind
bash: line 0: echo: write error: No such device

But I figured this was because 'FTE1001' wasn't in elan_acpi_id:

static const struct acpi_device_id elan_acpi_id[] = {
        { "ELAN0000", 0 },
        { "ELAN0100", 0 },
        { "ELAN0600", 0 },
        { "ELAN1000", 0 },
        { }
};

So I added it and tried binding again. I got a core dump. Here's the top part of the stack trace:
[  298.346985] Call Trace:
[  298.347032]  [<ffffffff81489690>] ? acpi_pm_device_sleep_state+0x137/0x137
[  298.347134]  [<ffffffff8148a2ad>] ? acpi_add_pm_notifier+0xd0/0xdc
[  298.347224]  [<ffffffff81489a4c>] ? acpi_device_wakeup+0x84/0x8c
[  298.347316]  [<ffffffffc02102d0>] ? elan_sysfs_update_fw+0x400/0x400 [elan_i2c]
[  298.347422]  [<ffffffff81685a40>] i2c_device_probe+0x100/0x1b0
...

So I tried removing elan_sysfs_update_fw (just in case that was the only problem) but it core dumped again:
[  821.125594]  [<ffffffff81489690>] ? acpi_pm_device_sleep_state+0x137/0x137
[  821.125679]  [<ffffffff8148a2ad>] ? acpi_add_pm_notifier+0xd0/0xdc
[  821.125753]  [<ffffffff81489a4c>] ? acpi_device_wakeup+0x84/0x8c
[  821.125829]  [<ffffffffc01f8c70>] ? elan_remove_sysfs_groups+0x20/0x20 [elan_i2c]
[  821.125920]  [<ffffffff81685a40>] i2c_device_probe+0x100/0x1b0
...


I didn't really understand that one. So I though I'd try looking at the code instead.

It looks like the FTE1001 device has an additional HID overlay. For example - to enable multitouch - the elan_i2c driver sends the byte sequence 0x00 0x03 0x01 0x00 directly via i2c_transfer. Whilst our driver sends the same sequence as a SET FEATURE of REPORT ID 0x0d.

I also noticed the data expected in elan_report_contact is different to what our driver expects. Only the first byte (which defines the number of contacts) and the first three bytes of each contact (which defines the x and y coordinates) are the same. The elan_report_contact also expects two extra bytes (which includes HOVER_INFO - something we don't have).
Comment 111 Benjamin Tissoires 2016-11-24 09:56:01 UTC
Thanks for the tests. Indeed, you are right, elan_i2c won't work. It was still worth a shot because ELAN0600 are both i2c-hid and elan_i2c compatible.

Hardware makers will not stop surprising me.
Comment 112 Victor Vlasenko 2016-11-24 10:13:31 UTC
@Benjamin while you are here, a question. One of the biggest issues of our DKMS driver is that we cannot find the right way to load our driver reliably for device instead of hid-generic at boot. 

When we will submit the driver code to LKML we are going to patch hid-core.c and add our device id to hid_have_special_driver. This has one drawback though, if our driver will not be compiled, hid-generic won't handle the device too, so user will be left without device support at all in this scenario?

Right now in DKMS driver we are trying to address this problem by having:
MODULE_ALIAS("acpi*:FTE1*:*");

This seems to be not reliable solution, though for DKMS driver.

Do you know some reliable solution for DKMS driver to tell the kernel that DKMS driver should be used instead of hid-generic for the specific device?

The relevant discussion is also here:
https://github.com/vlasenko/hid-asus-dkms/issues/16

Thank you,
Victor
Comment 113 Benjamin Tissoires 2016-11-24 10:29:47 UTC
(In reply to Victor Vlasenko from comment #112)
> @Benjamin while you are here, a question. One of the biggest issues of our
> DKMS driver is that we cannot find the right way to load our driver reliably
> for device instead of hid-generic at boot. 
> 
> When we will submit the driver code to LKML we are going to patch hid-core.c
> and add our device id to hid_have_special_driver. This has one drawback
> though, if our driver will not be compiled, hid-generic won't handle the
> device too, so user will be left without device support at all in this
> scenario?

Yes, and that's the case now for most drivers in HID. We expect distributions to be smart enough and compile all those modules. If they are not here, complain to the distribution :)

Some drivers have "#ifdef CONFIG_*" in hid-core.c, but I dislike that. To switch to the correct driver, users need to recompile the kernel, and that's not something we want to ask users.

> 
> Right now in DKMS driver we are trying to address this problem by having:
> MODULE_ALIAS("acpi*:FTE1*:*");
> 
> This seems to be not reliable solution, though for DKMS driver.

I must say, that's clever. This way, you have a chance to load this driver before hid-generic, and so you have the chance of being in the list of available drivers before hid-generic :)

But it's not reliable :(

> 
> Do you know some reliable solution for DKMS driver to tell the kernel that
> DKMS driver should be used instead of hid-generic for the specific device?

I used to have this issue in the past for hid-multitouch. The solution was to use a udev rule. See https://github.com/bentiss/hid-multitouch/blob/master/install.sh
You'll need to adapt the script to unbind from hid-generic, but that's the only way I can think of (without touching the current kernel).

> 
> The relevant discussion is also here:
> https://github.com/vlasenko/hid-asus-dkms/issues/16

OK, I'll add my 2 cents there as well.
Comment 114 david jeanneteau 2016-11-26 10:02:25 UTC
I'd like to let you a new issue on this driver:
when my laptop wake up after being in sleep mode, the touchpad is off: it don't moves the mouse cursor.

I have to disable and re-enable it (fn+F9, on my asus laptop) to make ti work again.

Am i the onlyone with this problem ?

Regards ?
Comment 115 david jeanneteau 2016-11-26 10:03:48 UTC
Just to let you know: i use the dkms driver

(In reply to david jeanneteau from comment #114)
> I'd like to let you a new issue on this driver:
> when my laptop wake up after being in sleep mode, the touchpad is off: it
> don't moves the mouse cursor.
> 
> I have to disable and re-enable it (fn+F9, on my asus laptop) to make ti
> work again.
> 
> Am i the onlyone with this problem ?
> 
> Regards ?
Comment 116 Victor Vlasenko 2016-11-26 10:10:48 UTC
@david jeanneteau

As far as I know you are the first who is having this problem.

Please report your issue to GitHub page of the DKMS driver and attach dmesg output when this happens. Then we will be able to followup on your problem there in the separate thread:
https://github.com/vlasenko/hid-asus-dkms

Victor

(In reply to david jeanneteau from comment #115)
> Just to let you know: i use the dkms driver
> 
> (In reply to david jeanneteau from comment #114)
> > I'd like to let you a new issue on this driver:
> > when my laptop wake up after being in sleep mode, the touchpad is off: it
> > don't moves the mouse cursor.
> > 
> > I have to disable and re-enable it (fn+F9, on my asus laptop) to make ti
> > work again.
> > 
> > Am i the onlyone with this problem ?
> > 
> > Regards ?
Comment 117 david jeanneteau 2016-11-26 14:38:34 UTC
Caramba, encore raté !

I just tried twice, and the issue didn't occured any more.
I'm afraid of a random problem ...

I let you know in another thread if it happens again.

Regards,
David
Comment 118 u.r.qoou 2016-11-30 17:40:40 UTC
With anyone with problems disabling secure boot, you can sign the driver yourself, using this (simple) tutorial:
http://askubuntu.com/questions/760671/could-not-load-vboxdrv-after-upgrade-to-ubuntu-16-04-and-i-want-to-keep-secur

Just make sure you are signing the right driver, which for me sits in:
/lib/modules/4.8.0-28-generic/updates/dkms/hid-asus-fte.ko

Victor, can you add this to the github page?
Comment 119 Dmitry Tunin 2016-12-08 22:01:25 UTC
See https://github.com/vlasenko/hid-asus-dkms for a driver.
Comment 120 nvsl 2016-12-17 20:29:24 UTC
*** Bug 178271 has been marked as a duplicate of this bug. ***
Comment 121 Adrian Miranda 2016-12-27 06:23:21 UTC
Thank you all guys!

I tried the driver and it worked perfectly. I've been following this thread for quite a while since I purchased my new laptop a few months back. I'm using LM 18 4.4.0-53 on ASUS K401UQ. I created an account just to say thank you. You guys are awesome. :)
Comment 122 botinada 2016-12-30 00:02:57 UTC
Hi

After installing driver from @Victor Vlasenko:

DKMS: install completed.
Rebinding to hid-asus
sh: echo: I/O error
sh: echo: I/O error


Touchpad not working

I have an ASUS X5556uj and ubuntu 16.04 LTS
Comment 123 redmcg 2016-12-30 07:24:21 UTC
@botinada Can you please raise an issue at the GitHub repository:
https://github.com/vlasenko/hid-asus-dkms

You'll want to include the output of dmesg.
Comment 124 botinada 2016-12-30 08:14:21 UTC
How do i have to do this?

I'm a noob user of GNU-Linux
Comment 125 pete 2017-01-13 13:41:40 UTC
Works for me on ASUS UX501VW FHD model!
When can we expect this in the linux kernel? :)
Comment 126 Victor Vlasenko 2017-01-13 13:48:08 UTC
Brendan McGrath (@redmcg) has submitted patches to linux kernel mailing list, these patches have been included into Linux Kernel 4.10 release candidates already.
Comment 127 freefal67 2017-02-20 04:52:53 UTC
Linux 4.10 was just released and this fix is in it. It's been amazing to experience the issue, watch people diagnose the problem and reverse engineer a solution, and then see it integrated into the kernel. Thanks to everyone that made it happen.
Comment 128 freefal67 2017-02-20 04:53:34 UTC
Linux 4.10 was just released and this fix is in it. It's been amazing to experience the issue, watch people diagnose the problem and reverse engineer a solution, and then see it integrated into the kernel. Thanks to everyone that made it happen.
Comment 129 Szőgyényi Gábor 2017-03-06 20:43:28 UTC
Can we close this bug?
Comment 130 Alexander Mishurov 2017-07-02 18:09:30 UTC
The same problem here with ELAN1200, it's handled by hid_multitouch driver which doesn't report ABS_PRESSURE data. As far as I can understand, the touchpad doesn't work in a fully-fledged mode. Without the width and pressure data userspace drivers badly handle two finger taps and fire random right clicks during two finger scrolling.

dmesg output:
[ 4865.849823] input: ELAN1200:00 04F3:3022 Touchpad as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/i2c-ELAN1200:00/0018:04F3:3022.0003/input/input18
[ 4865.850396] hid-multitouch 0018:04F3:3022.0003: input,hidraw0: I2C HID v1.00 Mouse [ELAN1200:00 04F3:3022] on i2c-ELAN1200:00
[ 4866.119535] i2c_hid i2c-ELAN1200:00: i2c_hid_get_input: incomplete report (16/16466)

I tried merely to insert "ELAN1200" to elan_acpi_id in elan_i2c_core.c and rebind the device to the elan_i2c module, it didn't help, the dmesg output is:

elan_i2c i2c-ELAN1200:00: invalid report id data (2)
elan_i2c i2c-ELAN1200:00: invalid report id data (4)
elan_i2c i2c-ELAN1200:00: invalid report id data (0)

I wrote to ASUS consumer technical support about the I2C commands sequence to turn on the touchpad mode.
Comment 131 Victor Vlasenko 2017-07-02 18:20:53 UTC
@Alexander Mishurov If you plan to work on the kernel driver for this TouchPad hardware you might find Brendan McGrath userspace driver for FTE1001 TouchPad helpful as a starting point for your driver:
https://github.com/redmcg/FTE1001

Regards,
Victor
Comment 132 Victor Vlasenko 2017-07-02 18:25:13 UTC
@Alexander Mishurov ELAN1200 Touch Pad might actually work in a fully-fledged mode, but kernel driver cannot correctly decode reports from the Touch Pad. So you can launch Brendan's userspace driver and try to migrate current kernel driver code to this userspace driver and then try to decode reports from ELAN1200
Comment 133 Alexander Mishurov 2017-07-02 21:43:13 UTC
(In reply to Victor Vlasenko from comment #132)
> @Alexander Mishurov ELAN1200 Touch Pad might actually work in a
> fully-fledged mode
It seems so, these are reports from hid-recorder after two taps. During playing with hid-recorder I found that some bytes are differ only when I change the area of a touch and the values keep about the same regardless to a location of a touch.

E: 21.972110 14 04 03 07 0b d4 00 8d d7 01 00 24 55 00 00
E: 21.972800 14 04 41 f5 06 ac 06 2b 6e 00 00 32 5a 00 00
E: 21.973768 14 04 01 07 0b d4 00 b5 dc 01 00 24 55 00 00

E: 26.408097 14 04 03 40 0b 8b 01 2f 85 01 00 0a 44 00 00
E: 26.408807 14 04 41 f5 06 ac 06 2b 6e 00 00 32 5a 00 00
E: 26.410287 14 04 01 40 0b 8b 01 7b 89 01 00 0a 44 00 00

FTE1001's writes to /hid/raw0 are making the touchpad irresponsible, without writing I can register some activity by changing the report id from "5d" to "04". The idea of using protocol information from the kernel driver as a start looks reasonable.
Comment 134 Alexander Mishurov 2017-07-17 19:45:31 UTC
I've deciphered ELAN1200 hid data, it seems that the touchpad doesn't report pressure but reports width and height, this is how the data is being handled:

x = (data[1] << 8) | data[0];
y = (data[3] << 8) | data[2];

width = data[9] & 0x0f;
height = data[9] >> 4;

int toolType = (data[7] & 0x0f) > 10 ? MT_TOOL_FINGER : MT_TOOL_PALM;

int count = data[6];

input_report_key(input, BTN_LEFT, data[7] & 0x01);

It also reports an event with hex 41, which can be confused with a release event of a 4th slot. I've made userspace and kernel drivers, it became a bit more accurate with the width data and filtering the redundant event but it is still not good enough.

Therefore I have another question, I'd examined the elan_i2c driver with added my touchpad name to the acpi list and it turned out that it was making the initialisation process quite correctly:

elan_i2c i2c-ELAN1200:00: Elan Touchpad Extra Information:
Max ABS X,Y:   3200,2198
Width X,Y:   160,157
Resolution X,Y:   31,31 (dots/mm)
ic type: 0xe
info pattern: 0x0

The output is correct.

Moreover, during the initialisation it reads some variable:
error = data->ops->get_pressure_adjustment(data->client,
				 &data->pressure_adjustment);

The variable "pressure_adjustment" has the value 25 and that makes sense I suspect.

It has problems with getting reports from i2c though and a corresponding input device doesn't report any activity.

So, the question is: can it be, that i2c-hid isn't getting all data from the touchpad and some changes can be made to elan_i2c in order to get pressure?
Comment 135 redmcg 2017-07-24 00:55:12 UTC
@Alexander Mishurov

Given this conversation is no longer related to the device in the initial bug report - it might be more appropriate to create a new bug for your device.

But to answer your question:
It is likely the i2c-hid driver is reporting everything that is being sent by your multi-touch device and that the device is not sending pressure data. No one but the manufacturer can really answer questions about the capability of the device (i.e. can the device be configured to send pressure data).

If you can't obtain more information about your device - your best bet is to make it work with what you know. You need to interpret what the device is sending in to something that the kernel multi-touch input API can work with. That API is documented here:
https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt

Note that under ABS_MT_PRESSURE it states:
> The pressure, in arbitrary units, on the contact area. May be used instead of
> TOUCH and WIDTH for pressure-based devices or any device with a spatial
> signal intensity distribution.

So if you are receiving TOUCH and WIDTH information - pressure data is not needed.

I recommend reading the section under 'Event Usage' to understand what the TOUCH and WIDTH parameters should describe.
Comment 136 Alexander Mishurov 2017-07-24 03:47:49 UTC
@redmcg

I agree about the bug. Just a little remark.

I've already tested reports from the modified elan_i2c, reports are the same. And it seems that they are made according to Microsoft's specification:
https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-precision-touchpad-required-hid-top-level-collections
"Single finger hybrid reporting mode". There're no requirement on pressure.

Furthermore, I'd tried my old laptop with a Synaptics touchpad. The touchpad in i2c mode don't report pressure and width either but nonetheless works correctly. It seems that problem is somewhere else. I'm working on it.

The repo:
https://github.com/mishurov/linux_elan1200_touchpad
Comment 137 Gustavo Garcia 2018-08-07 13:56:35 UTC
(In reply to Alexander Mishurov from comment #136)
> @redmcg
> 
> I agree about the bug. Just a little remark.
> 
> I've already tested reports from the modified elan_i2c, reports are the
> same. And it seems that they are made according to Microsoft's specification:
> https://docs.microsoft.com/en-us/windows-hardware/design/component-
> guidelines/windows-precision-touchpad-required-hid-top-level-collections
> "Single finger hybrid reporting mode". There're no requirement on pressure.
> 
> Furthermore, I'd tried my old laptop with a Synaptics touchpad. The touchpad
> in i2c mode don't report pressure and width either but nonetheless works
> correctly. It seems that problem is somewhere else. I'm working on it.
> 
> The repo:
> https://github.com/mishurov/linux_elan1200_touchpad

I'm following multiple threads on elan1200 touchpads. I've found out on asus forums that the problem may be related to pinctl, they applied some pinctl patches on kernel 4.18. And they pointed this specific bug discussion and patches.

They say it fixes, but i didn't had time to compile and test. But it may show some new possibilities

https://bugzilla.kernel.org/show_bug.cgi?id=199911#c68

Note You need to log in before you can comment on or make changes to this bug.