touchscreens in multiscreen setups
peter.hutterer at who-t.net
Thu Dec 17 21:41:00 PST 2009
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
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.
More information about the xorg