Soltech TA12 touchpad scrolling area not flush to the right

Bug #403869 reported by Earl Malmrose on 2009-07-24
This bug affects 2 people
Affects Status Importance Assigned to Milestone
xserver-xorg-input-synaptics (Ubuntu)

Bug Description

Binary package hint: xfree86-driver-synaptics

The vertical area on the touchpad that registers scrolling isn't in the right location. It should to flush against the right edge of the touchpad, but it is too far to the left.

Using synclient to monitor the x-values, the following approximate ranges are observered:

700-1100 no mouse movement
1100-5200 regular mouse movement
5200-5900 scrolling movement
5900-6250 no mouse movement

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: xserver-xorg-input-synaptics 0.99.3-2ubuntu4
ProcVersion: Linux version 2.6.28-14-generic (root@x-laptop) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #46 SMP Tue Jul 7 12:12:46 CDT 2009
SourcePackage: xfree86-driver-synaptics
Uname: Linux 2.6.28-14-generic i686

Earl Malmrose (earl) wrote :
Alberto Milone (albertomilone) wrote :

Please follow these steps:

1) Type:
xinput list --short

and get the id of your touchpad (which is a number e.g. 5)

2) Type:
xinput list-props YOUR_DEVICE_ID

and attach the output.

Earl Malmrose (earl) wrote :

$ xinput list-props 5
Device 'SynPS/2 Synaptics TouchPad':
    Device Enabled (109): 1
    Synaptics Edges (253): 1632, 5312, 1575, 4281
    Synaptics Finger (254): 24, 29, 255
    Synaptics Tap Time (255): 180
    Synaptics Tap Move (256): 221
    Synaptics Tap Durations (257): 180, 180, 100
    Synaptics Tap FastTap (258): 0
    Synaptics Middle Button Timeout (259): 75
    Synaptics Two-Finger Pressure (260): 280
    Synaptics Scrolling Distance (261): 100, 100
    Synaptics Edge Scrolling (262): 1, 0, 0
    Synaptics Two-Finger Scrolling (263): 1, 0
    Synaptics Edge Motion Pressure (264): 29, 159
    Synaptics Edge Motion Speed (265): 1, 401
    Synaptics Edge Motion Always (266): 0
    Synaptics Button Scrolling (267): 1, 1
    Synaptics Button Scrolling Repeat (268): 1, 1
    Synaptics Button Scrolling Time (269): 100
    Synaptics Off (270): 0
    Synaptics Guestmouse Off (271): 0
    Synaptics Locked Drags (272): 0
    Synaptics Locked Drags Timeout (273): 5000
    Synaptics Tap Action (274): 2, 3, 0, 0, 1, 2, 3
    Synaptics Click Action (275): 1, 1, 1
    Synaptics Circular Scrolling (276): 0
    Synaptics Circular Scrolling Trigger (277): 0
    Synaptics Circular Pad (278): 0
    Synaptics Palm Detection (279): 0
    Synaptics Palm Dimensions (280): 10, 199
    Synaptics Pressure Motion (281): 29, 159
    Synaptics Grab Event Device (282): 1

Jerone Young (jerone) wrote :

      Can you try out Karmic Alpha 3. Does it also demonstrate the same issue?

Earl Malmrose (earl) wrote :

2.6.31-4-generic #23-Ubuntu SMP Mon Jul 27 18:39:51 UTC 2009 i686 GNU/Linux kernel installed

Same issue.

Alberto Milone (albertomilone) wrote :

Does it help if you set the right edge to a bigger value (i.e. replace 5312 with a bigger number in the command below)?

xinput set-int-prop 5 "Synaptics Edges" 32 1632 5312 1575 4281

Earl Malmrose (earl) wrote :

This is hard to describe. Let me describe it like this. Consider 4 vertical lines. Between lines A and B is the area of the touchpad that affects movement of the mouse. Between lines C and D is the area of the touchpad that performs scrolling.

In the previous xinput command, 1632 is line A, and 5312 is line B. Line C seems to always be the same as line B. If line B is moved to the left, then the width of the scroll area increases. If line B is moved to the right, the scroll area decreases.

Line D never moves. So, if line B (and C) move to the right of D, then the scroll area has a negative width, which results in scrolling being completely disabled.

Does that make sense?

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:// 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.

Alberto Milone (albertomilone) wrote :

Yes, it definitely makes sense to me and (fortunately) I'm able to reproduce the bug on my Eee Pc 901 Go which has an Elantech touchpad.

I'll file a bug report upstream and I'll start working on it soon.

Thanks for reporting.

Created an attachment (id=28305)
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.

Changed in xfree86-driver-synaptics (Ubuntu):
assignee: nobody → Alberto Milone (albertomilone)
importance: Undecided → Medium
status: New → Confirmed
importance: Medium → Undecided
importance: Undecided → Medium
Changed in xorg-driver-synaptics:
status: Unknown → Confirmed

(In reply to comment #2)
> Does the attached patch help?

did you test this? both devices fail immediately with an "invalid argument" error.

Created an attachment (id=28333)
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.

affects: xfree86-driver-synaptics (Ubuntu) → xserver-xorg-input-synaptics (Ubuntu)
Bryce Harrington (bryce) on 2009-09-02
tags: added: jaunty

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?

Alberto Milone (albertomilone) wrote :

Can you try Ubuntu Karmic (even from the livecd) and see if you can still reproduce the problem, please?

If you can reproduce the problem, please attach your /var/log/Xorg.0.log and the output of synclient as you did when you reported this bug.

Earl Malmrose (earl) wrote :

No change in the current Karmic version. Will try Lucid Alpha.

Changed in xorg-driver-synaptics:
importance: Unknown → Medium
Changed in xorg-driver-synaptics:
importance: Medium → Unknown
Changed in xorg-driver-synaptics:
importance: Unknown → Medium

> 2 years silence, closing. please reopen if this is still an issue, or better file a new bug with up-to-date logs

Changed in xorg-driver-synaptics:
status: Confirmed → Invalid
Changed in xserver-xorg-input-synaptics (Ubuntu):
assignee: Alberto Milone (albertomilone) → nobody

Earl Malmrose, 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 .

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:

Changed in xserver-xorg-input-synaptics (Ubuntu):
importance: Medium → Low
status: Confirmed → Incomplete
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.