The vertical (right) edge area on the touchpad begins at 5312 (the right edge value) but doesn't end where the physical right edge is (priv->maxx). As a result, right edge scrolling takes place only in a vertical stripe which is almost in the middle of the touchpad while it should flush against the physical right edge. No scrolling takes place right of the vertical stripe, only movements. NOTE: this happens with some Synaptics and Elantech touchpads.
my first guess is that this is done by clipping in the server. I can't reproduce this on my touchpad though. Please clone git://people.freedesktop.org/~whot/testdevices.git and create a simple test device with the values on your touchpad. It's quite easy to do and there are already a few devices that can serve as example. that'd help reproduce it on my side so we can fix it.
Created attachment 28305 [details] [review] Patch to test the devices Does the attached patch help? It should reproduce the behaviour of my Elantech touchpad and the one of the Synaptics touchpad used by the user who reported the problem on Launchpad. Let me know if you need further information. Also I would like to know where clipping takes place so that I can investigate the problem.
(In reply to comment #2) > Does the attached patch help? did you test this? both devices fail immediately with an "invalid argument" error.
Created attachment 28333 [details] [review] Patch to test the devices - tested I found the reason why the two programs failed. It looks like neither dev->absmax[ABS_PRESSURE] nor can dev->absmax[ABS_TOOL_WIDTH] can be 0. Using evtest Elantech reports dev->absmax[ABS_PRESSURE] = 0 while the Synaptics touchpad reports dev->absmax[ABS_TOOL_WIDTH] = 0. My patch works now.
I think I didn't provide enough information with my first comment. So the problem is that I cannot reproduce the effect on my touchpad, scrolling works all the way up to the right edge. These things are simple to reproduce with software test devices as you can force a device to look a certain way and you can force a distinct set of events. With the patch above, the cursor simply moves left/up to right/bottom and back. This wouldn't trigger scrolling on any touchpad, so the test device as is cannot be used to reproduce the bug. Please modify the test device's run method to send events that trigger scrolling in the first region but don't trigger scrolling in the second region (even though they should). I can then run this here and see what happens in the driver.
I just had a look at this again and the source of the whole issue is that the touchpad reports different coordinates that it provides. From the launchpad bugreport: 700-1100 no mouse movement 1100-5200 regular mouse movement 5200-5900 scrolling movement 5900-6250 no mouse movement from the log: (II) SynPS/2 Synaptics TouchPad: x-axis range 1472 - 5472 (II) SynPS/2 Synaptics TouchPad: y-axis range 1408 - 4448 so anything above 5472 is iffy anyway. It also explains why a uinput test device is pointless here, uinput won't allow this stuff. looking at the code, there's a few places where this could cause issues, especially when scaling back. However, I need feedback for a current version of synaptics, not 0.99.3 which the original bugreport is based on. Is this still an issue with an up-to-date driver?
> 2 years silence, closing. please reopen if this is still an issue, or better file a new bug with up-to-date logs
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.