Touchpad speed scales with multimonitor size per axis

Bug #726832 reported by Martin Spacek on 2011-02-28
88
This bug affects 17 people
Affects Status Importance Assigned to Milestone
XOrg-Driver-Synaptics
Won't Fix
Medium
xserver-xorg-input-synaptics (Ubuntu)
Low
Unassigned

Bug Description

When enabling a second screen, say horizontally next to the primary screen, horizontal touchpad speed increases proportionally to the increase in horizontal resolution. I assume the same happens when enabling multiple screens in a vertical configuration. So, it seems that touchpad speed is relative to the total screen layout size in each axis. This is quite irritating. It would be more reasonable to define speed in absolute terms (pixels/sec) rather than relative terms (% x/y resolution / sec), thereby keeping speed in both axes constant, regardless of the addition/removal of extra screens.

I've noticed this on my Thinkpad W510 running Maverick amd64, the latest nvidia binary blob, utouch 1.1, synaptics-dkms 1.0.0, and xserver-xorg-input-synaptics 1.2.2-2ubuntu5

Note that external mice don't exhibit this problem. This might be why this situation isn't encountered often: when plugged into an external monitor, the user is more likely to also plug in an external mouse rather than rely on the touchpad.

This was brought up by Ricardo Caldeira at https://bugs.launchpad.net/xorg-driver-synaptics/+bug/308191/comments/187, and Duncan McGreggor replied at https://bugs.launchpad.net/xorg-driver-synaptics/+bug/308191/comments/189.

Created attachment 40284
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
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

Yes, this does indeed fix the errors in the Xorg log. But the other problem remains of course. :)

Martin Spacek (mspacek) on 2011-02-28
description: updated
Martin Spacek (mspacek) wrote :

Just a note, the integrated pointing stick (trackpoint) on my Thinkpad W510 also doesn't exhibit this problem.

Chase Douglas (chasedouglas) wrote :

Hi Martin,

First, you notice a difference in speed between trackpads and other devices because trackpads are handled by the X synaptics input module, while the rest are handled by the X evdev input module.

On to the major point of the bug. I don't think there's an absolute *correct* way to handle this. However, a case may be made that this should be configurable. The best place for this discussion is on the xorg-devel mailing list. Would you feel comfortable asking about this there? If so, you can sign up at http://lists.freedesktop.org/mailman/listinfo/xorg-devel. If not, please let me know and I can ask on your behalf.

Thanks!

Changed in utouch:
status: New → Invalid
Changed in xorg-driver-synaptics:
status: New → Confirmed
Martin Spacek (mspacek) wrote :

Hi Chase,

Thanks for that. Since I don't know much about Xorg, and since I'm most certainly not an Xorg developer, could you perhaps bring this up on xorg-devel on my behalf? A message from you would probably get a lot more attention anyways. Then perhaps I could join such a discussion, once started. I'm curious to hear what the arguments for the current behaviour might be. I can't really imagine how anyone would actually want the current behaviour...

Thanks again.

Changed in xorg-driver-synaptics:
importance: Undecided → Unknown
status: Confirmed → Unknown
Changed in xorg-driver-synaptics:
importance: Unknown → Medium
status: Unknown → Confirmed

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 Spacek (mspacek) wrote :

I posted a comment at the linked xorg bug (http://bugs.freedesktop.org/show_bug.cgi?id=31636), and linked back to here. Chase, was there any sort of discussion of this on the xorg-devel mailing list?

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

Chase Douglas (chasedouglas) wrote :

Hi Martin,

Sorry for the delayed response. I haven't had a chance to bring this up on xorg-devel. Sadly, I'm not sure I will have the time to do so for a while either...

Sorry!

(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

MedO (smaxein) wrote :

I just noticed this as well on my EeePC 901 (Precise beta).

IMO, it can make some sense to scale the resolution of the touchpad with screen size. However, it does NOT make sense to change the ratio between the axes, unless perhaps the pixel aspect ratio of the display device(s) is nonsquare.

no longer affects: utouch
Changed in xserver-xorg-input-synaptics (Ubuntu):
status: New → Confirmed
importance: Undecided → Low

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.

Bryce Harrington (bryce) on 2012-04-28
Changed in xserver-xorg-input-synaptics (Ubuntu):
status: Confirmed → Triaged
Download full text (6.2 KiB)

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

Read more...

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)

i30817 (i30817) wrote :

Something strange happens with exult that appears related to this scaling, if you use a touchpad.

You do need the games, and sudo apt-get install exult ( this ppa is best, since it asks for location: https://code.launchpad.net/~exult-team/+archive/exult-daily ).

What appears to happen is that the touchpad speed scaling goes crazy with the smaller resolution that exult uses if used in fullscreen; the speed is far too fast for confortable uses, whatever speed you set it at with gpointingdevice settings (but you can make it worse).

i30817 (i30817) wrote :

Also, the above is especially strange, because exult normally _decreases_ the normal resolution, to 800x600 or 640x480, and the speed increases rather alot. I think synaptics might be scaling speed with 'real' pixels, instead of 'logical' pixels.
Granted, it doesn't seem to happen in gnome 3, if you change to 800x600 so maybe it's something else.

The patch in comment 15 seems to be working. Thanks! :)

commit 61a99aff9d33728a0b67920254d2d4d79f80cf39
Author: Peter Hutterer <email address hidden>
Date: Fri Jan 11 14:22:07 2013 +1000

    dix: pre-scale relative events from abs devices to desktop ratio (#31636)

Changed in xorg-driver-synaptics:
status: Confirmed → Fix Released

Martin Spacek, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xserver-xorg-input-synaptics REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

Changed in xserver-xorg-input-synaptics (Ubuntu):
status: Triaged → Incomplete

FWIW, I am currently experiencing this problem and wish to provide more information. This is my first bug report, so I'd appreciate some guidance.

The problem is exactly as described, on 14.04.1 LTS 64-bit on an Asus Zenbook with Elan touchpad.

I've reported the outcome of the apport-collect command over at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1398621

Dan Smith (dansmith-r) wrote :

 I can confirm similar behaviour on 14.04 64-bit with ETPS/2 Elantech Touchpad.
As soon as I attach an external monitor over VGA, my touchpad loses precision: the cursor fidgets as I move it around. I can barely aim it at a button to click.

Dan Smith (dansmith-r) wrote :

Just wanted to clarify that I'm not experiencing cursor acceleration like in the OP, just the cursor fidgeting.

Dan Smith, thank you for your comment. So your problem and hardware may be tracked, could you please file a new report by executing the following in a terminal:
ubuntu-bug xorg

Please ensure you have xdiagnose installed, and that you click the Yes button for attaching additional debugging information.

For more on this, please see the official Ubuntu documentation:
Ubuntu X.Org Team, Ubuntu Bug Control, and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

As well, please do not announce in this report you created a new bug report.

Thank you for your understanding.

tags: added: apport-collected trusty ubuntu
tags: removed: apport-collected trusty ubuntu

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.

Changed in xorg-driver-synaptics:
status: Fix Released → Confirmed

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.

Changed in xorg-driver-synaptics:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.