Description of problem:
On the new Asus Transformer Book Trio TX201LA Elantech touchpad works only as a mouse. Synaptics / multitouch features are not detected.
Version-Release number of selected component (if applicable):
Kernel version is 3.12.6-300.fc20.x86_64
Steps to Reproduce:
Touchpad has only basic point, right-click, left-click functions and does not show up as a configurable multitouch device
Touchpad should be recognized as multitouch device w
--dmesg output shows:
psmouse serio4: elantech: unknown hardware version, aborting...
input: PS/2 Elantech Touchpad as /devices/platform/i8042/serio4/input/input61
--xinput list-props shows:
xinput list-props 'PS/2 Elantech Touchpad'
Device 'PS/2 Elantech Touchpad':
Device Enabled (132): 1
Coordinate Transformation Matrix (134): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Device Accel Profile (258): 0
Device Accel Constant Deceleration (259): 1.000000
Device Accel Adaptive Deceleration (260): 1.000000
Device Accel Velocity Scaling (261): 10.000000
Device Product ID (250): 2, 1
Device Node (251): "/dev/input/event8"
Evdev Axis Inversion (262): 0, 0
Evdev Axes Swap (264): 0
Axis Labels (265): "Rel X" (142), "Rel Y" (143)
Button Labels (266): "Button Left" (135), "Button Middle" (136), "Button Right" (137), "Button Wheel Up" (138), "Button Wheel Down" (139)
Evdev Middle Button Emulation (267): 0
Evdev Middle Button Timeout (268): 50
Evdev Third Button Emulation (269): 0
Evdev Third Button Emulation Timeout (270): 1000
Evdev Third Button Emulation Button (271): 3
Evdev Third Button Emulation Threshold (272): 20
Evdev Wheel Emulation (273): 0
Evdev Wheel Emulation Axes (274): 0, 0, 4, 5
Evdev Wheel Emulation Inertia (275): 10
Evdev Wheel Emulation Timeout (276): 200
Evdev Wheel Emulation Button (277): 4
Evdev Drag Lock Buttons (278): 0
--cat /proc/bus/input/devices shows
I: Bus=0011 Vendor=0002 Product=0001 Version=0000
N: Name="PS/2 Elantech Touchpad"
H: Handlers=mouse1 event8
B: KEY=70000 0 0 0 0
Can you attach the full dmesg output please?
3.12.6 contains a backport of a patch in 3.13 to add support for newer Elantech devices, so you device must be even newer than that.
Created attachment 849573 [details]
Full Dmesg output
I have attached the full dmesg output
Just wondering if there is any new insight on this problem. I have tried out the vanilla kernel 3.13 at the Kernel Vanilla Repositories for Fedora with no success so I reverted back to the latest kernel in stable repo. After looking around and rummaging through the windows driver I haven't been able to discover anything of worth.
It just occured to me that since this touchpad worked on android (ASUS TX201LA is a hybrid win8/android transformer), there had to be source code for the android kernel. Short story: I found the source code on ASUS's website (http://dlcdnet.asus.com/pub/ASUS/nb/TX201LA/Android_TX201LA_Kernel_Code_4_2.zip) and was able to locate the necessary files in the following directories
/drivers/input/mouse/elan_touchpad.c (note: this file differs from the elantech.c typically found in the linux kernel)
I will try compiling the drivers against my present kernel later today to see if it works.
Created attachment 862056 [details]
elan_touchpad.c from Android kernel
Some additional files from "/include/linux/" of the archive need to be copied over the source build directory such as
Compiling ended unsuccessful with lots of errors. Nevertheless, some useful information can be gathered from the elan_touchpad.c driver file (attached) such as:
#define ETP_INF_LENGTH 2
#define ETP_MAX_FINGERS 5
#define ETP_REPORT_DESC_LENGTH 148
#define ETP_REPORT_LENGTH 30
#define ETP_FINGER_DATA_OFFSET 4
#define ETP_FINGER_DATA_LEN 5
#define ETP_REPORT_ID 0x5d
#define HID_CMD_REGISTER 0x0005
#define ETP_CMD_REGISTER 0x0300
#define ETP_CTRL_REGISTER 0x0301
#define CMD_RESET 0x0100
#define CMD_WAKE_UP 0x0800
#define CMD_SLEEP 0x0801
#define CMD_ENABLE_ABS 0x0001
#define REG_DESC 0x0001
#define REG_REPORT_DESC 0x0002
#define REG_UNIQUE_ID 0x0101
#define REG_FW_VERSION 0x0102
#define REG_XY_TRACE_NUM 0x0105
#define REG_X_AXIS_MAX 0x0106
#define REG_Y_AXIS_MAX 0x0107
#define REG_RESOLUTION 0x0108
At this point, I have exhausted my non-existent skill in coding/compiling/debugging and gathering data so I will leave the rest in your capable hands and look forward to a response. Hope all the foot work thus far helps reduce the time and work required to fix the issue.
Hmm, you might want to give a try to the latest version of this kernel sent by Elan on linux-input LKML: https://patchwork.kernel.org/patch/3445601/
I will not push Dmitry to take this upstream given that it seems to be an i2c_hid device not binded to i2c_hid...
Anyway, giving a try does not cost too much :)
Thanks. I got the patch and compiled the elan_i2c.ko module against my Fedora Kernel 3.12.10-300. While the make, depmod, and modprobe commands worked flawlessly, nothing happened (not even dmesg output). I am assuming that this may be caused by the fact that the psmouse/elantech module is built into the Fedora kernel; that is, I cannot simply remove the psmouse module and insert the elan_i2c one instead. I am guessing that there may be some way to bind the device to the proper driver, but I am in way over my head and I am not quite sure what I am doing. Can you let me know if my assumptions are correct?
So I did the following
#Change bind mode to manual for the device
su -c 'echo -n "manual" /sys/bus/serio/devices/serio4/bind_mode'
# Unbind the device from psmouse driver
su -c 'echo -n "serio4" /sys/bus/serio/drivers/psmouse/unbind'
At this point mouse stops working and rightly so
# Bind device to elan_12c
su -c 'echo -n "serio4" /sys/bus/i2c/drivers/elan_i2c/bind'
Output is: write error: No such device.
I think that I understand what is going on. The tablet portion of the laptop (where Android resides) connects to the touchpad by i2c bus, but the dock portion (where linux resides) has the touchpad physically attached. Hence, linux sees it as a serio device whereas Android sees it as an i2c device. In other words, the driver that I provided earlier and the patch will not be useful for linux on the ASUS TX201LA dock portion. That driver will work only for laptops such as the ASUS TX300 and some of the VivoBooks.
This brings us back to the first post. The touchpad is detected only as a mouse on serio bus.
This issue also occurs on newer Lenovo laptops. I have a z710 that also has this in dmesg:
psmouse serio1: elantech: unknown hardware version, aborting...psmouse serio1: elantech: unknown hardware version, aborting...
It looks like there have been some recent updates to the elantech driver in Kernel 3.15 rc to add support for additional devices see
When I get the opportunity, I will try one of the vanilla rc kernels at
and see whether it fixes the issue.
Kernel 3.15-rc3 , specifically the patch  fixes the problem.
@Neil Can you try the latest mainline kernel at  and confirm that the problem is solved on your end as well?
@Benjamin Tissoires and @Josh Boyer
Is there any chace that we will see a backport of this patch for kernel 3.14.x in Fedora?
I added that patch to Fedora git for f19/f20. It will be in the next build.
kernel-3.14.5-200.fc20 has been submitted as an update for Fedora 20.
kernel-3.14.5-100.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.14.5-200.fc20'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).
Problem fixed as stated. I will get on q &a to vote later today if the kernel is not already in updates.
kernel-3.14.5-200.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.14.6-100.fc19 has been submitted as an update for Fedora 19.
kernel-3.14.7-100.fc19 has been submitted as an update for Fedora 19.
kernel-3.14.7-100.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.