Bug 77391 - touchpad does not work
Summary: touchpad does not work
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-05 14:48 UTC by Jiri Slaby
Modified: 2015-12-02 13:44 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.x
Tree: Mainline
Regression: No


Attachments
i8042.debug=1 dmesg (392.19 KB, text/plain)
2014-06-05 14:48 UTC, Jiri Slaby
Details
i8042.debug=1 i8042.nomux=1 (571.51 KB, text/plain)
2014-06-05 14:49 UTC, Jiri Slaby
Details
dmidecode (9.39 KB, text/plain)
2014-06-05 14:52 UTC, Jiri Slaby
Details
Elantech: Recognize touchpads with different magic numbers (1.03 KB, patch)
2014-08-04 16:11 UTC, Mateusz Jończyk
Details | Diff
dmesg_77391_comment25.txt dmesg output asked in comment 25 (64.63 KB, text/plain)
2014-09-10 14:52 UTC, Hugo P
Details
dmesg_77391_comment28.txt (100.53 KB, text/plain)
2014-09-10 15:39 UTC, Hugo P
Details
AVARTAR_AVIU-145A2_dmidecode.log (19.70 KB, text/plain)
2014-09-11 01:11 UTC, Hugo P
Details

Description Jiri Slaby 2014-06-05 14:48:55 UTC
Created attachment 138241 [details]
i8042.debug=1 dmesg

I tried kernels from 3.0 to 3.15-rc8, but still, I am seeing:
psmouse serio4: Failed to enable mouse on isa0060/serio4

I tried 8042.noloop, nomux. I am attaching i8042.debug=1.
Comment 1 Jiri Slaby 2014-06-05 14:49:36 UTC
Created attachment 138251 [details]
i8042.debug=1 i8042.nomux=1
Comment 2 Jiri Slaby 2014-06-05 14:52:48 UTC
Created attachment 138261 [details]
dmidecode
Comment 4 Mateusz Jończyk 2014-07-31 17:09:08 UTC
Hello,
This is interesting:

Jun 05 22:29:58 linux-pjln kernel: i8042: Detected active multiplexing controller, rev 1.1
Jun 05 22:29:58 linux-pjln kernel: i8042: [2] 60 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [2] 74 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [2] 90 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [2] a8 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [2] 91 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [2] a8 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [2] 92 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3] a8 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3] a8 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3] 60 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3] 56 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3] 60 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3] 47 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Jun 05 22:29:58 linux-pjln kernel: i8042: [3] Interrupt 1, without any data

It looks like there was some interrupt pending that was not cleared at the initialization time so that it fired just after the i8042 interrupt line was enabled.

In http://wiki.osdev.org/%228042%22_PS/2_Controller#Step_3:_Disable_Devices
 it is written
"Step 3: Disable Devices
So that any PS/2 devices can't send data at the wrong time and mess up your initialisation; start by sending a command 0xAD and command 0xA7 to the PS/2 controller. If the controller is a "single channel" device, it will ignore the "command 0xA7". "

Do we do this? 
Please excuse my incompetence, but I do not see anything like that in the logs.
Comment 5 Mateusz Jończyk 2014-07-31 17:30:45 UTC
KBD_DISABLE is nowhere used:

http://lxr.free-electrons.com/ident?i=I8042_CMD_KBD_DISABLE
Comment 6 Mateusz Jończyk 2014-07-31 18:12:44 UTC
We disable KBD and AUX ports by setting respective bits in the status register.
Maybe we should also execute command 0xAD.

Then we have:

