Synaptics touchpad ceases functioning after suspend and resume.

Bug #59867 reported by Joseph Slaker
220
This bug affects 30 people
Affects Status Importance Assigned to Milestone
Ubuntu
Invalid
Undecided
Unassigned
cruft (Ubuntu)
Invalid
Undecided
Unassigned
linux (Ubuntu)
Won't Fix
Medium
Unassigned
linux-source-2.6.20 (Ubuntu)
Won't Fix
Low
Unassigned

Bug Description

After suspending the notebook, resume works fine except that the Synaptics touchpad no longer responds to any input.

Restarting the X server does not help.

Attempting to cat /dev/input/mice at the console and then moving the touchpad does not show any input being received. The touchpad which had been /dev/input/mouse0 is no longer listed after the resume.

This bug was present in Dapper and still exists in the current (2006-09-11) build of Edgy as well and Karmic Koala (9.10)

Gateway MX6625 Notebook
Centrino Chipset
Synaptics Touchpad

Also affects
Gateway MX6025 Notebook with Karmic Koala 9.10
HP EliteBook 2530p with Ubuntu Lucid 10.04 LTS amd64
Fujitsu Siemens Computer Aminlo Si1520 with Ubuntu Lucid 10.04 LTS
and others.

Multiple ways to bypass the bug are suggested in comments. Adding Grub parameter atkbd.reset worked for many. Set GRUB_CMDLINE_LINUX_DEFAULT="quiet splash atkbd.reset" in /etc/default/grub, run 'sudo update-grub' and reboot.

Revision history for this message
Joseph Slaker (jslaker) wrote :
Revision history for this message
Joseph Slaker (jslaker) wrote :
Revision history for this message
Joseph Slaker (jslaker) wrote :
Revision history for this message
Joseph Slaker (jslaker) wrote :

Not sure that I agree with assigning this bug as belonging to xserver-xorg-input-synaptics. The fact that the touchpad no longer shows up in /dev/input/ would suggest to me that the problem is lower level than the X server.

I'm no expert on the matter, however, so I could certainly be wrong. :-)

Revision history for this message
Joseph Slaker (jslaker) wrote :

Seems to be the same problem these people are experiencing, so their efforts so far may give a better idea as to what's going on.

http://<email address hidden>/msg47874.html

Revision history for this message
Joseph Slaker (jslaker) wrote :

I believe this affects the kernel given the symptoms found, not X.org. Package listing changed appropriately.

Revision history for this message
Ben Collins (ben-collins) wrote :

Please try latest edgy kernel (2.6.17-8.22).

Changed in kernel-package:
status: Unconfirmed → Needs Info
Revision history for this message
Joseph Slaker (jslaker) wrote :

Sorry for the long delay.

I can confirm that this is still present in the latest Edgy update (2006-09-29, 01:30 EST).

Revision history for this message
Thomas Babut (thbabut) wrote :

I can confirm this, too. It's a Fujitsu-Siemens notebook with synaptics touchpad. After going back from suspend mode the touchpad doesn't work anymore. An external mouse does work.

Revision history for this message
Joseph Slaker (jslaker) wrote :

My symptoms include being able to use an external mouse normally after suspend as well.

Thomas, think you could post further system specifications/lspci output so we could see what common factors in hardware there are here?

Revision history for this message
Thomas Babut (thbabut) wrote :

I've attached some outputs/logfiles.

Revision history for this message
Tim Caswell (tim-creationix) wrote :

I still have the same problem with a Gateway MX6441 with Turion and ATI motherboard. I have the newest updates to date

Revision history for this message
Joseph Slaker (jslaker) wrote :

This behavior is still present as of 2006-10-22 in my notebook.

Tim's report of similar behavior in an AMD/ATI based notebook makes me wonder if it might be related to a specific touchpad model, since they would seem to rule out any chipset related issues.

Revision history for this message
Pedro Martinez-Julia (pedromj) wrote :

After suspend/hibernate the device file that points to the touchpad (event*) changes its name (event1 -> event3 or something like it).

I had to add rules to "udev" that makes it create a link called /dev/input/touchpad that points to the "right" device file.

Revision history for this message
Joseph Slaker (jslaker) wrote :

In my case, the touchpad is apparently /dev/input/event1 before suspend, but afterwards is not recreated at all.

Revision history for this message
Bastanteroma (bastanteroma) wrote :

I've got a new hp/compaq with similar behavior - touchpad works after hibernate, but not after suspend, and a mouse always works. I'm happy to provide logs given directions.

