Created attachment 17028 [details]
Test program

On Tue, Jun 10, 2008 at 02:10:43AM -0700, bugzilla-daemon@freedesktop.org wrote:
> Events from XINPUT have the x and y set to the x and y for the CorePointer
> rather than the correct value.

this is a bug for 7.3, thanks. Be aware howevever that with XI v2.0 this
behaviour will be standard.

Ah, so there will be no way to get 

Ah, so does this mean there will be no support for getting window relative position?

> --- Comment #4 from Rob Bradford <rob@robster.org.uk>  2008-06-10 04:05:07 PST ---
> Ah, so does this mean there will be no support for getting window relative
> position?

No, it just means that root_x/y and event_x/y in the event are always in
screen coordinates. The data in the deviceValuators is in device coordinates.

When he says screen vs. device, it means this:
 * VCP
 * device1 (coreEvents = y)
 * device2 (coreEvents = n)

device1 moves the core pointer and generates screen co-ord {event,root}_{x,y} events, with the co-ords of the VCP.  This is fine.

device2 does not move the core pointer and generates screen co-ord {event,root}_{x,y} events, _with the co-ords of the VCP_, as opposed to the the device's last x/y.  Surely floating devices in MPX should also be generating events with the device's last x/y, rather than the co-ords of a random sprite?

I'm very much inclined to think that this is fixed in master with your work, but OTOH couldn't see with a poke at the code how this would be happening before the MPX merge, either.

Ok, but how would we be expected to then get window relative event co-ords for non VCP motion, button etc events in both current XI and upcoming XI 2 ?

On Tue, Jun 10, 2008 at 05:28:01AM -0700, bugzilla-daemon@freedesktop.org wrote:
> device2 does not move the core pointer and generates screen co-ord
> {event,root}_{x,y} events, _with the co-ords of the VCP_, as opposed to the the
> device's last x/y.  Surely floating devices in MPX should also be generating
> events with the device's last x/y, rather than the co-ords of a random sprite?

Actually, no. Each floating device has its own sprite (invisible though)
and the coordinates are still screen coordinates.

> --- Comment #7 from Matthew Allum <mallum@openedhand.com>  2008-06-10 05:50:46 PST ---
> Ok, but how would we be expected to then get window relative event co-ords for
> non VCP motion, button etc events in both current XI and upcoming XI 2 ?

Current XI:
 event x/y has window-relative coordinates in the device-specific coordinate
 system (well, it should anyway, once this bug is fixed)

XI 2:
  event x/y has window-relative coordiantes in the screen coordinate system.
  If you need them in device coordinates, do a simple linear scale from the
  device's min/max axis values.

(In reply to comment #9)
> > --- Comment #7 from Matthew Allum <mallum@openedhand.com>  2008-06-10 05:50:46 PST ---
> > Ok, but how would we be expected to then get window relative event co-ords for
> > non VCP motion, button etc events in both current XI and upcoming XI 2 ?
> 
> Current XI:
>  event x/y has window-relative coordinates in the device-specific coordinate
>  system (well, it should anyway, once this bug is fixed)
> 
> XI 2:
>   event x/y has window-relative coordiantes in the screen coordinate system.
>   If you need them in device coordinates, do a simple linear scale from the
>   device's min/max axis values.

Okay, so we have a simple terminology collision here.  As I said, the problem is that event_{x,y} is giving values for the wrong sprite (imagining non-core devices have their own invisible sprite).  Their problem is not device co-ord space vs. screen co-ord space.  This untested patch might well fix it:
http://people.freedesktop.org/~daniels/xi-dont-stomp-dmn-coords.diff

Daniel, you are my hero.

This patch works almost perfectly. My only query is whether the events should be bounded. If I move the pointer (first mouse, core pointer) outside of the window the events stop. If I do this with the non-core second mouse the events continue with x/y vlaues outside the window (negative or too large)

Rocking.  Assuming we want to be delivering the events to the window in this case anyway (Peter, should focus not change?), then yeah, the co-ords should probably be negative, as we explicitly have a signed co-ordinate space.  I'd have to spend a bit of time with the spec to know what we should be doing in this case, though ...

Okay, so after reading the spec and code, this is what I ended up blithering into Jabber (for 'now', read 'before MPX'):
(18:12:55) daniel s: okay, so it's always going to deliver to the focussed window
(18:13:13) daniel s: which i guess makes sense, since there's only one focus now
(18:15:37) daniel s: the event delivery logic looks like this:
(18:15:47) daniel s:   * if there's a grab, do normal grab delivery
(18:15:57) daniel s:   * if the device is explicitly focussed, deliver to its focus
(18:16:05) daniel s:     (i.e. XSetDeviceFocus or so)
(18:16:14) daniel s:   * else deliver to the currently focussed window
(18:16:46) daniel s: so it's a bit different from core delivery in that the window parameter only determines your co-ord base for event_{x,y}
(18:18:06) daniel s: so you get event delivery if you've selected for extension events on the window the core pointer is currently focussed on, rather than if it's for a window the extended device is currently within
(18:18:46) daniel s: afaict this is completely within spec, but mpx gives every sprite focus [edit: and devices either move a visible sprite or floating devices have an invisible sprite], so you get the core event delivery model back in that sense: it'll stop delivering you events as soon as the extended device leaves the window you've selected on
(18:19:17) daniel s: so this should just be RESOLVED/MPX, and you'll just need to ignore events outside the bounds of your window for Xi 1.x, i guess

I've also pushed the patch linked to from comment #10 to server-1.5-branch and server-1.4-branch, so 1.4.1, all 1.5.x and all 1.6.x releases will all have this fixed.