Created attachment 40284 [details] Xorg.0.log I've installed Ubuntu 10.10 on two netbooks, one Acer D250 and one Samsung nf310. Both have a problem with the synaptics driver. The horizontal acceleration is greater than the vertical, hence the pointer is not very precise and it's very annoying. This can be solved by tweaking the config: On the samsung I use: Option "VertResolution" "135" Option "HorizResolution" "100" And on the Acer: Option "VertResolution" "1" Option "HorizResolution" "1" But the driver should be able to auto identify this, especially since windows gets it right. The driver seems to have problems loading as there is stuff like this in the Xorg.0.log on both machines: [ 495.943] (EE) Query no Synaptics: 6003C8 [ 495.943] (--) SynPS/2 Synaptics TouchPad: no supported touchpad found [ 495.943] (EE) SynPS/2 Synaptics TouchPad Unable to query/initialize Synaptics hardware. [ 495.944] (EE) PreInit returned NULL for "SynPS/2 Synaptics TouchPad" But the touchpad works anyway and it's possible to use touchpad features like tapping and scrolling. The Xserver is version 1.9.0 and synaptics is version 1.3.99 from git but 1.2.2 that came with ubuntu had this problem too. I've attatched the Xorg.0.log from the samsung (the one from the acer is similar). The log is taken when my tweaks are disabled.
Created attachment 40346 [details] 50-synaptics.conf As requested, this is my 50-synaptics.conf from the samsung (I have a similar one on the acer). When I ran X to create the attatched Xorg.0.log I disabled all my options so that they wouldn't interfere with the auto detection. All line staring with # are my own, the others are from ubuntu. Also I don't have an /etc/X11/xorg.conf
http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html
Yes, this does indeed fix the errors in the Xorg log. But the other problem remains of course. :)
Just to confirm, I and others have the same problem. It seems synaptics calculates pointer speed/acceleration as a percentage of the total horizontal and vertical pixels available. On a single screen (16:9 ratio, 1920x1080) my horizontal and vertical speeds are identical, but when I extend my desktop horizontally by adding another screen (using TwinView, if that matters), the horizontal speed increases, while vertical speed stays the same. Very annoying. Other pointing devices (like external mice and the trackpoint) do not have this problem, apparently because they're handled by evdev and not synaptics. This is in Ubuntu 10.10 amd64 on a Lenovo Thinkpad W510. I've linked to the ubuntu bug (https://bugs.launchpad.net/utouch/+bug/726832). Is this the most appropriate xorg bug to be linking to from there?
@Martin: I think this is the correct bug, unless the acceleration changing when attatching a second screen is considered a different issue. Synaptics should set the correct resolution on start and then stick with it. It doesn't change if you manually set the resolution btw.
(In reply to comment #4) > Just to confirm, I and others have the same problem. It seems synaptics > calculates pointer speed/acceleration as a percentage of the total horizontal > and vertical pixels available. Same problem here! Vertical and horizontal touchpad cursor speeds seem to be similar when starting X with a single screen, then as soon as another screen is attached horizontally, the horizontal cursor speed goes insane. Conversely, when a screen is attached vertically, the vertical cursor speed is increased. I'm not using any synaptics specific Xorg.conf options. xf86-input-synaptics-1.4.0 xorg-server-1.11.2-r2 Thanks, Angelo
This is somewhere in the server, the accel the driver supplies is always the same.
*** Bug 40417 has been marked as a duplicate of this bug. ***
It looks like Bryce Harrington put together a patch way back in 2010 to address this, or at least something closely related. Here's the link: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/327428/+attachment/1752254/+files/116_resolution_detect_option.patch Here's another patch from the same (duplicate) launchpad bug report: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/327428/+attachment/1368744/+files/synaptics.diff
(In reply to comment #9) > It looks like Bryce Harrington put together a patch way back in 2010 to address > this, or at least something closely related. Here's the link: > > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/327428/+attachment/1752254/+files/116_resolution_detect_option.patch > > Here's another patch from the same (duplicate) launchpad bug report: > > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/327428/+attachment/1368744/+files/synaptics.diff That's a hack. We need to fix the problem, not just paper over it with another option.
I think this was discussed recently on the mailing list - maybe in your holidays - synaptics somehow adjusts itself to the display geometry, IIRC. I don't find it right now, but it sounds as if you could check for display code in synaptics just to be safe.
(In reply to comment #11) > I think this was discussed recently on the mailing list - maybe in your > holidays - synaptics somehow adjusts itself to the display geometry, IIRC. the driver itself has no knowledge of the display size, I think it's just the only driver that triggers it. some combination of setups, possibly the absolute axis ranges but relative events being sent.
I have the same problem. I use one screen above the other and my vertical mouse pointer speed is about double of the horizontal speed. It's unusable this way. Now this might be a different bug or not a bug at all, but I noticed that the VertResolution and HorizResolution options are missing, even though they are specified in man synaptics: --------------- Option "VertResolution" "integer" Resolution of X coordinates in units/millimeter. The value is used together with HorizResolution to compensate unequal vertical and horizontal sensi‐ tivity. Setting VertResolution and HorizResolution equal values means no compensation. Default value is read from the touchpad or set to 1 if value could not be read. Property: "Synaptics Pad Reso‐ lution" Option "HorizResolution" "integer" Resolution of Y coordinates in units/millimeter. The value is used together with VertResolution to compensate unequal vertical and horizontal sensi‐ tivity. Setting VertResolution and HorizResolution equal values means no compensation. Default value is read from the touchpad or set to 1 if value could not be read. Property: "Synaptics Pad Reso‐ lution" --------------- synclient: --------------- Parameter settings: LeftEdge = 130 RightEdge = 3130 TopEdge = 114 BottomEdge = 2005 FingerLow = 1 FingerHigh = 1 FingerPress = 256 MaxTapTime = 180 MaxTapMove = 171 MaxDoubleTapTime = 180 SingleTapTimeout = 180 ClickTime = 100 FastTaps = 1 EmulateMidButtonTime = 0 EmulateTwoFingerMinZ = 282 EmulateTwoFingerMinW = 7 VertScrollDelta = 77 HorizScrollDelta = 77 VertEdgeScroll = 0 HorizEdgeScroll = 0 CornerCoasting = 0 VertTwoFingerScroll = 1 HorizTwoFingerScroll = 1 MinSpeed = 1 MaxSpeed = 0.1 AccelFactor = 0.1 TrackstickSpeed = 40 EdgeMotionMinZ = 30 EdgeMotionMaxZ = 160 EdgeMotionMinSpeed = 1 EdgeMotionMaxSpeed = 311 EdgeMotionUseAlways = 0 TouchpadOff = 2 LockedDrags = 0 LockedDragTimeout = 5000 RTCornerButton = 0 RBCornerButton = 0 LTCornerButton = 0 LBCornerButton = 0 TapButton1 = 1 TapButton2 = 2 TapButton3 = 3 ClickFinger1 = 1 ClickFinger2 = 3 ClickFinger3 = 2 CircularScrolling = 0 CircScrollDelta = 0.1 CircScrollTrigger = 0 CircularPad = 0 PalmDetect = 1 PalmMinWidth = 4 PalmMinZ = 1 CoastingSpeed = 20 CoastingFriction = 50 PressureMotionMinZ = 30 PressureMotionMaxZ = 160 PressureMotionMinFactor = 1 PressureMotionMaxFactor = 1 GrabEventDevice = 1 TapAndDragGesture = 1 AreaLeftEdge = 0 AreaRightEdge = 0 AreaTopEdge = 0 AreaBottomEdge = 0 HorizHysteresis = 19 VertHysteresis = 19 ClickPad = 1 RightButtonAreaLeft = 1630 RightButtonAreaRight = 0 RightButtonAreaTop = 1737 RightButtonAreaBottom = 0 MiddleButtonAreaLeft = 0 MiddleButtonAreaRight = 0 MiddleButtonAreaTop = 0 MiddleButtonAreaBottom = 0 --------------- xinput list-props "ETPS/2 Elantech Touchpad": --------------- Device 'ETPS/2 Elantech Touchpad': Device Enabled (129): 1 Coordinate Transformation Matrix (131): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 Device Accel Profile (258): 1 Device Accel Constant Deceleration (259): 2.500000 Device Accel Adaptive Deceleration (260): 1.000000 Device Accel Velocity Scaling (261): 12.500000 Synaptics Edges (283): 130, 3130, 114, 2005 Synaptics Finger (284): 1, 1, 256 Synaptics Tap Time (285): 180 Synaptics Tap Move (286): 171 Synaptics Tap Durations (287): 180, 180, 100 Synaptics ClickPad (288): 1 Synaptics Tap FastTap (289): 1 Synaptics Middle Button Timeout (290): 0 Synaptics Two-Finger Pressure (291): 282 Synaptics Two-Finger Width (292): 7 Synaptics Scrolling Distance (293): 77, 77 Synaptics Edge Scrolling (294): 0, 0, 0 Synaptics Two-Finger Scrolling (295): 1, 1 Synaptics Move Speed (296): 1.000000, 0.100000, 0.100000, 40.000000 Synaptics Edge Motion Pressure (297): 30, 160 Synaptics Edge Motion Speed (298): 1, 311 Synaptics Edge Motion Always (299): 0 Synaptics Off (300): 2 Synaptics Locked Drags (301): 0 Synaptics Locked Drags Timeout (302): 5000 Synaptics Tap Action (303): 0, 0, 0, 0, 1, 2, 3 Synaptics Click Action (304): 1, 3, 2 Synaptics Circular Scrolling (305): 0 Synaptics Circular Scrolling Distance (306): 0.100000 Synaptics Circular Scrolling Trigger (307): 0 Synaptics Circular Pad (308): 0 Synaptics Palm Detection (309): 1 Synaptics Palm Dimensions (310): 4, 1 Synaptics Coasting Speed (311): 20.000000, 50.000000 Synaptics Pressure Motion (312): 30, 160 Synaptics Pressure Motion Factor (313): 1.000000, 1.000000 Synaptics Grab Event Device (314): 1 Synaptics Gestures (315): 1 Synaptics Capabilities (316): 1, 0, 0, 1, 1, 1, 1 Synaptics Pad Resolution (317): 32, 32 Synaptics Area (318): 0, 0, 0, 0 Synaptics Soft Button Areas (319): 1630, 0, 1737, 0, 0, 0, 0, 0 Synaptics Noise Cancellation (320): 19, 19 Device Product ID (247): 2, 14 Device Node (248): "/dev/input/event7" MaxSpeed (504): 0.100000 Note especially that the capabilities: Synaptics Capabilities (316): 1, 0, 0, 1, 1, 1, 1 They specify that the horizontal and vertical resolution can in fact be set (the last two "1"s). However the parameters are missing from xinput and I can't set them. Setting "Pad Resolution" (317) is impossible because it's readonly. So the mechanism to compensate resolutions as specified in the manpage is completely missing. Could this be related? I'm using xf86-input-synaptics 1.6.2 built on Oct 5. 2012.
Pad Resolution is currently readonly on purpose - your pad is unlikely to change resolutions at runtime. I admit it would make testing it easier but right now you need to add an xorg.conf(.d) option for it. synclient appears to be lacking it altogether, that should be fixed (patches appreciated)
http://patchwork.freedesktop.org/patch/12839/
The patch in comment 15 seems to be working. Thanks! :)
commit 61a99aff9d33728a0b67920254d2d4d79f80cf39 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Fri Jan 11 14:22:07 2013 +1000 dix: pre-scale relative events from abs devices to desktop ratio (#31636)
What release was this actually fixed in? I still seem to be experiencing this behaviour in Fedora 21 (xorg-x11-drv-synaptics-1.8.1-4). Or was there some regression? Much Thanks!
you're right, it had a regression, it's still not fixed. looks like the only fix doable is to drop abs events from the driver and make the touchpad relative only. This requires re-adjusting the pointer acceleration though.
I don't know If this is caused by the same issue, but the problem is quite siilar, so I attach this as a commen instead of filing a new bug. I'm using debian testing / x.org 1.17.2 with a Lenovo U41 which has an ALPS touchpad. The problem is that the touchpad is way faster on the horizontal axis than on the vertical axis: while a swipe from left to right will move the pointer approximately from the left to the right screen edge, a complete top-down swipe only covers one quarter of the screen - of course influenced by the acceleration settings. Fiddling with the "VertResolution" and "HorizResolution" options didn't show any effect for me. Looking at the code it seems that these options were actually rendered useless when the synaptics driver scaling was removed in commit #0fb59b3487d57523a03f078a2061e2ea0cacbc7c. The driver always passes the resolution values reported by the device to the server instead of the overwritten ones from the config. Some debugging later, this is what the device reports to the server: minx: 0, maxx: 4095, resx: 40 miny: 0, maxy: 2047, resy: 71 So it looks like the device has indeed a different resolution in x and y and this seems to get mix up the scaling somehow. I tried to make the driver pass the VertResolution and HorizResolution parameters instead of the device values by changing some lines from synaptics.c: xf86InitValuatorAxisStruct(dev, 0, axes_labels[0], min, max, priv->resx * 1000, 0, priv->resx * 1000, Relative); into xf86InitValuatorAxisStruct(dev, 0, axes_labels[0], min, max, priv->synpara.resolution_horiz * 1000, 0, priv->synpara.resolution_horiz * 1000, Relative); and xf86InitValuatorAxisStruct(dev, 1, axes_labels[1], min, max, priv->resy * 1000, 0, priv->resy * 1000, Relative); into xf86InitValuatorAxisStruct(dev, 1, axes_labels[1], min, max, priv->synpara.resolution_vert * 1000, 0, priv->synpara.resolution_vert * 1000, Relative); After that, setting both "VertResolution" and "HorizResolution" to the same value, makes the touchpad behave as expected. But I think the real problem is somewhere deeper in getevents.c As far as I understand the scale_for_device_resolution function tries to map the touch pad size to the screen size which works fine as long as resolution_ratio equals 1 which is the case for all pads with an equal x/y resolution and breaks on devices with uneven resolutions. But why is the resolution involved in the scaling anyway? If we try to map 1the device size to the screen size we don't need to bother about the device resolution. The axis sizes and the screen resolution should be enough?!
The VertResolution/HorizResolution options shouldn't be needed on newer touchpads anyway if the kernel provides it. So you can ignore those. and yes, this is the same bug. the problem is caused by the server needing to support true absolute devices in relative mode (e.g. graphics tablets). If you have one of those, a relative motion on the device should reflect the motion on the screen - that's harder to do on touchpads where the aspect ratio and sizes are out of whack. fwiw, as of http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=0a4cf80a00663ff3ce8e76baf0940782576efe13, synaptics doesn't need to be absolute anymore, you can replace all xf86InitValuatorAxisStruct() calls with a min/max of -1. This makes the axes truly relative and is the right solution. But you'll find the pointer accel will be completely out of whack after that, if you manage to find the magic numbers to tweak it back to what it currently is, you've found the solution.
This is still a problem for me on xorg-server 1.18.4 with my synaptics touchpad on my x220t. Can anyone please look into it and fix it upstream?
this bug is effectively WONTFIX to fix this properly, we need to change the device's axes into a relative axis. That's easy, a 2 line fix. Once done, the pointer acceleration will feel completely different. Which is going to cause outrage that I'm not willing to deal with. Trying to figure out how to restore the current acceleration feel is going to be tricky at best, given the convoluted way of acceleration in synaptics. Better solution is to switch to libinput, since synaptics is in maintenance mode now anyway.
*** Bug 83114 has been marked as a duplicate of this 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.