Revision history for this message
GiuseppeVerde (launchpad-digitasaru) wrote :

Could somebody post xorg.log output? (/var/log/Xorg.[num].log, depending on your server number). This bug may be related to bug 60544: https://launchpad.net/distros/ubuntu/+source/xorg-driver-synaptics/+bug/60544.

Revision history for this message
Javi Becerra (javi-becerra) wrote :

Hi,
I'm experiencing the same problem on an Ahtec Signal 1 laptop using Ubuntu 6.10.

I send you my Xorg.log in attachment...

Revision history for this message
Jeff Gehlbach (jeffg+launchpad) wrote :

Identical issue to the one originally reported with Edgy release, all packages up to date as of time of this post, on a Gateway 6525GP. Touchpad works before suspend, but stops functioning after resume and its nodes in /dev/input disappear. Issue does not manifest after hibernate.

Attached archive contains output of lspci, lsmod, dmesg, and `ls -lR /dev/input`, as well as /var/log/Xorg.0.log, each from before (./presuspend) and after (./postresume) the suspend / resume.

Revision history for this message
Joseph Slaker (jslaker) wrote :

Just updating that this bug is still present in the latest Feisty Herd 2 release, with all updates current as of 2007-01-18 23:15 GMT.

Revision history for this message
Joseph Slaker (jslaker) wrote :

Bug still present in latest available kernel in feisty development builds (2.6.20-5)

Tim Gardner (timg-tpi)
Changed in linux-source-2.6.20:
assignee: nobody → timg-tpi
Tim Gardner (timg-tpi)
Changed in linux-source-2.6.20:
assignee: timg-tpi → ubuntu-kernel-acpi
importance: Undecided → Low
status: Needs Info → Confirmed
Revision history for this message
Luca (sciamano) wrote :

Bug still presend in the latest available kernel in feisty beta (2.6.20-13)

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

What I find weird is that after a suspend&resume, I have this issue (2.6.20-15 now, and all the previous ones of the series).

However, once it's triggered, I can fix it by HIBERNATING and then resuming.

Revision history for this message
Jeff Gehlbach (jeffg+launchpad) wrote :

Jeremy, it's really not surprising at all that a hibernate / resume clears the issue, because to hibernate is to save the state of RAM to a swap partition and then power off the machine. To resume from a hibernate is to do a cold boot and then reload that saved RAM state from the swap partition.

-jeff

Revision history for this message
trubblelmaker (matt-andruff) wrote :

duplicate of this bug with more information:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/80303

if there is a solution these forums should be contacted:

http://ubuntuforums.org/showthread.php?t=304364
http://ubuntuforums.org/showthread.php?p=2464945#post2464945
http://ubuntuforums.org/showthread.php?t=331088
http://ubuntuforums.org/showthread.php?t=253620

above I read:

 Pedro Martínez Juliá said on 2006-10-23: (permalink)

          After suspend/hibernate the device file that points to the touchpad (event*) changes its name (event1 -> event3 or something like it).
         I had to add rules to "udev" that makes it create a link called /dev/input/touchpad that points to the "right" device file.

What does this mean? Does this mean there a fix, and if so how do I add a udev rule?

Revision history for this message
Tavis J. Hampton (hamptont) wrote :

I can confirm that the same problem exists with my Averatc 5110H laptop. Interestingly, if I turn of ACPI and use APM to suspend-to-ram, it comes back with a working touchpad, but battery and fan monitoring/control are absent.

I also should note that my laptop has a software controlled RF switch; to turn on the wireless radio requires a special kernel module (av5100). Is it possible that the laptops experiencing this problem require some software to turn them back on? Apparently, it would seem as though the Bios (acpi) is disabling the touchpad purposely. Otherwise, if it is a linux kernel issue, why aren't all laptops affected?

Finally, you should know that Pedro's issue seems to be different. On my laptop, and most on this bug, /dev/input/event* are not just changed for the touchpad, they are completely gone.

Normally, I have the attached under /proc/bus/input/devices. That is gone after resuming from suspend-to-ram.

Revision history for this message
trubblelmaker (matt-andruff) wrote :

I've had seen a work around for returning synaptic functionality: I post it here as help to people that want to fix the issue as it's not an acceptable fix to me.

   1. System -> Quit
   2. Switch User
   3. Login as the same user again

original post with answer:
http://ubuntuforums.org/showpost.php?p=2532846&postcount=7

Revision history for this message
trubblelmaker (matt-andruff) wrote :

I confirm that /proc/bus/input/devices is missing the synaptic after suspend to ram

here are the files for comparison

