[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