After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 344354 - GDK translates xinput tilt and wheel axes incorrectly (patch)
GDK translates xinput tilt and wheel axes incorrectly (patch)
Status: RESOLVED NOTGNOME
Product: gtk+
Classification: Platform
Component: Backend: X11
2.8.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2006-06-09 02:24 UTC by Philip L
Modified: 2006-12-11 13:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to gdk/x11/gdkinput-x11.c:gdk_input_translate_coordinates() (809 bytes, patch)
2006-06-09 02:31 UTC, Philip L
none Details | Review

Description Philip L 2006-06-09 02:24:52 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.
Comment 1 Philip L 2006-06-09 02:31:14 UTC
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
Comment 2 Oldrich Jedlicka 2006-11-07 09:14:42 UTC
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.
Comment 3 Marc Lehmann 2006-11-07 13:26:50 UTC
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.
Comment 4 Oldrich Jedlicka 2006-11-07 17:55:43 UTC
(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 :-)
Comment 5 Marc Lehmann 2006-11-08 14:16:23 UTC
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.
Comment 6 Oldrich Jedlicka 2006-11-08 17:56:33 UTC
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
Comment 7 Oldrich Jedlicka 2006-12-09 15:40:51 UTC
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).
Comment 8 Marc Lehmann 2006-12-10 14:57:28 UTC
Verified with 0.7.6-4, works for me.
Comment 9 Matthias Clasen 2006-12-11 13:36:11 UTC
Thanks for tracking this down.