touchscreens in multiscreen setups

[Keith Packard]

On Fri, 18 Dec 2009 15:41:00 +1000, Peter Hutterer <peter.hutterer at who-t.net> wrote:

> by default, devices cross screen boundaries and tablets/touchscreens map to
> the range of the screen. With xf86InputSetScreen a driver could be mapped
> to a single screen only, thus a right-hand corner would always be the
> right-hand corner on that screen, not on the right-hand corner of the
> right-most screen.

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.

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.

> 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.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20091217/fb9d732f/attachment.pgp>