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

[Jeremy Huddleston]

On Mar 21, 2012, at 00:23, Jeremy Huddleston wrote:

> 
> On Mar 20, 2012, at 8:07 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> 
>> On Sat, Mar 17, 2012 at 12:49:53AM -0700, Jeremy Huddleston wrote:
>>> 
>>> 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. 
> 
> The copy/pasted text above actually *are* the valuators sent to the dix.  The debug printing does include pointer_x and pointer_y, but I omitted those in the information above.  From darwinEvents.c[1], you can see the Valuators above match what we're sending to QueuePointerEvents:
> 
>    DEBUG_LOG("Pointer (%lf, %lf), Valuators: {%lf,%lf,%lf,%lf,%lf}\n", pointer_x, pointer_y,
>              valuator_mask_get_double(pmask, 0), valuator_mask_get_double(pmask, 1),
>              valuator_mask_get_double(pmask, 2), valuator_mask_get_double(pmask, 3),
>              valuator_mask_get_double(pmask, 4));
>    }
> 
> 1: http://cgit.freedesktop.org/~jeremyhu/xserver/tree/hw/xquartz/darwinEvents.c?h=server-1.13-apple&id=5adf599c893e68a3057a6c4af507e4275dc6fca5

I traced it a bit further today, and the correct value for the valuator is landing on the input queue and is set right in FP3232 in the xi event.  In the case below, I'm trying to send 32768.  eventToRawEvent() gives us something that looks right, but 16636 is still coming out the other end (xinput test pen).  


(gdb) bt
#0  eventToRawEvent (ev=0x106bc5248, xi=0x106bc50f8) at eventconvert.c:763
#1  0x000000010017bb03 in EventToXI2 (ev=0x106bc5248, xi=0x106bc50f8) at eventconvert.c:287
#2  0x000000010016ffb3 in DeliverRawEvent (ev=0x106bc5248, device=0x103384e50) at events.c:2299
#3  0x00000001000df42a in ProcessOtherEvent (ev=0x106bc5248, device=0x103384e50) at exevents.c:1738
#4  0x0000000100120a72 in ProcessPointerEvent (ev=0x106bc5248, mouse=0x103384e50) at xkbAccessX.c:726
#5  0x00000001001bf7d7 in mieqProcessDeviceEvent (dev=0x10303ca40, event=0x1002fbc30, screen=0x100c17cf0) at mieq.c:549
#6  0x00000001001bfaaa in mieqProcessInputEvents () at mieq.c:609
#7  0x0000000100017314 in ProcessInputEvents () at darwinEvents.c:386
#8  0x000000010015d3ea in Dispatch () at dispatch.c:362
#9  0x000000010003d532 in dix_main (argc=8, argv=0x7fff5fbff710, envp=0x7fff5fbff670) at main.c:287
#10 0x000000010001c9c0 in server_thread (arg=0x100c12a60) at quartzStartup.c:63
#11 0x00007fff940d58bf in _pthread_start (self=0x106bc6000, kport=21511, fun=0x10001c980 <server_thread>, funarg=0x100c12a60, stacksize=20, pflags=67108864) at pthread.c:897
#12 0x00007fff940d8b75 in thread_start () at thread_start.s:34
(gdb) print *ev
$36 = {
  header = 255 '?', 
  type = ET_RawMotion, 
  length = 624, 
  time = 1103041104, 
  deviceid = 2, 
  sourceid = 8, 
  detail = {
    button = 0, 
    key = 0
  }, 
  valuators = {
    mask = "\037\000\000\000", 
    data = {32768, 0, 0, 25598.781212805567, -16384.500015259255, 0 <repeats 31 times>}, 
    data_raw = {32768, 0, 0, 25598.781212805567, -16384.500015259255, 0 <repeats 31 times>}
  }, 
  flags = 0
}
...
785	    for (i = 0; i < sizeof(ev->valuators.mask) * 8; i++)
(gdb) n
787	        if (BitIsOn(ev->valuators.mask, i))
(gdb) n
789	            SetBit(ptr, i);
(gdb) n
790	            *axisval =  double_to_fp3232(ev->valuators.data[i]);
(gdb) print ev->valuators.data[i]
$39 = 32768
(gdb) n
791	            *axisval_raw = double_to_fp3232(ev->valuators.data_raw[i]);
(gdb) n     
792	            axisval++;
(gdb) print *axisval
$40 = {
  integral = 32768, 
  frac = 0
}
(gdb) print *axisval_raw
$41 = {
  integral = 32768, 
  frac = 0
}
...
Breakpoint 5, eventToRawEvent (ev=0x106bc5248, xi=0x106bc50f8) at eventconvert.c:797
797	    return Success;
(gdb) print *(FP3232*)(ptr + raw->valuators_len * 4)
$43 = {
  integral = 32768, 
  frac = 0
}

>> I'd prefer to see those too, to rule out that there's some scaling issue
>> before QueuePointerEvents.
> 
> Yeah, that was essentially what I did =/
> 
>> Do you have anything that sets the coordinate transformation matrix?
> 
> We should have it set to unity by our call to AddInputDevice().  I'll check that explicitly when I get back home later this week and have access to a tablet again.
> 
>> Do you have more than one ScreenRec?
> 
> No.