I can confirm that it's regression from 1.1.2. Just installed 1.1.2 and the bug doesn't occur any more.

Henrik, Christoph - do you have time to look at this? I'm a bit busy right now.

Instantly isn't appropriate word to describe the problem, so I changed it to suddenly in summary line :P

what's the output of synclient -l?
is the output different between 1.1.2 and 1.1.3?

Output is the same for both versions:

Parameter settings:                
    LeftEdge                = 1700 
    RightEdge               = 5300 
    TopEdge                 = 1700 
    BottomEdge              = 4200 
    FingerLow               = 25   
    FingerHigh              = 30   
    FingerPress             = 255  
    MaxTapTime              = 180  
    MaxTapMove              = 221  
    MaxDoubleTapTime        = 180  
    SingleTapTimeout        = 180  
    ClickTime               = 100  
    FastTaps                = 0    
    EmulateMidButtonTime    = 75   
    EmulateTwoFingerMinZ    = 280  
    EmulateTwoFingerMinW    = 7    
    VertScrollDelta         = 100  
    HorizScrollDelta        = 100  
    VertEdgeScroll          = 1    
    HorizEdgeScroll         = 1    
    CornerCoasting          = 1    
    VertTwoFingerScroll     = 1    
    HorizTwoFingerScroll    = 1    
    MinSpeed                = 0.3  
    MaxSpeed                = 1    
    AccelFactor             = 0.006
    TrackstickSpeed         = 40   
    EdgeMotionMinZ          = 29   
    EdgeMotionMaxZ          = 159  
    EdgeMotionMinSpeed      = 1    
    EdgeMotionMaxSpeed      = 401  
    EdgeMotionUseAlways     = 0    
    UpDownScrolling         = 1    
    LeftRightScrolling      = 1    
    UpDownScrollRepeat      = 1    
    LeftRightScrollRepeat   = 1    
    ScrollButtonRepeat      = 100
    TouchpadOff             = 0
    GuestMouseOff           = 0
    LockedDrags             = 0
    LockedDragTimeout       = 5000
    RTCornerButton          = 0
    RBCornerButton          = 0
    LTCornerButton          = 0
    LBCornerButton          = 0
    TapButton1              = 1
    TapButton2              = 3
    TapButton3              = 2
    ClickFinger1            = 1
    ClickFinger2            = 1
    ClickFinger3            = 1
    CircularScrolling       = 0
    CircScrollDelta         = 0.1
    CircScrollTrigger       = 0
    CircularPad             = 0
    PalmDetect              = 0
    PalmMinWidth            = 10
    PalmMinZ                = 199
    CoastingSpeed           = 0.3
    PressureMotionMinZ      = 29
    PressureMotionMaxZ      = 159
    PressureMotionMinFactor = 1
    PressureMotionMaxFactor = 1
    GrabEventDevice         = 1

weird. there's only one patch between 1.1.2 and 1.1.3 and that was the removal of the auto-scaling of the right edge (which broke scrolling on every touchpad I tested/emulated). just to be sure, please check that there aren't any distro-specific patches that may affect this. 

If you remove the settings for the touchpad (except the edge scrolling on) from the config file do you still see the issue?
please enable shmconfig and run synclient -m 20 while moving the finger across this line. At what coordinates does the cursor jump?
also, I think the log file may help at this point, please attach this as well.

I'm beginning to think that the issue may be coordinates outside the kernel-reported range (which may make this a semi-duplicate of #23102).

I've deleted all options from config file except vertical scrolling and shmconfig. The problem still exist. My /etc/hal/fdi/policy/10osvendor/11-x11-synaptics.fdi now:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.touchpad">
      <match key="info.product" contains="Synaptics TouchPad">
        <merge key="input.x11_driver" type="string">synaptics</merge>
        <!-- Arbitrary options can be passed to the driver using
             the input.x11_options property since xorg-server-1.5. -->

        <merge key="input.x11_options.VertEdgeScroll" type="string">true</merge>
        <merge key="input.x11_options.VertScrollDelta" type="string">100</merge>
        <merge key="input.x11_options.SHMConfig" type="string">on</merge>

      </match>
      <match key="info.product" contains="AlpsPS/2 ALPS">
        <merge key="input.x11_driver" type="string">synaptics</merge>
      </match>
      <match key="info.product" contains="appletouch">
        <merge key="input.x11_driver" type="string">synaptics</merge>
      </match>
      <match key="info.product" contains="bcm5974">
        <merge key="input.x11_driver" type="string">synaptics</merge>
      </match>
    </match>
  </device>
</deviceinfo>

But I have a problem with running synclient -m 20. It tells me that shmconfig is disabled although it's enabled in the config as you see above.

Please get the evtest repo and run evtest-capture against the device. Try to reproduce the bug and then attach the resulting xml file here.

http://people.freedesktop.org/~whot/evtest/

Note that you need to set option GrabEventDevice off, otherwise you won't see events on the device while the driver is running.        
<merge key="input.x11_options.GrabEventDevice" type="string">off</merge>

Created attachment 31513 [details]
evtest file

This is the file you asked for.

Confirmed here too.

I first saw it on Zenwalk distribution 6.2 with xorg 1.6.3 (synaptic 1.1.3) and it is still present with Zenwalk 6.4 with xorg 1.7.5 (synaptic 1.2.1).
Also present in other new distribution using xorg 1.7.5 (saw it on crunchbang linux 10 alpha1, unity linux 2010 RC1)

