XInput: Tablet to screen coordinate translation

[Magnus Vigerlöf]

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 
available anymore?).

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 
sync...
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 
me... :)


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 
us ;)

> Cheers,
>    Peter

Thanks
  Magnus V

> --
> Multi-Pointer X Server
> http://wearables.unisa.edu.au/mpx