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
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?
I have the same problem on ASUS X540SA (with the exact same touchpad device "FTE1001:00 0B05:0101") with kernel 4.7.0.
The same thing happens here on openSUSE Tumbleweed with Kernel 4.7.0. The touchpad is recognized as a "pointer" rather than a touchpad.
Also happens on Ubuntu 16.04, ASUS X556U (kernel 4.4.0)
And ASUS K501U, Ubuntu 16.04, kernel 4.4.0.
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?
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
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
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
Same problem with Asus K501UW, Linux Mint 18, kernel 4.4
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
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)]
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)]
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)]
Same exact issue here on Asus Zenbook ux501vw. Any better fixes than downgrading to the 4.3 kernel are very welcome.
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.
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.
I tried the same thing, along with basically every proposed solution I could find on the internet.
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
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?
@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.
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
This touchpad will not work on any Linux kernel until a new driver is made.
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.
(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 :)
(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.
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?
(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.
My ASUS TP200SA has a FTE1000:00 0B05:0101 touchpad device. This bug report probably applies to that one, too.
(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.
I can confirm this issue on ASUS VIVOBOOK R301UA-FN115T.
(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
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.
(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
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.
(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
Then sniffing PS/2 or USB, I meant, sorry for typo.
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
Victor, FYI: Looks like Dmitry Tunin is looking into this already, https://lkml.org/lkml/2016/10/17/747 -- Jitendra.
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
FWIW, asus Israel also said it's azwave: >Thank you for contacting us > >The touch pad manufacture is > >AZWAVE >MODEL: >AW-TP242
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.
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.
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.
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
Thank you Egor, I'm going to ask FocalTech for documentation as well at Monday, to show our interest. Victor
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. >
Thank you all.. me four (sent one two weeks ago) and five (another e-mail yesterday). Thank you Jitendra.
(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?
(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
Got the same problem... i've just send an email to FocalTech to ask them anything that could help us.
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...
Created attachment 243821 [details] TouchPad photo
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.
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.
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
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
(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.
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.
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
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.
// data sheets http://www.newhavendisplay.com/appnotes/datasheets/touchpanel/FT5x06_registers.pdf http://www.newhavendisplay.com/appnotes/datasheets/touchpanel/FT5x06.pdf
http://www.newhavendisplay.com/appnotes/datasheets/touchpanel/FT5x46.pdf
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)
// 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.
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.
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
I think the Asus E200HA may have this touchpad as well. At least, I get these same issues on it.
(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
(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
(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
@ 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.
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
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
@ 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?
@ain Try now, I've uploaded all the code. Use GitHub issues if you face any problem. Thanks, Victor
@ Victor Vlasenko Working great now. Love it. Thanks
@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!
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!
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.
@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
@redmcg, Thanks! scrolling works (with hidraw2), palm detection doesn't yet. God I love to see the community in action.
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. >
It does not work well for me :/
(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
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!
Hi Benjamin, Thank you for your help and showing us the right road :) Victor
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 :-)
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
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.
Oh, cool! Awesome work @redmcg! Thanks, Victor
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
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.
@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
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
@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
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.
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.
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.
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
@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
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.
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
Hi Chris, Please submit your issue here: https://github.com/vlasenko/hid-asus-fte-dkms/issues Thanks, Victor
Hi, Victor's driver solved the touchpad issues on my asus r558u laptop. Thanks ;)
@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
Ok, thanks to all, though ;)
Solved my touchpad problems on ASUS ZenBook UX305UA. Thanks Victor.
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.
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).
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.
@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
(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.
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 ?
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 ?
@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 ?
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
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?
See https://github.com/vlasenko/hid-asus-dkms for a driver.
*** Bug 178271 has been marked as a duplicate of this bug. ***
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. :)
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
@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.
How do i have to do this? I'm a noob user of GNU-Linux
Works for me on ASUS UX501VW FHD model! When can we expect this in the linux kernel? :)
Brendan McGrath (@redmcg) has submitted patches to linux kernel mailing list, these patches have been included into Linux Kernel 4.10 release candidates already.
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.
Can we close this bug?
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.
@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
@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
(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.
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?
@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.
@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
(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