GNOME Bugzilla – Bug 344354
GDK translates xinput tilt and wheel axes incorrectly (patch)
Last modified: 2006-12-11 13:36:11 UTC
GDK does not translate xinput tilt and wheel axes correctly. Here are some sample values from my machine (same data as tests/testinput.c): stylus p= 0.473118 tx= 2198294.259843 ty= 941241.692913 stylus p= 0.474096 tx= 2198294.259843 ty= 941241.708661 stylus p= 0.478006 tx= 2198294.244094 ty= 941241.708661 stylus p= 0.479961 tx= 2198294.228346 ty= 941241.724409 where p, tx, and ty are pressure, xtilt and ytilt, respectively. The tilt values are supposed to be between -1 and 1.
Created attachment 67012 [details] [review] patch to gdk/x11/gdkinput-x11.c:gdk_input_translate_coordinates() The xidump program from linuxwacom reads the values this way: printf("Motion: x=%+6d y=%+6d p=%4d tx=%+4d ty=%+4d " "w=%+5d ID: %4d Serial: %11d \n", pMove->axis_data[0], pMove->axis_data[1], pMove->axis_data[2], (short)(pMove->axis_data[3]&0xffff), (short)(pMove->axis_data[4]&0xffff), (short)(pMove->axis_data[5]&0xffff), (pMove->axis_data[3]&0xffff0000)>>16, v); My patch simply ANDs the tilt and wheel axis data with 0xffff before translating it, as is done in this code. This causes the proper values to be given: stylus p= 0.506354 tx= 0.023622 ty= -0.133858 stylus p= 0.506354 tx= 0.007874 ty= -0.133858 stylus p= 0.509286 tx= -0.007874 ty= -0.118110 stylus p= 0.508309 tx= -0.007874 ty= -0.118110
I have Wacom Intuos 3 and I discovered the same problem yesterday. The result of my playing is almost identical to the patch from comment 1. So I have to confirm the problem, also that the solution works. The linuxwacom utility xidump masks those three axes (xtilt, ytilt, wheel) by 0xFFFF and Qt4 uses similar trick (casts the type to short) for xtilt and ytilt axes only. It seems to me that Qt4 ignores the wheel axis completely.
I have the same problem witz my intuis 3 and had the same problem years ago with my first intuos. The driver correctly hands ints with the upper bits 0 to the server, but the server sends out garbage in the upper 16 bits. It seems the real problem is a bug in the x-server which corrupts those additional bits. But maybe the protocol defines it that way and apps have to mask that themselves.
(In reply to comment #3) > It seems the real problem is a bug in the x-server which corrupts those > additional bits. But maybe the protocol defines it that way and apps have to > mask that themselves. According to linuxwacom sources, this is not a bug, but a feature. Look at version 0.7.6-2, wcmCommon.c, line 644: /* report tool id in the upper 2 bytes of 4th valuator * serial number in the upper 2 bytes of 5th and 6th * valuators for the 4 bytes of serial number . * All tools except pad */ if (type != PAD_ID) { v3 = ((id<<16) & 0xffff0000) | (((short)v3)& 0xffff); v4 = (serial & 0xffff0000) | (((short)v4)& 0xffff); v5 = ((serial<<16) & 0xffff0000) | (((short)v5)& 0xffff); So the tool ID and the serial number of the tablet is coded into axes 4, 5, and 6 - xtilt, ytilt and wheel. The xidump tool knows this and filters the "garbage" out. I really do not know if this is specified somewhere, but I guess that this is simple tunnelling of data through the current protocol, so it may introduce a possible incompatibility between tablet drivers. You can ask linuxwacom developers why they made this :-)
I see that this is a "feature" by the driver, however, I can hardly call it a feature. How about reporting the distance from the tablet in the x-coordinate? One can call it a "feature", but it still breaks applications, because the field is not split into two 16 bit values, but is a single value. Besides, this is really a bad hack, its better to use an extra axis or, better yet, a different device. Anyways, I didn't know that, even though I looked through the driver. That explains everything, although I am now convinced that it is indeed a X (or actualyl linuxwacom) drive rbug.
Reported as a bug #1592814 at linuxwacom project, if you are interested (just to endorse me), look at http://sourceforge.net/tracker/index.php?func=detail&aid=1592814&group_id=69596&atid=525124
Just to have information here: the bug #1592814 at linuxwacom project had been accepted and closed. Any additional information in axes should be removed - the fix for that should be included in version 0.7.6-3 (I have not tried it yet).
Verified with 0.7.6-4, works for me.
Thanks for tracking this down.