Revision history for this message
trubblelmaker (matt-andruff) wrote :

here's the after with mouse broken

Revision history for this message
Tavis J. Hampton (hamptont) wrote :

I tried the fix listed on http://ubuntuforums.org/showpost.php?p=2532846&postcount=7, and it does not work. That person must still have their touchpad listed in /proc/bus/input/devices, and they just have the switch-around problem mentioned by Pedro. That seems to be a separate, less severe bug.

By the way, I am running Feisty.

Revision history for this message
trubblelmaker (matt-andruff) wrote :

yeah, I'm on fiesty and I believe my problem can be fixed by udev rule, my mouse entry as in /proc/bus/input/devices switches from:

before suspend:
I: Bus=0011 Vendor=0002 Product=0007 Version=0000
N: Name="SynPS/2 Synaptics TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/class/input/input2
H: Handlers=mouse1 event2 ts1
B: EV=b
B: KEY=6420 0 70000 0 0 0 0 0 0 0 0
B: ABS=11000003

after suspend:
I: Bus=0017 Vendor=0001 Product=0001 Version=0100
N: Name="Macintosh mouse button emulation"
P: Phys=
S: Sysfs=/class/input/input0
H: Handlers=mouse0 ts0 event0
B: EV=7
B: KEY=70000 0 0 0 0 0 0 0 0
B: REL=3

not even close !

anyone now how to right a udev rule ? Or point me to a howto and I'll do it myself. The research I've done says this is probably what I need to do to fix it...

Revision history for this message
Joseph Slaker (jslaker) wrote :

trubblemaker said:
"I also should note that my laptop has a software controlled RF switch; to turn on the wireless radio requires a special kernel module (av5100). Is it possible that the laptops experiencing this problem require some software to turn them back on? Apparently, it would seem as though the Bios (acpi) is disabling the touchpad purposely. Otherwise, if it is a linux kernel issue, why aren't all laptops affected?"

The Gateway notebook that this bug was originally filed for used a software switch to control the WiFi, so I wouldn't think that the problem should be related to that.

The motherboard chipset was an Intel 915G, not sure if that could be related or not.

Revision history for this message
Tavis J. Hampton (hamptont) wrote :

I have discovered a workaround. The bug is posted at

http://bugzilla.kernel.org/show_bug.cgi?id=7977

and is currently being fixed for 2.6.21-rc3

Since I have no intention of replacing the default Ubuntu kernel, attached is a script that allows you to unbind the touchpad driver and then rebind it after resume. This solves the problem. I've tested it several times with 100% success. I also added the script to /etc/acpi/events/lidbtn so that closing the lid would execute the script.

This is not a fix, only a workaround, but it's better than nothing.

Revision history for this message
Nick Barcet (nijaba) wrote :

Modify /etc/default/acpi-support
In the value of MODULES, add psmouse ex : MODULES="psmouse"
Works fine for me.

Revision history for this message
dhenry (tfc-duke) wrote :

Synaptics touchpad is broken after resume on Lenovo 3000 N100 too.
The device in /dev/input disappears after resume, and in /proc/bus/input/devices too.

Who in the system is responsible of this device? (which kernel module? ...)
And is there a way to restart it manually?

Revision history for this message
Zsolt Zakál (zakalzs) wrote :

I have a Fujitsu Siemens Amilo Pro V3205, with Ubuntu Gutsy (generic kernel 2.6.22-14). Suspend works like a charm except this annoying touchpad problem. I tried to modify the /etc/default/acpi-support (MODULES="psmouse"), but it does'nt help.

Revision history for this message
dhenry (tfc-duke) wrote :

Try adding i8042.reset parameter to kernel in the bootloader.

In /boot/grub/menu.lst, the line begining with "# defoptions" like thise one on my system:
# defoptions=quiet splash locale=fr_FR i8042.reset

Then run update-grub, reboot, and play with suspend.

Revision history for this message
Zsolt Zakál (zakalzs) wrote :

