XI 1.5 questions

[Thomas Jaeger]

Daniel Stone wrote:
> On Thu, Dec 11, 2008 at 11:32:57AM -0500, Thomas Jaeger wrote:
>> I'm currently in the process of updating my gesture-recognition
>> application easystroke to reflect the XInput changes in xserver-1.6 and
>> I have a couple of questions about the direction that we're headed.
>>
>> The first question is about the behavior under core pointer freezes
>> caused by passive grabs with GrabModeSync.  Currently, xserver-1.6's
>> behavior differs from xserver-1.5 in the following ways:
>> (1) While the core pointer is frozen, XInput events report the logical
>> state of the pointer, i.e. the point where the mouse was pressed down
>> (2) After the client calls XAllowEvents(dpy, ReplayPointer), the
>> complete motion history is replayed, but the coordinates reported are
>> the same as in (1), which isn't very useful.
>>
>> (1) is not a big deal, since the information about the physical position
>> of the pointer is still available through valuators. (2) would be an
>> improvement over the behavior in 1.5 if actual physical coordinates were
>> replayed, which is presumably what was intended here.
> 
> If that's the problem I'm thinking of, unfortunately that's unfixable.
> The spec actually demands that {event,root}_[xy] in events track the
> core pointer, not the current device.  Awesome, isn't it?

Thanks, I wasn't aware that there was a spec.  Maybe not a bad thing
considering that the contents of that field changed at least twice
during the 1.4 cycle.  This behavior is a little annoying, but not
really a problem since all the information is still available via
valuators (modulo the fact that some drivers don't notify clients of a
change in device resolution, but I can work around that fairly effectively).

The question was actually about how the core pointer is reporting events
when they are being replayed after a grab by a different client.  Here
is a part of the xev output in this situation:

ButtonPress event, serial 31, synthetic NO, window 0x3c00001,
    root 0x7c, subw 0x3c00002, time 7082369, (37,21), root:(44,75),
    state 0x0, button 1, same_screen YES

EnterNotify event, serial 31, synthetic NO, window 0x3c00001,
    root 0x7c, subw 0x0, time 7082546, (37,21), root:(44,75),
    mode NotifyGrab, detail NotifyInferior, same_screen YES,
    focus YES, state 256

KeymapNotify event, serial 31, synthetic NO, window 0x0,
    keys:  124 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

MotionNotify event, serial 31, synthetic NO, window 0x3c00001,
    root 0x7c, subw 0x3c00002, time 7082384, (37,21), root:(44,75),
    state 0x100, is_hint 0, same_screen YES

MotionNotify event, serial 31, synthetic NO, window 0x3c00001,
    root 0x7c, subw 0x3c00002, time 7082396, (37,21), root:(44,75),
    state 0x100, is_hint 0, same_screen YES

[about 10 more MotionNotify events with the same coordinates]

MotionNotify event, serial 31, synthetic NO, window 0x3c00001,
    root 0x7c, subw 0x3c00002, time 7082546, (37,21), root:(44,75),
    state 0x100, is_hint 0, same_screen YES

ButtonRelease event, serial 31, synthetic NO, window 0x3c00001,
    root 0x7c, subw 0x3c00002, time 7082710, (67,61), root:(74,115),
    state 0x100, button 1, same_screen YES

Notice that all the replayed MotionNotify events have identical
coordinates (the position where the mouse was pressed down), so we don't
get any real information here.  In particular, after the call to
XAllowEvents, the application will be unaware of the actual position of
the pointer until the mouse is either moved or released.

Thanks,
Tom