The output of synclient -m 20 shows that x values jumps from ~5900 to 8176 instantly when reaching the  right of the touchpad.

Any chances of having this solved in the soon-to-be-released xorg 1.8 ?

thanx,

-S

same here. Pretty annoying.

1.1.0 shows the same coordinate behaviour (i.e. jumps from a little about 5900-6000 straight to 8176 (stays at that value, even when you move further to the right) but: It didn't move the cursor. No jumping cursor. This is far more usable.

Maybe the touchpad is physically divided into two areas..

Synaptics Touchpad, model: 1, fw: 6.1, id: 0xa3a0b3, caps: 0xa04713/0x10008

This bug has also been reported for Ubuntu: 
https://bugs.launchpad.net/xorg-driver-synaptics/+bug/591656

To me it doesn't look like there is anything new there compared to this bug report, but here are links to the output of xev and synclient -m 1 in case it's useful:
http://launchpadlibrarian.net/50400750/xev.txt
http://launchpadlibrarian.net/50431559/synclient.txt

Created attachment 38026 [details] [review]
Proposed fix

I have the same problem. So I made a little change to synaptics.c that seems to fix the problem.
Basically, what I do is fix hw->x to a maximum of param->right_edge when calculating delta x (on ComputeDelta(...)). So, it shouldn't mess with other parts of the driver, and anyway hw->x shouldn't be higher than RightEdge at that point of the code.

The modification is working great in my laptop, but i didn't try on other ones. If someone like to try it, I leave you the patch here. If this breaks something else, I would be glad to refix it (if I can, of course).
By the way, if the fix it's too dirty, the problem seems to reside on the fact that some touchpads' hardware 'x' jumps from around 5900 to exactly 8176 and back , close to their right edge. So maybe a better solution is to keep watch of the 8176 value.

(In reply to comment #13)
> Created an attachment (id=38026) [details]
> Proposed fix
> 
> I have the same problem. So I made a little change to synaptics.c that seems to
> fix the problem.
> Basically, what I do is fix hw->x to a maximum of param->right_edge when
> calculating delta x (on ComputeDelta(...)). So, it shouldn't mess with other
> parts of the driver, and anyway hw->x shouldn't be higher than RightEdge at
> that point of the code.
> 
> The modification is working great in my laptop, but i didn't try on other ones.
> If someone like to try it, I leave you the patch here. If this breaks something
> else, I would be glad to refix it (if I can, of course).
> By the way, if the fix it's too dirty, the problem seems to reside on the fact
> that some touchpads' hardware 'x' jumps from around 5900 to exactly 8176 and
> back , close to their right edge. So maybe a better solution is to keep watch
> of the 8176 value.

I'm using your patch on Debian Squeeze, and it seems to be working perfectly.
Thanks.

Martín J. Di Liscia,

thank you very much!

I had the same problem with my Asus F3JC notebook. This patch really helped me. The only thing is that when my finger slides from the "normal" zone of the touchpad to the scrolling zone, Y coordinate is still working when I'm sliding up or down.

Please let me know how can I help you to make this patch a part of the driver, so many people will be happy with that without manual patching? Should I vote somewhere or stuff like that?

I don't know if I'm understanding you well. But if I'm, that's how I felt was natural. I mean, when you slide past the right edge, is like staying on the border of the normal pad area, so it should keep processing the vertical slide.
Anyway, the two posible behaviors could be configured via a new variable handled from synclient. But that should be a design desicion from the mantainers of the driver.

About making this patch permanent part of the driver, sincerely it's my first patch commitment, so I have no idea how to do it. I was hoping that Hutterer saw the patch and do it himself. But yes, I would also like it, I would't want to apply it to every new version by myself.

Created attachment 38536 [details] [review]
0001-eventcomm-Clip-x-y-coordinates-into-axis-range-23890.patch

how does this patch work for you? It clips the coordinates into the ones announced by the kernel so that right edge should just be clipped back.

That fixes the jumping problem, but it messes two other things. Now my pad doesn't work on the whole area (left edge principally, now have a inactive gap), and the vertical scroll isn't working either (horizontal scroll seems to work fine).
Maybe the kernel announce a smaller area then the real one.

Created attachment 43146 [details]
touchpad.svg

This plot of the X axis values shows the problem nicely. In the plot, the x axis is just the events in consecutive order, y axis is the actual X value the kernel gave us.

The kernel itself claims that the max value is 5472. You can see that many events go above this value (up to 5976). Then there are a few outliers at 8176 which I suspect is the scroll bar. So the clipping patch makes you lose all these outliers plus all data that goes above the announced maximum.

Please accept this patch. This is major issue.

Created attachment 49443 [details] [review]
xf86-input-synaptics-1.4.1-8176.patch

I've attached a patch file that work on synaptics 1.4.1. It is modified version of Martin's patch.

Please submit a evemu recording of the device. I've converted the evtest-capture file but it's not quite enough.

Specifically, I need:
- the event log of the bug when the cursor jumps (the previous file contained that)
- an event log of scrolling in that scroll area on the right
- an event log of movement in the left edge that wasn't working with my previous patch applied

http://people.freedesktop.org/~whot/evemu/

This is a mass change of bugs. Bugs assigned to me that haven't been updated in the last 3 years are closed as WONTFIX, because, well, let's at least be honest about it.

Please do not re-open unless you have a really good reason to do so (e.g. you're fixing it yourself). If it hasn't been fixed in the last 3 years, it probably won't be fixed anytime soon either. Sorry.