Bug 81331 - Elantech touch pad stops working after shutdown
Summary: Elantech touch pad stops working after shutdown
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: x86-64 Linux
: P1 high
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-29 11:22 UTC by Srihari Vijayaraghavan
Modified: 2017-08-25 13:37 UTC (History)
27 users (show)

See Also:
Kernel Version: 3.16.0-rc7
Tree: Mainline
Regression: No


Attachments
.config, dmesg & xinput (160.00 KB, application/x-tar)
2014-07-29 11:22 UTC, Srihari Vijayaraghavan
Details
i8042.debug activated dmesg (with i8042.nomux & i8042.reset were set too) (116.75 KB, application/octet-stream)
2014-07-30 08:04 UTC, Srihari Vijayaraghavan
Details
i8042.debug activated dmesg during a good working session (39.03 KB, application/gzip)
2014-07-31 09:21 UTC, Srihari Vijayaraghavan
Details
dmesg-i8042.debug-with-psmouse-patch-while-broken (85.02 KB, text/plain)
2014-08-01 14:20 UTC, Srihari Vijayaraghavan
Details
dmesg-i8042.debug-with-psmouse-patch-while-working (171.90 KB, text/plain)
2014-08-01 14:20 UTC, Srihari Vijayaraghavan
Details
Try this (1.69 KB, patch)
2014-08-01 15:21 UTC, Mateusz Jończyk
Details | Diff
Enable platform quirk (626 bytes, patch)
2014-08-02 08:12 UTC, Mateusz Jończyk
Details | Diff
dmesg when used acpi_osi=! acpi_osi=!* acpi_osi="Linux" (72.66 KB, text/plain)
2014-08-03 10:34 UTC, Srihari Vijayaraghavan
Details
dmesg when used acpi_osi=! acpi_osi="Linux" (72.97 KB, text/plain)
2014-08-03 10:39 UTC, Srihari Vijayaraghavan
Details
dmesg with i8042.debug & acpi debug (1.21 MB, text/plain)
2014-08-03 12:05 UTC, Srihari Vijayaraghavan
Details
dmesg with i8042.debug & acpi debug when Elantech works (1.31 MB, text/plain)
2014-08-03 12:53 UTC, Srihari Vijayaraghavan
Details
This patch is required (together with the prev one) to test IRQ delivery on IRQ12 (597 bytes, patch)
2014-08-03 17:52 UTC, Mateusz Jończyk
Details | Diff
dmesg with i8042 patch, i8042.debug & acpi debug when Elantech not working (1.21 MB, text/plain)
2014-08-04 08:47 UTC, Srihari Vijayaraghavan
Details
dmesg with i8042 patch, i8042.debug & acpi debug when Elantech working (1.26 MB, text/plain)
2014-08-04 08:47 UTC, Srihari Vijayaraghavan
Details
superio -deV output (8.32 KB, text/plain)
2014-08-05 08:16 UTC, Srihari Vijayaraghavan
Details
ls -alR /sys (2.53 MB, text/plain)
2014-08-05 08:50 UTC, Srihari Vijayaraghavan
Details
dmesg with i8042.debug when Elantech is working (231.79 KB, text/plain)
2014-08-07 12:44 UTC, Srihari Vijayaraghavan
Details
/proc/interrupts (4.15 KB, text/plain)
2014-08-07 12:45 UTC, Srihari Vijayaraghavan
Details
[PATCH] Enable i2c Hid debugging (1.86 KB, patch)
2014-08-07 13:29 UTC, Mateusz Jończyk
Details | Diff
[DO NOT APPLY] Unfinished patch to reset the device (7.13 KB, patch)
2014-08-07 17:35 UTC, Mateusz Jończyk
Details | Diff
Diff after grepping i8042 and some cutting (54.86 KB, application/octet-stream)
2014-08-07 17:48 UTC, Mateusz Jończyk
Details
Same but as plaintext (54.86 KB, text/plain)
2014-08-07 17:49 UTC, Mateusz Jończyk
Details
My analysis, partially translated (4.01 KB, text/plain)
2014-08-07 17:55 UTC, Mateusz Jończyk
Details
dmesg with i8042.nokbd (93.97 KB, text/plain)
2014-08-08 09:08 UTC, Srihari Vijayaraghavan
Details
dmesg with i8042.debug & i8042.nokbd (91.38 KB, application/octet-stream)
2014-08-08 10:10 UTC, Srihari Vijayaraghavan
Details
dmesg with i8042.debug & i8042.nokbd (but after Windows 8.1 activating elantech) (86.60 KB, text/plain)
2014-08-08 10:14 UTC, Srihari Vijayaraghavan
Details
Enable (1.00 KB, patch)
2014-08-08 21:49 UTC, Mateusz Jończyk
Details | Diff
dmesg after above i8042 patch when elantech not working (75.08 KB, text/plain)
2014-08-09 03:44 UTC, Srihari Vijayaraghavan
Details
Read internal memory and do some other things (1.25 KB, patch)
2014-08-09 12:15 UTC, Mateusz Jończyk
Details | Diff
Read internal memory of the 8042 and many other things (1.72 KB, patch)
2014-08-09 12:30 UTC, Mateusz Jończyk
Details | Diff
dmesg with i8042.debug with the most recent patch where elantech worked after a cold power up (92.56 KB, text/plain)
2014-08-09 12:46 UTC, Srihari Vijayaraghavan
Details
Mateusz Jończyk's patch that fixes Elantech touch pad on Gigabyte laptops (e.g., P35G v2) (1.91 KB, patch)
2014-08-09 13:02 UTC, Srihari Vijayaraghavan
Details | Diff
Never-disable-the-AUX-port (1.07 KB, patch)
2014-08-10 08:33 UTC, Mateusz Jończyk
Details | Diff
Test-the-second-port-of-8042 (824 bytes, patch)
2014-08-10 10:08 UTC, Mateusz Jończyk
Details | Diff
Reset kbd (824 bytes, patch)
2014-08-10 12:09 UTC, Mateusz Jończyk
Details | Diff
Reset kbd (846 bytes, patch)
2014-08-10 13:11 UTC, Mateusz Jończyk
Details | Diff
Reset mouse (785 bytes, patch)
2014-08-10 13:49 UTC, Mateusz Jończyk
Details | Diff
dmesg with i8042.debug (110.59 KB, text/plain)
2014-08-10 21:52 UTC, Srihari Vijayaraghavan
Details
Reset the mouse (821 bytes, patch)
2014-08-11 08:13 UTC, Mateusz Jończyk
Details | Diff
dmesg with i8042.debug (76.26 KB, text/plain)
2014-08-11 08:38 UTC, Srihari Vijayaraghavan
Details
A patch that makes the touchpad work (871 bytes, patch)
2014-10-15 10:24 UTC, Mateusz Jończyk
Details | Diff
Patch based on Mateusz Jończyk's patch that fixes Elantech touch pad on Gigabyte laptops (e.g., P35G v2) (1.56 KB, patch)
2014-12-17 12:51 UTC, Srihari Vijayaraghavan
Details | Diff
V1 Patch based on Mateusz Jończyk's patch that fixes Elantech trackpad on many laptops (e.g., Gigabyte P35G v2) (1.71 KB, patch)
2014-12-17 23:15 UTC, Srihari Vijayaraghavan
Details | Diff
Patch based on Mateusz Jończyk's original patch fix that fixes Elantech touch pad on Gigabyte laptops (e.g., P35G v2) (2.86 KB, patch)
2014-12-19 23:31 UTC, Srihari Vijayaraghavan
Details | Diff
V3 Patch based on Mateusz Jończyk's patch that helps detecting Elantech touchpad on many laptops (3.02 KB, patch)
2014-12-20 22:00 UTC, Srihari Vijayaraghavan
Details | Diff
V4 Patch against mainline based on Mateusz Jończyk's patch that helps detecting Elantech touchpad on many laptops (3.99 KB, patch)
2015-01-05 08:47 UTC, Srihari Vijayaraghavan
Details | Diff
DMI addition to address XMG C404 laptop's touchpad detection (542 bytes, patch)
2015-01-26 11:55 UTC, Srihari Vijayaraghavan
Details | Diff
dmesg with i8042.debug and i8042.kbdreset on Acer Aspire E5-571P (29.37 KB, text/plain)
2015-02-01 15:12 UTC, Kevin
Details

Description Srihari Vijayaraghavan 2014-07-29 11:22:42 UTC
Created attachment 144611 [details]
.config, dmesg & xinput

Although this bug isn't specific to mainline 3.16.0-rc7 (i.e., observed in Fedora's 3.15.6 based kernel too), I thought of raising it against mainline, as I've got the dmesg, minimal config etc. lined up for it.

It'd be working fine, till you accidentally shutdown as opposed to reboot. Once shutdown command was used to power down the laptop, then no matter how many reboots I do, the touch pad doesn't work.

Here's a elantech info from dmesg (while it's working):
[    1.834930] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x361f0e)
[    1.849051] psmouse serio1: elantech: Synaptics capabilities query result 0x00, 0x15, 0x0f.

When it stops working, however, those messages don't appear, of course. I've worked out this ugly work-around, when it stops working: Regrettably, I'd have to boot the laptop into Windows 8.1 & quickly reboot it after seeing the mouse pointer on the screen (right from the login screen itself). Once the mouse pointer is thus 'activated,' then it'd start working on Linux just fine (till you mistakenly use power button or shutdown command). If you keep rebooting the laptop (using reboot command or such facility on the desktop env.) then it'd continue to work just fine.

The function hot keys to activate/deactivate the touchpad, though works when the touchpad is working under Linux, has no effect when touchpad stops working (due to shutdown/powerdown procedure obviously).

(Any help is much appreciated. Booting Windows 8.1 just to 'fix' the touchpad is becoming a little combersome, as Windows won't boot without Secure Boot activated, which means going into the BIOS/Firmware to toggle it on to boot Windows & then to toggle it off to boot mainline etc. Sorry for winging and complaining.)

My complete .config, xinput list (while working & not working) & dmesg (while working & not working) are attached as a tar ball.

Thank you.
Comment 1 Srihari Vijayaraghavan 2014-07-29 13:03:26 UTC
Just a bit more info: when it's working fine, the /proc/interrupts shows a lot of activities against it (IRQ 12 against i8042), but when it stops working, the counter remains zero.

A shutdown (which powers the laptop down) using either power button or shutdown command (either from within Linux or Windows OS) leads to broken touchpad on Linux. Then booting Windows OS becomes necessary to 'fix' the touchpad for later Linux usage. Although inelegant, this ugly work-around does work every time.

Thanks
Comment 2 Dmitry Torokhov 2014-07-29 17:15:41 UTC
To be able to diagnose the issue you need to boot with i8042.debug parameter so that IO to and from i8042 is logged. Also, have you tried i8042.reset and/or i8042.nomux options?
Comment 3 Srihari Vijayaraghavan 2014-07-30 08:04:14 UTC
Created attachment 144681 [details]
i8042.debug activated dmesg (with i8042.nomux & i8042.reset were set too)
Comment 4 Srihari Vijayaraghavan 2014-07-30 08:06:29 UTC
Thanks Dmitry. The i8042.debug enabled dmesg is attached above. It was booted with i8042.nomux & i8042.reset kernel parameters too. Unfortunately i8042.nomux & i8042.reset parameters didn't help.
Comment 5 Srihari Vijayaraghavan 2014-07-30 08:37:05 UTC
Just to clarify, I've tried both i8042.nomux & i8042.reset kernel parameters both independently & together. As per above report, unfortunately they didn't help. Thanks
Comment 6 Srihari Vijayaraghavan 2014-07-31 09:19:02 UTC
As a data point, I'm attaching dmesg from when the trackpoint does work in the next entry in this report. It was booted with i8042.debug (without i8042.reset & i8042.nomux, as they've no effect in my case). Perhaps comparing the previous (non-working session) and this one (during working session) sheds some light on the issue??

Thanks
Comment 7 Srihari Vijayaraghavan 2014-07-31 09:21:34 UTC
Created attachment 144801 [details]
i8042.debug activated dmesg during a good working session
Comment 8 Philip Nye 2014-07-31 09:56:29 UTC
I have observed what is almost certainly the same bug as reported here: https://bbs.archlinux.org/viewtopic.php?id=174217

I have not tried booting Windows as I don't have Windows installed, but as with Srihari once detected it works fine and is consistently detected again on a warm reboot.

After regular use I can say my touchpad is usually detected OK at startup if the laptop has been off for a long time (several hours). If it has only been off for a few minutes the trackpad is rarely detected on startup. This suggests success in detection is related to some marginal condition affected by heat or residual charge in power supplies.
Comment 9 Srihari Vijayaraghavan 2014-08-01 12:56:55 UTC
The longest period I could keep the laptop powered down (off the wall socket, but battery is non-removal unfortunately) was 12 hours :-). Alas, in my case, it didn't help to detect the Elantech touchpad.
Comment 10 Mateusz Jończyk 2014-08-01 13:16:52 UTC
Hello,
Could You provide dmesg with i8042.debug=1 without nomux and reset?
Your two dmesgs (working and not-working) are with different parameters so it is difficult to compare.
Also please include them as plaintext files so that they may be opened in a browser.

You have some warning in the dmesg:
[    0.029802] Freeing SMP alternatives memory: 24K (ffffffff81e23000 - ffffffff81e29000)
[    0.029829] ------------[ cut here ]------------
[    0.029843] WARNING: CPU: 0 PID: 0 at mm/page_alloc.c:2522 __alloc_pages_nodemask+0x350/0xab0()
[    0.029850] Modules linked in:
[    0.029859] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc7 #1
[    0.029865] Hardware name: GIGABYTE P35V2/P35V2, BIOS FB0A 07/14/2014
[    0.029871]  0000000000000000 5f5bb1e0fb96ecf4 ffffffff81c03c78 ffffffff8167c05f
[    0.029882]  0000000000000000 ffffffff81c03cb0 ffffffff8106ec4d 0000000000024000
[    0.029893]  0000000000004000 000000000000000b 0000000000000000 0000000000000000
[    0.029903] Call Trace:
[    0.029915]  [<ffffffff8167c05f>] dump_stack+0x45/0x56
[    0.029924]  [<ffffffff8106ec4d>] warn_slowpath_common+0x7d/0xa0
[    0.029932]  [<ffffffff8106ed7a>] warn_slowpath_null+0x1a/0x20
[    0.029940]  [<ffffffff81163240>] __alloc_pages_nodemask+0x350/0xab0
[    0.029952]  [<ffffffff81193f3e>] ? __insert_vmap_area+0x8e/0xc0
[    0.029963]  [<ffffffff81194f20>] ? alloc_vmap_area+0x2b0/0x310
[    0.029976]  [<ffffffff811a433a>] alloc_page_interleave+0x3a/0x90
[    0.029986]  [<ffffffff811a4a65>] alloc_pages_current+0xf5/0x170
[    0.029998]  [<ffffffff8115f4eb>] alloc_kmem_pages+0x3b/0xf0
[    0.030009]  [<ffffffff8117c238>] kmalloc_order+0x18/0x50
[    0.030018]  [<ffffffff8117c296>] kmalloc_order_trace+0x26/0xa0
[    0.030028]  [<ffffffff811af111>] __kmalloc+0x221/0x240
[    0.030041]  [<ffffffff81d23830>] efi_bgrt_init+0xce/0x13d
[    0.030051]  [<ffffffff81d22d6d>] efi_late_init+0x9/0xb
[    0.030060]  [<ffffffff81d0eff0>] start_kernel+0x43a/0x46a
[    0.030067]  [<ffffffff81d0e9bf>] ? set_init_arg+0x53/0x53
[    0.030078]  [<ffffffff81d0e5ad>] x86_64_start_reservations+0x2a/0x2c
[    0.030088]  [<ffffffff81d0e6a0>] x86_64_start_kernel+0xf1/0xf4
[    0.030101] ---[ end trace eff6fb67ff9f469d ]---

This should be investigated.