Thanks for the tip, but no luck :( I tried i8042.nomux also, but the touchpad is dead after resume.

Revision history for this message
Stein-Arne Kolaas (sakolaas) wrote :

"I have a Fujitsu Siemens Amilo Pro V3205, with Ubuntu Gutsy (generic kernel 2.6.22-14). Suspend works like a charm except this annoying touchpad problem. I tried to modify the /etc/default/acpi-support (MODULES="psmouse"), but it does'nt help."

I have the same laptop, and found the solution some months ago:
Change to BIOS 1.10, that solves the suspend issue.

Revision history for this message
Benjamin Drung (bdrung) wrote :

I think, this is not a bug in xserver-xorg-input-synaptics. It is a linux/acpi problem. The touchpad does not wake up correctly. After resume the touchpad should appear in the /dev tree.

Changed in linux-source-2.6.24:
status: New → Invalid
Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: New → Triaged
Changed in linux-source-2.6.20:
status: Confirmed → Won't Fix
50 comments hidden view all 130 comments
Revision history for this message
Charlie Dyson (charlie-charliedyson) wrote :

I'm having this problem with Karmic on an old Toshiba Tecra. I started having a similar but less serious problem with Intrepid. Now when I resume from suspend, the touchpad often locks up completely - even the button's don't work. I found this in Xorg.0.log

(EE) PS/2 Mouse: Failed to reopen device after 10 attempts.
(II) config/hal: removing device PS/2 Mouse
(II) PS/2 Mouse: Close
(II) UnloadModule: "evdev"
(II) config/hal: removing device AlpsPS/2 ALPS GlidePoint
(II) UnloadModule: "synaptics"
(II) config/hal: Adding input device PS/2 Mouse
(**) PS/2 Mouse: always reports core events
(**) PS/2 Mouse: Device: "/dev/input/event7"
(EE) Unable to open evdev device "/dev/input/event7".
(II) UnloadModule: "evdev"
(EE) PreInit returned NULL for "PS/2 Mouse"
(EE) config/hal: NewInputDeviceRequest failed (8)
(II) config/hal: Adding input device AlpsPS/2 ALPS GlidePoint
(II) Synaptics touchpad driver version 1.1.2
(**) Option "Device" "/dev/input/event8"
(EE) xf86OpenSerial: Cannot open device /dev/input/event8
 No such file or directory.
(EE) Synaptics driver unable to open device
(EE) PreInit failed for input device "AlpsPS/2 ALPS GlidePoint"
(II) UnloadModule: "synaptics"
(EE) config/hal: NewInputDeviceRequest failed (8)

Solution that worked for me:
$ sudo rmmod psmouse
$ sudo modprbe psmouse

...and the touchpad springs back to life!

Revision history for this message
Charlie Dyson (charlie-charliedyson) wrote :

Correction: substitute "Intrepid" for "Jaunty" in my previous comment. I had no problems with Intrepid.

Revision history for this message
FraGe (fragebuntu) wrote :

... found that one again, the bug still persists - as found on other pages
-> http://si1520.blogspot.com/
on Amilo Si1520 it helps to downgrade the BIOS to 1.10 (if you don't have a Yonah D0 CPU)
but there should be other solutions - till now, nothing helped for me :(

FraGe

Revision history for this message
steveG (steffen-schreiner) wrote :

I got a HP EliteBook 2530p on u9.10 with the same problem. Though it's has a fancy behaviour: First of all, after resuming the touchpad is going rogue and doesn't work anymore. If I use only the pointer stick, everything is fine, keyboard works as well. Yet, the first slide over the touchpad ends up in a unpredictable keyboard/mouse input and keyboard+stick+touchpad is ending up dead or bogus. Now, if I standby and resume again, either everything work fine right away, or I can use tab or stick to "Switch User" in the "Unlock Screen". Then X refreches someway and everything is fine again and I select my user and unlock the screen. The cherry on the cage, this is without exception an alternating behaviour. I'm already used to wake up the thingy by a resume+immediate standby+resume again.

Xorg.0.log says:
---------------------------
(II) config/hal: Adding input device SynPS/2 Synaptics TouchPad
(II) Synaptics touchpad driver version 1.1.2
(**) Option "Device" "/dev/input/event8"
(EE) xf86OpenSerial: Cannot open device /dev/input/event8
        No such device.
(EE) Synaptics driver unable to open device
(EE) PreInit failed for input device "SynPS/2 Synaptics TouchPad"
(II) UnloadModule: "synaptics"
---------------------------

and in /var/log/messages I realized the following lines are missing, for wake-ups with the problem:
---------------------------
Jan 30 00:14:31 pluto kernel: [831050.033342] Synaptics Touchpad, model: 1, fw: 7.0, id: 0x1a0b1, caps: 0xd04711/0xa00000
Jan 30 00:14:31 pluto kernel: [831050.079701] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input301
Jan 30 00:14:32 pluto kernel: [831050.857121] Synaptics Touchpad, model: 1, fw: 7.0, id: 0x1a0b1, caps: 0xd04711/0xa00000
Jan 30 00:14:32 pluto kernel: [831050.898051] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input302
---------------------------

Revision history for this message
Jens Rantil (jens-rantil) wrote :

I am experiencing this with Amilo Pro v3205 on Karmic Koala with kernel 2.6.31-14-generic. I am not interested in downgrading my BIOS.

description: updated
Revision history for this message
Surak (smkozasa) wrote :

Also, in my Semp-Toshiba IS1253 notebook running Kubuntu Karmic Koala with kernel 2.6.31-19-generic the problem persists, no touchpad after resuming from suspend.

Some interesting lines from dmesg:

(...)
[ 9217.732183] e100 0000:07:08.0: wake-up capability disabled by ACPI
[ 9217.732189] e100 0000:07:08.0: PME# disabled
(...)
[ 9219.425416] PM: resume devices took 3.152 seconds
[ 9219.425459] PM: Finishing wakeup.
[ 9219.425461] Restarting tasks ... done.
[ 9219.701985] Unable to query Synaptics hardware.
(...)

Revision history for this message
Paede (patrick-steiner-gmx) wrote :

Similar problem after resume: When i move my finger over the touchpad its looks like the left mouse button is pressed but never released. every icon, button or everything else is opened, moved or smilliar when i move the mouse pointer over it.
i have to reboot my notebook (hp nx8220) to fix this problem. (which is very hard to move to mouse pointer to the reboot button without to move all my icon on my desktop ;-) )

Revision history for this message
R K (rkuzsma) wrote :

I have the same problem as Jeremy Wilkins (same output logs, etc.). The Synaptics touchpad on my Gateway machine resumes properly in Windows XP, but not on Ubuntu 9.10. None of the workarounds mentioned in the thread work for me to revive the mouse after resuming from suspend.

Revision history for this message
Surak (smkozasa) wrote :

Well, suspend to RAM and resuming, causes the problem and when this happens, hibernating to disk and resuming solves it.

It seems that this fact has been underestimated before. This might, in fact lead to the solution. Note that in my case, dmesg says that it just can't query Synaptics hardware. Well, what happens after a hibernate to disk and resume? The computer is powered off and the synaptics hardware is reset!

So, I may be guessing too much, but I'm an Electronics Engineer and would say that maybe the solution to all of this is to send a reset command to the synaptics touchpad when resuming from suspend to RAM??

Revision history for this message
Jeremy Wilkins (wjeremy) wrote :

@Surak: I believe you are correct for the most part, but the difference here between suspend to RAM and suspend to disk is that in suspend to disk the hardware is physically shut off, versus put to sleep in suspend to RAM. The power is not off in suspend to RAM, some devices are powered off, but most devices are powered low or suspended until resume (note: no hardware power down so state registers may be preserved). I do agree that a reset of the hardware should fix the problem, but all the methods of software device reset known have been tried and still fail. I do agree it is possible to resolve this issue somehow, since it works in other non-linux OSs. I suspect there is a resume command that needs to be sent to the PS/2 port chip once the OS is loaded to repower the chip before the OS GUI is up for those that the touchpad reset doesn't solve (like mine). I am not certain, but I think there are possible three different problems happening here on this bug.
1) The touch pad needs a reset command and comes back up (most devices this works)
2) The PS/2 port chip is still off during resume and needs a resume command (possibly my case) which may not need a touchpad reset if the touchpad was power off. Touchpad reset does nothing in this case, however a suspend and resume fixes it because state registers are changed.
3) The touchpad needs a suspend command and doesn't receive one, so when the system goes into suspend it is left hanging. (maybe my case)
I am by no means a hardware excpert, but I work with low-level hardware involvement daily and write software to make the hardware work and this is what I think I am seeing.

