touchscreens in multiscreen setups

Peter Korsgaard jacmet at
Thu Apr 8 08:22:56 PDT 2010

>>>>> "Keith" == Keith Packard <keithp at> writes:

Old thread, but I unfortunately couldn't work on it before now - The
issue is about binding touchscreen events to a randr output

Original thread is here:

 Keith> It would need to be tied to an output, not a crtc. And, what
 Keith> we'd need to do is let the input device know which output it is
 Keith> associated with, and then provide a helper function to translate
 Keith> coordinates relative to that output. That could deal with output
 Keith> transforms as well. I don't see how xf86XInputSetScreen has much
 Keith> to do with this though, other than having that be used as a hint
 Keith> to go lookup the output property in the config file?

So just to make sure I get it all (this is the first time I hack on X) -
I'll need to:

- Add an XInput property to evdev to assign a screen number / randr
  output name to a device
- Add an API to forward this info to the server (xf86XInputSetOutput?)
- Translate the raw coordinates in GetPointerEvents() if that flag is
  set (POINTER_OUTPUT?), and optionally ignore event if output is disabled.


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

 Keith> It seems like xf86PostMotionEventP could deal with this internally,
 Keith> by having the device know which output it was associated with and having
 Keith> that code deal with finding the transform and doing the right
 Keith> thing. Input devices not associated with an output would not be
 Keith> transformed, and input devices associated with disabled outputs could
 Keith> either be ignored (?) or have their output untransformed.

Bye, Peter Korsgaard

More information about the xorg mailing list