[kde-linux] Re: KDE 4.6.3 update messed up my TwinView setup?
Duncan
1i5t5.duncan at cox.net
Tue Jun 14 23:49:21 UTC 2011
Mark Knecht posted on Tue, 14 Jun 2011 13:49:56 -0700 as excerpted:
> Well, to say I lack an understanding of the subject at hand is simply a
> gross understatement! ;-)
>
> That said, the NVidia forums suggest a different view of the efficiency
> of TwinView in that when using TwinView the user has only one X server
> with 1 set of window geometry management. (My language, not taking the
> time to go find the exact technically right set of words)
That's true, but it reflects the old/full usage of the term "xinerama",
making multiple graphics cards and their outputs work together with a
single X, not the more frequent modern usage, which simply has to do with
the hints X makes available about the layout beyond "the big bounding
rectangle", regardless of whether the multiple monitors are processed by
one card/chip or many. The latter is much less complicated, and is the
context we're talking about here. So concerns valid against the full
xinerama aren't valid, here, because it's just the protocol extensions
we're talking about, not the full-on X extension.
> How TwinView manages different monitor resolutions and other things that
> create holes isn't currently important to me as my monitors are matched.
I'm actually running matched as well, on my main machine. It's nice as
it vastly simplifies things. =:^) But of course "hole management" still
makes a big difference for laptops with less than normal resolution (like
netbooks) especially.
> Also, TwinView seems a very specific solution to a much larger problem.
> I have no idea how TwinView would work at all with, for instance, 3
> graphics cards and 6 monitors. Likely it's a card specific solution for
> 2 & 4 monitor type setups, and even then specifically only NVidia cards.
Actually, the full-on xinerama could be seen similarly as a specific
solution to one aspect of the larger problem -- a different aspect than
twinview covers, since it's mainly useful when using multiple graphics
cards in the same machine (and not in crossfire or whatever config),
while twinview, pseudo-xinerama, etc, work with multiple outputs on a
single card.
(FWIW, years ago, when I first switched from MS, I had a triple monitor
setup, using an nVidia card with dual outputs and twinview, and a cheap
Trident 4 MB PCI card I still had floating around from before. The nVidia
card and driver handled its two outputs using twinview/pseudo-xinerama,
but I had to use the real xinerama to merge the second card with the
third output into the mix. I think that may no longer be necessary
provided both cards are supported by the same X driver, but I've not
tried it in years as monitors have gotten far bigger since then and I've
not needed to. Plus, the full-on xinerama had major negatives, such as
no OpenGL accel on the "extra" card/output, etc. Again, with the newer
architecture and the kernel's new graphics routing arbiter going, that
may no longer be true, or it may, but I don't know as I've not used such
a setup in years. Meanwhile, I had made the mistake of getting that
nVidia card while I was still on MS and knew to look for Linux drivers
but did NOT realize the difference between freedomware and proprietary
drivers, but once I did switch to Linux and realized the downsides as
well, it was the LAST time I made that mistake. I've always run native
driver supported Radeons in my main machine since, and of course the
native driver supported Intel in my netbook. So I know what the nVidia
twinview thing is all about and actually found their driver config and
documentation quite reasonable -- just not the fact that it wasn't
freedomware AND that I had to hassle rebuilding it every time I changed
kernels.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
More information about the kde-linux
mailing list