who is the caller when this happens? Are you using synergy or something similar?
Do you have a reproduceable test case?

While I think your patch fixes the problem, this is a bit of a sore spot which we currently have to patch around. It seems to be yet another candidate for a XTest virtual slave device.

I don't use something like synergy, this happens using a plain kde4, and probably using others.

I test with kde4 okular, which tries to move the cursor to the top/bottom of the screen if one drags the document to the other edge, so one can continue moving the document without releasing the mouse button. This works if a regular mouse or trackpoint is used, but fails for synaptics, which uses said non-identity scaling.

This is a backtrace of my current xserver, so miPointerMove is inlined into miPointerWarpCursor.
#0  miPointerWarpCursor (pDev=0x85d68c0, pScreen=0x822b448, x=525, y=1044)
    at mipointer.c:554
#1  0x08167562 in xf86WarpCursor (pDev=0x85d68c0, pScreen=0x822b448, x=525,
    y=1044) at xf86Cursor.c:475
#2  0x080dfb6f in miPointerSetCursorPosition (pDev=0x85d68c0,
    pScreen=0x822b448, x=525, y=1044, generateEvent=1) at mipointer.c:239
#3  0x081a6415 in AnimCurSetCursorPosition (pDev=0x85d68c0,
pScreen=0x822b448,
    x=525, y=1044, generateEvent=1) at animcur.c:277
#4  0x080c4582 in ProcWarpPointer (client=0xaeb9bb0) at events.c:3226
#5  0x080ba0ff in Dispatch () at dispatch.c:437
#6  0x080698dd in main (argc=6, argv=0xbfbf7df4, envp=0x0) at main.c:382

I don't know which of these functions is supposed to work with master or slave devices, so i put my changes at the last position that is not regularly used, on my system at least. And then i added stuff until it worked for me.

Created attachment 21784 [details] [review]
0001-dix-fix-WarpPointer-calls-for-devices-with-custom-v.patch

Verified. Unfortunately, your patch can't go in like this as it is against the protocol spec which require that an event is sent after a warp pointer request.

How about this one. Not perfect either, but we're only breaking XWarpDevicePointer, which is not released yet anyway.

Is this supposed to get a slave if dev is a master device?
+    if (dev->u.lastSlave)
+        dev = dev->u.lastSlave;
That won't work because u.lastSlave is unionized with u.master.
Otherwise, i think this should rather fail than push a master device down to  GetPointerEvents, or try to find a slave device by other means.

(In reply to comment #4)
> Is this supposed to get a slave if dev is a master device?
> +    if (dev->u.lastSlave)
> +        dev = dev->u.lastSlave;
> That won't work because u.lastSlave is unionized with u.master.

PickPointer always returns a master, so u.lastSlave - if not NULL - will always be a slave device. If it isn't then we have to push the master down and hope for the best.

> Otherwise, i think this should rather fail than push a master device down to 
> GetPointerEvents, or try to find a slave device by other means.

If there's no SD, then we don't have the problem of scaling in the first place, so we're fine.

(In reply to comment #5)
So i think this is fine. I just have one nitpick: it doesn't work ;-). 

The cursor is now warped to the bottom right corner. I will try to split the two parts of the patch, but i suspect the "assume that WarpPointer coordinates are always in screen coordinates"-part is not respected everywhere.

Created attachment 21835 [details] [review]
Bits needed for attachment #21784 [details] [review] to work

Using this patch together with attachment #21784 [details] [review] works.

Created attachment 21890 [details] [review]
0001-dix-fix-WarpPointer-calls-for-devices-with-custom-v.patch

ok, how about this one. If POINTER_SCREEN is set, scale valuators to device coordinates before continuing. Seems to work here, but then again - so did the previous patch.

btw. what's the app that triggers this behaviour? Your patch fixed the behaviour for GPE being called for events with only valuators[2:] set, which is quite unusual for a warp pointer request (if it still is warp pointer).

(In reply to comment #8)
> Created an attachment (id=21890) [details]
> 0001-dix-fix-WarpPointer-calls-for-devices-with-custom-v.patch
> 
> ok, how about this one. If POINTER_SCREEN is set, scale valuators to device
> coordinates before continuing. Seems to work here, but then again - so did the
> previous patch.

that one works.

> btw. what's the app that triggers this behaviour? Your patch fixed the
> behaviour for GPE being called for events with only valuators[2:] set, which is
> quite unusual for a warp pointer request (if it still is warp pointer).

Still the same as in comment #2: okular from kde4. I don't see where i did anything special that makes you think it helps only for valuators[2:]. The real meat of my patch is 1: disable clipping in moveAbsolute(synaptics coordinates start at around 1400,1400) and 2: convert the screen coordinates to device coordinates after setting the pointer sprite. Fetching the screen coordinates in moveAbsolute is probably never used. Simply disabling clipping is probably not the right thing, though.

> (In reply to comment #8)
> > Created an attachment (id=21890)
>  --> (http://bugs.freedesktop.org/attachment.cgi?id=21890) [details]
> > 0001-dix-fix-WarpPointer-calls-for-devices-with-custom-v.patch
> > 
> > ok, how about this one. If POINTER_SCREEN is set, scale valuators to device
> > coordinates before continuing. Seems to work here, but then again - so did the
> > previous patch.
> 
> that one works.

Pushed as d36adf52a2b2711d22b11105f7bd907d4493fb9b. Closing as fixed.

> > btw. what's the app that triggers this behaviour? Your patch fixed the
> > behaviour for GPE being called for events with only valuators[2:] set, which is
> > quite unusual for a warp pointer request (if it still is warp pointer).
> 
> Still the same as in comment #2: okular from kde4. I don't see where i did
> anything special that makes you think it helps only for valuators[2:]. 

The first hunks of the patch threw me off I guess since they only apply for
valuators >= 2.