X server testing

Thomas Jaeger thjaeger at gmail.com
Fri Jun 19 23:40:07 PDT 2009


Hi Peter,

Thanks for your comments.

> On Mon, Jun 15, 2009 at 10:49:28PM -0400, Thomas Jaeger wrote:
>> * A related question is what the best way to detect virtual XTest
>> devices is.  I'm currently checking whether the device name ends in
>> "Xtst pointer", which seems slightly hackish, but should be fine as long
>> as the servers keeps using a predictable name for the device.
> 
> I'm not quite sure why you need to detect virtual XTest devices? If you're
> using XI anyway, leave them be, and if you're sending core events, then
> you don't know they exist anyway. What's your use-case here?
My application need to grab SDs in order to be able to intercept events
before they reach the master device.

>> * My tablet's valuators (which should be absolute) are reported as
>> having mode 3 (as opposed to XIModeAbsolute == 1 or XIModeRelative ==
>> 0), which causes xinput to list them as relative devices.
> 
> I think this should be fixed with bc2ff5365030ad8bc11efde430b1064080dd7098.
> Xi: copy the valuator mode from SD to MD.
> Can you confirm that?

No, it's still happening.

>> * Proximity events aren't reported as XI2 events at this points.  This
>> is not a big deal to me, I'm basically just making sure that you're
>> aware of this.
> 
> there are no proximity XI2 events. If a device can do proximity, it should
> report a proximity axis, even if that axis only has a range of [0, 1].
> And no, no driver supports that yet :)

I see.  I suppose AXIS_LABEL_PROP_ABS_DISTANCE is what we should be
going for?

>> * Subpixel coordinates are not working for me.  Glancing through the
>> code, I think this is to be expected for devices like my tablet whose
>> device resolution is higher than the screen resolution, but it seems
>> that this should work for accelerated devices like my trackpoint.  Once
>> again, not really a big deal.
> 
> yes, those bits are missing. sorry. subpixels right now are only for accel
> code. feel free to send me a patch for this though, rescaleValuatorAxis
> should be it.

I'll see what I can do.

>> (gdb) bt
>> #0  0x0086b422 in __kernel_vsyscall ()
>> #1  0x002d46d0 in raise () from /lib/tls/i686/cmov/libc.so.6
>> #2  0x002d6098 in abort () from /lib/tls/i686/cmov/libc.so.6
>> #3  0x0031224d in ?? () from /lib/tls/i686/cmov/libc.so.6
>> #4  0x00318604 in ?? () from /lib/tls/i686/cmov/libc.so.6
>> #5  0x0031a5b6 in free () from /lib/tls/i686/cmov/libc.so.6
>> #6  0x080a7a61 in Xfree (ptr=0x0) at ../../os/utils.c:1159
>> #7  0x08129420 in ProcessOtherEvent (ev=0x944e298, device=0xbec2d38) at ../../Xi/exevents.c:953
>> #8  0x08151ec8 in ProcessPointerEvent (ev=0x944e298, mouse=0xbec2d38) at ../../xkb/xkbAccessX.c:732
>> #9  0x0809fb05 in mieqProcessDeviceEvent (dev=0xbec2d38, event=0x944e298, screen=0x0) at ../../mi/mieq.c:403
>> #10 0x081056b8 in ProcXTestFakeInput (client=<value optimized out>) at ../../Xext/xtest.c:418
>> #11 0x0806cf87 in Dispatch () at ../../dix/dispatch.c:426
>> #12 0x080674b5 in main (argc=10, argv=0xbff73ac4, envp=0xbff73af0) at ../../dix/main.c:283
>> (gdb) print ev->any.type == ET_Raw
>> $11 = 1
>> (gdb)
> 
> Xfree shouldn't crash on NULL pointers, we might actually have some memory
> corruption happening. Does valgrind complain about anything?

I'll run a few checks as soon as I have access to a second computer
(Sunday at the earliest).

>> From 0f46b8a25fba1001b47850763d5de92162bce367 Mon Sep 17 00:00:00 2001
>> From: Thomas Jaeger <ThJaeger at gmail.com>
>> Date: Sun, 14 Jun 2009 13:58:39 -0400
>> Subject: [PATCH] reattach: Default to return to VCP/VCK when returnMode is AttachToMaster
>>
>> Signed-off-by: Thomas Jaeger <ThJaeger at gmail.com>
>> ---
>>  src/hierarchy.c |   39 +++++++++++++++++++++++++++++++++++++--
>>  src/xinput.c    |    2 +-
>>  2 files changed, 38 insertions(+), 3 deletions(-)
>>
> the approach seems a bit ineffective. Swap XIAllDevices for
> XIAllMasterDevices and if you check the arguments before, you only need one
> XIQueryDevice call.

I'm still stuck in the XI1 mindset, I suppose.  Anyway, I've attached an
updated patch.

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-reattach-Default-to-return-to-VCP-VCK-when-returnMod.patch
Type: text/x-patch
Size: 0 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20090620/36b1f1e4/attachment.bin 


More information about the xorg-devel mailing list