touchscreens in multiscreen setups

[Peter Hutterer]

On Thu, Dec 17, 2009 at 09:27:07PM -0800, Keith Packard wrote:
> On Fri, 18 Dec 2009 15:04:48 +1000, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> 
> > there's two parts to it:
> > - xf86InputSetScreen seems broken, this should be fixed in the server.
> >   though it's probably optimised for the Xinerama scenario, I think it
> >   should be possible to set it up for randr output or CRTC tracking in a
> >   similar manner.
> 
> It would need to be tied to an output, not a crtc. And, what we'd need
> to do is let the input device know which output it is associated with,
> and then provide a helper function to translate coordinates relative to
> that output. That could deal with output transforms as well. I don't see
> how xf86XInputSetScreen has much to do with this though, other than
> having that be used as a hint to go lookup the output property in the
> config file?
> 

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.

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.

> > - randr notification. with screens being added and removed, there's no
> >   driver interface that I know of that input drivers can use to get notified
> >   about this stuff. Obviously the simple thing to do would be to handle this
> >   stuff in the server - if a screen goes away the device defaults back to
> >   whatever screen is still there. this would be without the driver knowing
> >   though - not ideal.
> 
> It seems like xf86PostMotionEventP could deal with this internally,
> by having the device know which output it was associated with and having
> that code deal with finding the transform and doing the right
> thing. Input devices not associated with an output would not be
> transformed, and input devices associated with disabled outputs could
> either be ignored (?) or have their output untransformed.

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.

Cheers,
  Peter