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.
Created attachment 138251 [details] i8042.debug=1 i8042.nomux=1
Created attachment 138261 [details] dmidecode
https://bugzilla.redhat.com/show_bug.cgi?id=1110011
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.
KBD_DISABLE is nowhere used: http://lxr.free-electrons.com/ident?i=I8042_CMD_KBD_DISABLE
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?
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)
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)
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.
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.
What kind of touchpad do YOu have?
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.
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.
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.
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
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
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",
(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.
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
Note: although destroying the hardware by applying the above patch is very improbable, it is not impossible.
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
(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.)
Hi , FYI I have the same issue with a Elantech Touchpad on the laptop AVATAR AVIU-145A6. thx Hugo P
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.
(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
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
(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
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
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.
Created attachment 149651 [details] dmesg_77391_comment28.txt
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
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.
Thx again ;-)
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
Created attachment 149711 [details] AVARTAR_AVIU-145A2_dmidecode.log the dmidecode command on a laptop AVATAR AVIU-145A2
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
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