I have a Gigabyte U2442 Laptop featuring an Elantech touchpad. The current Linux driver fails to initialize that touchpad properly, so it is only usable as a normal mouse without any advanced touchpad features. The output of dmesg | grep elantech: [ 5.751852] psmouse serio1: elantech: assuming hardware version 3 (with firmware version 0x450f01) [ 5.780033] psmouse serio1: elantech: Synaptics capabilities query result 0x58, 0x17, 0x0c. [ 6.016937] psmouse serio1: elantech: retrying ps2 command 0x0b (2). [ 6.721079] psmouse serio1: elantech: retrying ps2 command 0x0b (1). [ 7.425214] psmouse serio1: elantech: retrying ps2 command 0x0b (0). [ 7.929179] psmouse serio1: elantech: ps2 command 0x0b failed. [ 7.929185] psmouse serio1: elantech: failed to write register 0x10 with value 0x0b. [ 7.929187] psmouse serio1: elantech: failed to initialise registers. [ 7.929189] psmouse serio1: elantech: failed to put touchpad into absolute mode. I have not yet tried whether treating the touchpad as a different hardware version, e.g. hw_version 4 instead of the detected 3, would work. Please note that this bug affects the current kernel 3.11.0, which has the patch at https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/input/mouse/elantech.c?id=9eebed7de660c0b5ab129a9de4f89d20b60de68c applied.
I have now updated to the latest Linux 3.14 kernel. I had the hope that the recent changes to the elantech driver would fix the issue, but I still get exactly the same error output as posted above.
Hi All, A quick update on this, Philipp contacted me by email because I was one of the last people to work on the elantech driver (I worked on the clickpad detection code). A quick google found me: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1272777 Which claims that this elantech driver: http://planet76.com/drivers/elantech/psmouse-elantech-v6.tar.bz2 Actually works. So I compared that to the mainline code and send Philipp a patch to test, it seems this change fixes the touchpad on the Gigabyte U2442 : --- a/drivers/input/mouse/elantech.c +++ b/drivers/input/mouse/elantech.c @@ -831,7 +845,7 @@ static int elantech_set_absolute_mode(struct psmouse *psmou break; case 3: - etd->reg_10 = 0x0b; + etd->reg_10 = 0x03; if (elantech_write_reg(psmouse, 0x10, etd->reg_10)) rc = -1; But we don't know if that change is safe for all v3 models. Philipp can you test the patch which I'll attach here after this comment, please ? This should avoid causing regressions, while hopefully still fixing your touchpad. In the mean time I'll try to contact Elantech, as they may be able to provide a better solution. Regards, Hans
Created attachment 133261 [details] [PATCH] elantech: Fix elantech on Gigabyte U2442 (and possibly others)
Interestingly this patch fails. Output of dmesg | grep -i elantech: [ 5.428498] psmouse serio1: elantech: assuming hardware version 3 (with firmware version 0x450f01) [ 5.455524] psmouse serio1: elantech: Synaptics capabilities query result 0x58, 0x17, 0x0c. [ 5.695917] psmouse serio1: elantech: retrying ps2 command 0x0b (2). [ 6.399997] psmouse serio1: elantech: retrying ps2 command 0x0b (1). [ 7.104174] psmouse serio1: elantech: retrying ps2 command 0x0b (0). [ 7.608052] psmouse serio1: elantech: ps2 command 0x0b failed. [ 7.609885] psmouse serio1: elantech: failed to write register 0x10 with value 0x0b. [ 7.611723] psmouse serio1: elantech: rejected r10 = 0x0b, retry-ing with 0x03 [ 7.631447] psmouse serio1: elantech: retrying ps2 command 0x00 (2). [ 8.335622] psmouse serio1: elantech: retrying ps2 command 0x00 (1). [ 8.851510] psmouse serio1: elantech: retrying ps2 command 0x00 (0). [ 9.353411] psmouse serio1: elantech: ps2 command 0x00 failed. [ 9.353419] psmouse serio1: elantech: failed to write register 0x10 with value 0x03. [ 9.353423] psmouse serio1: elantech: failed to initialise registers. [ 9.353426] psmouse serio1: elantech: failed to put touchpad into absolute mode. [ 9.603004] input: PS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input9 Just to make sure I am now retrying with the patch you posted above (and not the patch you originally send me with the additional change, although those changes seemed to be totally unrelated). But maybe it could be that attempting to write a wrong value to that register causes all following writes to fail.
I can confirm now that directly setting etd->reg_10 = 0x03, as the patch in comment #2 does, works. dmesg | grep -i elantech: [ 5.607324] psmouse serio1: elantech: assuming hardware version 3 (with firmware version 0x450f01) [ 5.640143] psmouse serio1: elantech: Synaptics capabilities query result 0x58, 0x17, 0x0c. [ 5.788549] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input9 However, the patch in attachment 133261 [details] does not work and fails with the output I posted in the previous comment #4. So it really looks like once writing to reg_10 failed subsequent writes also fail. I am curious whether Elantech can provide some more insight.
Thanks for testing! I'll get back to you when I've some more info.
Philipp, Can you add the patch I'm attaching here to your kernel, and then paste the elantech probe messages of a boot with the patch here ? Also it looks like we may have to solve this with a device specific quirk, can you please run the following command and copy and paste the output here ? : sudo grep '.*' /sys/class/dmi/id/*_* Thanks, Hans
Created attachment 133991 [details] PATCH: elantech: add SAMPLE_QUERY info logging
Hans, here is the output of dmesg -linfo | grep elantech: [ 5.441357] psmouse serio1: elantech: assuming hardware version 3 (with firmware version 0x450f01) [ 5.461244] psmouse serio1: elantech: D1 03 information 0x034c85) [ 5.486731] psmouse serio1: elantech: Synaptics capabilities query result 0x58, 0x17, 0x0c. sudo grep '.*' /sys/class/dmi/id/*_* /sys/class/dmi/id/bios_date:04/25/2013 /sys/class/dmi/id/bios_vendor:American Megatrends Inc. /sys/class/dmi/id/bios_version:U2442.F30CA /sys/class/dmi/id/board_asset_tag:To be filled by O.E.M. /sys/class/dmi/id/board_name:U2442 /sys/class/dmi/id/board_serial:To be filled by O.E.M. /sys/class/dmi/id/board_vendor:GIGABYTE /sys/class/dmi/id/board_version:To be filled by O.E.M. /sys/class/dmi/id/chassis_asset_tag:To Be Filled By O.E.M. /sys/class/dmi/id/chassis_serial:To Be Filled By O.E.M. /sys/class/dmi/id/chassis_type:10 /sys/class/dmi/id/chassis_vendor:To Be Filled By O.E.M. /sys/class/dmi/id/chassis_version:To Be Filled By O.E.M. /sys/class/dmi/id/product_name:U2442 /sys/class/dmi/id/product_serial:To be filled by O.E.M. /sys/class/dmi/id/product_uuid:00020003-0004-0005-0006-000700080009 /sys/class/dmi/id/product_version:To be filled by O.E.M. /sys/class/dmi/id/sys_vendor:GIGABYTE Thanks, Philipp
Hi Philipp, It looks like we will need to go for a dmi based blacklist for now. Can you please test the patch I'm attaching here ? If you can confirm that it fixes things then I'll send it upstream. Thanks, Hans
Created attachment 134181 [details] [PATCH] elantech: Fix elantech on Gigabyte U2442
Hello Hans, thanks for all the work. I have just applied your patch and the touchpad gets initialized properly and is working fine in X with the advanced touchpad features. The code looks fine to me, too. It is a bit unfortunate we could not find a solution to detect the behavior from the device, but so far all the reports for this bug I have found were for one of the Gigabyte U2442 model variations. Just out of interest: Is it actually known, what the various bits for reg_10 mean? The current doc at https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/input/elantech.txt#n502 mentions only the meaning for bit 1, but I wonder why bit 0 and 3 get set at all. Regards, Philipp
Patch is included in Linux 3.15-rc5, see commit https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=36189cc3cd57ab0f1cd75241f93fe01de928ac06
Patch is included in the current version of the kernel in fedora (3.14.4-200.fc20.x86_64) and I confirm the touchpad works fine with scrolling and so on.
I've hit the same issue with my u2442 but the above patch didn't quite fix it for me. With the above patch I get identical behaviour to pre-patch except the error stated: failed to write register 0x10 with value 0x03 I changed the patch to set the register to 0x01 instead and this produced the desired affect. The only difference I can see between my machine and the above is the firmware version: # sudo grep '.*' /sys/class/dmi/id/*_* /sys/class/dmi/id/bios_date:08/07/2012 /sys/class/dmi/id/bios_vendor:American Megatrends Inc. /sys/class/dmi/id/bios_version:U2442.F0C /sys/class/dmi/id/board_asset_tag:To be filled by O.E.M. /sys/class/dmi/id/board_name:U2442 /sys/class/dmi/id/board_serial:To be filled by O.E.M. /sys/class/dmi/id/board_vendor:GIGABYTE /sys/class/dmi/id/board_version:To be filled by O.E.M. /sys/class/dmi/id/chassis_asset_tag:To Be Filled By O.E.M. /sys/class/dmi/id/chassis_serial:To Be Filled By O.E.M. /sys/class/dmi/id/chassis_type:10 /sys/class/dmi/id/chassis_vendor:To Be Filled By O.E.M. /sys/class/dmi/id/chassis_version:To Be Filled By O.E.M. /sys/class/dmi/id/product_name:U2442 /sys/class/dmi/id/product_serial:To be filled by O.E.M. /sys/class/dmi/id/product_uuid:00020003-0004-0005-0006-000700080009 /sys/class/dmi/id/product_version:To be filled by O.E.M. /sys/class/dmi/id/sys_vendor:GIGABYTE From the Gigabyte website it looks as though the F0X series of bioses is aimed at windows 7 while the F3X series is aimed at windows 8 (I don't have any secure boot related options for example).
Hi James, Thanks for the input. So the 0x02 / bit 1 you're moving from the value written to reg_10 stands for "enable two finger mode auto correct", although not ideal we can probably do without this in general, so the easiest fix would be to always write 0x01 instead of 0x03 on the U2442. Philipp, can you build a kernel with elantech.c modified accordingly and see if you get any adverse side-effects from doing so ? Please also test 2 finger scrolling. James and Philipp, Recently we've learned that Windows drivers seem to bind by the pnp-id of the touchpad. Maybe your 2 laptops will have 2 different pnp-ids for the touchpad. Can you *both* please run: for i in /sys/devices/pnp0/00*; do echo $i: ; cat "$i/id"; done In a shell and copy and paste the output here ? Thanks, Hans
I tested it with the 0x01 value and it works for me. I tested two finger scrolling in various applications under Gnome 3 and could not detect a difference in behavior compared to the kernel which used 0x03. Output of `for i in /sys/devices/pnp0/00*; do echo $i: ; cat "$i/id"; done`: /sys/devices/pnp0/00:00: PNP0c01 /sys/devices/pnp0/00:01: PNP0200 /sys/devices/pnp0/00:02: INT0800 /sys/devices/pnp0/00:03: PNP0103 /sys/devices/pnp0/00:04: PNP0c02 /sys/devices/pnp0/00:05: PNP0b00 /sys/devices/pnp0/00:06: INT3f0d PNP0c02 /sys/devices/pnp0/00:07: PNP0c02 /sys/devices/pnp0/00:08: PNP0c04 /sys/devices/pnp0/00:09: MSF0001 PNP0303 /sys/devices/pnp0/00:0a: ETD0a00 PNP0f13 /sys/devices/pnp0/00:0b: PNP0c02 /sys/devices/pnp0/00:0c: PNP0c01 I do not really understand that output or how to identify the pnp-id of my touchpad, but I hope it helps you.
(In reply to Philipp Wolfer from comment #17) > I do not really understand that output or how to identify the pnp-id of my > touchpad, but I hope it helps you. Thanks for the info! As for the list of pnp ids, if you look in the kernel sources file drivers/input/serio/i8042-x86ia64io.h, and search for pnp_aux_devids you will find a list of pnp-ids for the ps/2 aux (aka mouse) port there. So from your list of pnp devices, the following is the touchpad: /sys/devices/pnp0/00:0a: ETD0a00 PNP0f13 Which has 2 pnp ids, the standard PNP0f13 and ETD0a00, which seems like an elantech id to me, too bad I was hoping for a Gigabyte specificpnp-id, ie GIG0345 or some such. Still it will be interesting to see what James output for that commando is.
Hans, Unfortunately I've actually upgraded to the same BIOS/firmware as Philipp now since I was having a few problems with suspending and GFX card switching and thought that it may be related (I'm in the middle of converting over from Win7). Thus I can't test the above for you without downgrading, which probably isn't recommended. I can however concur that there seems to be no noticeable difference in the function of the touchpad between 0x01 and 0x03, and that both values now work for me with the new bios revision. James.
(In reply to James Lademann from comment #19) > Hans, > > Unfortunately I've actually upgraded to the same BIOS/firmware as Philipp > now since I was having a few problems with suspending and GFX card switching > and thought that it may be related (I'm in the middle of converting over > from Win7). Thus I can't test the above for you without downgrading, which > probably isn't recommended. Ok, then I'm just going to move forward with a patch to always inti reg-10 to 0x01 on the U2442.
Hi, I'm facing a similar issue with the Elantech touchpad in my Gigabyte P34g laptop. The problem is that occassionally the touchpad is simply not detected at bootup. I'm running Ubuntu 14.04 with kernel 3.13.0-29. This problem has been described very well on: https://bbs.archlinux.org/viewtopic.php?id=174217 I was wondering if this issue could be somehow connected to the above bug. Thanks, Anish.
Hi Anish, That seems like a different problem, since there are no messages printed at all when the detection fails, where as in the case this bug is about there is a clear error message printed. The best way to get this resolved is to send a mail about this to linux-input@vger.kernel.org, with yourself in the CC, and then hopefully someone who is more familiar with the ps2 detection code can help you further. Regards, Hans
Hi Hans, Thanks for the reply. I'll follow it up like you suggested. Thanks, Anish