Jun 05 22:29:58 linux-pjln kernel: i8042: [64] fa <- i8042 (interrupt, 0, 1)
Jun 05 22:29:58 linux-pjln kernel: i8042: [64] f4 -> i8042 (kbd-data)
Jun 05 22:29:58 linux-pjln kernel: i8042: [67] fa <- i8042 (interrupt, 0, 1)
Jun 05 22:29:58 linux-pjln kernel: input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
Jun 05 22:29:58 linux-pjln kernel: i8042: [67] 90 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [67] f2 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [94] MUX error, status is 35, data is fe
Jun 05 22:29:58 linux-pjln kernel: i8042: [94] fe <- i8042 (interrupt, 2, 12, timeout)
Jun 05 22:29:58 linux-pjln kernel: i8042: [94] 90 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [94] ed -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [121] MUX error, status is 35, data is fe
Jun 05 22:29:58 linux-pjln kernel: i8042: [121] fe <- i8042 (interrupt, 2, 12, timeout)
Jun 05 22:29:58 linux-pjln kernel: i8042: [121] 91 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [121] f2 -> i8042 (parameter)

We try to identify each AUX device by executing command f2 on each. In every case, we get a timeout when the device tries to send us sth.

The OSDEV wiki specifies that we should execute command 0xf5 on the device first to "disable scanning" before executing f2. Maybe this confuses the MUX?
Comment 7 Mateusz Jończyk 2014-07-31 18:21:41 UTC
Finally, (device nr 3) answers us:

Jun 05 22:29:58 linux-pjln kernel: i8042: [123] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [123] f2 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [125] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [126] 00 <- i8042 (interrupt, 5, 12)

Now we know that AUX0 - AUX2 do not exist (are disconnected).

Then occurs a long transaction with AUX3, for each command we get "fa" as a response:

Jun 05 22:29:58 linux-pjln kernel: i8042: [154] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [154] f2 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [156] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [157] 00 <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [157] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [157] f6 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [159] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [159] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [159] f3 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [162] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [162] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [162] 0a -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [164] fa <- i8042 (interrupt, 5, 12)

[...]

At some time we suddenly decide that we deal with
Jun 05 22:29:58 linux-pjln kernel: input: PS/2 Logitech Wheel Mouse as /devices/platform/i8042/serio4/input/input8

But that changes nothing and we poll on AUX3 till the end of the log, always getting fa.

Jun 05 22:30:18 linux-pjln.site kernel: i8042: [29331] 93 -> i8042 (command)
Jun 05 22:30:18 linux-pjln.site kernel: i8042: [29331] f3 -> i8042 (parameter)
Jun 05 22:30:18 linux-pjln.site kernel: i8042: [29333] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:30:18 linux-pjln.site kernel: i8042: [29333] 93 -> i8042 (command)
Jun 05 22:30:18 linux-pjln.site kernel: i8042: [29333] 64 -> i8042 (parameter)
Jun 05 22:30:18 linux-pjln.site kernel: i8042: [29342] fa <- i8042 (interrupt, 5, 12)
Comment 8 Mateusz Jończyk 2014-07-31 18:35:04 UTC
OK, I'm still learning.
"fa" means ACK. 
The touchpad sends "00" as device type ID, which means "Standard PS/2 mouse".

Jun 05 22:29:58 linux-pjln kernel: i8042: [157] 00 <- i8042 (interrupt, 5, 12)
Comment 9 Mateusz Jończyk 2014-07-31 18:58:35 UTC
OK, we have a following interesting bits:


Jun 05 22:30:11 linux-pjln.site kernel: i8042: [21846] 93 -> i8042 (command)
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [21846] f4 -> i8042 (parameter)
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [21873] MUX error, status is f5, data is fe
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [21873] fe <- i8042 (interrupt, 5, 12, timeout)
Jun 05 22:30:11 linux-pjln.site kernel: psmouse serio4: Failed to enable mouse on isa0060/serio4
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [22403] aa <- i8042 (interrupt, 5, 12)
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [22404] 00 <- i8042 (interrupt, 5, 12)
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [22404] 93 -> i8042 (command)
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [22404] ff -> i8042 (parameter)
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [22406] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [22408] aa <- i8042 (interrupt, 5, 12)
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [22409] 00 <- i8042 (interrupt, 5, 12)
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [22409] 93 -> i8042 (command)
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [22409] f2 -> i8042 (parameter)

