On my Asus Eee PC 701, the vertical scroll function stops working after a very short while. The touchpad itself seems to be working correctly. If the psmouse module is reloaded, scrolling starts working for a short while again. No error messages are visible in the dmesg output or in the Xorg log. Synaptics is configured like this: <?xml version="1.0" encoding="ISO-8859-1"?> <deviceinfo version="0.2"> <device> <match key="input.x11_driver" string="synaptics"> <merge key="input.x11_options.VertEdgeScroll" type="string">true</merge> <merge key="input.x11_options.TapButton1" type="string">1</merge> </match> </device> </deviceinfo> I'm using version 0.99.3 of the synaptics driver from Debian unstable on Xserver 1.5.99.902.
Created attachment 24655 [details] Xorg log I'm adding my Xorg log. Please let me know if there's anything else you need to debug this.
please add input.x11_options.SHMConfig (true) to the fdi and restart HAL, then the X server. Then run synclient -m 20 and move your finger along the scrolling area. Note the coordinates you get from the touchpad. When the scrolling stops, run the same command again. Do you still get the same or similar coordinates? I'm trying to figure out whether this deterioration is in the synaptics or the kernel driver.
I'm not noticing any big difference in the values reported. However, synclient -l reports a different RightEdge when scrolling stops working. It's reported as 5312 on login, but when scrolling breaks, it's 6143, or somewhere in that range, the value varies slightly. Adding this value to the configuration file seems to keep scrolling working.
Not sure if this is helpful info, but if it is a problem with the kernel driver, it's probably present as far back as 2.6.26. That's the kernel I upgraded from to 2.6.29, and the problem is present in both (using the same Xorg version). Unfortunately I have no clue about the X version this broke in.
Is the log file from an instance where it stopped working? If not, do you notice anything in the log files (eg. device disappeared) when that happens?
(In reply to comment #5) > Is the log file from an instance where it stopped working? If not, do you > notice anything in the log files (eg. device disappeared) when that happens? > Yes, the log is taken after scrolling stopped working.
Seems to be what is reported in: https://qa.mandriva.com/show_bug.cgi?id=51845 Is there anything I can do to help fix this Peter?
We'd need a reproducible test case. I tried the one from comment 6 in the mandriva report but it doesn't happen here. It doesn't look like the device is removed and re-added with different settings, so my best guess is that some memory corruption causes the values to be overwritten. The simplest way to track this is gdb the server and watch priv->synpara.right_edge in the driver. if it changes when that bug occurs, then you'll find the culprit.
Actually, this sounds much like http://lists.freedesktop.org/archives/xorg/2009-June/046237.html
Please get evtest from http://people.freedesktop.org/~whot/evtest.c, compile it up and run it (as root) against the touchpad's device file (/dev/input/eventX where X is a number, check /proc/bus/input/devices to get the number). Then move your finger along the right edge as if you were scrolling, this should show the coordinates as the driver receives them. Note that you need to VT switch away from the server (ctrl+alt+F1) before running evtest, otherwise you won't see any events.
Created attachment 27229 [details] evtest output with broken scroll I'm using kernel 2.6.30 now, and the problem is still the same. I have noticed one peculiar thing. Scrolling seems to work fine in gnome-terminal, but as soon as I try scrolling in my browser (Epiphany based on Gecko) it breaks almost immediately. I'm attaching the evtest output, both when vertical scrolling is broken, and when it's functional.
Created attachment 27230 [details] evtest output with functional scroll
Created attachment 27244 [details] [review] auto-adjust-edges.patch Patch applies to current git master. It's a bit long because it also includes cleanup parts in it. The source of the issue is the special scroll area handling that auto-shifts the right edge. The code is buggy though, it results in the edge being 1 unit wide and stops it from triggering the scroll (unless you manage to get into the corner). Bug is triggered by moving the finger continuously once from left to right. Any right-edge scrolling from then on is difficult as the edge is set to XMAX_VALID (6143). Please give this patch a test and let me know if it works for you now.
Created attachment 27245 [details] [review] auto-adjust-edges.patch previous patch was inverted. this is the correct one.
It seems to work fine now :)
Created attachment 27312 [details] [review] 0001-Auto-adjust-edges-if-values-fall-outside-queried-min.patch Updated patch, this time with the required property notify events. Please test this patch (it's two git patches in the same file) and let me know if it works for you. The edge properties should be updated with the new edges, if you run xinput --list-props "SynPS/2 Synaptics TouchPad" before and after moving your finger to the right edge, you should see different values. Alternatively, use synclient -l to check the edge properties.
This latest patch does not seem to apply cleanly to git master.
Created attachment 27348 [details] [review] diff against master
Scrolling works fine with the updated patch, and synclient -l does report different edge values before and after the first time I do a vertical scroll.
pushed as afb60a0b2497c5d08cbd1739fa8ae6585c428881. Thanks for testing!
Is it just me or does this patch seem to move the scrolling area out by just a tad too much? scroll works comfortably for me on the right side but after the adjustment it seems a bit too far on the right and a lot harder to trigger.
I'm on holiday at the moment, but I will do some more testing next week.
(In reply to comment #21) > Is it just me or does this patch seem to move the scrolling area out by just a > tad too much? scroll works comfortably for me on the right side but after the > adjustment it seems a bit too far on the right and a lot harder to trigger. > Yes, I think you're right. It's not a huge problem for me, but it does seem a bit harder to trigger the scrolling.
I've been running this code for over a week now and I'm not happy with it. Once I move over to the right, the scroll-edge becomes so small that it's hard to trigger. Source of the problem is the information provided by the kernel. The kernel hands us a min/max value for the synaptics pads but this value is not reflective of the actual physical boundaries. The other dimensions are based on these min/max ranges. My RightEdge setting by default is 5129, after moving to the right it becomes 5677. The announced max for x is 5472. We have model-specific edge settings and in the case of synaptics the width of the scroll area is 7% of the total width (based on min/max). This works, but obviously only because the max is wrong. I've tried upping this to 15% and it works fine but unless the edge is adjusted the scroll bar takes over too much of the pad. So right now I'm inclined to revert this patch and just ditch any auto-adjustment of scroll edges whatsoever. This way, the original setting is maintained even if we reach outside of the min/max area. Any comments?
As far as I can tell, it sounds like a good idea.
Yes, please revert the patch again. On my setup the edges seem to be adjusted multiple times during an X session even when I set them manually through xinput.
Created attachment 28018 [details] [review] 0001-Remove-the-SpecialScrollAreaRight-option.patch Patch is reverted, here's an updated patch that simply removes the SpecialScrollAreaRight feature. This way, edges are never auto-adjusted at runtime. Works on my box but I never saw the original problem. Testing would be appreciated.
Created attachment 28026 [details] [review] Remove-the-SpecialScrollAreaRight-option-for-1.1.2.patch Peter, thanks for the patch. This attachment is the patch used by Moblin, backported to 1.1.2. I've included it in into Moblin to fix the touchpad issue found on some models of Acer Aspire One netbooks. I'll report if I found any issues.
I just gave it a try, and it seems to work fine on my Eee.
Thank you for testing. Pushed with a minor amendment to the man page. This should close this bug now. Yan: thanks for the backport. I will wait a bit though before pushing it on the 1.1 branch to make sure this one doesn't come back again too.
Till now the patch I've backported to 1.1.2 have worked well in all our Moblin QA tests. We've covered many (but not all) netbook models. I think the patch is quite safe and reliable now.
Thanks Yan, I've already pushed this to the branch and it's part of 1.1.3. Note that I didn't directly apply your patch but cherry-picked it from master and fixed up the few build errors. the end result is the same but cherry-picking preserves the path of the patch (having a back-reference to the original commit).
Thank you Peter. I'm pulling 1.1.3 into Moblin now.
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.