Comment 20 for bug 365952

(In reply to comment #14)
> What I meant to say is that, for example, if the event takes place in a point
> below the bottom edge defined by the Synaptics Area property, we can do
> something similar to what my current patch does:
>
> 1) The driver updates hw->y to its real value only if the event didn't take
> place in the blacklisted area.
>
> 2) The driver updates hw->x only if the y event didn't take place in the
> blacklisted area.
>
> I didn't notice cursor jumps when testing the case that you suggested.
> Furthermore you would get a jump only if hw->y and hw->x were updated when
> touching the blacklisted area.

the scenario I was thinking of is that you move into the right bottom corner, then along in the blacklisted area to the left bottom corner and then up into the allowed area. This would generate a jump the length of the touchpad's width.

We can work around that though. Since by default the touchpad is in relative mode anyway, the only thing that should be capped here are the actual posts of the motion event, not the internal state. So at any point in time, the movement history contains the actual values - including the blacklisted area.

For your patch, this means that you hook in before posting the event and reset dx/dy to zero for blacklisted areas. I think that should do the job.
This simple diff shows what I mean:

iff --git a/src/synaptics.c b/src/synaptics.c
index a40d160..40ee7f2 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -2230,6 +2230,9 @@ HandleState(LocalDevicePtr local, struct SynapticsHwState *hw)
            buttons |= tap_mask;
     }

+ /* FIXME: HACK: */
+ if (edge) dx = dy = 0;
+
     /* Post events */
     if (dx || dy)
        xf86PostMotionEvent(local->dev, 0, 0, 2, dx, dy);

If the finger triggers an edge, no motion event is posted (i.e. the edges form the blacklisted area).