Description of problem: Recently purchased a laptop with an Elantech touch pad. Everything I can tell seems to be properly detecting the device. On login via LiveCD (manually created one fully updated as of today (kernel 3.5.1)) xinput lists the device properties and says it is enabled, however moving the mouse does nothing. How reproducible: Always Additional info: I can get it working if I do the following: Log into X. Switch to a VT, run evtest as root Switch back to X Toggle the touchpad via Fn+F7 (first off, then back on) Switch to the VT running evtest, touch the touchpad (evtest starts to detect data) quit evtest switch to X What is odd is that toggling the touchpad alone doesn't enable the device. I am very motivated to do whatever to fix this as we have 26 devices that need to work soon.
Booting into single user mode doesn't fix the issue. evtest shows no output, however Fn+F7 does cause output to start on second run.
So thanks to jwb and mjg59 there is additional information and the real cause. acer-wmi has two issues #1) It is sending TOUCHPAD_TOGGLE and simultaneously changing state #2) It disables the touchpad at init It should apparently do neither of those. Blacklisting acer-wmi fixes the issue
Created attachment 604773 [details] 0001-acer-wmi-test-patch-for-remove-0x82-acpi-event-with.patch Please help to test this testing patch. And, please attach dmidecode on bugzilla. If this testing patch can avoid problem on your machine, then I will write code to parser the dmidecode information for grab the acpi code of touchpad. Thanks a lot! Joey Lee
Created attachment 604789 [details] dmidecode
Will test and report back - thanks
(In reply to comment #3) > Created attachment 604773 [details] > 0001-acer-wmi-test-patch-for-remove-0x82-acpi-event-with.patch > > Please help to test this testing patch. And, please attach dmidecode on > bugzilla. > If this testing patch can avoid problem on your machine, then I will write > code to parser the dmidecode information for grab the acpi code of touchpad. That would likely fix issue #1, but do you think it would also fix the touchpad getting disabled during module init?
It definitely fixes issue #1. However Josh is correct that issue #2 is still at play. The device comes up with the touchpad disabled by default.
Also I should note that the brightness control is entirely broken. Do you want a separate bug filed for that?
Created attachment 612620 [details] ACPI dump from the acer
Created attachment 612621 [details] dmesg output with debug kernel One thing to note. This is running a kernel *with* the suggested patch for acer_wmi sent via email on 08/15. Which is likely why you see the unknown key 0x82 in dmesg. If you want me to re-run this without that patch let me know >From 969d1c0bb4fc4b69ef9d037687b4591fbd9df24f Mon Sep 17 00:00:00 2001 From: Lee, Chun-Yi <jlee> Date: Thu, 16 Aug 2012 11:28:20 +0800 Subject: [PATCH] acer-wmi: test patch for remove 0x82 acpi event with KEY_TOUCHPAD_TOGGLE Signed-off-by: Lee, Chun-Yi <jlee> --- drivers/platform/x86/acer-wmi.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c index 3782e1c..db7376b 100644 --- a/drivers/platform/x86/acer-wmi.c +++ b/drivers/platform/x86/acer-wmi.c @@ -125,7 +125,7 @@ static const struct key_entry acer_wmi_keymap[] = { {KE_IGNORE, 0x63, {KEY_BRIGHTNESSDOWN} }, {KE_KEY, 0x64, {KEY_SWITCHVIDEOMODE} }, /* Display Switch */ {KE_IGNORE, 0x81, {KEY_SLEEP} }, - {KE_KEY, 0x82, {KEY_TOUCHPAD_TOGGLE} }, /* Touch Pad On/Off */ +// {KE_KEY, 0x82, {KEY_TOUCHPAD_TOGGLE} }, /* Touch Pad On/Off */ {KE_IGNORE, 0x83, {KEY_TOUCHPAD_TOGGLE} }, {KE_END, 0} }; -- 1.6.0.2
(In reply to comment #9) > Created attachment 612620 [details] > ACPI dump from the acer Per DSDT the touchpad status should return from acpi event: Method (GOTS, 1, NotSerialized) { Store (Zero, Local0) If (LEqual (^^PCI0.LPC0.EC0.ODST, Zero)) /* ODD status */ { Or (Local0, One, Local0) /* 0 bit for ODD power state */ } If (LEqual (^^PCI0.LPC0.EC0.TOHP, Zero)) /* Touchpad status? */ { Or (Local0, 0x02, Local0) /* enable the 1 bit (10) in bitmap of device status */ } Store (Local0, Arg0) Return (Zero) } I will attach a patch for this. Let's fix the touchpad status problem, then look at the issue when system boot.
Created attachment 613362 [details] 0001-acer-wmi-change-to-emit-touchpad-on-off-key.patch This patch for acer-wmi change to emit KEY_TOUCHPAD_ON/OFF when grab acpi event of touchpad state.
Of course please remove test patch on Comment#3 before test 0001-acer-wmi-change-to-emit-touchpad-on-off-key.patch.
Created attachment 613366 [details] 0001-acer-wmi-enable-touchpad-when-acer-wmi-load.patch A test patch for enable touchpad when acer-wmi load. Sorry for I doesn't have machine to verify. If you got any problem, please remove battery and ac-power then boot system again.
So with both patches 0001-acer-wmi-change-to-emit-touchpad-on-off-key.patch 0001-acer-wmi-enable-touchpad-when-acer-wmi-load.patch The touchpad toggle button works as expected. However it stills starts disabled.
Ok scratch that, the touchpad comes up initialized to whatever state it was when it was rebooted/shutdown. Can it be unconditionally be turned on when the machine boots? That seems like a more sensible default perhaps?
First, thanks for your help on testing, at least it confirm the first patch works on function key. (In reply to comment #16) > Ok scratch that, the touchpad comes up initialized to whatever state it was > when it was rebooted/shutdown. Can it be unconditionally be turned on when > the machine boots? That seems like a more sensible default perhaps? I understand! Actually, in 0001-acer-wmi-enable-touchpad-when-acer-wmi-load.patch, I try to enable touchpad when acer-wmi loaded, but looks it not work like my expect. That means need more detail to debug the initialization of acer-wmi. Did you see "Enabled Launch Manager mode" message show up in dmesg or boot message?
Yes, on boot I have one message like that when I do dmesg | grep Enabled.
Created attachment 613883 [details] 0001-acer-wmi-test-patch-for-remove-code-to-run-LM-mode.patch Please help to try this acer-wmi test patch, look at does it avoid the touchpad disabled problem when system boot. I removed the code that do the launch manager mode setup, want to make sure this problem is really cause by this function. Thanks
So I finally noticed you had posted another bug. I built and tested against 3.6.3-2. The following three patches were applied: acer-wmi-change-touchpad-on-off-key.patch acer-wmi-enable-touchpad-when-acer-wmi-loads.patch acer-wmi-test-patch-for-remove-code-to-run-LM-mode.patch When the machine boots, the touchpad is still at whatever state it was when you rebooted. So for example, if I reboot while the touchpad is active, on reboot it is active. If I disable (Fn+F7) the touchpad and reboot, the touchpad is inactive on reboot. Anything else you need/want to know?
(In reply to comment #20) > So I finally noticed you had posted another bug. I built and tested against > 3.6.3-2. > > The following three patches were applied: > > acer-wmi-change-touchpad-on-off-key.patch > acer-wmi-enable-touchpad-when-acer-wmi-loads.patch > acer-wmi-test-patch-for-remove-code-to-run-LM-mode.patch > > When the machine boots, the touchpad is still at whatever state it was when > you rebooted. So for example, if I reboot while the touchpad is active, on > reboot it is active. If I disable (Fn+F7) the touchpad and reboot, the > touchpad is inactive on reboot. Thanks for your test, then I understand this behavior didn't introduce by launch manager mode. Looks the BIOS keep the touchpad state by itself. > > Anything else you need/want to know? I will try to find a way to enable it when system boot, but I prefer to keep this BIOS behavior.
Are you still seeing this with the 3.9.4 kernel in updates-testing?
I saw some improvements in a test a few weeks ago but I haven't had time to fully test the behaviour. I will test soon and let you know. I do know that Fn-F5 wasn't working to rotate through additional screens and wasn't sure if it was related.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.