XInput: Tablet to screen coordinate translation
Magnus.Vigerlof at home.se
Tue Feb 27 15:47:35 PST 2007
On Tuesday 27 February 2007 13:16, Peter Hutterer wrote:
> On 26/02/2007, at 08:27 , Magnus Vigerlöf wrote:
> > Hi,
> > [...]
> > So I wonder if anybody could help me and point out where the
> > coordinate
> > conversion should be made?
> GetPointerEvents converts coordinates into xEvents. At this point you
> need to know whether the coordinates you pass in are absolute or
> relative ones, and they will be clipped accordingly. GPE is called
> when your driver calls xf86PostXXXEvent, so the answer to your
> question is that conversion from a device-specific coordinate system
> into screen coordinates should to be done in the driver.
So the coordinates that is sent on the first two axis (x & y) to
xf86PostXXXEvent must be converted into coordinates that will fit the actual
screen resolution (provided first_valuator is 0)?
This conversion is something that the xf86PostXXXEvent-functions seems to have
handled itself previously with a little help by the actual driver (by calling
LocalDeviceRec->conversion_proc() from within xf86PostXXXEvent), so it can
generate XInput events with the native (sub-pixel precision) resolution for
that device which is independent of the screen and also core-events that is
scaled to the screen resolution.
I'm not sure I like the new way since it limits the value range the driver may
report and also put the full responsibility of handling notification of
screen resolution changes in the device driver for its device.
> Didn't quite understand your problem with GIMP though.
Gimp open the XInput device directly and listens to the raw events instead of
getting it through the core device (which is how it get the pressure
sensitivity and more). The min/max values are used to match the position
where to draw to where the pointer is on the screen. Historically it seems
that there has been no connection between the X & Y axis of the device and
the screen resolution, so it has been possible to read sub-pixel changes from
the device if is has higher resolution than the screen (Cintix 21" has a
resolution of 87200x65600, should this fine-grained information not be
If the device driver must adjust its min/max values to the screen resolution,
it must also change those whenever the screen resolution changes or we'll be
out of sync with the screen. The Cintiq is a touch-screen so we *must* be in
It is possible to have two different screens side-by-side with different
resolution? If it is, which resolution should the driver select? Which one
should it reply to Gimp when it asks for the min/max values the device will
send out? As it has been up 'til 7.2 there's no problem at all as it has it's
own range that the applications knows that it has to rescale.
There is a slight problem with gimp (or is it gtk/qt/...?) and changing XInput
devices. It can't handle new devices nor changes in existing device, in those
cases it has to be restarted or it will not see the new devices and it'll be
out of sync with the changed. Not fun..
Since the hotplug in the X-server is a new thing I have a feeling there are
none or only a few application (that uses XInput devices directly) that will
handle this in a good manner at the moment. But I don't think it's fair to
leave them with a new behaviour that isn't backward compatible (but that's
Maybe there's a fundamental change in how this should work which I haven't got
my head around. If so, please help me understand. But at the moment I can see
quite big changes for the applications. Changes that I see problems with..
Don't get me wrong here. I think the cleaning of the core pointer/kbd code and
the new HotPlug ability are really nice and I appreciate the effort you've
put into that part. Now we'll just make sure that the wacom driver for
linux/*bsd will be able to use all these new stuff you've made available for
> Multi-Pointer X Server
More information about the xorg