XQuartz tablet mouse events are at the wrong location and other Xinput headaches

[Peter Hutterer]

On Sat, Mar 17, 2012 at 12:49:53AM -0700, Jeremy Huddleston wrote:
> 
> 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'.
> 
> Valuators: {32777.666667,0.000000,0.000000,22526.687460,0.000000}
> motion a[0]=16398 a[1]=0 a[2]=0 a[3]=22526 a[4]=0
> 
> Valuators: {32777.666667,65510.186667,0.000000,-23552.718772,-12288.375011}
> motion a[0]=16398 a[1]=65510 a[2]=0 a[3]=-23552 a[4]=-12288
> 
> Valuators: {65526.266667,21.333333,0.000000,39935.218726,3070.093692}
> motion a[0]=65521 a[1]=21 a[2]=0 a[3]=39935 a[4]=3070 
> 
> Valuators: {65526.266667,65471.360000,0.000000,61439.874996,-21504.656270}
> motion a[0]=65521 a[1]=65471 a[2]=0 a[3]=61439 a[4]=-21504

I just tried this with a uinput test device that submits exactly the same
values and has the same button/axes as the darwinTablet (had to set
BTN_STYLUS to avoid evdev treating it as touchpad but that does not
affect any coordinate handling in the server).
The coordinates are identical, so I'm a bit confused where the scaling comes
from. I noticed that the debug output displays pointer_x, pointer_y, but not
the valuators[] values you actually submit to the dix. 

I'd prefer to see those too, to rule out that there's some scaling issue
before QueuePointerEvents.

Do you have anything that sets the coordinate transformation matrix?
Do you have more than one ScreenRec?

Cheers,
  Peter