We send 0xF4 to "Enable Data Reporting".
The trackpad timeouts. We determine that we failed to init the mouse, then execute reset "ff", rediscover the device, try to initialize it, send 0xf4 once again, which again failes, and loop the loop.
Comment 10 Mateusz Jończyk 2014-07-31 19:03:05 UTC
Another snippet:
"
Jun 05 22:30:15 linux-pjln.site kernel: i8042: [26275] 93 -> i8042 (command)
Jun 05 22:30:15 linux-pjln.site kernel: i8042: [26275] e9 -> i8042 (parameter)
Jun 05 22:30:15 linux-pjln.site kernel: i8042: [26277] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:30:15 linux-pjln.site kernel: i8042: [26279] 3c <- i8042 (interrupt, 5, 12)
Jun 05 22:30:15 linux-pjln.site kernel: i8042: [26280] f0 <- i8042 (interrupt, 5, 12)
Jun 05 22:30:15 linux-pjln.site kernel: i8042: [26281] 00 <- i8042 (interrupt, 5, 12)

"e9" is "get status".
The results look strange.

A possible hint: do not reset the mouse when "f4" timeouts, it is possible that we will see some data.
Comment 11 Mateusz Jończyk 2014-07-31 19:03:43 UTC
What kind of touchpad do YOu have?
Comment 12 Mateusz Jończyk 2014-08-01 09:08:57 UTC
I looked at it again:

Jun 05 22:30:11 linux-pjln.site kernel: i8042: [21846] 93 -> i8042 (command)
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [21846] f4 -> i8042 (parameter)
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [21873] MUX error, status is f5, data is fe
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [21873] fe <- i8042 (interrupt, 5, 12, timeout)
Jun 05 22:30:11 linux-pjln.site kernel: psmouse serio4: Failed to enable mouse on isa0060/serio4
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [22403] aa <- i8042 (interrupt, 5, 12)
Jun 05 22:30:11 linux-pjln.site kernel: i8042: [22404] 00 <- i8042 (interrupt, 5, 12)

It looks like we get some response from the touchpad for the command f4 but it is late. Also, the driver should return fa AFAIK, not "aa" "00".

It looks like CONFIG_HZ = 1000, so we wait for 557 jiffies - half a second.
After ff (reset) we wait for under 10 jiffies.
It is possible that somehow the command failed so the touchpad reset itself after some time.
Comment 13 Mateusz Jończyk 2014-08-01 09:53:59 UTC
In the log every time we execute f2, we get "00" in response.

Jun 05 22:29:58 linux-pjln kernel: i8042: [3153] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3153] f2 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3155] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3156] 00 <- i8042 (interrupt, 5, 12)


Here we try to detect a Synaptics touchpad - by sending e8 00 e8 00 e8 00 e8 00 e9.
The respond does not, however, looks like one from a Synaptics touchpad because in a syn touchpad the middle byte should be 47.
http://www.synaptics.com/sites/default/files/511-000275-01_RevB.pdf

Jun 05 22:29:58 linux-pjln kernel: i8042: [3787] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3787] e8 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3789] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3789] 93 -> i8042 (command)
...
Jun 05 22:29:58 linux-pjln kernel: i8042: [3803] 00 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3804] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3804] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3805] e9 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3806] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3808] 3c <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3809] f0 <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [3810] 00 <- i8042 (interrupt, 5, 12)

The output looks strange. It isn't legal for a normal ps2 mouse or something fully emulating it, neither it could be a Synaptics touchpad.
In a different place we send e9 without that invocation and the result is the same.

Jun 05 22:29:58 linux-pjln kernel: i8042: [7787] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [7787] e6 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [7788] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [7788] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [7789] e9 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [7790] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [7792] 3c <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [7793] f0 <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [7794] 00 <- i8042 (interrupt, 5, 12)

