touchscreens in multiscreen setups

[Matthieu Herrb]

Hi,

On Thu, Dec 17, 2009 at 10:35:16PM -0800, Keith Packard wrote:
> From what I can see, there's no way of fixing the coordinate space issue
> with any driver that uses xf86XInputSetScreen today as they all convert
> From device to screen coordinates internally, before posting those
> events to the X server. And, they use cached versions of the screen size
> to make those transforms.

That's not completely true. XInput can take care of this (although it
probably suffers from the problems you mention too). I've worked on
the BSD specific wscons input driver recently to update it to use
modern XInput features  and it doesn't need the screen dimensions
anymore (except in one specific case where the calibration is done 
in the kernel, but this mode is currently not so great)

<http://www.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-input-ws/>

> 
> I'd say tablets and touch screens should report raw device coordinates
> and let the X server transform them as appropriate. It'd be really cool
> if we could make all absolute devices report position in floating point
> using a [0..1] range on each axis. I think. The X server would then
> transform those as appropriate. I think all that would take is a new
> PostMotionEvent function that took doubles instead of ints; fixed
> drivers would use that, broken drivers would continue to report
> coordinates as they do today.

Not really necessary: X Input has the min/max values for each axes and
can do the computation for the driver. But why not ?

> 
> > xf86InputSetScreen comes into play mostly when it comes to figuring out if
> > this feature is possible to bring back without breaking the ABI. If we can
> > re-use it in a sensible manner, great.
> 
> Yeah, I don't see it as useful; the drivers are using the target 
> screen size to scale their data. Not helpful.
> 
> > if you modify the coordinates, you break raw events though and lose
> > precision on the screen you're restricted to. I think this needs to be tied
> > to miPointerSetScreen and possibly the pointer accel code, but that includes
> > a fair deal of speculation as well.
> 
> I don't see how miPointerSetScreen relates; most X servers have only one
> screen today.

If we break the API, it doesn't matter. It just currently the only
callback to upper layer beside the post event one to tell the X server
to update any data related to the current state of the input driver. 




> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg


-- 
Matthieu Herrb