Created attachment 25905 [details] Xorg full configuration. Overview: On the acer aspire xxxx, there is a new button next to the touchpad. If you press it, the touchpad is switched off, and the button's LED is switched on. After that, you cannot switch the touchpad on again. i.e.: There is no touchpad switch on FN+F5 anymore. It has moved. Notebook (incl. Picture): https://wiki.ubuntu.com/LaptopTestingTeam/AcerAspire5738 Steps to Reproduce: (1) Press the button - the touchpad is off, as expected (2) Press the button again, so the button's LED is off (3) Repeat as often as you like. Actual Results: Touchpad is still switched off. Expected Results: Touchpad switched on. Build Date & Platform: Ubuntu 9.04 amd64 Additional Builds and Platforms: Not really sure. I didn't test it on Vista, I removed it directly after buying. But it should work - explanation follows. Additional Information: Ok, now it gets a little complicated, or lets say, wired. "modprobe -r psmouse; modprobe psmouse" actually fixes it. If it is on and you run this command, the touchpad will work. If it is off and you run this command, the touchpad is still switched off, but - tada - can be switched on. But if you switch it off again afterwards, the bug occurs again. Conclusion: Switching on/off works until you switch it off for the first time. Logs: * dmesg - no output * /var/log/messages - as above * Button has keycode 200 * xmodmap -pk (attached) * Xorg.0.log relevant excerpt ProblemType: Bug Architecture: amd64 DistroRelease: Ubuntu 9.04 NonfreeKernelModules: nvidia Package: xserver-xorg-input-synaptics 0.99.3-2ubuntu4 ProcEnviron: LANG=de_DE.UTF-8 SHELL=/bin/bash ProcVersion: Linux version 2.6.28-11-generic (buildd@crested) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 SourcePackage: xfree86-driver-synaptics Uname: Linux 2.6.28-11-generic x86_64
Created attachment 25906 [details] excerpt of Xorg.0.log
Created attachment 25907 [details] output of 'xmodmap -pk
Created attachment 25908 [details] system specs as from ubuntu-bug
Created attachment 25909 [details] setxkbmap
Bug entry in Launchpad: https://bugs.launchpad.net/xorg-driver-synaptics/+bug/374459
Please download http://people.freedesktop.org/~whot/evtest.c, compile it with "gcc -o evtest evtest.c" and then run it as root with "./evtest /dev/input/eventX" where X is the number for the device. You can get the number by looking at /proc/bus/input/devices. When the touchpad works,you should get the events as you use it. When the touchpad does not work, do you still see events? (btw. please do not attach excerpts of a log. In most cases, these excerpts are missing vital information)
Created attachment 26007 [details] full output of evtest > When the touchpad works,you should get the events as you use it. I'm afraid not. I found out that my touchpad uses event9. But I get an error just when the events should be comming. > When the touchpad does not work, do you still see events? Same as above, so just one file.
> > When the touchpad works,you should get the events as you use it. > I'm afraid not. I found out that my touchpad uses event9. But I get an error > just when the events should be comming. Oh sorry. I forgot that synaptics grabs the device. You need to VT switch away and then run evtest from the tty. While X is running you'll get the device information but not the events.
Hi, well it's very confusing to me what actually has happened. ------------------- TP=Touchpad TPL= Touchpadbutton's LED aka Touchpad lock 1.) TPbutton working, TPL off output: events 2.) TPbutton pressed. TPL on. output: none 3.) TPbutton pressed. TPL off. output: none 4.) TPbutton pressed. TPL on modprobe -r psmouse; modprobe psmouse output: events - on x the TP wouldn't work now 5.) TPbutton pressed. TPL off. output: events - on x the TP starts operating as the lock is gone 6.) TPbutton pressed. TPL on. output: none. 7.) TPbutton pressed. TPL off. modprobe... output: events 8.) TPbutton pressed. TPL on output: none Seems pretty much like a hardware lock to me, but why do I see events after reloading psmouse when the TP should be locked (#4)? On the other hand, if it were a software issue, why does it handle it correctly on step 4 to 5 in X? Hope I got all combinations. If you need more info, just tell me. Also, there is a full Xorg.0.log on launchpad. Regards and thanks for helping.
Not an X bug, needs to be fixed in the kernel. On a guess, I'd say that it's only a hardware lock for the LED, not for the touchpad itself. And the kernel doesn't (or can't?) query the state of the lock. And it seems the kernel may not get the "on" event, only the "off" event. Hence this weird sequence of events. Only guessing here though. Either way, there's nothing we can do in the X drivers until we get the right sequence of events.
Allright, filed at kernel's bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=13363 What's confusing to me is, that I always get an keycode.
I just found out that the touchpad started working again after a while. I'm not sure how to reproduce, but this means it might not be a harware issue. Or maybe it resuming late. I got this message when switching off again: kernel: [ 6499.100541] psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
Created attachment 26112 [details] new messages and working touchpad
ok, I'd need to you to do the following: tail -f /var/log/Xorg.0.log (assuming this is your running X.log) tail -f /var/log/messages then switch the touchpad off and on again. wait until you see something in messages about the device being there again, at this point the X log should print a message too ("touchpad found"). Once this message is printed, does the touchpad work? unfortunately, the touchpad driver isn't very chatty and doesn't print much when the connection is lost.
ping? any update on this?
Yes, on linux kernel bugs, they said it's been fixed. However, wasn't able to test it yet. see here https://bugs.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/374459 and here http://bugzilla.kernel.org/show_bug.cgi?id=13363 Vielen Dank! Thanks for helping! (Setting to invalid, since this is not a xorg-bug).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.