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.hutte...@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 _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg