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?

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

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

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

Created attachment 144951
dmesg when used acpi_osi=! acpi_osi="Linux"

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.

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

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

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

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

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

When You captured the dmesg, did the tablet work?

Please supply similar dmesg when the "tablet working state" was different.

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

Created attachment 144971
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

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

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

Lots of thank You for really good handling of the bug report.

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

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

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

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

Created attachment 145031
dmesg with i8042 patch, i8042.debug & acpi debug when Elantech not working

dmesg with i8042 patch, i8042.debug & acpi debug when Elantech not working

Created attachment 145041
dmesg with i8042 patch, i8042.debug & acpi debug when Elantech working

dmesg with i8042 patch, i8042.debug & acpi debug when Elantech working

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

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

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.

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

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.

Please give me output of
ls -alR /sys
There are some interesting things in the DSDT

Created attachment 145221
ls -alR /sys

Right off 3.16.0, although booted without acpi debug & i8042.debug.

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.

Thank You for support.

Could You compile and run
ectool: http://www.coreboot.org/Ectool
when the touchpad works and when it does not?

(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

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.

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
"

Which driver on Windows supports the touchpad?

In this sense HID means specifically Human Interface Device, this can be said for sure because of the section the MSDN article is in.

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

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

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

(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

CCing <email address hidden> 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?

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

Created attachment 145381
dmesg with i8042.debug when Elantech is working

Created attachment 145391
/proc/interrupts

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

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

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

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

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

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

Created attachment 145401
[PATCH] Enable i2c Hid debugging

Please build with this patch.

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.

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

Created attachment 145511
[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.

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

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.

Created attachment 145521
Diff after grepping i8042 and some cutting

Created attachment 145531
Same but as plaintext

Created attachment 145541
My analysis, partially translated

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

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

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

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

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.

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

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)

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

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

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)

Could YOu try booting with i8042.nokbd=1 ?
Please give logs if that helps (or if it doesnt).

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

Please excuse me, please give me the above one with i8042.debug=1.

Created attachment 145711
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)

Created attachment 145721
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 :-))

It's interesting but I don't have time now.

Does rmmod i8042 rmmod psmouse insmod psmouse insmod i8042 help?

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

(In reply to Mateusz Jończyk from comment #116)
> Does rmmod i8042 rmmod psmouse insmod psmouse insmod i8042 help?

Please ignore it.

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.

Created attachment 145921
Enable

Created attachment 145931
dmesg after above i8042 patch when elantech not working

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.

Created attachment 145951
Read internal memory and do some other things

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

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

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

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

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

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

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

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

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.

Created attachment 145971
dmesg with i8042.debug with the most recent patch where elantech worked after a cold power up

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.

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

    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.

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

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

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

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

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

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 or all of it is helping my problem.

Created attachment 146111
Reset kbd

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

Created attachment 146121
Reset kbd

Mateusz, indeed your patch above in attachment 146121 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.

Created attachment 146141
Reset mouse

Please test this.

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

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

Could You give me a dmesg with i8042.debug with this?

Created attachment 146161
dmesg with i8042.debug

The dmesg produced with the most recent patch from comment #149 applied & i8042.debug kernel parameter.

I'm sorry, but it doesn't look like YOu had my patch applied.

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

Created attachment 146221
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

(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 has worked flawlessly, so far.)

Thanks

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

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.

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

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

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

@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!

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

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

Me too

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!

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.

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.

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

Created attachment 153821
A patch that makes the touchpad work

I am obsoleting all other patches to make finding the correct one easier.

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

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.