Please describe the problem:
If a GdkDeviceAxis describing the x or y axis of an input device has a non-zero
minimum value, then the translation of axis values to xy-coordinates for XInput
events is incorrect.

The culprit is the function gdk_input_translate_coordinates() in
gdk/x11/gdkinput-x11.c: in the code of that function,

          axis_out[i] = x_offset + x_scale * axis_data[x_axis];

should be fixed to

          axis_out[i] = x_offset + x_scale *
            (axis_data[x_axis] - gdkdev->axes[x_axis].min_value);

and similarly for the y axis.


Steps to reproduce:
1. configure an XInput device driver to have non-zero minimum xy-axis values
2. open any GTK+ XInput-aware app (e.g. Gimp) and enable the extension input
events in that app
3. watch the app get confused as the XInput events occur at xy-coordinates
completely different from those of the corresponding Core Pointer events (in
Gimp, you end up painting at some place other than where the pointer is).


Actual results:
The xy-coordinates of the GdkEvent structure are filled in incorrectly due to a
bug in gdk_input_translate_coordinates() in gdk/x11/gdkinput-x11.c.


Expected results:
The xy-coordinates of the GdkEvent structure for the extension input event
should be obtained by mapping linearly the range [min_value, max_value] to the
entire screen (or window, depending on how the device is configured). Currently,
the range [0, max_value - min_value] is mapped to the screen, instead.

Does this happen every time?
Yes.

Other information:
See http://www-math.mit.edu/~auroux/software/XINPUT-AXES-ISSUES
for a more detailed discussion of this bug, a related bug in the linuxwacom
driver, how this is important in the context of stylus calibration and display
rotation on Tablet PCs, and proposed bugfixes and workarounds.