Bug 31636

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. ***