Revision history for this message
steveG (steffen-schreiner) wrote :

I just updated to Lucid today, well nice, first try and hit. It showed the exact same behavior.

But then after googling again, today I found this: http://ubuntuforums.org/archive/index.php/t-1335007.html

And simply appending "atkbd.reset" as a kernel parameter worked, keyboard and touchpad come up properly
after each suspend!

Revision history for this message
jmkhenka (jmkhenka) wrote :

YES! Finaly!

On my Amilo SI 1520 with latest firmware (got a c2d 2ghz, so i cant downgrade) the
atkbd.reset as kernel extension WORKS.

My touchpad WORKS after suspend.

As steveG wrote:
I just updated to Lucid today, well nice, first try and hit. It showed the exact same behavior.

But then after googling again, today I found this: http://ubuntuforums.org/archive/index.php/t-1335007.html

And simply appending "atkbd.reset" as a kernel parameter worked, keyboard and touchpad come up properly
after each suspend

---

read the link for instructions to add it to boot.
Now im wondering, how do you permanently add this at boot? It saves betweeen suspend/reset but if i reboot i have to add it again.

Revision history for this message
jmkhenka (jmkhenka) wrote :

Found a permanent solution!

Edit /etc/default/grub
and change the line
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
to
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash atkbd.reset"

