XQuartz tablet mouse events are at the wrong location and other Xinput headaches
jeremyhu at apple.com
Sat Mar 17 00:49:53 PDT 2012
On Mar 13, 2012, at 02:23, Jeremy Huddleston wrote:
> Hey Peter,
> I'm having an Xi week here in XQuartz. I just received a bug report (http://xquartz.macosforge.org/trac/ticket/555) that tablet support has regressed in XQuartz in 1.12.0 from 1.11.4. The DDX code in both versions is practically the same, so I think this might be a regression somewhere in DIX. Does this sound related to anything you've heard about?
So I've been able to reproduce the issue reported by XQuartz users. In my debugging, I'm seeing that the valuators we're setting in our ValuatorMask aren't properly relayed to either libXi or core clients. The corresponding core events match location with the Xi events (ie: xev shows the events as located in a location corresponding to the events reported by 'xinput test pen'). I'm hoping you might have some ideas about what is going on here or direction on where to dig next.
You can see how we setup the tablet in DarwinTabletProc on line 347 in http://cgit.freedesktop.org/~jeremyhu/xserver/tree/hw/xquartz/darwin.c?h=server-1.13-apple (DarwinPrepareValuators and DarwinSendPointerEvents may also be of interest in http://cgit.freedesktop.org/~jeremyhu/xserver/tree/hw/xquartz/darwinEvents.c?h=server-1.13-apple
Here are some examples. The first is just valuator_mask_get_double(..., #) for the valuators of the event we enqueue with QueuePointerEvents(pDev, ev_type, ev_button, POINTER_ABSOLUTE, &valuators). The second is from the corresponding event sent to 'xinput test pointer'.
motion a=16398 a=0 a=0 a=22526 a=0
motion a=16398 a=65510 a=0 a=-23552 a=-12288
motion a=65521 a=21 a=0 a=39935 a=3070
motion a=65521 a=65471 a=0 a=61439 a=-21504
More information about the xorg-devel