[    1.390019] i8042: [20] d4 -> i8042 (command)
[    1.390185] i8042: [20] f2 -> i8042 (parameter)
[    1.589398] i8042: [220] d4 -> i8042 (command)
[    1.589463] i8042: [220] ed -> i8042 (parameter)
[    1.789570] i8042: [420] 60 -> i8042 (command)
[    1.789684] i8042: [420] 45 -> i8042 (parameter)
[    1.789741] i8042: [420] 60 -> i8042 (command)
[    1.789852] i8042: [420] 47 -> i8042 (parameter)
[    1.789947] i8042: [420] d4 -> i8042 (command)
[    1.790005] i8042: [420] f2 -> i8042 (parameter)
[    1.989793] i8042: [620] 60 -> i8042 (command)
[    1.989858] i8042: [620] 45 -> i8042 (parameter)
[    1.989969] i8042: [620] 60 -> i8042 (command)
[    1.990083] i8042: [620] 47 -> i8042 (parameter)

We are sending "f2" (identify) to the mouse, but receive nothing back.

When the mouse works:
[    1.258331] i8042: [7] d4 -> i8042 (command)
[    1.258391] i8042: [7] f2 -> i8042 (parameter)
[    1.258692] EFI Variables Facility v0.08 2004-May-17
[    1.261237] i8042: [10] fa <- i8042 (interrupt, 1, 12)
[    1.262787] i8042: [11] 00 <- i8042 (interrupt, 1, 12)
It responds immediately.

We could reset the touchpad before issuing f2.

Could You try:
--- a/drivers/input/mouse/psmouse-base.c	2014-07-21 06:04:16.000000000 +0200
+++ b/drivers/input/mouse/psmouse-base.c	2014-08-01 15:15:06.837120339 +0200
@@ -1083,6 +1083,8 @@
  * Sunrex K8561 IR Keyboard/Mouse reports 0xff on second and subsequent
  * ID queries, probably due to a firmware bug.
  */
+        if (ps2_command(ps2dev, NULL, 0xff))
+                return -1;
 
 	param[0] = 0xa5;
 	if (ps2_command(ps2dev, param, PSMOUSE_CMD_GETID))
Comment 11 Mateusz Jończyk 2014-08-01 13:20:03 UTC
OK, no need for the new dmesgs.
The current ones are sufficient to debug the issue.
Comment 12 Srihari Vijayaraghavan 2014-08-01 13:24:38 UTC
Thanks Mateusz. I won't worry about the WARNING in page allocator. It's already been fixed in mainline as per my other bug report (https://bugzilla.kernel.org/show_bug.cgi?id=81321). It was related to EFI. There is some discussion amongst them as to if there is a better patch etc., but that's just procedural thing.

Now I'm compiling a kernel with your above patch. Will update this report shortly..
Comment 13 Mateusz Jończyk 2014-08-01 13:35:55 UTC
Sorry, this is the correct patch:

--- a/drivers/input/mouse/psmouse-base.c	2014-07-21 06:04:16.000000000 +0200
+++ b/drivers/input/mouse/psmouse-base.c	2014-08-01 15:15:06.837120339 +0200
@@ -1083,7 +1083,9 @@
  * Sunrex K8561 IR Keyboard/Mouse reports 0xff on second and subsequent
  * ID queries, probably due to a firmware bug.
  */
-        if (ps2_command(ps2dev, NULL, 0xff))
+        if (ps2_command(ps2dev, param, PSMOUSE_CMD_RESET_BAT))
+                return -1;
+        if (param[0] != 0xaa && param[1] != 0x00)
                 return -1;
 
 	param[0] = 0xa5;
Comment 14 Srihari Vijayaraghavan 2014-08-01 14:06:04 UTC
Unfortunately, the above patch didn't help. (Thanks for your explanation, now I see that when it's working, it communicates on irq 12) Here's a snippet of i8042.debug results around f2:
[    1.239956] serio: i8042 AUX port at 0x60,0x64 irq 12
[    1.240689] i8042: [4] f2 -> i8042 (kbd-data)
[    1.240845] i8042: [5] fa <- i8042 (interrupt, 0, 1)
[    1.243479] i8042: [7] fa <- i8042 (interrupt, 0, 1)
[    1.243502] i8042: [7] 60 -> i8042 (command)
[    1.243563] i8042: [7] 46 -> i8042 (parameter)
[    1.243674] i8042: [7] 60 -> i8042 (command)
[    1.243788] i8042: [8] 47 -> i8042 (parameter)
[    1.243881] i8042: [8] d4 -> i8042 (command)
[    1.244053] i8042: [8] f2 -> i8042 (parameter)
[    1.251535] i8042: [15] ab <- i8042 (interrupt, 0, 1)
[    1.253559] i8042: [17] 83 <- i8042 (interrupt, 0, 1)
[    1.444014] i8042: [208] d4 -> i8042 (command)
[    1.444080] i8042: [208] ed -> i8042 (parameter)
[    1.644174] i8042: [408] 60 -> i8042 (command)
[    1.644294] i8042: [408] 45 -> i8042 (parameter)
[    1.644354] i8042: [408] 60 -> i8042 (command)
[    1.644467] i8042: [408] 47 -> i8042 (parameter)
[    1.644568] i8042: [408] d4 -> i8042 (command)
[    1.644681] i8042: [408] ff -> i8042 (parameter)
[    2.645353] i8042: [1408] 60 -> i8042 (command)
[    2.645413] i8042: [1408] 45 -> i8042 (parameter)
[    2.645522] i8042: [1408] 60 -> i8042 (command)
[    2.645635] i8042: [1408] 47 -> i8042 (parameter)
[    2.645740] i8042: [1408] f2 -> i8042 (kbd-data)
[    2.646071] i8042: [1408] fa <- i8042 (interrupt, 0, 1)
[    2.648178] i8042: [1410] ab <- i8042 (interrupt, 0, 1)

Nothing coming from irq 12.

I'm happy to test other patches or methods that you may suggest. Thanks
Comment 15 Mateusz Jończyk 2014-08-01 14:14:03 UTC
Excuse me, could You give a full dmesg?
Comment 16 Srihari Vijayaraghavan 2014-08-01 14:17:37 UTC
Yes, please refer to next entry in this report. It has 2 logs--both with i8042.debug--one while trackpad wasn't working and other while it was working (after 'activating' it using Windows). Let's see if the plain text format of loading works.
Comment 17 Srihari Vijayaraghavan 2014-08-01 14:20:02 UTC
Created attachment 144841 [details]
dmesg-i8042.debug-with-psmouse-patch-while-broken
Comment 18 Srihari Vijayaraghavan 2014-08-01 14:20:54 UTC
Created attachment 144851 [details]
dmesg-i8042.debug-with-psmouse-patch-while-working
Comment 19 Mateusz Jończyk 2014-08-01 14:51:26 UTC
What happens after a reset?
Comment 20 Mateusz Jończyk 2014-08-01 15:21:44 UTC
Created attachment 144861 [details]
Try this

Is this a regression?
Comment 21 Mateusz Jończyk 2014-08-01 15:28:26 UTC
What happens if You restart WIndows?
Comment 22 Mateusz Jończyk 2014-08-01 15:51:28 UTC
"(Any help is much appreciated. Booting Windows 8.1 just to 'fix' the touchpad is becoming a little combersome, as Windows won't boot without Secure Boot activated, which means going into the BIOS/Firmware to toggle it on to boot Windows & then to toggle it off to boot mainline etc. Sorry for winging and complaining.)"
There was some program from mjg that enabled you to boot anything with Secure Boot on.

"Just a bit more info: when it's working fine, the /proc/interrupts shows a lot of activities against it (IRQ 12 against i8042), but when it stops working, the counter remains zero." Very interesting.

It isn't impossible that the hardware is broken.
Comment 23 Mateusz Jończyk 2014-08-01 15:52:08 UTC
BTW, Win does not require Secure boot.
Comment 24 Mateusz Jończyk 2014-08-01 15:58:22 UTC
We may in any case just try to use polling and not interrupts.
Comment 25 Srihari Vijayaraghavan 2014-08-01 22:13:22 UTC
(In reply to Mateusz Jończyk from comment #19)
> What happens after a reset?

In Linux, if it were in working condition (because it was 'activated' by booting Windows beforehand), then after every reset, the trackpad would work without fail. If it wasn't in working condition (because Windows wasn't booted after the current power on), then no matter how many times we reset from Linux, it won't work at all.
Comment 26 Srihari Vijayaraghavan 2014-08-01 22:17:40 UTC
(In reply to Mateusz Jończyk from comment #20)
> Created attachment 144861 [details]
> Try this
> 
> Is this a regression?

No this is no regression. It's a brand new laptop only a few days old. I've discovered this problem from the first time I booted Linux, from power on. And as quickly as having discovered the problem, I've discovered the work-around too of temporarily booting Windows every time after power on and before I want to use Linux, which is both my favourite and preferred OS of course.
Comment 27 Srihari Vijayaraghavan 2014-08-01 22:21:05 UTC
(In reply to Mateusz Jończyk from comment #21)
> What happens if You restart WIndows?

In Windows, it's no problem whether the laptop was previously powered on or power resetted etc. It always works. I've done a little analysis to understand that even in Windows, there is no special flashy driver from Elantech as such. It's using the usual i8042 & psmouse driver (with Elantech trackpad support) over irq 12. Just as exactly as Linux.
Comment 28 Srihari Vijayaraghavan 2014-08-01 22:29:00 UTC
(In reply to Mateusz Jończyk from comment #23)
> BTW, Win does not require Secure boot.

I've failed in my every attempt to boot Windows 8.1 with secure boot off in the BIOS/Firmware. My suspicion is that MS ushered in a new era of "Windows 8.1" logo certified laptops or some such non-sense, where it becomes mandatory to have it. Or it could be because it was installed when secure boot was on, now it doesn't want to boot when it goes off. Something like that.

I've found another equally cumbersome work-around, after a power on, of booting in Windows recovery image, which doesn't "enforce" secure boot on; that too sets the trackpad right for subsequent Linux boot.

Anywa
Comment 29 Srihari Vijayaraghavan 2014-08-01 22:34:49 UTC
Sorry, the previous comment was unfinished.

Anyway, Fedora supporting secure boot is ok with me for that thingy to be on in the BIOS/Firmware.

Or once this problem is resolved (i.e., trackpad is made to work even after power down), then I've really no use for Windows 8.1 non-sense. The only real purpose it's serving now is to set the trackpad in working order for Linux :-).

Looking forward to this trackpad eventually working natively under Linux, I can tolerate the non-sense of the closed OS like Windows 8.1 till such time.

Thank you for your help so far.
Comment 30 Srihari Vijayaraghavan 2014-08-01 22:36:22 UTC
(In reply to Mateusz Jończyk from comment #24)
> We may in any case just try to use polling and not interrupts.

Oh, thanks for this tip. I'm now reading about how to configure polling over interrupts. Will update this report after trying that out.
Comment 31 Mateusz Jończyk 2014-08-02 08:12:26 UTC
Created attachment 144891 [details]
Enable platform quirk

This snippet is interesting:
/*
 * Some hw_version 3 models go into error state when we try to set
 * bit 3 and/or bit 1 of r10.
 */
static const struct dmi_system_id no_hw_res_dmi_table[] = {
#if defined(CONFIG_DMI) && defined(CONFIG_X86)
        {
                /* Gigabyte U2442 */
                .matches = {
                        DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
                        DMI_MATCH(DMI_PRODUCT_NAME, "U2442"),
                },
        },
#endif
        { }
};
U2442 seems to be recent.

This patch will enable the same behaviour as on this model.
Apply together with the previous one.
Comment 32 Srihari Vijayaraghavan 2014-08-02 08:35:56 UTC
Mateusz, sorry that patch, attachment 144891 [details], doesn't apply:
[srihari@laptop linux-3.16.0-rc7]$ cat /home/srihari/elantech_patch
--- linux-3.16-rc6/drivers/input/mouse/elantech.c~ 2014-08-01 13:04:10.958714728 +0200
+++ b/drivers/input/mouse/elantech.c  2014-08-02 10:10:05.795982898 +0200
@@ -1428,7 +1428,10 @@ 
        etd->crc_enabled = ((etd->fw_version & 0x4000) == 0x4000);
 
        /* Enable real hardware resolution on hw_version 3 ? */
-       etd->set_hw_resolution = !dmi_check_system(no_hw_res_dmi_table);
+       //etd->set_hw_resolution = !dmi_check_system(no_hw_res_dmi_table);
+        //on GIGABYTE U2442, dmi_check_system returns 1
+        //so set_hw_resolution is set to 0
+       etd->set_hw_resolution = 0;
 
        return 0;
 }

[srihari@laptop linux-3.16.0-rc7]$ cat /home/srihari/elantech_patch|patch -p1 --dry-run
checking file drivers/input/mouse/elantech.c
Hunk #1 FAILED at 1428.
1 out of 1 hunk FAILED
[srihari@laptop linux-3.16.0-rc7]$
Comment 33 Srihari Vijayaraghavan 2014-08-02 08:56:30 UTC
I've applied this one, which I reckon is equivalent to yours:
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index ee2a04d..ddeb89c 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1427,7 +1427,8 @@ static int elantech_set_properties(struct elantech_data *etd)
        etd->crc_enabled = ((etd->fw_version & 0x4000) == 0x4000);
 
        /* Enable real hardware resolution on hw_version 3 ? */
-       etd->set_hw_resolution = !dmi_check_system(no_hw_res_dmi_table);
+       //etd->set_hw_resolution = !dmi_check_system(no_hw_res_dmi_table);
+       etd->set_hw_resolution = 0;
 
        return 0;
 }

This is the touchpad h/w version:
psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x361f0e)

Reading between the words, perhaps the above patch would have no effect on hw_version 4? Perhaps we need an equivalent one for hw_version 4?
Comment 34 Mateusz Jończyk 2014-08-02 13:56:05 UTC
OK, nevermind. I didn't check the versions.

(In reply to Srihari Vijayaraghavan from comment #30)
> Oh, thanks for this tip. I'm now reading about how to configure polling over
> interrupts. Will update this report after trying that out.
AFAIK, it is not possible. It will be neccessary to code it manually when it will be needed.
Comment 35 Srihari Vijayaraghavan 2014-08-03 08:04:31 UTC
There's been a change! As per Philip Nye's observation reported above, I too got the Elantech trackpad working right after cold power on by disconnecting the laptop power cable (at the laptop end) for precisely 60 seconds, as per stop watch, before powering laptop up to directly boot in Linux (mainline or distribution kernel doesn't really matter in my testing). Then every time trackpad gets initialised (as per dmesg|egrep elantech) and works! Now it has to be precisely 60 or more seconds off power cable; 55 seconds, then it doesn't work.

(My previous observation of 12 hours of power off wasn't disconnecting the laptop power cable just before the power on, because I've always had the power on. As I've proven now, it really needs to be off the power cable for a minute, before direct Linux boot, for trackpad to work. Once trackpad is initialised successfully under Linux, power can be turned on. Of course, this is going to be a problem when eventually the battery dies, but then booting Windows 8 first before Linux should get it going at that time, if assuming the root cause hasn't been identified & fixed/worked-around by then.)

Although I'm no expert, it's however starting to feel like some power management issue (perhaps ACPI) and device initialisation (interrupts etc.) in relation to that, although it's totally limited to Elantech trackpad alone from my observation (i.e., no other device -- be it Ethernet, Wireless, Video (Intel 4600 or Noveau driven GTX860M), key board, sound card, USB ports etc. -- exhibits this quirky behaviour.)

As always, am happy to try any fixes or steps that may be provided. It'd be ideal if this Elantech trackpad can be made to work (although, it might not its fault) with Linux straight after a cold power up, with the power cable plugged in, of course.

Thanks
Comment 36 Mateusz Jończyk 2014-08-03 08:49:16 UTC
(In reply to Srihari Vijayaraghavan from comment #35)
> There's been a change! As per Philip Nye's observation reported above, I too
> got the Elantech trackpad working right after cold power on by disconnecting
> the laptop power cable (at the laptop end) for precisely 60 seconds, as per
> stop watch, before powering laptop up to directly boot in Linux (mainline or
> distribution kernel doesn't really matter in my testing). Then every time
> trackpad gets initialised (as per dmesg|egrep elantech) and works! Now it
> has to be precisely 60 or more seconds off power cable; 55 seconds, then it
> doesn't work.
> 
Are You booting Linux before or after connecting the power cord?

It looks like something with the Embedded Controller. It's a chip on the MB that runs some code stored in EEPROM, is driving the leds (battery, AC, running, etc.).

I will ask You to send me Your ACPI tables once I will sort out whether this is legal. You are based in India?
Comment 37 Srihari Vijayaraghavan 2014-08-03 09:47:54 UTC
Only if I boot Linux before connecting power cable, would it work. This problem is somewhat elusive from what I can see. Although all throughout the morning it worked with just 1 minute unplugging the cable, now, at the end of the day, having been on the power for a few hours, not just one minute, even 20 minutes off the power cord hasn't helped. But like Philip Nye stated above, am sure perhaps after a couple of hours off the cord, might help.

In terms of LEDs, yes, there are 5 of them at the front, one each for displaying the status of Bluetooth, Wifi, hard disk, battery & power. (There is a small button (called power check button), which when pushed, blinks all those LEDs; although it works only when OS is powered down). Occasionally, I've noticed that one LED (either battery or power LED, it's one of them for sure; now that I think about it, it could have been the battery LED) would stay on for a while even after power down. It doesn't happen all the time, but some times, perhaps when the battery is fully charged or something. But whenever the machine is suspended to RAM, the power LED constantly blinks, in a gentle rhythm.

(This manual from Gigabyte vendor explains the LED arrangement as well: http://download.gigabyte.asia/FileList/Manual/p35-manual-en-v2.0.pdf)

Nope, I'm living outside India. In another bug (https://bugzilla.kernel.org/show_bug.cgi?id=81321), I've very recently given acpidump (https://bugzilla.kernel.org/attachment.cgi?id=144691). And am happy to give another fresh copy right here, if needed.

Thanks
Comment 38 Mateusz Jończyk 2014-08-03 09:48:10 UTC
Please try acpi_osi="Linux"


Does booting with acpi=off help?

Alternatively, please recompile with CONFIG_ACPI_DEBUG and boot with acpi.debug_layer=0xffffffff acpi.debug_level=0x4 .
Comment 39 Mateusz Jończyk 2014-08-03 10:00:50 UTC
Do all other features of ACPI work?
Can fan be controlled / is its speed reasonable?
Can You see the cpu temp?
Does suspend / hibernation work?
What about "multimedia" keys?
Comment 40 Srihari Vijayaraghavan 2014-08-03 10:15:48 UTC
acpi_osi="Linux" didn't help. When using acpi=off, the machine doesn't even boot :-(, hangs somewhere along the way, though pushing button had it shutdown immediately. So ACPI appears to be must for this laptop.

I've been using various Fn + one of the function key combination to accomplish something. E.g., to turn on/off Bluetooth, to un/mute the speakers, to increase/decrease the volume, to turn wireless on/off, to turn back light on/off for the keyboard etc. they all just work.

Suspend to RAM works. I haven't tried suspend to hard disk yet, considering it only takes around 10 seconds from boot loader to desktop environment, so felt no reason to try suspend to disk yet.

CPU temp (individual cores etc.) and some other temperature are nicely reported, with the help of lm_sensors & KSensors GUI tool. Fan kicks in when the CPU temp goes up above certain threshold (like when compiling kernel) & slows down or stops upon reaching certain threshold.

All these things indicate that ACPI appears to be helping. But we don't know for sure, whether it's extending its help to Elantech trackpad.

Will try activating ACPI debug & give the results here.

Thanks
Comment 41 Mateusz Jończyk 2014-08-03 10:21:36 UTC
(In reply to Mateusz Jończyk from comment #38)
> Please try acpi_osi="Linux"
Sorry, it should be:
acpi_osi=! acpi_osi=!* acpi_osi="Linux"

and also try with:

acpi_osi=! acpi_osi="Linux"

Please give me dmesg with both.
Comment 42 Srihari Vijayaraghavan 2014-08-03 10:34:03 UTC
Created attachment 144941 [details]
dmesg when used acpi_osi=! acpi_osi=!* acpi_osi="Linux"

I've confirmed it twice that although I had acpi_osi="Linux" in grub, it isn't showing those double quotes in the dmesg itself. I take it is harmless.
Comment 43 Srihari Vijayaraghavan 2014-08-03 10:39:37 UTC
Created attachment 144951 [details]
dmesg when used acpi_osi=! acpi_osi="Linux"
Comment 44 Mateusz Jończyk 2014-08-03 10:58:38 UTC
OK, it seems that You may have problems with
"Intel(R) Smart Sound Technology Host Controller - INT33C8". If reporting that in the future, please point to the ACPI DSDT.

I am assuming that none of the above helped.

Please always use in the future
acpi_osi=! acpi_osi=!* acpi_osi="Linux" i8042.debug=1
unless noted otherwise.

Please recompile with my patch ("Try this") and the patch from https://bugzilla.kernel.org/show_bug.cgi?id=81321. Enable by the way the CONFIG_ACPI_DEBUG.

Then run with 
acpi_osi=! acpi_osi=!* acpi_osi="Linux" i8042.debug=1 
and please give me dmesg.
Comment 45 Mateusz Jończyk 2014-08-03 11:03:26 UTC
(In reply to Mateusz Jończyk from comment #44)
> OK, it seems that You may have problems with
> "Intel(R) Smart Sound Technology Host Controller - INT33C8". If reporting
> that in the future, please point to the ACPI DSDT.
It's that:
http://www.techspot.com/news/54334-integrated-dsp-coming-in-intel-broadwell-cpus-to-facilitate-low-power-voice-recognition.html
It seems to be supported in kernel, but AFAIK pulseaudio does not use it.
Comment 46 Srihari Vijayaraghavan 2014-08-03 11:15:03 UTC
Thank you for all your help & suggestions so far. I highly appreciate it.

The only multimedia apps that I use are Amarok, VLC (and extremely rarely Skype) with both inbuilt speakers/microphone or my old 3.5mm ear-phone/microphone set. All these things just work fine for my use. So that's as multimedia as I'm going to get :-). If what you're talking is more than that, then I didn't even know there's more this laptop can offer & I don't think I'm going to need it anytime soon though.

I've made acpi_osi=! acpi_osi=!* acpi_osi="Linux" permanent in grub. That's taken care of, going forward (although as you've hinted, they haven't helped, but neither have they given me grief, so they can stay). Only i8042.debug to be used on demand, for obvious reasons.

Now on to i8042.debug with your original patches... Won't be long for that dmesg.

Thanks
Comment 47 Mateusz Jończyk 2014-08-03 11:59:43 UTC
(In reply to Srihari Vijayaraghavan from comment #46)
> The only multimedia apps that I use are Amarok, VLC (and extremely rarely
> Skype) with both inbuilt speakers/microphone or my old 3.5mm
> ear-phone/microphone set. All these things just work fine for my use. So
> that's as multimedia as I'm going to get :-). If what you're talking is more
> than that, then I didn't even know there's more this laptop can offer & I
> don't think I'm going to need it anytime soon though.

This chip is only for acceleration and reducing energy use.

Is there anything in the BIOS that is related to touchpad?
Comment 48 Srihari Vijayaraghavan 2014-08-03 12:05:22 UTC
Created attachment 144961 [details]
dmesg with i8042.debug & acpi debug

Had to increase the kernel log buffer to 21 to capture it all, so at ~1.3 MB, it's quite big.
Comment 49 Srihari Vijayaraghavan 2014-08-03 12:10:42 UTC
(In reply to Mateusz Jończyk from comment #47)
... 
> Is there anything in the BIOS that is related to touchpad?

The BIOS is extremely limited in terms of tunables, practically only a dozen tunables (like Secure boot on/off, date/time, administrator password, enabling/disabling some chipset devices like Bluetooth, SATA mode -- AHCI by default of course, like that. Not much really. And indeed there's nothing related to touchpad whatsoever in it.

Unfortunately, I'm going offline now, as it's quite late here. I'll however respond with more data, if required, tomorrow.

Once again, thank you for all your help. Good on you.
Comment 50 Mateusz Jończyk 2014-08-03 12:29:45 UTC
When You captured the dmesg, did the tablet work?

Please supply similar dmesg when the "tablet working state" was different.
Comment 51 Srihari Vijayaraghavan 2014-08-03 12:37:54 UTC
The above dmesg is from when elantech didn't work. The below dmesg is from when elantech did work (I booted in Windows to activate it).
Comment 52 Srihari Vijayaraghavan 2014-08-03 12:53:10 UTC
Created attachment 144971 [details]
dmesg with i8042.debug & acpi debug when Elantech works

This dmesg is generated with acpi debug & i8042.debug when Elantech is working. 

(Whenever Elantech is working, there's always 2 entries for it in dmesg without fail as per this dmesg log. And whenever it doesn't work -- just as per previous dmesg, obviously there won't be any dmesg entry for it. In other words, when it is doesn't work psmouse_extensions() and associates don't  even get invoked, as per some printk's I peppered around yesterday. So it's as if there's no Elantech during psmouse probing. I've since abandoned my attempts at studying the problem further, as it was getting too difficult for me to comprehend psmouse*.c, elantech.c etc., although I'm not so easily discouraged, so I might venture into it again during next weekend to understand the path various kernel routines traverse when Elantech is detected/working & they fail to traverse when it isn't detected/working.)

Thanks
Comment 53 Mateusz Jończyk 2014-08-03 17:52:00 UTC
Created attachment 145011 [details]
This patch is required (together with the prev one) to test IRQ delivery on IRQ12

The patch labeled "Try this" wasnt really efective because IRQ delivery testing is disabled by default on laptops.
Comment 54 Mateusz Jończyk 2014-08-03 18:06:12 UTC
(In reply to Srihari Vijayaraghavan from comment #52)
> (Whenever Elantech is working, there's always 2 entries for it in dmesg
> without fail as per this dmesg log. And whenever it doesn't work -- just as
> per previous dmesg, obviously there won't be any dmesg entry for it. In
> other words, when it is doesn't work psmouse_extensions() and associates
> don't  even get invoked, as per some printk's I peppered around yesterday.
> So it's as if there's no Elantech during psmouse probing. I've since
> abandoned my attempts at studying the problem further, as it was getting too
> difficult for me to comprehend psmouse*.c, elantech.c etc., although I'm not
> so easily discouraged, so I might venture into it again during next weekend
> to understand the path various kernel routines traverse when Elantech is
> detected/working & they fail to traverse when it isn't detected/working.)

When the touchpad doesnt work, it is dumb and deaf and doesn't respond to anything.
Therefore psmouse_probe() - in psmouse-base.c exits immediately.
It looks like it is completly powered down - disconnected from the power source.

If You are interested, read
http://wiki.osdev.org/%228042%22_PS/2_Controller
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-13.html
The PS2 protocol is quite simple.
Comment 55 Mateusz Jończyk 2014-08-03 18:06:56 UTC
Lots of thank You for really good handling of the bug report.
Comment 56 Mateusz Jończyk 2014-08-04 08:07:43 UTC
//to make this page show up in the Google Search:
Linux Gigabyte P35V2 touchpad not working
Linux Gigabyte P35V2 trackpad not working
Linux Gigabyte laptop touchpad not working
Comment 57 Mateusz Jończyk 2014-08-04 08:11:51 UTC
Is there a Bios update for Your laptop? (but don't install it yet)

This laptop seems to be really fresh, was probably released just in June or July.

//should be similar
Linux Gigabyte P34G touchpad not working
Linux Gigabyte P35W touchpad not working
Comment 58 Srihari Vijayaraghavan 2014-08-04 08:26:40 UTC
(In reply to Mateusz Jończyk from comment #53)
> Created attachment 145011 [details]
> This patch is required (together with the prev one) to test IRQ delivery on
> IRQ12
> 
> The patch labeled "Try this" wasnt really efective because IRQ delivery
> testing is disabled by default on laptops.

Just FYI, that patch doesn't apply. Here's its equivalent:

diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 3807c3e..53d4264 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -794,14 +794,6 @@ static int __init i8042_check_aux(void)
  * used it for a PCI card or somethig else.
  */
 
-       if (i8042_noloop || i8042_bypass_aux_irq_test || aux_loop_broken) {
-/*
- * Without LOOP command we can't test AUX IRQ delivery. Assume the port
- * is working and hope we are right.
- */
-               retval = 0;                                                                                         
-               goto out;                                                                                           
-       }                                                                                                           
                                                                                                                    
        if (request_irq(I8042_AUX_IRQ, i8042_aux_test_irq, IRQF_SHARED,                                             
                        "i8042", i8042_platform_device))

Now actually compiling & testing it. Although it's been off the power cable for nearly 20 hours, when I booted it off to Linux directly this evening, Elantech trackpad didn't work. Anyway, I'll give you the acpi debug & i8042.debug activated dmesg with the above patch applied shortly.
Comment 59 Srihari Vijayaraghavan 2014-08-04 08:32:13 UTC
(In reply to Mateusz Jończyk from comment #57)
> Is there a Bios update for Your laptop? (but don't install it yet)
> 
> This laptop seems to be really fresh, was probably released just in June or
> July.
> 
> //should be similar
> Linux Gigabyte P34G touchpad not working
> Linux Gigabyte P35W touchpad not working

Agreed. It's a new laptop model. It isn't more than a month or two old. There was one BIOS update when I set it up initially just a little over week ago, which I did apply. The trackpad problem was there before that & it continued to be there even after update. When I read its release notes, that update was for some fluffy useless stuff (hardware RAID stuff, which I don't have anyway).
Comment 60 Srihari Vijayaraghavan 2014-08-04 08:47:05 UTC
Created attachment 145031 [details]
dmesg with i8042 patch, i8042.debug & acpi debug when Elantech not working

dmesg with i8042 patch, i8042.debug & acpi debug when Elantech not working
Comment 61 Srihari Vijayaraghavan 2014-08-04 08:47:46 UTC
Created attachment 145041 [details]
dmesg with i8042 patch, i8042.debug & acpi debug when Elantech working

dmesg with i8042 patch, i8042.debug & acpi debug when Elantech working
Comment 62 Mateusz Jończyk 2014-08-04 14:21:22 UTC
(In reply to Srihari Vijayaraghavan from comment #58)
> Just FYI, that patch doesn't apply. Here's its equivalent:
> 
OK, please excuse me.
I am relatively new to kernel dev (this is my first real debugging session).
Will check the patches more in the future.

I am now moving to git, managing the patches manually was really painful.
The patch quality should be better.

Did You really compile with the patch labelled "Try this"? I have just noticed that it contained mistakes that prevented it from building. Or did You fix them manually?
Comment 63 Srihari Vijayaraghavan 2014-08-04 19:38:59 UTC
Am sure I've applied your patches and that's the reason I was able to generate the diff's using git diff. Never mind, if you can please supply all patches against 3.16 that would be nice. Thanks
Comment 64 Mateusz Jończyk 2014-08-05 07:20:39 UTC
Hello,
Could You give me output of superiotool -deV ?

Please compile superiotool as described here:
http://www.coreboot.org/Superiotool

Please note that there is a very small possibility of damaging hardware with superiotool (just like it is with sensors-detect) although I wasn't able to find any reports of that on the net.

Please give me the dump when the touchpad is working, unless superiotool finds something, then both.
Comment 65 Srihari Vijayaraghavan 2014-08-05 08:16:52 UTC
Created attachment 145211 [details]
superio -deV output

Although the entire output is attached here, this is the snippet that stands out:
Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e...
Found SMSC SCH5317 (id=0x85, rev=0x87) at 0x4e
No dump available for this Super I/O
No extra registers known for this chip.
Comment 66 Mateusz Jończyk 2014-08-05 08:36:58 UTC
It may as well be IT8500
https://groups.google.com/a/chromium.org/d/topic/chromium-os-reviews/nSLD9xITq7U

The SCH5317 chip is quite oldm so the IT8500 is probable. There is a driver for it in the kernel, but don't load it, it may be risky if there is the IT8500.
Comment 67 Mateusz Jończyk 2014-08-05 08:44:13 UTC
Please give me output of 
ls -alR /sys
There are some interesting things in the DSDT
Comment 68 Srihari Vijayaraghavan 2014-08-05 08:50:19 UTC
Created attachment 145221 [details]
ls -alR /sys

Right off 3.16.0, although booted without acpi debug & i8042.debug.
Comment 69 Mateusz Jończyk 2014-08-05 09:43:08 UTC
I'm sorry, but don't have time now.
You can drop all patches and boot vanilla 3.16.0. When I will post You something, I will rebase it on top of 3.16.0.

You can also drop all kernel parameters.
Comment 70 Mateusz Jończyk 2014-08-05 09:44:05 UTC
Thank You for support.
Comment 71 Mateusz Jończyk 2014-08-05 10:08:33 UTC
Could You compile and run
ectool: http://www.coreboot.org/Ectool
when the touchpad works and when it does not?
Comment 72 Srihari Vijayaraghavan 2014-08-05 10:25:24 UTC
(Both under vanilla 3.16.0)

Output of ectool, when Elantech is working:
EC RAM:

00: 08 e3 5b a0 00 c0 60 00 00 11 00 01 00 00 00 00 
10: bc 1b 75 1b 75 1b 27 31 c6 02 db 00 00 00 00 00 
20: 5c 2b 00 00 98 0b 01 01 00 00 55 32 35 00 00 00 
30: 47 42 54 20 00 00 00 00 00 00 00 00 00 00 00 00 
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
50: 00 00 00 00 75 1b 00 00 00 00 00 00 00 00 00 00 
60: 36 00 36 03 00 00 a9 00 00 00 00 07 00 00 1b 75 
70: 00 db aa fb 1b 75 00 00 0b 98 04 56 00 00 00 a9 
80: 02 bf 05 7d 08 3c 0a fb 0d ba 1a 16 00 00 00 00 
90: 98 00 00 a9 00 00 00 a9 00 00 00 00 00 01 04 56 
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
c0: 40 31 00 0d 00 10 00 00 04 00 00 00 00 00 00 00 
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

Not dumping EC IDX RAM.

Output of ectool, when Elantech is not working:
EC RAM:

00: 08 e3 5b a0 00 c0 60 00 00 11 00 01 00 00 00 00 
10: bc 1b 75 1b 75 1b 26 31 c6 02 db 00 00 00 00 00 
20: 5c 2b 00 00 98 0b 01 01 00 00 55 32 35 00 00 00 
30: 47 42 54 20 00 00 00 00 00 00 00 00 00 00 00 00 
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
50: 00 00 00 00 75 1b 00 00 00 00 00 00 00 00 00 00 
60: 37 00 37 03 00 00 a8 00 00 00 00 07 00 00 1b 75 
70: 00 db aa fb 1b 75 00 00 0b 98 04 56 00 00 00 a9 
80: 02 bf 05 7d 08 3c 0a fb 0d ba 1a 16 00 00 00 00 
90: 98 00 00 a8 00 00 00 a8 00 00 00 00 00 01 04 56 
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
c0: 40 31 00 0d 00 10 00 00 04 00 00 00 00 00 00 00 
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

Not dumping EC IDX RAM.

There's obviously some difference (on 60: & 70:). Don't know its significance though. Very interesting, however. Thanks
Comment 73 Mateusz Jończyk 2014-08-05 10:42:52 UTC
In the RAM there could be some things like temp readings and fan speeds.
Also there may be different causes why these values differ for other reasons then the touchpad (reboot vs straight boot).

Could You execute ectool several times, with some timespan between these?

Do not dump the idx ram (command line switches) until I will check whether this is safe.

Also, a small request: could You not answer till tomorrow? I have to get my work done.
Comment 74 Mateusz Jończyk 2014-08-07 11:52:19 UTC
Hello,
I have been randomly browsing Your DSDT table and I spotted this:

            Device (TPD0)
            {
                Name (_ADR, One)  // _ADR: Address
                Name (_HID, "ELAN1000")  // _HID: Hardware ID
                Name (_CID, "PNP0C50")  // _CID: Compatible ID
                Name (_UID, One)  // _UID: Unique ID
                Name (_S0W, 0x04)  // _S0W: S0 Device Wake State
                Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                {
                    If (LEqual (Arg0, Buffer (0x10)

What this reminds You of?

And then I searched for PNP0C50 and found 
http://msdn.microsoft.com/en-us/library/windows/hardware/jj131711%28v=vs.85%29.aspx
"This section describes plug and play support for devices that support HID over the I2C transport."

And in the initiaization sequence on this page:

"The following list gives the enumeration sequence. Note that the order of this list may change in future versions of Windows.

 1.   Retrieve ACPI ASL code for HID I2C DEVICE from System BIOS.
 2.   Retrieve HID Descriptor from the Device.
        Write HID Descriptor Address
        Read HID Descriptor
 3.   Issue a SET_POWER to the Device.
        Write SET_POWER Command
"
Comment 75 Mateusz Jończyk 2014-08-07 11:53:22 UTC
Which driver on Windows supports the touchpad?
Comment 76 Mateusz Jończyk 2014-08-07 11:55:40 UTC
In this sense HID means specifically Human Interface Device, this can be said for sure because of the section the MSDN article is in.
Comment 77 Mateusz Jończyk 2014-08-07 12:01:00 UTC
This is additionally interesting:
http://msdn.microsoft.com/en-us/library/windows/hardware/jj127210%28v=vs.85%29.aspx

Well, there are very many devices labeled PNP0C50 in the DSDT.

Do You have many touchpads (for example for the function buttons)?
Comment 78 Srihari Vijayaraghavan 2014-08-07 12:21:04 UTC
(In reply to Mateusz Jończyk from comment #75)
> Which driver on Windows supports the touchpad?

Looking in the Windows 8.1 device manager, it reports to be managed by ELAN PS/2 Port Smart-Pad driver version 11.14.5.2 dated 2013-12-06, which is digitally signed by MS.
Comment 79 Mateusz Jończyk 2014-08-07 12:26:22 UTC
There was something going with this on 
https://lkml.org/lkml/2012/7/4/292

Do You have CONFIG_I2C_HID enabled?

Some such driver is written
http://lxr.free-electrons.com/source/drivers/hid/i2c-hid/i2c-hid.c

We must be a bit cautious because the BIOS EEPROM may be connected to the i2c bus and we must not try to drive it as a touchpad because it may modify its contents.

This is also interesting
http://msdn.microsoft.com/en-us/library/windows/hardware/jj191738%28v=vs.85%29.aspx

This also looks sensibly:
"This combined support for I2C over HID in the inbox driver, allows hardware manufactures to get their devices running quickly on windows without imposing the need to create a driver."


Give me Your /proc/interrupts  when the touchpad is working.

Boot with hid.debug=1 and gimme dmesg when the toucpad is working.

I hope that YOu have CONFIG_PRINTK on
Comment 80 Srihari Vijayaraghavan 2014-08-07 12:30:08 UTC
(In reply to Mateusz Jończyk from comment #77)
> This is additionally interesting:
> http://msdn.microsoft.com/en-us/library/windows/hardware/jj127210%28v=vs.
> 85%29.aspx
> 
> Well, there are very many devices labeled PNP0C50 in the DSDT.
> 
> Do You have many touchpads (for example for the function buttons)?

Well there is one touchpad as you'd have seen on the user manual picture for this Gigabyte P35G v2 model laptop.

As for Fn combinations of keys, yes, there're many of them - all of F1 to F12 do something when pressed together with Fn key, such as turing Wi-Fi on or off, Bluetooth on or off, screen brightness increase or decrease, speaker volume increase or decrease or mute etc. Interestingly there is one for locking or unlocking the touch pad itself (so that moving your palm over it or accidentally touching it takes no action).

Thanks
Comment 81 Mateusz Jończyk 2014-08-07 12:33:47 UTC
CCing benjamin.tissoires@gmail.com because He wrote the HID i2c driver.

Benjamin, here we have an Elantech touchpad that is currently detected only through the PS2 port and there it "sometimes" work.

It works if restarted from Windows into Linux quickly after the Windows desktop loads and then only if the computer was not shut down.
It works reliably across suspend and restarts, but not shut downs.

Currently the driver is detected and used only through PS/2.
Probably Your driver was not compiled in when the dmesgs were made, but it also didn't detect the touchpad when a distro kernel was used.


(In reply to Srihari Vijayaraghavan from comment #78)
> Looking in the Windows 8.1 device manager, it reports to be managed by ELAN
> PS/2 Port Smart-Pad driver version 11.14.5.2 dated 2013-12-06, which is
> digitally signed by MS.
Do You have HIDI2C.SYS anywhere connected with this touchpad?
Comment 82 Srihari Vijayaraghavan 2014-08-07 12:43:57 UTC
(In reply to Mateusz Jończyk from comment #79)
> There was something going with this on 
> https://lkml.org/lkml/2012/7/4/292
> 
> Do You have CONFIG_I2C_HID enabled?

Yes

> 
> Give me Your /proc/interrupts  when the touchpad is working.
> 
> Boot with hid.debug=1 and gimme dmesg when the toucpad is working.
> 
> I hope that YOu have CONFIG_PRINTK on

Yes. Both dmesg (when Elantech is working) & /proc/interrupts are attached in the next entry. Both under vanilla 3.16.0, with no added patches whatsoever.
Comment 83 Srihari Vijayaraghavan 2014-08-07 12:44:55 UTC
Created attachment 145381 [details]
dmesg with i8042.debug when Elantech is working
Comment 84 Srihari Vijayaraghavan 2014-08-07 12:45:35 UTC
Created attachment 145391 [details]
/proc/interrupts
Comment 85 Mateusz Jończyk 2014-08-07 12:53:17 UTC
(In reply to Srihari Vijayaraghavan from comment #83)
> Created attachment 145381 [details]
> dmesg with i8042.debug when Elantech is working

I meant hid.debug=1, not i8042.debug

Please make sure that You have the i2c HID driver compiled in or as a module and the Elantech driver also.
Please enable CONFIG_DYNAMIC_DEBUG. That's why we did not see any Elantech debug msgs.
Comment 86 Mateusz Jończyk 2014-08-07 13:07:11 UTC
(In reply to Srihari Vijayaraghavan from comment #84)
> Created attachment 145391 [details]
> /proc/interrupts
Nice. The interrupts claimed by ACPI to the touchpad are unused.
Comment 87 Srihari Vijayaraghavan 2014-08-07 13:16:04 UTC
(In reply to Mateusz Jończyk from comment #85)
> (In reply to Srihari Vijayaraghavan from comment #83)
> > Created attachment 145381 [details]
> > dmesg with i8042.debug when Elantech is working
> 
> I meant hid.debug=1, not i8042.debug
> 
> Please make sure that You have the i2c HID driver compiled in or as a module
> and the Elantech driver also.
> Please enable CONFIG_DYNAMIC_DEBUG. That's why we did not see any Elantech
> debug msgs.

I've all of things complied in. However, when I supply hid.debug, the system fails to boot successfully. It doesn't show any boot up messages whatsoever, including the graphical Tux. The system fans spin crazily. Interestingly, the very same kernel boots & works when I eliminate hid.debug kernel parameter.

Sorry.
Comment 88 Mateusz Jończyk 2014-08-07 13:16:40 UTC
(In reply to Srihari Vijayaraghavan from comment #80)
> Interestingly there is one for
> locking or unlocking the touch pad itself (so that moving your palm over it
> or accidentally touching it takes no action).

That's possibly implemented in software.
At least the Synaptics driver, in a very good shape does not implement it.
Comment 89 Srihari Vijayaraghavan 2014-08-07 13:20:40 UTC
(In reply to Mateusz Jończyk from comment #88)
> (In reply to Srihari Vijayaraghavan from comment #80)
> > Interestingly there is one for
> > locking or unlocking the touch pad itself (so that moving your palm over it
> > or accidentally touching it takes no action).
> 
> That's possibly implemented in software.
> At least the Synaptics driver, in a very good shape does not implement it.

It works nicely under Linux though. It totally disables the pad (when Elantech is working of course), so that you don't have to fear cursor jumping here and there and making a mess of what you're trying to type (as it happened during this very message). I've come to use this function often when typing something running long over many sentences.
Comment 90 Mateusz Jończyk 2014-08-07 13:28:37 UTC
(In reply to Srihari Vijayaraghavan from comment #87)
> I've all of things complied in. However, when I supply hid.debug, the system
> fails to boot successfully. It doesn't show any boot up messages whatsoever,
> including the graphical Tux. The system fans spin crazily. Interestingly,
> the very same kernel boots & works when I eliminate hid.debug kernel
> parameter.
> 
That's interesting.

This should be filled as a separate bug after we fix that one (hopefully).
The only place when it is really used is:

1071 #define dbg_hid(format, arg...)                                         \
1072 do {                                                                    \
1073         if (hid_debug)                                                  \
1074                 printk(KERN_DEBUG "%s: " format, __FILE__, ##arg);      \
1075 } while (0)
Comment 91 Mateusz Jończyk 2014-08-07 13:29:57 UTC
Created attachment 145401 [details]
[PATCH] Enable i2c Hid debugging

Please build with this patch.
Comment 92 Benjamin Tissoires 2014-08-07 15:06:11 UTC
I went through all the comments of this bug, and I don't think that the touchpad is using i2c-hid. The DSDT apparently shows a lot of i2c-hid devices, and so does the /sys dir, but that does not means that all the declared devices are used/included in the laptop. I have already seen this in an Asus laptop. The OEM just add all of the available touchpads in the market in their DSDT table, so that they do not have to edit the table when using various touchpads/touchscreens.

Anyway, the various /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C3:00/*/status files should return 0 for all of the touchpads whether or not the physical touchpad is working. If one returns 1, i2c-hid should pick it, so I doubt this is the case.

I am trying to understand why the touchpad does not initialize correctly when we poke him, but IMO, the root of the problem lies in the PS/2 code.
Comment 93 Mateusz Jończyk 2014-08-07 17:34:45 UTC
(In reply to Benjamin Tissoires from comment #92)
> I went through all the comments of this bug, and I don't think that the
> touchpad is using i2c-hid. 
Thank You for Your work.
> The DSDT apparently shows a lot of i2c-hid
> devices, and so does the /sys dir, but that does not means that all the
> declared devices are used/included in the laptop. I have already seen this
> in an Asus laptop. The OEM just add all of the available touchpads in the
> market in their DSDT table, so that they do not have to edit the table when
> using various touchpads/touchscreens.
Yep, in the DSDT there are 3 entries for Elantech, entries for Cypress, for Synaptics, etc.
> 
> Anyway, the various
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C3:00/*/status files
> should return 0 for all of the touchpads whether or not the physical
> touchpad is working. If one returns 1, i2c-hid should pick it, so I doubt
> this is the case.
> 
> I am trying to understand why the touchpad does not initialize correctly
> when we poke him, but IMO, the root of the problem lies in the PS/2 code.

We could probably reset (send 0xd4 0xff) the device before trying to identify it.

http://www.win.tue.nl/~aeb/linux/kbd/scancodes-13.html - here is some identification protocol described, it tells to reset the device before identification.
Comment 94 Mateusz Jończyk 2014-08-07 17:35:52 UTC
Created attachment 145511 [details]
[DO NOT APPLY] Unfinished patch to reset the device

There is a patch to reset the mouse / touchpad before identification.
We will see if it responds, when the touchpad does not it is deaf for all purposes.

It is unfinished so please do not judge me based on it.
Comment 95 Benjamin Tissoires 2014-08-07 17:39:33 UTC
There are some differences between the working and non working dmesgs regarding the mux capability of the i8042 controller.
Srihari, can you try booting the kernel with "i8042.nomux=1"? If it does not work, try "i8042.reset=1". And if it does not work, try both.

Of course, when the laptop is on a cold boot :)
Comment 96 Mateusz Jończyk 2014-08-07 17:47:13 UTC
Nope, both didn't help. It was mentioned above.

The controller does not have mux. Even when the mouse is working, it does not use it.
I have made diffs of the i8042 output in both states.
Analyzed the i8042 output extensively and found not much interesting except for that:

  at 0x60,0x64 irq 1,12 //start of i8042 initialization
  d1 -> i8042 (command)
  df -> i8042 (parameter)
  ff -> i8042 (command)
  c4 <- i8042 (flush, kbd)
  20 -> i8042 (command)
  65 <- i8042 (return)
  20 -> i8042 (command)
+ fa <- i8042 (return)
+ 20 -> i8042 (command)
+ 65 <- i8042 (return)
+ 20 -> i8042 (command)
  65 <- i8042 (return)
  60 -> i8042 (command)
  74 -> i8042 (parameter)
  d3 -> i8042 (command)
  5a -> i8042 (parameter)

It happened when it worked. I have seen this only on this one log.


AUX interrupts are delivered, it was checked separately.
Comment 97 Mateusz Jończyk 2014-08-07 17:48:06 UTC
Created attachment 145521 [details]
Diff after grepping i8042 and some cutting
Comment 98 Mateusz Jończyk 2014-08-07 17:49:50 UTC
Created attachment 145531 [details]
Same but as plaintext
Comment 99 Mateusz Jończyk 2014-08-07 17:55:00 UTC
Created attachment 145541 [details]
My analysis, partially translated
Comment 100 Mateusz Jończyk 2014-08-07 17:57:11 UTC
(In reply to Mateusz Jończyk from comment #96)
> Analyzed the i8042 output extensively and found not much interesting except
> for that:
> 
[...]
Oh, and this:

  f2 -> i8042 (kbd-data)
  fa <- i8042 (interrupt, 0, 1)
- fa <- i8042 (interrupt, 0, 1)
+ 65 <- i8042 (interrupt, 0, 1)
  60 -> i8042 (command)
  46 -> i8042 (parameter)
  60 -> i8042 (command)
  47 -> i8042 (parameter)

But there are two machines so this is not a hardware failure.
Comment 101 Benjamin Tissoires 2014-08-07 17:58:13 UTC
(In reply to Mateusz Jończyk from comment #96)
> Analyzed the i8042 output extensively and found not much interesting except
> for that:
> 
>   at 0x60,0x64 irq 1,12 //start of i8042 initialization
>   d1 -> i8042 (command)
>   df -> i8042 (parameter)
>   ff -> i8042 (command)
>   c4 <- i8042 (flush, kbd)
>   20 -> i8042 (command)
>   65 <- i8042 (return)
>   20 -> i8042 (command)
> + fa <- i8042 (return)
> + 20 -> i8042 (command)
> + 65 <- i8042 (return)
> + 20 -> i8042 (command)
>   65 <- i8042 (return)
>   60 -> i8042 (command)
>   74 -> i8042 (parameter)
>   d3 -> i8042 (command)
>   5a -> i8042 (parameter)
> 

this does not seems to be very important. The function i8042_controller_init() waits for receiving twice the same answer to its I8042_CMD_CTL_RCTR before continuing.

The problem comes that psmouse_probe() is not called at all (it should be called by psmouse_connect()). There are no traces of psmouse trying to ping the touchpad to guess its protocol.

My suggestion would be to add some debug information to check that psmouse_connect() and psmouse_probe() are actually called. And if they are not, try to debug where they are cut short.
Comment 102 Mateusz Jończyk 2014-08-07 18:02:29 UTC
(In reply to Benjamin Tissoires from comment #101)
> The problem comes that psmouse_probe() is not called at all (it should be
> called by psmouse_connect()). There are no traces of psmouse trying to ping
> the touchpad to guess its protocol.
> 
> My suggestion would be to add some debug information to check that
> psmouse_connect() and psmouse_probe() are actually called. And if they are
> not, try to debug where they are cut short.

The touchpad is deaf and dead when it does not work.
It can be seen in the logs, it does not return a single byte.

Probably it is some driver core infrastructure that calls 0xf2 on the mouse which does not respond and the driver core gives up.
Comment 103 Benjamin Tissoires 2014-08-07 18:15:21 UTC
(In reply to Mateusz Jończyk from comment #102)
> The touchpad is deaf and dead when it does not work.
> It can be seen in the logs, it does not return a single byte.

What I read in case the touchpad is not working is that no one is trying to read from it. The irq might not be even requested, so no one can get events from it. It might be a command missing, but to me the problem lies after the i8042 controller has been initilized.

BTW your analysis is correct (minus the translations that I could not check), so the problem comes later when the psmouse driver tries to probe the touchpad.
Comment 104 Dmitry Torokhov 2014-08-07 18:25:15 UTC
The very first thing we do when probing PS/2 keyboard and/or mouse is issue GETID (F2) command. If the device does not respond with data that we consider valid keyboard or mouse ID we do not touch that device anymore.
Comment 105 Dmitry Torokhov 2014-08-07 18:29:12 UTC
(In reply to Benjamin Tissoires from comment #103)
> (In reply to Mateusz Jończyk from comment #102)
> > The touchpad is deaf and dead when it does not work.
> > It can be seen in the logs, it does not return a single byte.
> 
> What I read in case the touchpad is not working is that no one is trying to
> read from it.

We are trying - if you see there is a sequence of D4 F2 being sent out. That's sending GETID through AUX port. Unfortunately there is no response from the touchpad so psmouse does not bind to the serio port.

(In reply to Benjamin Tissoires from comment #103)
> The irq might not be even requested

IRQ is requested and owned by i8042 driver, not by psmouse or atkbd.
Comment 106 Mateusz Jończyk 2014-08-07 18:34:31 UTC
It may be like in http://mjg59.dreamwidth.org/3561.html - some 

(In reply to Benjamin Tissoires from comment #103)
> (In reply to Mateusz Jończyk from comment #102)
> What I read in case the touchpad is not working is that no one is trying to
> read from it. The irq might not be even requested, so no one can get events
> from it. It might be a command missing, but to me the problem lies after the
> i8042 controller has been initilized.
> 
The IRQ is delivered and this is confirmed when the laptop does not work.
[    1.327225] i8042: [2] 20 -> i8042 (command)
[    1.327448] i8042: [2] 54 <- i8042 (return)
[    1.327471] i8042: [2] 60 -> i8042 (command)
[    1.327530] i8042: [2] 56 -> i8042 (parameter)
[    1.327644] i8042: [2] d3 -> i8042 (command)
[    1.327757] i8042: [2] a5 -> i8042 (parameter)
[    1.327995] i8042: [3] a5 <- i8042 (aux_test_irq, aux)
[    1.328035] i8042: [3] 60 -> i8042 (command)
[    1.328097] i8042: [3] 74 -> i8042 (parameter)
[    1.328227] i8042: [3] d3 -> i8042 (command)

Additionally, IRQs are not strictly neccessary and polling may be used.
My WIP patch should definitely check whether the device is sending something.

> BTW your analysis is correct (minus the translations that I could not
> check), so the problem comes later when the psmouse driver tries to probe
> the touchpad.

(In reply to Dmitry Torokhov from comment #104)
> The very first thing we do when probing PS/2 keyboard and/or mouse is issue
> GETID (F2) command. If the device does not respond with data that we
> consider valid keyboard or mouse ID we do not touch that device anymore.
It isn't true:

 d4 -> i8042 (command)
 f2 -> i8042 (parameter)                      //probe
 ab <- i8042 (interrupt, 0, 1)
 83 <- i8042 (interrupt, 0, 1)
 d4 -> i8042 (command)                        //???
 ed -> i8042 (parameter)
 60 -> i8042 (command)
 45 -> i8042 (parameter)
 60 -> i8042 (command)
 47 -> i8042 (parameter)
 d4 -> i8042 (command)                         //reset
 ff -> i8042 (parameter)
 60 -> i8042 (command)
 45 -> i8042 (parameter)
 60 -> i8042 (command)
 47 -> i8042 (parameter)
 f2 -> i8042 (kbd-data)
Comment 107 Mateusz Jończyk 2014-08-07 18:36:14 UTC
(In reply to Mateusz Jończyk from comment #106)
> (In reply to Dmitry Torokhov from comment #104)
> > The very first thing we do when probing PS/2 keyboard and/or mouse is issue
> > GETID (F2) command. If the device does not respond with data that we
> > consider valid keyboard or mouse ID we do not touch that device anymore.
> It isn't true:
Please excuse me for being so blatant.

I can't swear that this output is from an unpatched kernel, but probably yes.
Comment 108 Dmitry Torokhov 2014-08-07 18:59:16 UTC
(In reply to Mateusz Jończyk from comment #107)
> (In reply to Mateusz Jończyk from comment #106)
> > (In reply to Dmitry Torokhov from comment #104)
> > > The very first thing we do when probing PS/2 keyboard and/or mouse is
> issue
> > > GETID (F2) command. If the device does not respond with data that we
> > > consider valid keyboard or mouse ID we do not touch that device anymore.
> > It isn't true:
> Please excuse me for being so blatant.
> 
> I can't swear that this output is from an unpatched kernel, but probably yes.

OK, you are right. Atkbd, when it does not get GETID response, also tries to toggle leds on the device.

Now the really weird thing is that we are asking for ID device on AUX port but apparently keyboard is responding to our query (with valid ID). It's like BIOS is really confused where to route the data.
Comment 109 Mateusz Jończyk 2014-08-07 20:26:37 UTC
We could just disable keyboard when probing for mouse or possibly completely.

This may also be interesting if ACPI is suspected.
http://msdn.microsoft.com/en-us/library/windows/hardware/ff538017%28v=vs.85%29.aspx

(debuggin ACPI code on Windows)
Comment 110 Mateusz Jończyk 2014-08-08 07:19:14 UTC
Could YOu try booting with i8042.nokbd=1 ?
Please give logs if that helps (or if it doesnt).
Comment 111 Srihari Vijayaraghavan 2014-08-08 09:08:51 UTC
Created attachment 145701 [details]
dmesg with i8042.nokbd

(In reply to Mateusz Jończyk from comment #110)
> Could YOu try booting with i8042.nokbd=1 ?
> Please give logs if that helps (or if it doesnt).

i8042.nokbd (as per Documentation/kernel-parameters.txt i8042.* parameters don't accept =0 or =1 etc.) disabled the keyboard altogether. It didn't help the trackpad either.

Anyway, I've extracted dmesg out of syslog records, so there might be other nuisance entries there.
Comment 112 Mateusz Jończyk 2014-08-08 09:26:36 UTC
Please excuse me, please give me the above one with i8042.debug=1.
Comment 113 Srihari Vijayaraghavan 2014-08-08 10:10:13 UTC
Created attachment 145711 [details]
dmesg with i8042.debug & i8042.nokbd

(In reply to Mateusz Jończyk from comment #112)
> Please excuse me, please give me the above one with i8042.debug=1.

Done (with both i8042.debug & i8042.nokbd)
Comment 114 Srihari Vijayaraghavan 2014-08-08 10:14:15 UTC
Created attachment 145721 [details]
dmesg with i8042.debug & i8042.nokbd (but after Windows 8.1 activating elantech)

This is after activating Elantech on Windows 8.1 and when booted kernel with i8042.debug & i8042.nokbd. Although Elantech didn't work, but surprisingly it worked after rebooting from within Linux, without i8042.nokbd. In other words, once Windows activates it, even if it gets disabled under Linux due to i8042.nokbd, upon rebooting Linux without i8042.nokbd, it works. (i.e., it remembers it :-))
Comment 115 Mateusz Jończyk 2014-08-08 11:29:16 UTC
It's interesting but I don't have time now.
Comment 116 Mateusz Jończyk 2014-08-08 11:49:35 UTC
Does rmmod i8042 rmmod psmouse insmod psmouse insmod i8042 help?
Comment 117 Mateusz Jończyk 2014-08-08 21:28:45 UTC
(In reply to Srihari Vijayaraghavan from comment #114)
> Created attachment 145721 [details]
> dmesg with i8042.debug & i8042.nokbd (but after Windows 8.1 activating
> elantech)
In this log the mouse "deafens" after some time.

[    7.331643] i8042: [6101] d4 -> i8042 (command)
[    7.331712] i8042: [6101] e8 -> i8042 (parameter)
[    7.531853] i8042: [6301] d4 -> i8042 (command)
[    7.531921] i8042: [6301] e9 -> i8042 (parameter)
[    7.932317] i8042: [6701] d4 -> i8042 (command)
[    7.932385] i8042: [6701] e8 -> i8042 (parameter)
[    8.132547] i8042: [6901] d4 -> i8042 (command)
[    8.132718] i8042: [6901] e8 -> i8042 (parameter)
[    8.332794] i8042: [7101] d4 -> i8042 (command)
[    8.332861] i8042: [7101] e8 -> i8042 (parameter)
[    8.533997] i8042: [7302] d4 -> i8042 (command)
[    8.534064] i8042: [7302] e8 -> i8042 (parameter)

Its input isn't routed to the keyboard as previously. It cant be because we have no keyboard. 
It does this just after

[    1.313235] i8042: [89] d4 -> i8042 (command)
[    1.313299] i8042: [89] f2 -> i8042 (parameter)
[    1.316311] i8042: [92] fa <- i8042 (interrupt, 1, 12)
[    1.317898] i8042: [93] 00 <- i8042 (interrupt, 1, 12)
Comment 118 Mateusz Jończyk 2014-08-08 21:29:07 UTC
(In reply to Mateusz Jończyk from comment #116)
> Does rmmod i8042 rmmod psmouse insmod psmouse insmod i8042 help?

Please ignore it.
Comment 119 Mateusz Jończyk 2014-08-08 21:45:12 UTC
We may just write to Gigabyte and ask them for support.

OK, I get this.
Just looked at the logs again.
We are not really enabling the AUX port

int i8042_enable_aux_port(void) should send 0xa8 "Enable second PS/2 port " separately from setting the control reg.

It was done previously byt appparently the controller got confused.
Comment 120 Mateusz Jończyk 2014-08-08 21:49:21 UTC
Created attachment 145921 [details]
Enable
Comment 121 Srihari Vijayaraghavan 2014-08-09 03:44:55 UTC
Created attachment 145931 [details]
dmesg after above i8042 patch when elantech not working
Comment 122 Srihari Vijayaraghavan 2014-08-09 04:28:33 UTC
Just an observation: When Elantech isn't working, at that time, when I use Fn key combinations, though those functions work (such as mute/unmute speaker, increase/decrease speaker volume, increase/decrease display brightness etc.), these errors are logged by the kernel:
[   37.160508] atkbd serio0: Unknown key pressed (translated set 2, code 0x65 on isa0060/serio0).
[   37.160515] atkbd serio0: Use 'setkeycodes 65 <keycode>' to make it known.
[   37.313601] atkbd serio0: Unknown key released (translated set 2, code 0x65 on isa0060/serio0).
[   37.313606] atkbd serio0: Use 'setkeycodes 65 <keycode>' to make it known.

When Elantech is working, obviously those errors don't appear.
Comment 123 Mateusz Jończyk 2014-08-09 12:15:42 UTC
Created attachment 145951 [details]
Read internal memory and do some other things
Comment 124 Mateusz Jończyk 2014-08-09 12:18:21 UTC
(In reply to Srihari Vijayaraghavan from comment #122)
> Just an observation: When Elantech isn't working, at that time, when I use
> Fn key combinations, though those functions work (such as mute/unmute
> speaker, increase/decrease speaker volume, increase/decrease display
> brightness etc.), these errors are logged by the kernel:
> [   37.160508] atkbd serio0: Unknown key pressed (translated set 2, code
> 0x65 on isa0060/serio0).
> [   37.160515] atkbd serio0: Use 'setkeycodes 65 <keycode>' to make it known.
> [   37.313601] atkbd serio0: Unknown key released (translated set 2, code
> 0x65 on isa0060/serio0).
> [   37.313606] atkbd serio0: Use 'setkeycodes 65 <keycode>' to make it known.
> 
> When Elantech is working, obviously those errors don't appear.
Are You sure?

Dmesgs without i8042.debug are useless to me (but do not repeat the test from comment 121)
To debug this (*only* if it really is related to the touchpad) please give me dmesgs with the lines where YOu press the buttons marked.
Comment 125 Mateusz Jończyk 2014-08-09 12:20:24 UTC
(In reply to Mateusz Jończyk from comment #123)
> Created attachment 145951 [details]
> Read internal memory and do some other things

There is a really slight possibility that this will confuse the i8042 and taking the battery out will be needed.
Comment 126 Srihari Vijayaraghavan 2014-08-09 12:26:03 UTC
(In reply to Mateusz Jończyk from comment #125)
> (In reply to Mateusz Jończyk from comment #123)
> > Created attachment 145951 [details]
> > Read internal memory and do some other things
> 
> There is a really slight possibility that this will confuse the i8042 and
> taking the battery out will be needed.

Unfortunately, the battery is integrated, i.e., not user replaceable. I think that's the standard these days with li-polymer.

Is this risk worth taking? :-)
Comment 127 Mateusz Jończyk 2014-08-09 12:30:03 UTC
Created attachment 145961 [details]
Read internal memory of the 8042 and many other things

Read internal memory of the 8042 and many other things

This is much safer.
It just prints the debug dump.
Comment 128 Srihari Vijayaraghavan 2014-08-09 12:34:55 UTC
(In reply to Mateusz Jończyk from comment #127)
> Created attachment 145961 [details]
> Read internal memory of the 8042 and many other things
> 
> Read internal memory of the 8042 and many other things
> 
> This is much safer.
> It just prints the debug dump.

It compiled, but printed this warning:

  CC      drivers/input/serio/i8042.o
drivers/input/serio/i8042.c: In function ‘i8042_check_aux’:
drivers/input/serio/i8042.c:804:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
         unsigned char output[10];
         ^
drivers/input/serio/i8042.c:809:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
         int ii = 0;
         ^
Anyway, testing it out. Fingers crossed.
Comment 129 Mateusz Jończyk 2014-08-09 12:39:11 UTC
(In reply to Srihari Vijayaraghavan from comment #126)
> 
> Is this risk worth taking? :-)

Well, I am probably paranoid in these things a bit and careful more than is necessary.

Also worth noting:
"	64h  write  8042 command register.  Writing this port sets Bit 3
		    of the status register to 1 and the byte is treated
		    as a controller command.  Devices attached to the
		    8042 should be disabled before issuing commands that
		    return data since data in the output register will
		    be overwritten."

The above patch tries to reset the mouse very early, before the keyboard is enabled.
Comment 130 Mateusz Jończyk 2014-08-09 12:39:58 UTC
(In reply to Srihari Vijayaraghavan from comment #128)
>   CC      drivers/input/serio/i8042.o
> drivers/input/serio/i8042.c: In function ‘i8042_check_aux’:
> drivers/input/serio/i8042.c:804:9: warning: ISO C90 forbids mixed
> declarations and code [-Wdeclaration-after-statement]
>          unsigned char output[10];
>          ^
> drivers/input/serio/i8042.c:809:9: warning: ISO C90 forbids mixed
> declarations and code [-Wdeclaration-after-statement]
>          int ii = 0;
>          ^
> Anyway, testing it out. Fingers crossed.

It was predicted. I just didn't care about that.
Comment 131 Mateusz Jończyk 2014-08-09 12:41:15 UTC
A simple powerdown should be really enough in case the controller got confused as it is now - shutting it down resets it and makes the mouse not work.

gimme lspci -vvnn
Comment 132 Srihari Vijayaraghavan 2014-08-09 12:42:14 UTC
You're onto something wonderful here. Your latest patch has the Elantech working after a power off & power on. It never has worked like this before. I'm uploading the current i8042.debug dmesg for you here. I'm going to be doing this power off & booting directly on Linux a few times to confirm the results.
Comment 133 Srihari Vijayaraghavan 2014-08-09 12:46:30 UTC
Created attachment 145971 [details]
dmesg with i8042.debug with the most recent patch where elantech worked after a cold power up
Comment 134 Srihari Vijayaraghavan 2014-08-09 12:55:49 UTC
My friend you've done it! You've fixed this notorious problem for good. With your patch (which I'm enclosing in the next entry) Elantech worked three times straight after a complete power down & power up. I can't thank you enough! :-) I hope your fix works for every Gigabyte/Elantech user facing this problem & I hope they're as thrilled as I humbly am. Thank you.
Comment 135 Srihari Vijayaraghavan 2014-08-09 13:02:01 UTC
Created attachment 145981 [details]
Mateusz Jończyk's patch that fixes Elantech touch pad on Gigabyte laptops (e.g., P35G v2)

All credits to Mateusz Jończyk. With his patch above, the Elantech touch pad on my Gigabyte P35G v2 has worked every time after power up, which it wasn't doing before. Without his patch, the laptop had to be booted on Windows first, then rebooted in Linux. With his patch, however, Elantech touch pad works, when Linux is booted directly after a power down.
Comment 136 Mateusz Jończyk 2014-08-09 13:14:00 UTC
    Well, I have made a mistake in the patch:
            //reset the mouse
            output[0] = 0xff;
            i8042_command(output, 0x12ff);

    Should be:
            i8042_command(output, 0x12d4); - we are sending data to mouse

    The command should really be a nop:
    "Pulse output line low for 6 ms. Bits 0 to 3 are used as a mask (0 = pulse line, 1 = don't pulse line) and correspond to 4 different output lines.

    Note: Bit 0 corresponds to the "reset" line. The other output lines don't have a standard/defined purpose. "
    we set all line bits for 1 (don't pulse line) so this should really be a NOP. Additionally, no response should be given.

    Mysteriously, the device responded with:

    [    1.789711] i8042: [537] ff -> i8042 (command)
    [    1.789773] i8042: [537] ff -> i8042 (parameter)
    [    1.895570] i8042: [537] fa <- i8042 (return)
    [    1.898595] i8042: [537] aa <- i8042 (return)


    We should try to emulate Windows as much as possible. We should have someone with a legal Windows on a qemu (sorry, Srihari, Your does not qualify) run it and check how it accesses the keyboard controller - in which particular sequence and try to do it in the exact some way.
    This should fix this and other similar bugs.
      

Now we will have to narrow down what really fixed the issue.
Comment 137 Mateusz Jończyk 2014-08-09 13:19:10 UTC
(In reply to Srihari Vijayaraghavan from comment #135)
> All credits to Mateusz Jończyk. With his patch above, the Elantech touch pad
> on my Gigabyte P35G v2 has worked every time after power up, which it wasn't
> doing before. 

Dmitry and Benjamin helped me narrow down the issue and directed my searches appropriately.
It would all not be possible with such a dedicated bug reporter. I have been looking at another issue recently that seems much easier to debug and much more important (sorry, Srihari, just present on more popular laptops) and not given a response back even though it had two separate bugs on Launchapd and a bug here.

It seems that You will make a good kernel hacker.
Comment 138 Mateusz Jończyk 2014-08-10 08:31:22 UTC
(In reply to Mateusz Jończyk from comment #136)
> 
>     Mysteriously, the device responded with:
> 
>     [    1.789711] i8042: [537] ff -> i8042 (command)
>     [    1.789773] i8042: [537] ff -> i8042 (parameter)
>     [    1.895570] i8042: [537] fa <- i8042 (return)
>     [    1.898595] i8042: [537] aa <- i8042 (return)
> 
The 8042 was not waiting for any parameter so the second "ff" went straight to the keyboard controller and told it to reset.
The keyboard controller (even though it probably was disabled - I won't analyse it further now) answered with fa aa - according to the spec the "fa" should not be there, but it is probably just a mistake in the embedded controller.
Comment 139 Mateusz Jończyk 2014-08-10 08:33:01 UTC
Created attachment 146021 [details]
Never-disable-the-AUX-port

If You would like, I may provide a patch relative to Your current (patched) kernel source tree that reverts rest of the modifications.
Comment 140 Srihari Vijayaraghavan 2014-08-10 09:28:24 UTC
With git, life has never been simple to clone any version you like :-).

Anyway, the above patch is no-go. Only your patch as per my comment 135 and attachment 145981 [details] works. I've tested it no less than 20 times by now. It's a winner, every time without fail.

I'm happy to test a refined version of that working patch for you. No problem. It's preferable, however, if it's against 3.16.0 & we work against that stable tree (or any of 3.16.x to come, as mainline 3.17 is in highly volatile state till perhaps it reaches -rc6 or -rc7 etc.).

Thanks
Comment 141 Mateusz Jończyk 2014-08-10 10:08:59 UTC
Created attachment 146031 [details]
Test-the-second-port-of-8042

(In reply to Srihari Vijayaraghavan from comment #140)
> With git, life has never been simple to clone any version you like :-).
For me also. Diffing manually was really painful.
 
> I'm happy to test a refined version of that working patch for you. No
> problem. It's preferable, however, if it's against 3.16.0 & we work against
> that stable tree (or any of 3.16.x to come, as mainline 3.17 is in highly
> volatile state till perhaps it reaches -rc6 or -rc7 etc.).
Yeah, of course.

Please test this patch.
Comment 142 Srihari Vijayaraghavan 2014-08-10 10:35:45 UTC
Unfortunately, the above patch all by itself against vanilla 3.16.0 is still no-go. Obviously, there's some snippet of patch in attachment 145981 [details] or all of it is helping my problem.
Comment 143 Mateusz Jończyk 2014-08-10 12:09:28 UTC
Created attachment 146111 [details]
Reset kbd
Comment 144 Srihari Vijayaraghavan 2014-08-10 12:41:44 UTC
Sorry, with that patch applied over vanilla 3.16.0, kernel compilation fails:

drivers/input/serio/i8042.c: In function ‘i8042_check_aux’:
drivers/input/serio/i8042.c:795:9: warning: passing argument 1 of ‘i8042_kbd_write’ makes pointer from integer without a cast [enabled by default]
         i8042_kbd_write(0xff);
         ^
drivers/input/serio/i8042.c:317:12: note: expected ‘struct serio *’ but argument is of type ‘int’
 static int i8042_kbd_write(struct serio *port, unsigned char c)
            ^
drivers/input/serio/i8042.c:795:9: error: too few arguments to function ‘i8042_kbd_write’
         i8042_kbd_write(0xff);
         ^
drivers/input/serio/i8042.c:317:12: note: declared here
 static int i8042_kbd_write(struct serio *port, unsigned char c)
            ^
make[2]: *** [drivers/input/serio/i8042.o] Error 1
make[1]: *** [drivers/input/serio] Error 2
make[1]: *** Waiting for unfinished jobs....
Comment 145 Mateusz Jończyk 2014-08-10 13:11:57 UTC
Created attachment 146121 [details]
Reset kbd
Comment 146 Srihari Vijayaraghavan 2014-08-10 13:30:05 UTC
Mateusz, indeed your patch above in attachment 146121 [details] does fix the problem with Elantech touch pad never working after a cold boot in Linux.

From what I can see, it is very small & simple. Therefore, hopefully it'd be accepted in mainline (and stable) in some form or other (which will eventually trickle down to many distribution kernels).

Thank you for all your efforts to solve this problem. Am sure all Gigabyte/Elantech Linux users would highly appreciate your efforts in fixing this obnoxious bug. Well done!

Once again, I'm happy to test any other patch you (or anybody on this thread) may propose in this connection.
Comment 147 Mateusz Jończyk 2014-08-10 13:49:40 UTC
Created attachment 146141 [details]
Reset mouse

Please test this.
Comment 148 Mateusz Jończyk 2014-08-10 13:51:13 UTC
(In reply to Srihari Vijayaraghavan from comment #146)
> Mateusz, indeed your patch above in attachment 146121 [details] does fix the
> problem with Elantech touch pad never working after a cold boot in Linux.
> 
> From what I can see, it is very small & simple. Therefore, hopefully it'd be
> accepted in mainline (and stable) in some form or other (which will
> eventually trickle down to many distribution kernels).
Unfortunately it won't be because it resets the keyboard while we initialize the mouse.
This all boils down to small differences in behaviour between Windows and Linux.
See: http://mjg59.dreamwidth.org/3561.html
> 
> Thank you for all your efforts to solve this problem. Am sure all
> Gigabyte/Elantech Linux users would highly appreciate your efforts in fixing
> this obnoxious bug. Well done!
> 
> Once again, I'm happy to test any other patch you (or anybody on this
> thread) may propose in this connection.

Thank You for Your support.
Comment 149 Srihari Vijayaraghavan 2014-08-10 14:09:42 UTC
(In reply to Mateusz Jończyk from comment #147)
> Created attachment 146141 [details]
> Reset mouse
> 
> Please test this.

I had to slightly fix the patch like this to avoid the compilation error:

diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 3807c3e..41cf81a 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -789,6 +789,11 @@ static int __init i8042_check_aux(void)
        if (i8042_toggle_aux(true))
                return -1;
 
+        //reset the mouse
+        unsigned char output = 0xff;
+        i8042_command(&output, 0x12d4);
+
+
 /*
  * Test AUX IRQ delivery to make sure BIOS did not grab the IRQ and
  * used it for a PCI card or somethig else.

With that patch, unfortunately Elantech touch pad didn't work after a cold power on. In other words, it didn't solve the problem. Sorry.
Comment 150 Mateusz Jończyk 2014-08-10 14:20:17 UTC
Could You give me a dmesg with i8042.debug with this?
Comment 151 Srihari Vijayaraghavan 2014-08-10 21:52:40 UTC
Created attachment 146161 [details]
dmesg with i8042.debug

The dmesg produced with the most recent patch from comment #149 applied & i8042.debug kernel parameter.
Comment 152 Mateusz Jończyk 2014-08-11 06:37:13 UTC
I'm sorry, but it doesn't look like YOu had my patch applied.
Comment 153 Mateusz Jończyk 2014-08-11 08:13:10 UTC
Created attachment 146211 [details]
Reset the mouse

I'm sorry but Your modification to the patch caused a stack corruption because i8042_command was prepared to read 2 parameters and so wrote the second one somewhere on the stack.
This can happen to anyone, though.
Comment 154 Srihari Vijayaraghavan 2014-08-11 08:38:02 UTC
Created attachment 146221 [details]
dmesg with i8042.debug

Elantech didn't work when the above patch from comment 153 was applied over stock 3.16.0. The dmesg with i8042.debug is enclosed
Comment 155 Srihari Vijayaraghavan 2014-08-11 09:00:09 UTC
(In reply to Mateusz Jończyk from comment #153)
> Created attachment 146211 [details]
> Reset the mouse
> 
> I'm sorry but Your modification to the patch caused a stack corruption
> because i8042_command was prepared to read 2 parameters and so wrote the
> second one somewhere on the stack.
> This can happen to anyone, though.

Leaving aside the fact that this patch didn't help the problem, I closely checked the definition of i8042_command() and its many invocations all over drivers/input/serio/i8042.c; they all use a pointer to an unsigned char as the first argument as per its definition. So I don't believe I've used it incorrectly at all. Please double check.

(Anyway, this is all besides the point that only patch from attachment 146121 [details] has worked flawlessly, so far.)

Thanks
Comment 156 Mateusz Jończyk 2014-08-11 15:01:17 UTC
(In reply to Srihari Vijayaraghavan from comment #155)
> Leaving aside the fact that this patch didn't help the problem, I closely
> checked the definition of i8042_command() and its many invocations all over
> drivers/input/serio/i8042.c; they all use a pointer to an unsigned char as
> the first argument as per its definition. So I don't believe I've used it
> incorrectly at all. Please double check.
> 
There's some magic involved here.
For example:
        i8042_command(output, 0x12d4);
When we have as a parameter 0x12d4 the actual command (d4) is encoded in the least significant byte.
The two most significant nibbles specify the number of input parameters (1) for the 8042 and the number of bytes to receive (2). 
Therefore where we have something like this:

        param = 0x5a;
        retval = i8042_command(&param, I8042_CMD_AUX_LOOP);
With:
#define I8042_CMD_AUX_LOOP      0x11d3           //include/linux/i8042.h
we only receive one parameter so the invocation is safe.
Commands retuning two bytes are very rare so that's why You didn't found any.
Comment 157 Robert Roth 2014-08-11 19:07:05 UTC
Srihari: are you sure this is not a regression? I also have received a brand new laptop (with an elantech touchpad and a touchscreen), booted up Fedora 20 (with 3.11 kernel in the live image), and the touchpad worked (dmesg elantech mentions unknown version, as opposed to assuming hardware version 4 seen in 3.13+). Booting up anything 3.13, and the touchpad doesn't work at all.
Comment 158 Srihari Vijayaraghavan 2014-08-12 10:22:54 UTC
Robert: In my case it certainly is no regression. I still vividly recollect how I installed Fedora 20 with just keyboard (very painful :-)), for lack of a USB mouse around. Afterwards I discovered a temporary fix of always booting Windows to 'activate' the trackpad for subsequent Linux boot(s). So even a USB mouse can be avoided.

Is it possible you too had previously booted in Windows before trying Fedora Live?

My problem is very simple: After a cold boot, trackpad never works on Linux (without of course the patch from attachment 146121 [details]). So you can easily find out if your problem is identical to mine, by that simple test.

If kernel community is unable to find a workable solution (after all Mateusz Jonczyk has fixed it), rather than using Windows to 'activate' the trackpad, I'm thinking of a simple user space solution (involving a minimal kernel with that patch combined with some boot loader or some scripting to reboot to the distribution kernel or the highest version of the kernel in the boot loader configuration etc., perhaps with modified init=blah parameter for that minimal kernel or invoking a triple fault within the kernel after it has 'activated' trackpad or some such hackery; I'm not that desperate yet, though). We will see how this plays out in the long run. The idea is that although the patch is simple, I don't want to be patching my kernel all the time. So the above work-around might be a better solution in my case.
Comment 159 Srihari Vijayaraghavan 2014-08-12 10:33:22 UTC
To prove it's no regression, I've complied all releases from 3.10 to 3.16 to confirm it didn't work on any of them.

If I find motivation, I might try from 3.0 onward, but I'm not sure, if it'd be fruitful in terms of finding any real solution.

(Yes, I'm aware of Git's bisect functionality, which is quite useful if you know the last working version after which something broke. This might not be useful in this particular case, where I'm leaning towards this not being a regression.)
Comment 160 Robert Roth 2014-08-14 16:33:30 UTC
@Srihari: In the meantime I have also tried booting Windows 8, than rebooting into liveusb (I still haven't installed Linux on the PC, not until I'm sure I can work around the troubles), rebooting to BIOS then booting to the liveUSB from there, but none of them solved the touchpad issue. I have tried Fedora 20 again, and the touchpad works there again, so I must have another issue, sorry for the offtopic messages in this case.
Comment 161 li_qianxiao 2014-08-14 21:37:05 UTC
@Srihari: I am a new Linux user and I think I have the exact same problem as you on my Gigabyte u24f with ubuntu 14.04 installed. I saw that the patch fixed your problem but as a newbie I'm unsure how to apply the patch. Can you please direct me to any reference as to how to apply these kind of patches? Thank you very much!
Comment 162 Srihari Vijayaraghavan 2014-08-15 05:13:15 UTC
(In reply to li_qianxiao from comment #161)
> @Srihari: I am a new Linux user and I think I have the exact same problem as
> you on my Gigabyte u24f with ubuntu 14.04 installed. I saw that the patch
> fixed your problem but as a newbie I'm unsure how to apply the patch. Can
> you please direct me to any reference as to how to apply these kind of
> patches? Thank you very much!

No problem. If you haven't compiled the Linux kernel before, it might sound all complicated, but in reality, with right instructions it is relatively easy to compile it and test it out. It's quite a rewarding experience, if you're up for the challenge. You'd have learned a lot in the end for sure. The overall process is as simple as:
1. Installing the required development tools (gcc, make & ncurses-devel etc.)
2. Downloading the kernel source (from https://www.kernel.org or its mirrors)
3. Applying the patch from attachment 146121 [details] above
4. Compiling the kernel & installing it
5. Booting the new kernel to verify the track pad functionality.
Because it's off topic for this thread, you're welcome to privately email me for any further follow up questions.

I'm happy to assist you with compiling a kernel & troubleshooting the problem further, if you email me (either as per your distribution kernel configuration or a minimal config, such as mine which would most likely work on yours, if our configurations are similar).

Thanks
Comment 163 li_qianxiao 2014-08-16 03:00:32 UTC
Thanks. I'm out of town now. I'll attempt the steps you suggested next week and I'll email you if I run into problems. Thank you very much! 

(In reply to Srihari Vijayaraghavan from comment #162)
> (In reply to li_qianxiao from comment #161)
> > @Srihari: I am a new Linux user and I think I have the exact same problem
> as
> > you on my Gigabyte u24f with ubuntu 14.04 installed. I saw that the patch
> > fixed your problem but as a newbie I'm unsure how to apply the patch. Can
> > you please direct me to any reference as to how to apply these kind of
> > patches? Thank you very much!
> 
> No problem. If you haven't compiled the Linux kernel before, it might sound
> all complicated, but in reality, with right instructions it is relatively
> easy to compile it and test it out. It's quite a rewarding experience, if
> you're up for the challenge. You'd have learned a lot in the end for sure.
> The overall process is as simple as:
> 1. Installing the required development tools (gcc, make & ncurses-devel etc.)
> 2. Downloading the kernel source (from https://www.kernel.org or its mirrors)
> 3. Applying the patch from attachment 146121 [details] above
> 4. Compiling the kernel & installing it
> 5. Booting the new kernel to verify the track pad functionality.
> Because it's off topic for this thread, you're welcome to privately email me
> for any further follow up questions.
> 
> I'm happy to assist you with compiling a kernel & troubleshooting the
> problem further, if you email me (either as per your distribution kernel
> configuration or a minimal config, such as mine which would most likely work
> on yours, if our configurations are similar).
> 
> Thanks
Comment 164 ek0892 2014-09-12 14:59:45 UTC
Me too
Comment 165 Criztian Haunsen 2014-10-09 23:09:19 UTC
This patch has worked in Slackware64 14.1 with kernel 3.10.17.
Running in this ultrabook: http://www.exo.com.ar/content/nifty-touch-t7181

Thanks!
Comment 166 Zakariya Dehlawi 2014-10-10 22:36:20 UTC
Same issue with my Aorus X3 Plus. Which is a Gigabyte brand laptop. Sometimes the trackpad will be detected, sometimes it wont.

The power plug workaround works for me.
1) Power off the laptop
2) Unplug my laptop for 60 seconds
3) Power on the laptop and boot into Linux
4) The trackpad should work
5) Once the Login Manager loads you can plug the power back in

As Srihari pointed out, shutting down or using the power button will disable the trackpad again, but doing a reboot does not.

I have not tried the kernel patch yet.
Comment 167 4nti7rust 2014-10-14 09:33:55 UTC
Hello,

I also have a U24F Gigabyte under Archlinux and the exact same problem with my touchpad. I will try to compile my own patched kernel tonight and let you know if this solve the problem.

I'm not well aware of the usual timeline, but when do you think this patch will be applied to the mainline kernel version ?

Also I am curious, how to you manage to find what was wrong ? Did you "disassembles" the windows drivers ?

Thanks for your help.
Comment 168 Mateusz Jończyk 2014-10-15 10:18:34 UTC
(In reply to 4nti7rust from comment #167)
> I'm not well aware of the usual timeline, but when do you think this patch
> will be applied to the mainline kernel version ?
This patch is quite hacky and therefore unsuitable for mainline. I'm sorry, but do not have time now to work on this issue. We could try to reset the keyboard in some other place, for example.

> Also I am curious, how to you manage to find what was wrong ? Did you
> "disassembles" the windows drivers ?
Just trial and error together with pure luck. I made a mistake in one patch that send to Srihari to test and it worked (due to the mistake).
Comment 169 Mateusz Jończyk 2014-10-15 10:24:23 UTC
Created attachment 153821 [details]
A patch that makes the touchpad work

I am obsoleting all other patches to make finding the correct one easier.
Comment 170 ek0892 2014-11-26 10:01:26 UTC
Hi,

Please, is it possible to explain step by step to install this patch?


1) download this patch in a file ?
2) patch -p1 < file  ?
3) reboot ?

this OK ?


Best regards
Eric
Comment 171 Srihari Vijayaraghavan 2014-12-01 02:09:52 UTC
Hello Eric,

It's a bit more involved in terms of compiling a kernel from the source tree. These are some simple steps that might help you:

(Until it's stated explicitly, you don't need root privileges to perform a given task below.)
 
1. Download kernel source code from www.kernel.org (e.g., linux-3.17.4.tar.xz, which is the most recent stable kernel release) & untar it (say in your home directory):
    tar xJf linux-3.17.4.tar.xz

2. Download the patch (https://bugzilla.kernel.org/attachment.cgi?id=153821&action=diff&context=patch&collapsed=&headers=1&format=raw) to your home directory as say elantech-final.patch and then apply it:
    cd linux-3.17.4 (assuming this is the directory where the kernel source was untarred)
    cat ~/elantech-final.patch | patch -p1   (if there is an error message, then something went wrong)

3. You can start off with your distribution's .config as a starting point (although they tend to take a lot of time & hard drive space to compile) & customise your kernel further if need be:
    cp /boot/config-<most recent distribution kernel version> .config
    make oldconfig
    make menuconfig (optional step required only if you want to customise it further)

4. Now compile the kernel, kernel modules & install them:
    make bzImage modules  (you can speed it up by something like this: "make -j4 bzImage modules", where make is told to run 4 compiling jobs simultaneously)
    make modules_install install  (this step needs root privileges to work, as it'd be modifying your /boot, /lib file systems & boot loader etc.)

5. Optional: You may validate whether an entry has been added to the boot loader configuration file (if there was no error at the end of step 4, it generally means all has been successful):
    cat /etc/grub2-efi.cfg (where you should see a section for 3.17.4+; that's the location of the EFI compatible grub2 config file in Fedora & it needs root privileges to view; it may be slightly different in your distribution though.)

6. Reboot the laptop & boot the newly installed kernel to confirm whether it boots successfully & the trackpad works.

Good luck. Thanks

PS: You may privately email me, if you need further guidance.
Comment 172 prosf 2014-12-01 23:50:17 UTC
 
The sentelic fingerSensingPad in my laptop works at last :)
Before that I had tried Archlinux Ubuntu and Mint ,with their original kernels , without success.
The touchpad worked only when I was rebooting from Windows.
 
Now with the patched kernel, ubuntu 14.10 runs flawlessly.

My laptop model is branded with many different names around the word .Some of them are: 
Lengda X300 / X300V, Hasee X300 / X300V , Turbo-X Leaf S u5-4256 , Novatech N1402

With as small search I noticed that this bug has been discussed before without any luck(in the 64 bit versions):

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1244643
http://forum.novatech.co.uk/showthread.php?25330-nfinity-i5-laptop-how-can-I-get-the-touchpad-and-wireless-working-with-Ubuntu
http://forum.novatech.co.uk/showthread.php?25382-nFinity-2637-i7-touchpad
http://forum.novatech.co.uk/showthread.php?26038-Is-there-a-BIOS-update-for-the-nfinity-i5-please-moved

Srihari Vijayaraghavan thank you very much for your really helpful guides!
Mateusz Jończyk (and everybody else that helped this bug to get attention)  thanks a lot for this patch!
Comment 173 Srihari Vijayaraghavan 2014-12-17 12:47:45 UTC
Hello Dmitry,

This problem is really impacting a lot of users (I've been contacted by a number of folks already). Based on the original idea/patch of Mateusz, I've produced this patch against mainline for your kind consideration & for its merging into mainline. I've tested it to work just fine.

I'm no kernel wizard, just your regular Linux user. But like many others in this bug report, I'm very much affected by this bug. Therefore this patch has been produced out of dire necessity (might not be out of technical excellence, for sure).

If you think it needs to be worked out differently, please speak up (alas, I might not be able to implement your suggestions, as after all I'm just a Linux user, however, I'd happily send my deeply appreciative thanks and/or a small Paypal donation to whomsoever fixes as per your suggestions, be it even be yourself).

But please don't ignore us. We're really impacted by this problem & would appreciate to see a solution right out of mainline kernel.

PS: I'm attaching the above patch as a file attachment to this bug report.


diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 479f332..261e541 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1270,6 +1270,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
        i8042.notimeout [HW] Ignore timeout condition signalled by controller
        i8042.reset     [HW] Reset the controller during init and cleanup
        i8042.unlock    [HW] Unlock (ignore) the keylock
+       i8042.kbdreset  [HW] Reset keyboard to make trackpad work (in Gigabyte laptops with
+                            Elantech trackpad)
 
        i810=           [HW,DRM]
 
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index f5a98af..fb0c3d8 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -67,6 +67,10 @@ static bool i8042_notimeout;
 module_param_named(notimeout, i8042_notimeout, bool, 0);
 MODULE_PARM_DESC(notimeout, "Ignore timeouts signalled by i8042");
 
+static bool i8042_kbdreset;
+module_param_named(kbdreset, i8042_kbdreset, bool, 0);
+MODULE_PARM_DESC(kbdreset, "Reset keyboard to make trackpad work");
+
 #ifdef CONFIG_X86
 static bool i8042_dritek;
 module_param_named(dritek, i8042_dritek, bool, 0);
@@ -789,6 +793,10 @@ static int __init i8042_check_aux(void)
        if (i8042_toggle_aux(true))
                return -1;
 
+       /* To make trackpad work on many Gigabyte laptop models containg Elantech trackpad */
+       if (i8042_kbdreset)
+               i8042_kbd_write(NULL, (unsigned char) 0xff);
+
 /*
  * Test AUX IRQ delivery to make sure BIOS did not grab the IRQ and
  * used it for a PCI card or somethig else.
Comment 174 Srihari Vijayaraghavan 2014-12-17 12:51:05 UTC
Created attachment 160981 [details]
Patch based on Mateusz Jończyk's patch that fixes Elantech touch pad on Gigabyte laptops (e.g., P35G v2)

Just as per previous comment, the same patch is created as a file attachment here.
Comment 175 Mateusz Jończyk 2014-12-17 21:29:40 UTC
Thank You, Srihari, we really may try to get a similar patch upstream.

We should also provide DMI matches as in:
http://lxr.free-electrons.com/source/drivers/input/serio/i8042-x86ia64io.h#L74
To do this, we should get dmidecode output for all laptop brands affected.
Or we simply may match all Gigabyte laptops made in >= 2014.

This may even be accepted into stable.
Comment 176 Srihari Vijayaraghavan 2014-12-17 23:15:16 UTC
Created attachment 161081 [details]
V1 Patch based on Mateusz Jończyk's patch that fixes Elantech trackpad on many laptops (e.g., Gigabyte P35G v2)

Thanks for the encouragement Mateusz. This is a slightly improved patch containing a warning message. While at it, I've fixed silly typos & made comments a little better.

I'll research into DMI based idea (which, though I had it initially, didn't honestly know where to start off). Thank you for showing me that i8042-x86-ia64.h. I'll try starting off a new table (perhaps called i8042_dmi_kbdreset) of dmi_system_id struct for my Gigabyte laptop & try to invoke that knowledge where we're resetting the keyboard in the above patch.

If it's successful (a big if), besides it simplifying things, am sure other affected users would throw in their IDs too to populate it later.

But in any case, we badly need input maintainers' support for accepting either the current version of the patch or the future dmi based patch. Without any support whatsoever what is the use in investing much energy that would simply go waste?

Thank you.

(PS: Gone are the days when you could simply send a patch to lkml; now there is so much hierarchy and bureaucracy. What can be done, beggars can't be choosers. Therefore, I'm willing to pay, a nominal fee of course, for a patch that certainly would find its way to mainline.)
Comment 177 Srihari Vijayaraghavan 2014-12-19 23:28:36 UTC
Hello Dmitry,

The current version of the patch, as per the suggestions of Mateusz (thank you Mateusz for your original fix), for your consideration is attached to the next entry in this bug report. It works (by dmi based auto detection) nicely on my Gigabyte laptop, fixing the original issue reported here.

Please review it at your earliest convenience & suggest any input (pun intended) you may have. Please keep in mind that I'm just a humble Linux user & am no kernel coder. I've tried to keep things, as far as possible, as per the current conventions of all the files being updated by this patch.

If you're happy with this patch & approach -- which I so sincerely hope you would be -- I kindly request you to get it merged upstream (even including -stable if possible). Thank you & much appreciated.

Srihari Vijayaraghavan
Comment 178 Srihari Vijayaraghavan 2014-12-19 23:31:19 UTC
Created attachment 161431 [details]
Patch based on Mateusz Jończyk's original patch fix that fixes Elantech touch pad on Gigabyte laptops (e.g., P35G v2)

As per the above entry, this is the current version of the patch that fixes the original problem reported in this bug report.
Comment 179 Srihari Vijayaraghavan 2014-12-19 23:54:52 UTC
I'd like to request other users who are affected by the same bug to report whether this patch works for them using i8042.kbdreset=1 kernel parameter (or if it's complied as a module, then its equivalent).

If it does work, you may then report your dmi info (e.g., dmidecode | egrep 'Manufacturer|Product Name' | head -n2) and/or amend the drivers/input/serio/i8042-x86ia64io.h's i8042_dmi_elantech_kbdreset_table[] struct, for automatic application of the fix.

Thank you.
Comment 180 Zakariya Dehlawi 2014-12-20 13:52:46 UTC
Thanks for your persistence on this issue Srihari. I have tested your patch and it resolves the issue with my laptop.

In addition I have tested adding my dmi info to the i8042_dmi_elantech_kbdreset_table and it properly detects my laptop and applies the patch effects. 

I have an Aorus branded Gigabyte X3 Plus laptop. The DMI info is below.

#dmidecode | egrep 'Manufacturer|Product Name' | head -n2
Manufacturer: GIGABYTE
Product Name: X3

Thanks,
Zak
Comment 181 Srihari Vijayaraghavan 2014-12-20 22:00:50 UTC
Created attachment 161491 [details]
V3 Patch based on Mateusz Jończyk's patch that helps detecting Elantech touchpad on many laptops

Thanks Zak. This version of the patch includes your laptop's DMI info. Am sure there are other users, who might respond down the line.

Dmitry, could you please kindly review this patch & consider it for upstream merging? (we'd request for both stable & mainline please)

Thank you.
Comment 182 guillaum.bouchard 2015-01-04 17:15:25 UTC
Hi. Thank you for your work, your patch solve the issue with my computer.

My dmi infos are as following:

sudo dmidecode | egrep 'Manufacturer|Product Name' | head -n2
	Manufacturer: GIGABYTE
	Product Name: P34
Comment 183 Srihari Vijayaraghavan 2015-01-05 08:47:15 UTC
Created attachment 162471 [details]
V4 Patch against mainline based on Mateusz Jończyk's patch that helps detecting Elantech touchpad on many laptops
Comment 184 Srihari Vijayaraghavan 2015-01-05 09:15:07 UTC
Thanks Guillaum. The above patch includes your DMI info.
Comment 185 Ben 2015-01-19 23:11:42 UTC
(In reply to Srihari Vijayaraghavan from comment #184)
> Thanks Guillaum. The above patch includes your DMI info.

Hi,
Do you know if the patch is already merged in the linux kernel ?
Otherwise can someone explain me how to patch it and recompile/install the kernel ?

Thank you for your help

Ben
Comment 186 Srihari Vijayaraghavan 2015-01-20 07:35:52 UTC
Hello Ben,

Yes, the patch has just been merged on Linus's mainstream branch within the last day or two: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=66893885bbf95b6c9030d97804cb678a70804edf

It should be part of the upcoming 3.19-rc6. Because Dmitry has cc'ed stable, it should shortly be accepted into stable kernels too. These are indeed good times for us all affected users :-).

You may use the most recent patch attached to this bug report or you can pull Linus's kernel tree directly as well. Either way follow the guidelines I've given in Comment 171 to compile the kernel.

If either as it is or by using i8042.kbdreset kernel parameter your problem is fixed, then your DMI info (# dmidecode | egrep 'Manufacturer|Product Name' | head -n2) and the brand/model of touchpad your laptop has (should be there in boot log, e.g.: dmesg | egrep serio1) would be very valuable to learn too.

Thanks
Comment 187 Srihari Vijayaraghavan 2015-01-20 12:29:59 UTC
Sorry a small & possibly finally addendum :-):

On a kernel (e.g., post 3.19-rc5) with this fix, it takes effect either automatically (if DMI info is already in i8042_dmi_kbdreset_table[] in drivers/input/serio/i8042-x86ia64io.h) or it can be manually enforced by using kernel boot parameter i8042.kbdreset=1. Either way, there will be a kernel message about i8042 core trying to reset the keyboard port.

Naturally, having one's DMI info in that table would make this patch fix automatically applied, without having to manually use the i8042.kbdreset=1 boot parameter. Therefore, all users who manually get their touchpad working on a kernel with this patch fix using that boot parameter should ideally endeavour to have their DMI info listed in the above table for automatic application of this fix. This would certainly be beneficial to them & other users with same/similar configuration.

The best way to accomplish such amendment is to either send a patch (containing updates to aforementioned table in that header file) to linux-input mailing list or notify them of your finding/analysis.

Considering the original bug reported in this bugzilla report has been truly fixed now, ideally this ticket should be closed now.

Thanks
Comment 188 Srihari Vijayaraghavan 2015-01-20 12:35:47 UTC
Input maintainer Dmitry had this fix merged in mainline (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=66893885bbf95b6c9030d97804cb678a70804edf) & he has marked it for stable trees' consideration too.

The mainline kernel has been confirmed to fix the original issue reported in this bugzilla report. So, marking the ticket as resolved now.

Thank you everybody for your help & testing.
Comment 189 Mateusz Jończyk 2015-01-20 13:02:41 UTC
Thank You Srihari for solving this issue.

Much thanks to everybody else as well.
Comment 190 prosf 2015-01-20 15:10:22 UTC
These are indeed, really good news. Well done Srihari!

The fixed had  work for me also .My laptop comes with many different names
(Lengda X300 / X300V, Hasee X300 / X300V , Turbo-X Leaf S u5-4256 , Novatech N1402)

Unfortunately it seems that the dmi approach would not work for this laptop: 
" sudo dmidecode | egrep 'Manufacturer|Product Name' | head -n2"

returns
	Manufacturer: To be filled by O.E.M.
	Product Name: To be filled by O.E.M.


In the other hand the "dmesg | egrep serio1"

returns

[    2.648195] psmouse serio1: sentelic: Finger Sensing Pad, hw: 14.3.1, sn: 58344, sw: 1.1.0-K
[    2.709412] input: FSPPS/2 Sentelic FingerSensingPad as /devices/platform/i8042/serio1/input/input7

Anyway ,good thing that i8042.kbdreset=1 exists :)
Comment 191 Vincent 2015-01-21 22:53:00 UTC
Hello, I'd just like to quickly add that this patch also works for my laptop, a XMG C404, which is just a rebranded Gigabyte P34Gv2. It's probable that there are more rebrands of the same laptop...

`sudo dmidecode | egrep 'Manufacturer|Product Name' | head -n2`

returns

Manufacturer: XMG
Product Name: C404
Comment 192 Srihari Vijayaraghavan 2015-01-26 11:53:42 UTC
(In reply to Vincent from comment #191)
> Hello, I'd just like to quickly add that this patch also works for my
> laptop, a XMG C404, which is just a rebranded Gigabyte P34Gv2. It's probable
> that there are more rebrands of the same laptop...

Hello Vincent, that's good to know.
 
> `sudo dmidecode | egrep 'Manufacturer|Product Name' | head -n2`
> 
> returns
> 
> Manufacturer: XMG
> Product Name: C404

Please find the patch against 3.19-rc6 attached as the next entry. Hope it makes the touchpad detection automatic for you.

Considering Greg KH has accepted the original bug fix for stable, when upcoming 3.18.4, 3.14.30 & 3.10.66 are released in the next day or two, this addendum patch to fix your case ought to apply on top them as well.

Anyway, if it's confirmed to work (against any of them), which am sure it will, then we'll request Dmitry to merge it upstream, although to reduce noise, we may rather wait for another one or two new DMI entries as well to batch them all up together, as I can see new users subscribing to this bug report all the time :-).

Thanks
Comment 193 Srihari Vijayaraghavan 2015-01-26 11:55:55 UTC
Created attachment 164771 [details]
DMI addition to address XMG C404 laptop's touchpad detection

Refer to previous entry for more info about this patch.
Comment 194 Kevin 2015-02-01 15:10:18 UTC
I hope this is the correct place to report this.  I tried the patch on my laptop and it *does not work*.  Details:

Model: Acer Aspire E5-571P laptop with Elantech touchpad
Distro: Linux Mint 17.1 + Kernel 3.18.5 (with i8042.kbdreset option)

My touchpad is completely unresponsive.  I have scoured the Internet looking for solutions, and tried everything but the kitchen sink (e.g. playing with module parameters).  This is the only site I've found that is proposing any kind of patch/fix for Elantech touchpads - from examining my dmesg with i8042.debug one (and not really knowing what I'm looking at), it does seem like there is a communication problem.  Note: unlike the other post-ers, my touchpad does not work after coldboot after booting into Windows, so the problem may be different than what the Gigabyte laptop users experience.  Anyway, I'm attaching my dmesg file in case it is of any use.  Perhaps this should be started as a new bug project.
Comment 195 Kevin 2015-02-01 15:12:46 UTC
Created attachment 165511 [details]
dmesg with i8042.debug and i8042.kbdreset on Acer Aspire E5-571P
Comment 196 Srihari Vijayaraghavan 2015-02-02 06:23:25 UTC
Hello Kevin,

Sorry that your touchpad remains broken in Linux. However, I concur with your analysis that yours looks like a different bug to what is been worked on (and resolved) in this bug report.

(As per your dmesg, after all, your touchpad does get detected, but, as you say, doesn't work afterwards; in our case it wasn't even getting detected.)

May I request you to open a new bug report & perhaps escalating to linux-input@vger.kernel.org, if you observe no traction?

If you interactively type your password in Linux, be careful with i8042.debug, which would simply report it as well! So it's best not to report i8042.debug past the point of login manager start up (be it getty or kdm or gdm etc.). Or use a throwaway account/password combination; or temporarily use password-less login etc.

Good luck. Thanks
Comment 197 John 2015-02-08 00:55:25 UTC
Thank you guys, fixes my laptop's issue.

Booting with i8042.kbdreset=1 using 3.19-rc7 fixes it.

As suggested;

Ran this: "sudo dmidecode | egrep 'Manufacturer|Product Name' | head -n2"
Got this: "Manufacturer: CASPER BILGISAYAR SISTEMLERI A.S
	Product Name: Casper Nirvana"

Though I am pretty sure there are many models of "Casper Nirvana" mine is CN-VLA2830A but it doesn't say that in previous dmidecode command.
Comment 198 Alex 2015-03-27 20:59:49 UTC
I've read through all these comments starting with 1 after being in search of a fix for this issue for about a week.
I wasn't aware that a windows boot -> reboot -> linux (xubuntu in my case) fixed it temporarily and was pretty unsure what could possibly cause this weird behaviour.

As i don't have to apply the patch anymore, i just added the kernel parameter to test it, which fixed the problem for me.
My device is a XMG C405 a rebranded P34W V3 (successor to the P34 V2 series consisting of the G and W models).
This will probably work for all later gigabyte models most likely including the larger devices (P35K/W/X).

sudo dmidecode | egrep 'Manufacturer|Product Name' | head -n2
	Manufacturer: XMG
	Product Name: C405

As i just created the account for this issue and to report back, im unsure where to send this and hope its going to be enough when i leave this info here as requested earlier.

If i should send it somewhere else, please specify where it should go. I'm generally new to linux in general and am just trying to get switched.
Comment 199 tuomas.siren 2015-05-07 07:31:46 UTC
"i8042.kbdreset=1" fixed the touchpad detection.

sudo dmidecode | egrep 'Manufacturer|Product Name' | head -n2
	Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
	Product Name: 530U3C/530U4C/532U3C

uname -r
3.19.0-16-generic

dmesg | grep -i elantech
[    1.967966] psmouse serio1: elantech: assuming hardware version 3 (with firmware version 0x450f00)
[    1.982586] psmouse serio1: elantech: Synaptics capabilities query result 0x08, 0x17, 0x0c.
[    2.063573] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input5
Comment 200 kieran.honey 2015-09-06 21:01:54 UTC
Hi,

Thanks for this, it also fixed the issue on my Gigabyte P37X, I'm pretty new to linux so I've just run the same commands as tuomas, output listed below.

"i8042.kbdreset=1" fixed the touchpad detection.

sudo dmidecode | egrep 'Manufacturer|Product Name' | head -n2
	Manufacturer: GIGABYTE
	Product Name: P37

uname -r
3.19.0-26-generic

dmesg | grep -i elantech
[    2.259136] psmouse serio1: elantech: assuming hardware version 3 (with firmware version 0x450f01)
[    2.273489] psmouse serio1: elantech: Synaptics capabilities query result 0x58, 0x17, 0x0c.
[    2.348238] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input7
Comment 201 Matt 2015-12-07 21:28:10 UTC
Hi,

This also worked for me using the boot param on the following hardware:

bwadmin@p35w:~$ sudo dmidecode | egrep 'Manufacturer|Product Name' | head -n2
	Manufacturer: GIGABYTE
	Product Name: P35V3


Thanks!
Comment 202 Jan Böhland 2015-12-22 22:21:47 UTC
Hello,

the i8042.kbdreset=1 also fixes it for this machine:
        Manufacturer: XMG
        Product Name: C504

Thank You!
Comment 203 Reuben Steenekamp 2015-12-31 20:50:22 UTC
Hello,

Also works for:
Manufacturer: GIGABYTE
Product Name: X7V3

Thank you so much. I am so happy right now.
Comment 204 Ken Gregson 2016-01-10 22:16:59 UTC
Hi,

Also works for:
	Manufacturer: GIGABYTE
	Product Name: P35

Thanks, my life is so much better!
Comment 205 paul 2017-08-09 20:33:08 UTC
Also works for:

Manufacturer: GIGABYTE
	Product Name: Aero 14
Comment 206 Woodo 2017-08-22 05:36:57 UTC
Apologies in advance if not the correct forum but it looks like a similar issue I have with my asus t300chi running ubuntu 16.04.3 pts. I believe but don't really know it uses an elantech touchpad. I have no vertical or horizontal scrolling and function keys do not work except for volume keys. Also a separate issue is that you select the ubuntu rescue options the screen freezes up ands requires a reboot. Would the described patch help me with the touchpad issue?
Comment 207 Woodo 2017-08-24 05:45:23 UTC
Hi, following comment 171, I get the following error when I use the make -j4 command. Any assistance to unstick me from this point would be great:

scripts/sign-file.c:25:30: fatal error: openssl/opensslv.h: No such file or directory
compilation terminated.
scripts/Makefile.host:107: recipe for target 'scripts/sign-file' failed
make[1]: *** [scripts/sign-file] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:560: recipe for target 'scripts' failed
make: *** [scripts] Error 2
make: *** Waiting for unfinished jobs....
woodo@woodo-T300CHI:~/testkernel/linux-4.9.44$
Comment 208 Dmitry Torokhov 2017-08-24 22:22:16 UTC
You need libssl-dev package or similar. Or disable kernel module signing in kernel config.
Comment 209 Woodo 2017-08-25 13:03:47 UTC
Much appreciated Dmitry. I don't really know what I am doing but hope to learn. I got a bit further loading the libssl package. At the end of the make this error came up, not sure of the significance though. Will now test the amended 4.9.44. Again thanks.

W: Possible missing firmware /lib/firmware/i915/kbl_guc_ver9_14.bin for module i915
W: Possible missing firmware /lib/firmware/i915/bxt_guc_ver8_7.bin for module i915
run-parts: executing /etc/kernel/postinst.d/pm-utils 4.9.44 /boot/vmlinuz-4.9.44
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 4.9.44 /boot/vmlinuz-4.9.44
run-parts: executing /etc/kernel/postinst.d/update-notifier 4.9.44 /boot/vmlinuz-4.9.44
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 4.9.44 /boot/vmlinuz-4.9.44
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.10.0-32-generic
Found initrd image: /boot/initrd.img-4.10.0-32-generic
Found linux image: /boot/vmlinuz-4.9.44
Found initrd image: /boot/initrd.img-4.9.44
Found linux image: /boot/vmlinuz-4.8.0-36-generic
Found initrd image: /boot/initrd.img-4.8.0-36-generic
Found Windows Boot Manager on /dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for EFI firmware configuration
done
Comment 210 Woodo 2017-08-25 13:37:00 UTC
If I have compile this correctly then I don't think the patch works for the asus t300chi as far as scrolling or function key are concerned. Assistance welcome for further checks?

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