and run update-grub, reboot and when you press E in grub you will se the entry there.

Revision history for this message
Jeremy Wilkins (wjeremy) wrote :

@jmkhenka: Confirmed works for me. I have tried all the other solutions and none of them worked, but as soon as i tried this one, the touchpad worked after suspend. I am not certain if a reboot is required first, but I imagine it is. I rebooted just to be sure.

Revision history for this message
Timrit (wimurtz) wrote :

@jmkhenka: Confirmed it works for me as well. I also tried all the other solutions to no avail. I have suspended the laptop several times now and it comes back every time. Thank you!

description: updated
Revision history for this message
Tero Karvinen (karvinen+launchpad) wrote :

Touchpad doesn't work after suspend on 10.04 and HP EliteBook either.

Suspended, resumed, touchpad doesn't work. Keyboard worked at least mostly. External USB mouse connected after suspend worked.

Test setup was HP EliteBook 2530p (text in plastics), Ubuntu Lucid 10.04 LTS (cat /etc/lsb-release), amd64 (uname -m).

Revision history for this message
Tero Karvinen (karvinen+launchpad) wrote :

Grub atkbd.reset workaround seems to fix it for me. I have only tested this once.

I followed instructions in #103 and rebooted. After that, I suspended and resumed - touchpad worked. HP EliteBook 2530p, Ubuntu Lucid 10.04 LTS, amd64.

#103: atkbd.reset bug bypass proposed by jmkhenka and others.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/59867/comments/103

Revision history for this message
jmkhenka (jmkhenka) wrote :

#106: have you tried adding atkbd.reset as kernel option when booting (if you edit grub in ubuntu you need to restart for it to work)? It's confirmed working for several diffrent setups.

Se my earlier post on how to do it if you are uncertain..

description: updated
Revision history for this message
Tero Karvinen (karvinen+launchpad) wrote :

jmkhenka: Yes, atkbd.reset works as you describe in #103. We probably posted #107 and #108 at the same time. I added atkbd.reset bypass to bug description.

Revision history for this message
Surak (smkozasa) wrote : Re: [Bug 59867] Re: Synaptics touchpad ceases functioning after suspend and resume.

OK, so we know how to fix it manually. But why is status in Ubuntu
invalid and status in "linux-source-2.6.20" package in Ubuntu as WON'T
FIX? What does this mean? It's known how to solve it but nothing will be
done to solve it? I can't believe this!

Surak.

---

Em 04-05-2010 09:27, Tero Karvinen escreveu:
> jmkhenka: Yes, atkbd.reset works as you describe in #103. We probably
> posted #107 and #108 at the same time. I added atkbd.reset bypass to bug
> description.
>
>

Revision history for this message
Anders Kaseorg (andersk) wrote :

Surak: “linux-source-2.6.20 (Ubuntu)” is the kernel that came with Ubuntu 7.04 Feisty; that task is marked Won’t Fix for that kernel because Ubuntu 7.04 reached its end-of-life a year and a half ago and is no longer supported. Please don’t worry; the bug is still open for the current kernel package “linux (Ubuntu)”.

The “Ubuntu” task is marked Invalid because the more specific “linux (Ubuntu)” task open. Again, don’t worry; this is normal, and as long as at least one of the tasks is still open, the bug is considered open.

Revision history for this message
Thomas Sundell (thomas-sundell) wrote :

openSUSE 11.2 has the same exact issue on my laptop: https://bugzilla.novell.com/show_bug.cgi?id=585186

description: updated
Revision history for this message
lemon kun (lemon-kun) wrote :

Hello everybody, this is my first post and my first day with ubuntu (or any other linux).

I have the problem as well, with the latest ubuntu I downloaded yesterday and a lenovo-laptop.

I know there is a fix in post #103, but I don't know what to do with it. I tried to type into the terminal but that actually doesn't work. I also don't know what "grub" means. Sorry wasting your time, but I don't know much about computers.

All the best, and thank you

Edit /etc/default/grub
and change the line
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
to
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash atkbd.reset"

and run update-grub, reboot and when you press E in grub you will se the entry there.

Revision history for this message
Surak (smkozasa) wrote :

This may not be the best place for a how-to, but I guess many others
will benefit.

