On Thu, Aug 11, 2011 at 03:49:45PM -0700, Jason Gerecke wrote: > On Wed, Aug 10, 2011 at 6:43 PM, Peter Hutterer > <peter.hutte...@who-t.net> wrote: > > On Tue, Aug 09, 2011 at 05:50:11PM -0700, Jason Gerecke wrote: > >> Instead of having 'set_output' be responsible for choosing an > >> appropriate helper function, we let the helper functions be > >> autonomous. If they cannot find an appropriate output (or > >> encounter an error), they simply return False to let the > >> caller know that it failed. > > > > NAK. this changes the logic from RandR preferred to Xinerama preferred. > > > > In the original code, we only use xinerama for old servers or the nvidia > > blob. ok, let's be honest. it's only because of the nvidia blob. > > The change of "preferred" backend was unintentional, so I have no > aversion to swapping the order. However, I'm not certain that would > address your concerns, because... > > > in this code, you always call into the xinerama code first. I don't think > > there are any drivers that support randr but not xinerama (the server forces > > it) so any output specification in the form of "HEAD-X" will always work. > > That would also be the case if I swapped the checks. Unless you have a > really weird driver that exposes a head named "HEAD-0" through RandR, > checking it first would still fail and fallback to Xinerama. > > > Why is this a problem? if HEAD-0 always works but the correct randr notation > > VGA0 (etc.) only work on some machines, users will start using the one that > > always works. so you get forum entries sprinkled everywhere with "I don't > > know why but HEAD-0 works for me, try that". > > What is stopping users from making those kind of forum entries *right > now*? Users of nVidia's binary driver don't care why "HEAD-0" works -- > they'll still suggest it to users of the binary driver, open-source > driver, heck even to users of ATI drivers! If something works for > them, they're going to suggest other users try it. > > The difference is that that their advice would actually *work* with a > patch like this, which appears to be the crux of the isue.
yep, that's the crux of the issue. I'd like people to realise that HEAD-0 only works on nvidia, everyone else uses randr output names. > > the _only_ reason for supporting xinerama is the nvidia blob. So because of > > one driver, we end up nudging user towards a feature that's 11 year old > > instead of the newer feature. so, no, I don't think that's a good idea. > > I don't see it that way myself. Maintaining compatibility with > Xinerama does diminish demand for proper RandR support, but that's > hardly nudging users away from the newer feature. The only thing that > denying the use of Xinerama to those with the extension does is reduce > the amount of out-of-date information on the internet when Xinerama > finally goes the way of the dodo. There's something to be said for > keeping old information relevant (especially if the confused mass of > sample Wacom xorg.conf files a few years back was any indication), but > I can't see the fallout from the eventual death of Xinerama having > that big of an impact on us. Let's assume we build a few more features on top in the future. for example xsetwacom MatchOutputRotation. That won't work with HEAD-0 because xinerama doesn't do rotation. Output monitoring? Not with Xinerama. Output hotplugging? Not with Xinerama. These potential features are the reason I'd like Xinerama as a nvidia-only, last-case option while everyone else should use the xrandr notation. And one more thing I can think of right now though that's a weaker argument: (semi-)consistent output naming. LVDS is always the build-in screen. On laptops, VGA0 is the external monitor. HEAD-0 can be any monitor. Cheers, Peter ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