Looking for sequence 3c f0 00 did not yield any results, also in the kernel sources.
Looks like it will be neccessary to reveng this driver.
Comment 14 Mateusz Jończyk 2014-08-01 09:55:09 UTC
Alternatively we may try to drive it forcibly like a normal ps2 mouse, but from what I see it is done and does not give any meaningful results.
Comment 15 Mateusz Jończyk 2014-08-01 10:47:25 UTC
It is probably an Elantech touchpad:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1325881/comments/8

It is probably a regression (should work in linux-image-3.13.0-24-generic from Ubuntu):
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1325881/comments/20
Comment 16 Mateusz Jończyk 2014-08-01 11:01:15 UTC
There we try to detect elantech:

Jun 05 22:29:58 linux-pjln kernel: i8042: [460] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [460] e6 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [463] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [463] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [463] e6 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [465] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [465] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [465] e6 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [468] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [468] 93 -> i8042 (command)
Jun 05 22:29:58 linux-pjln kernel: i8042: [468] e9 -> i8042 (parameter)
Jun 05 22:29:58 linux-pjln kernel: i8042: [470] fa <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [473] 3c <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [474] f0 <- i8042 (interrupt, 5, 12)
Jun 05 22:29:58 linux-pjln kernel: i8042: [475] 00 <- i8042 (interrupt, 5, 12)

The driver expects to see 3c 03 c8 as magic numbers:

        /*
         * Report this in case there are Elantech models that use a different
         * set of magic numbers
         */
        if (param[0] != 0x3c || param[1] != 0x03 ||
            (param[2] != 0xc8 && param[2] != 0x00)) {
                psmouse_dbg(psmouse,
                            "unexpected magic knock result 0x%02x, 0x%02x, 0x%02x.\n",
                            param[0], param[1], param[2]);
                return -1;
        }

I have looked at http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/input/mouse/elantech.c but did not see anything that could disrupt the driver
Comment 17 Mateusz Jończyk 2014-08-01 11:06:00 UTC
This patch may fix the problem:

--- a/drivers/input/mouse/elantech.c 2014-07-21 06:04:16.000000000 +0200
+++ b/drivers/input/mouse/elantech.c 2014-08-01 13:04:10.958714728 +0200
@@ -1283,7 +1283,8 @@
 	 * Report this in case there are Elantech models that use a different
 	 * set of magic numbers
 	 */