Grub is the boot manager used by Ubuntu, the first program loaded, used
to choose from which installation or Operating System you want to boot.
The procedure is to add the "atkbd.reset" parameter on boot time.

1) Open a terminal or console.
2) Type in
     sudo nano /etc/default/grub
Followed by <ENTER> key and type your password, followed by pressing the
<ENTER> key.
3) A text file will appear. Move cursor with arrow keys until the line

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

just before the closing double quote, type

atkbd.reset

Press Control key without releasing it press "O" key (letter O, not zero), release both, press<ENTER> to save the file. Press Control key, without releasing it, press "X" key. Release both.

This will bring you back to command line prompt. Now type:

sudo update-grub

Followed by<ENTER> key. That's it! No need to press "E" key while rebooting. That's just for checking if the atkbd.reset parameter was correctly inserted.

Surak

---

Em 30-05-2010 09:24, lemon kun escreveu:
> Hello everybody, this is my first post and my first day with ubuntu (or
> any other linux).
>
> I have the problem as well, with the latest ubuntu I downloaded
> yesterday and a lenovo-laptop.
>
> I know there is a fix in post #103, but I don't know what to do with it.
> I tried to type into the terminal but that actually doesn't work. I also
> don't know what "grub" means. Sorry wasting your time, but I don't know
> much about computers.
>
> All the best, and thank you
>
> Edit /etc/default/grub
> and change the line
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
> to
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash atkbd.reset"
>
> and run update-grub, reboot and when you press E in grub you will se the
> entry there.
>
>

Revision history for this message
lemon kun (lemon-kun) wrote :

Thank you so much for answering so quickly. I tried everything, and the whole procedure worked fine, you described everything really fool-proof, thanks. So I had in the end:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash atkbd.reset"
GRUB_CMDLINE_LINUX=""

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

which I saved as you wrote it and then quit with cmd+x, and then did the sudo update. That worked all fine, but in the end, the problem remains, the cursor will freeze when I come from suspend-mode :-(

My computer is a lenovo, model name difficult to read (all in Chinese, except 0768), and I am using ubuntu 10.04 32-bit. It isn't a huge topic for me, as I use normally the mouse, so no problem, but still just for your information.

Revision history for this message
Surak (smkozasa) wrote :

Sorry, I've forgotten to say that you need to restart the computer after
the procedure. I hope it works after that. Plese make as know if it works.

Em 30-05-2010 15:16, lemon kun escreveu:
> Thank you so much for answering so quickly. I tried everything, and the
> whole procedure worked fine, you described everything really fool-proof,
> thanks. So I had in the end:
>
> # If you change this file, run 'update-grub' afterwards to update
> # /boot/grub/grub.cfg.
>
> GRUB_DEFAULT=0
> GRUB_HIDDEN_TIMEOUT=0
> GRUB_HIDDEN_TIMEOUT_QUIET=true
> GRUB_TIMEOUT=10
> GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash atkbd.reset"
> GRUB_CMDLINE_LINUX=""
>
> # Uncomment to disable graphical terminal (grub-pc only)
> #GRUB_TERMINAL=console
>
> # The resolution used on graphical terminal
> # note that you can use only modes which your graphic card supports via VBE
> # you can see them in real GRUB with the command `vbeinfo'
> #GRUB_GFXMODE=640x480
>
> which I saved as you wrote it and then quit with cmd+x, and then did the
> sudo update. That worked all fine, but in the end, the problem remains,
> the cursor will freeze when I come from suspend-mode :-(
>
> My computer is a lenovo, model name difficult to read (all in Chinese,
> except 0768), and I am using ubuntu 10.04 32-bit. It isn't a huge topic
> for me, as I use normally the mouse, so no problem, but still just for
> your information.
>
>

Revision history for this message
lemon kun (lemon-kun) wrote :

Yes, I made a restart anyway. I tried again now, but still the same problem. And I am sure I executed all the steps properly. Any suggestions? Should I try to get new firmware or anything else? Finally I found out what the model type of my laptop is, it's a Lenovo 3000 N100, Intel Core 2 CPU T5500 @ 1.66 GHz. 1GB RAM.

Revision history for this message
madbiologist (me-again) wrote :

This might be fixed upstream in kernel 2.6.35-rc5. From the changelog:

commit 04a08885c36dc2f4663900d007b9d71a7e7f2b92
Author: Dmitry Torokhov
Date: Thu May 13 00:42:23 2010 -0700

    Input: psmouse - reset all types of mice before reconnecting

    commit ef110b24e28f36620f63dab94708a17c7e267358 upstream.

    Synaptics hardware requires resetting device after suspend to ram
    in order for the device to be operational. The reset lives in
    synaptics-specific reconnect handler, but it is not being invoked
    if synaptics support is disabled and the device is handled as a
    standard PS/2 device (bare or IntelliMouse protocol).

    Let's add reset into generic reconnect handler as well.

    Signed-off-by: Dmitry Torokhov
    Cc: Tim Gardner
    Signed-off-by: Greg Kroah-Hartman

A PPA of this kernel can be found at http://kernel.ubuntu.com/~kernel-ppa/mainline/

Revision history for this message
madbiologist (me-again) wrote :

Oops, that should be kernel 2.6.32.16. Sorry.

Revision history for this message
vtomilin (vitaly-tomilin) wrote :

Adding atkbd.reset at the end of the kernel cmdline worked for me on Gateway MX6445. Kudos to jmkhenka! Thanks a mil!

Revision history for this message
Manjul Apratim (manzdagratiano) wrote :

I too have had the same issue on my Dell Vostro V13 starting a week ago after an upgrade - my mouse was always slow to reload after a resume from suspend, but now it had stopped resuming altogether. After a combination of fixes, I settled upon the following that works for me (thanks to anxrc from Arch Linux forums for the motivation - he originally employed the bind/unbind trick for i8042 drivers, but that did not work for me):

Create a file /etc/pm/sleeps.d/71input-reset, and paste in it:

#!/bin/sh
#
# Reload the AT keyboard interface.

case "$1" in
        hibernate|suspend)
                rmmod psmouse
                ;;
        thaw|resume)
                modprobe psmouse
                ;;
        *)
                ;;
esac

Make it executable:

sudo chmod +x /etc/pm/sleep.d/71input-reset

and we're done! This reloads the psmouse module every time a resume occurs (unloads it during suspend, but that does not affect anything), and it does work :)

Revision history for this message
Manjul Apratim (manzdagratiano) wrote :

By the way I have not tried fiddling with grub options, but I did not understand how that helps a resume after suspend, because grub is not invoked then? I figure it should work after a hibernate when grub is called into action.

Revision history for this message
Manjul Apratim (manzdagratiano) wrote :

Ah... my bad... the comment in the script is a relic from the old attempts to bind/unbind the i8042 module, so pray do ignore it

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

On Mon, Nov 8, 2010 at 17:01, manzdagratiano <email address hidden>wrote:

> By the way I have not tried fiddling with grub options, but I did not
> understand how that helps a resume after suspend, because grub is not
> invoked then? I figure it should work after a hibernate when grub is
> called into action.
>

The "grub options" are really just to pass parameters to the Linux kernel.
Those parameters persist until the kernel is shutdown, so they can have an
effect on suspend/resume.

--
Jeremy Nickurak -= Email/XMPP: -= <email address hidden> =-

Revision history for this message
Philipp Wendler (philw85) wrote :

This bug also affects Natty.
I have a Fujitsu-Siemens Amilo Pro V3205 and adding the parameter "atkbd.reset" to the kernel command line via grub worked.

Revision history for this message
Brad Figg (brad-figg) wrote : Unsupported series, setting status to "Won't Fix".

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: Triaged → Won't Fix
Revision history for this message
Philipp Wendler (philw85) wrote :

I added a new bug (bug 810327) as the problem still exists in Natty.

Revision history for this message
Surak (smkozasa) wrote : Re: [Bug 59867] Re: Synaptics touchpad ceases functioning after suspend and resume.

Just for the note, this bug seems hardware-dependant. Wiith my
current notebook (Meoo - Design Box - DB-N6643/U) the touchpad
does work after suspend.

Curtis Hovey (sinzui)
Changed in linux-source-2.6.20 (Ubuntu):
assignee: Registry Administrators (registry) → nobody
1 comments hidden view all 130 comments
Revision history for this message
vacaloca (ltirado) wrote :

I wanted to comfirm that I had the touchpad/keyboard not working after suspend, running Ubuntu Saucy GNOME 13.10 Beta 1 updated on a Toshiba P50-ABT2G22 Haswell-based laptop. The trick of:

"Adding Grub parameter atkbd.reset worked for many. Set GRUB_CMDLINE_LINUX_DEFAULT="quiet splash atkbd.reset" in /etc/default/grub, run 'sudo update-grub' and reboot."

worked for me, and I can confirm both keyboard & touchpad work after a suspend with this kernel parameter added.

Displaying first 40 and last 40 comments. View all 130 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.