On Mon, Sep 26, 2016 at 01:52:54PM +0100, Markus Kuhn wrote: > On 21/09/16 12:05, Peter Hutterer wrote: > > these days a protocol screen like you use it is the exception, not the rule. > > > > the problem with ScreenNo isn't the ambiguity, it's that it just doesn't > > really apply when a screen isn't already plugged in on boot. in many cases, > > the screen order isn't clear until after login, e.g. when you use xrandr to > > arrange the displays. > > The xrandr model, namely all displays just showing parts of a single > virtual screen, can cause problems in situations were one screen > really serves a completely different purpose from the other screen, > i.e. were you really don't want windows to go across screens, > or where a screen is linked to an input device that is meant to > provides absolute coordinates for one screen only. > > When I try to use xinput_calibrator to calibrate a touchpanel > against its built-in screen, under xrandr it really gets confused > about the size of the physical screen versus the size of > xrandr's virtual screen. xinput_calibrator opens its window > across both my desktop and my Cintiq 13HD, and there is no > option to tell it to cover just the latter. Even if there were, > there would still be a risk that stylus coordinates at the edge of the > tablet could leak into the other screen. > > Protocol screens used to be a very convenient way to keep > screens separate, rather than confuse applications by screens > sharing the same coordinate system. > > If integer protocol screen numbers really are no longer viable, is > there no other conceivable way to unambiguously bind the > coordinate system of an "absolute" input device to the coordinate > system of just one physical output of a graphics card? For example > by providing a new option to specify under Section "InputDevice" the > identifier of a corresponding Section "Screen" in xorg.conf > (just like Option "ScreenNo" "0" did, just not using integers > that might depend on hot-plug order, but something that actually > refers to a named device driver instance, Port-ID, Bus-ID, whatever).
the input transformation matrix that's used for calibration (and by the varous map-to-screen options) is just a matrix that represents the whole screen estate, normalised to [0, 1.0). So you can use it to map to any area on the screen, regardless of whether it's a protocol screen, a normal screen, or just an area. Cheers, Peter ------------------------------------------------------------------------------ _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