-	if (param[0] != 0x3c || param[1] != 0x03 ||
+	if (param[0] != 0x3c || 
+            (param[1] != 0x03 && param[1] != 0xf0) ||
 	    (param[2] != 0xc8 && param[2] != 0x00)) {
 		psmouse_dbg(psmouse,
 			    "unexpected magic knock result 0x%02x, 0x%02x, 0x%02x.\n",
Comment 18 Mateusz Jończyk 2014-08-01 13:19:24 UTC
(In reply to Mateusz Jończyk from comment #12)
> I looked at it again:
> 
> Jun 05 22:30:11 linux-pjln.site kernel: i8042: [21846] 93 -> i8042 (command)
> Jun 05 22:30:11 linux-pjln.site kernel: i8042: [21846] f4 -> i8042
> (parameter)
> Jun 05 22:30:11 linux-pjln.site kernel: i8042: [21873] MUX error, status is
> f5, data is fe
> Jun 05 22:30:11 linux-pjln.site kernel: i8042: [21873] fe <- i8042
> (interrupt, 5, 12, timeout)
> Jun 05 22:30:11 linux-pjln.site kernel: psmouse serio4: Failed to enable
> mouse on isa0060/serio4
> Jun 05 22:30:11 linux-pjln.site kernel: i8042: [22403] aa <- i8042
> (interrupt, 5, 12)
> Jun 05 22:30:11 linux-pjln.site kernel: i8042: [22404] 00 <- i8042
> (interrupt, 5, 12)
> 

In libps2.c
        /*
         * Some devices (Synaptics) peform the reset before
         * ACKing the reset command, and so it can take a long
         * time before the ACK arrives.
         */
[...]
        /*
         * The reset command takes a long time to execute.
         */
        timeout = msecs_to_jiffies(command == PS2_CMD_RESET_BAT ? 4000 : 500);
So it really lookse like a reset.
Comment 19 Mateusz Jończyk 2014-08-04 16:11:41 UTC
Created attachment 145111 [details]
Elantech: Recognize touchpads with different magic numbers

    The touchpad mentioned in bug #77391 uses magic numbers 0x3c, 0xf0,
    0x00. As this is probably an Elantech touchpad, recognize it as such.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=77391
Comment 20 Mateusz Jończyk 2014-08-10 21:40:03 UTC
Note: although destroying the hardware by applying the above patch is very improbable, it is not impossible.
Comment 21 Hans de Goede 2014-09-03 08:30:32 UTC
Hi,

I've been working on debugging issues with a touchpad which returns 0x3c, 0xf0, 0x00 too, see:

https://bugzilla.redhat.com/show_bug.cgi?id=1110011

Specifically in this bug I'm dealing with the touchpad on Asus X450 and Asus X550 models. What model laptop is the problem here with?

Looking at the dmesg attached here, this is the same issue, if not the same laptop, specifically this line tells the whole story:

Jun 05 22:29:58 linux-pjln kernel: pnp 00:09: Plug and Play ACPI device, IDs FLT0101 SYN0a00 SYN0002 PNP0f03 PNP0f13 PNP0f12 (active)

This list the PNP ids for the aux port of the i8042 keyboard controller, and the  FLT0101 idea indicates that
trying to get the elantech driver to work is a dead end, these laptops have touchpads from a new manufacturer called FocalTech, which very likely speak a whole new protocol.

As a workaround you can specify: "psmouse.proto=bare" on the kernel cmdline, this will make these devices at least work in mouse emulation mode. I'm working on a kernel patch set to detect these device based on their pnp-ids and automatically treat them as a bare ps2 mouse for now.

Regards,

Hans
Comment 22 Jiri Slaby 2014-09-03 08:34:10 UTC
(In reply to Hans de Goede from comment #21)
> Looking at the dmesg attached here, this is the same issue, if not the same
> laptop, specifically this line tells the whole story:
> 
> Jun 05 22:29:58 linux-pjln kernel: pnp 00:09: Plug and Play ACPI device, IDs
> FLT0101 SYN0a00 SYN0002 PNP0f03 PNP0f13 PNP0f12 (active)

Yes, it is x550.

> As a workaround you can specify: "psmouse.proto=bare" on the kernel cmdline,
> this will make these devices at least work in mouse emulation mode.

Yeah, this is what I set the laptop to too. And it works.

> I'm
> working on a kernel patch set to detect these device based on their pnp-ids
> and automatically treat them as a bare ps2 mouse for now.

Ok, thank you. (I'm the reporter and I am watching both bugs, you do not need to post to both bugs, when you have something to test.)
Comment 23 Hugo P 2014-09-08 17:19:37 UTC
Hi ,

FYI

I have the same issue with a Elantech Touchpad on the laptop AVATAR AVIU-145A6.

thx Hugo P
Comment 24 Hugo P 2014-09-08 17:32:24 UTC
I'm not a OS dev export but If I can help by doing tests and providing information  from my laptop, it will be a pleasure.
Comment 25 Hans de Goede 2014-09-10 13:18:33 UTC
(In reply to Hugo P from comment #23)
> Hi ,
> 
> FYI
> 
> I have the same issue with a Elantech Touchpad on the laptop AVATAR
> AVIU-145A6.

If that laptop has an elantech touchpad, then you're having a different issue. Can you please start a terminal directly after booting the laptop and then do:

dmesg > dmesg.txt

And then attach the generated dmesg.txt file here ?

Thanks,

Hans
Comment 26 Hugo P 2014-09-10 14:52:54 UTC
Created attachment 149641 [details]
dmesg_77391_comment25.txt dmesg output asked in comment 25

The dmesg output was provided from the Hugo P's laptop (AVATAR AVIU-145A6) which have issue with the Elantech Touchpad
Comment 27 Hugo P 2014-09-10 14:58:22 UTC
(In reply to Hans de Goede from comment #25)
> (In reply to Hugo P from comment #23)
> > Hi ,
> > 
> > FYI
> > 
> > I have the same issue with a Elantech Touchpad on the laptop AVATAR
> > AVIU-145A6.
> 
> If that laptop has an elantech touchpad, then you're having a different
> issue. Can you please start a terminal directly after booting the laptop and
> then do:
> 
> dmesg > dmesg.txt
> 
> And then attach the generated dmesg.txt file here ?
> 
> Thanks,
> 
> Hans

Hi Hans,

First, thx for your reply.

I attache my dmesg output (see dmesg_77391_comment25.txt).

I'm not a expert to decode dmesg but here lines that I remark:

[    3.088092] psmouse serio2: elantech: elantech_send_cmd query 0x02 failed.
[    3.088102] psmouse serio2: elantech: failed to query capabilities.
...
[    3.294458] input: PS/2 Elantech Touchpad as /devices/platform/i8042/serio2/input/input10
Comment 28 Hans de Goede 2014-09-10 15:00:48 UTC
Hi Hugo,

So you indeed have a different touchpad then the one this bug is about, yours has a pnp-id of: ETD0414 which I assume means that it really is an elantech.

Can you try adding i8042.nomux=1 to the kernel commandline and see if that helps?

Regards,

Hans
Comment 29 Hugo P 2014-09-10 15:38:32 UTC
Issue still there but system react differently

I post a new dmesg output (dmesg_77391_comment28.txt)

has we can see that part of the message is repeating itself...

[    5.412393] psmouse serio2: alps: Unknown ALPS touchpad: E7=10 00 64, EC=10 00 64
[    5.625428] psmouse serio2: elantech: assuming hardware version 4 (with firmware version 0x361f00)
...
[    5.825403] psmouse serio2: elantech: elantech_send_cmd query 0x02 failed.
[    5.825408] psmouse serio2: elantech: failed to query capabilities.
[    6.030749] input: PS/2 Elantech Touchpad as /devices/platform/i8042/serio2/input/input19
[    7.568744] psmouse serio2: alps: Unknown ALPS touchpad: E7=10 00 64, EC=10 00 64
[    8.116142] psmouse serio2: alps: Unknown ALPS touchpad: E7=10 00 64, EC=10 00 64
...
[    8.323884] psmouse serio2: elantech: assuming hardware version 4 (with firmware version 0x361f00)
[    8.522653] psmouse serio2: elantech: elantech_send_cmd query 0x02 failed.
[    8.522660] psmouse serio2: elantech: failed to query capabilities.
[    8.731899] input: PS/2 Elantech Touchpad as /devices/platform/i8042/serio2/input/input21
...
[   10.755328] psmouse serio2: alps: Unknown ALPS touchpad: E7=10 00 64, EC=10 00 64
[   11.289708] psmouse serio2: alps: Unknown ALPS touchpad: E7=10 00 64, EC=10 00 64
[   11.503436] psmouse serio2: elantech: assuming hardware version 4 (with firmware version 0x361f00)
[   11.700123] psmouse serio2: elantech: elantech_send_cmd query 0x02 failed.
[   11.700128] psmouse serio2: elantech: failed to query capabilities.
[   11.909720] input: PS/2 Elantech Touchpad as /devices/platform/i8042/serio2/input/input23
[   13.936437] psmouse serio2: alps: Unknown ALPS touchpad: E7=10 00 64, EC=10 00 64
[   14.481583] psmouse serio2: alps: Unknown ALPS touchpad: E7=10 00 64, EC=10 00 64
[   14.694368] psmouse serio2: elantech: assuming hardware version 4 (with firmware version 0x361f00)
[   14.893647] psmouse serio2: elantech: elantech_send_cmd query 0x02 failed.
Comment 30 Hugo P 2014-09-10 15:39:21 UTC
Created attachment 149651 [details]
dmesg_77391_comment28.txt
Comment 31 Hans de Goede 2014-09-10 15:54:03 UTC
Hi Hugo,

Looking at your latest log it seems that you've failed to properly put the i8042.nomux=1 on the kernel commandline:

[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.13.0-35-generic.efi.signed root=UUID=87515d1a-8236-42d4-b0d1-91bd522043d3 ro quiet splash vt.handoff=7

Regards,

Hans
Comment 32 Hugo P 2014-09-10 16:22:14 UTC
Yes! it works !

No more error message like:

[    3.088092] psmouse serio2: elantech: elantech_send_cmd query 0x02 failed.
[    3.088102] psmouse serio2: elantech: failed to query capabilities.

My understanding is that i8042.nomux=1 disable the  multiplexing data coming from multiple pointing devices.

My kernel was not able to multiplex device like THAT Elantech Touchpad. I guess.
Comment 33 Hugo P 2014-09-10 16:59:48 UTC
Thx again ;-)
Comment 34 Hans de Goede 2014-09-10 18:04:58 UTC
Hi,

(In reply to Hugo P from comment #32)
> Yes! it works !

That is good to hear :)  I would like to add a quirk for your model laptop to the kernel so that in the future the kernel will do the right thing automatically. Can you please as root run:

dmidecode > dmidecode.log

And then attach the generated dmidecode.log file here ?

That will give us the dmi strings for your laptop, which usually are unique per model, and then we can add a quirk based on those strings.

Regards,

Hans
Comment 35 Hugo P 2014-09-11 01:11:08 UTC
Created attachment 149711 [details]
AVARTAR_AVIU-145A2_dmidecode.log

the dmidecode command on a laptop AVATAR AVIU-145A2
Comment 36 Dmitry Torokhov 2015-11-29 04:52:04 UTC
Hmm, the manufacturer of that laptop (AVATAR) was quite lazy and did not fill DMI data with their own but rather left the defaults set by Intel so I am not sure if it is a good idea to add quirks for it to the kernel:

Handle 0x0008, DMI type 1, 27 bytes
System Information
	Manufacturer: Intel
	Product Name: IC4I
	Version: 0.1
	Serial Number: System Serial Number
	UUID: <redacted>
	Wake-up Type: Power Switch
	SKU Number: System SKUNumber
	Family: ChiefRiver System

Handle 0x0009, DMI type 2, 15 bytes
Base Board Information
	Manufacturer: Intel
	Product Name: IC4I
	Version: FAB1
	Serial Number: 1
	Asset Tag: Base Board Asset Tag
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: Part Component
	Chassis Handle: 0x0000
	Type: Motherboard
	Contained Object Handles: 0
Comment 37 Hans de Goede 2015-12-02 13:44:47 UTC
Hi,

(In reply to Dmitry Torokhov from comment #36)
> Hmm, the manufacturer of that laptop (AVATAR) was quite lazy and did not
> fill DMI data with their own but rather left the defaults set by Intel so I
> am not sure if it is a good idea to add quirks for it to the kernel:

I agree. and Hugo sorry for not getting back to you on this one. It looks like you will just need to always manually add the i8042.nomux=1 since there is no way for the kernel to (reliably) identify your laptop model.

Since the original issue this bug is about (adding support for focaltech touchpads) has long been fixed I'm closing this bug.

Regards,

Hans

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