elantech trackpad don`t work

Created attachment 144611
.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.

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

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?

Created attachment 144681
i8042.debug activated dmesg (with i8042.nomux & i8042.reset were set too)

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.

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

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

Created attachment 144801
i8042.debug activated dmesg during a good working session

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.

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.

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...

OK, no need for the new dmesgs.
The current ones are sufficient to debug the issue.

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..

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;

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

Excuse me, could You give a full dmesg?

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.

Created attachment 144841
dmesg-i8042.debug-with-psmouse-patch-while-broken

Created attachment 144851
dmesg-i8042.debug-with-psmouse-patch-while-working

What happens after a reset?

Created attachment 144861
Try this

Is this a regression?

What happens if You restart WIndows?

"(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.

BTW, Win does not require Secure boot.

We may in any case just try to use polling and not interrupts.

(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.

(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.

(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.

(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

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.

(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.

Created attachment 144891
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.

Mateusz, sorry that patch, attachment 144891, 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]$

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?

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.

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

(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?

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

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 .

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?

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.

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!

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.

Created attachment 160981
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.

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.

Created attachment 161081
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.)

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

Created attachment 161431
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.

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.

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

Created attachment 161491
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.

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

Created attachment 162471
V4 Patch against mainline based on Mateusz Jończyk's patch that helps detecting Elantech touchpad on many laptops

Thanks Guillaum. The above patch includes your DMI info.

(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

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

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

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.

Thank You Srihari for solving this issue.

Much thanks to everybody else as well.

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 :)

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

(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

Created attachment 164771
DMI addition to address XMG C404 laptop's touchpad detection

Refer to previous entry for more info about this patch.

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.

Created attachment 165511
dmesg with i8042.debug and i8042.kbdreset on Acer Aspire E5-571P

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 <email address hidden>, 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

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.

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.

"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

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

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!

Hello,

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

Thank You!

Hello,

Also works for:
Manufacturer: GIGABYTE
Product Name: X7V3

Thank you so much. I am so happy right now.

Hi,

Also works for:
 Manufacturer: GIGABYTE
 Product Name: P35

Thanks, my life is so much better!

Also works for:

Manufacturer: GIGABYTE
 Product Name: Aero 14

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?

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$

You need libssl-dev package or similar. Or disable kernel module signing in kernel config.

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

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?