[kde-linux] Re: KDE 4.6.3 update messed up my TwinView setup?

[Mark Knecht]

On Tue, Jun 14, 2011 at 11:57 AM, Duncan <1i5t5.duncan at cox.net> wrote:
<MASSIVE SNIP>
>
> So to say that nVidia does the same thing in hardware with Twinview
> really portrays a lack of understanding of the subject at hand, because
> even nVidia is using the same basic X protocol extensions to expose that
> information to the apps.  And BTW, it wouldn't really be doing it in
> hardware, so much as in the driver implementation, because what "xinerama"
> most often means as used today is simply exposing (as a driver) or making
> use of (as an X-client app) the extra information the original xinerama
> extension first provided, and exposing that information is something the
> driver's doing in software, tho it's making use of information the
> hardware itself provides, just in an X-standard compatible way that
> happens to be called xinerama, after the X extension that introduced the
> X-protocol extensions in support of a then-new feature.
>

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) The purported advantage is that decisions about which port to
write a window out on are done by the GPU and not by the X server.
Placing an app across two TwinView monitors has no impact at the CPU
level. All the driver does, as I understand it, is program the GPU to
be smart about this stuff and tell X that it's got a big monitor. How
the data gets to which monitor is then not dealt with by X...

How TwinView manages different monitor resolutions and other things
that create holes isn't currently important to me as my monitors are
matched.

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.

That all could be wrong. It's just the way I understood the threads I looked at.


<SNIP>
>
> What you're losing... doesn't appear to bother you.  But further up-
> thread, you said:
>
>>>> [T]he best I've gotten so far is that when nothing is checked I get
>>>> things like the logout dialog box or systemsettings spanning the two
>>>> monitors.
>
> Having things like the logout dialog or systemsettings spanning TWO
> monitors is definitely NOT what a lot of people would consider "best"
> behavior, at least as a default (having the ability to drag an occasional
> window across to span two monitors is one thing, having it happen by
> default is something ENTIRELY different).
>

Yep, don't like it at all...

> But you're used to it, indeed, to the point that now, having it NOT
> behave that way, is annoying to you.
>
> So indeed, for your case, having USE=-xinerama is probably (indeed,
> "probably" isn't strong enough, "certainly", as it turns out) what you
> want.
>

Login screens on my personal machines are a non-issue, just a minor
frustration. I wouldn't accept this for my parents for instance.

> But having windows split over multiple monitors like that by default
> would indeed be extremely frustrating to many people, including me (an
> avid multi-monitor user, but just as avid a xinerama protocol features
> user).  Luckily, kde makes it possible to customize most of that behavior
> at least with kwin, and I expect it eventually will with plasma as well,
> it's just that plasma is a substantially less mature project at this
> point, and some things simply aren't there yet.  But kde makes the
> dependencies and therefore features optional at build time, and gentoo
> being gentoo, exposes that to its users as USE flags, so we can all be
> happy! =:^)
>

Yep.....

>> I do wonder if this should be described somewhere in the Gentoo KDE
>> documentation...
>
> Good point.  The USE flag documentation in combination with google,
> should it be necessary, should be enough at that level.  However, the
> changed gentoo/kde profile USE flag default could probably be mentioned
> in the gentoo/kde guide.  Have you checked to see whether it is?  If it's
> not, the next step of course is to see if a bug has already been filed
> requesting that it be documented, and then filing one if not.
>

I will investigate the Gentoo side a bit more. I did file a bug report
with KDE, along with info about using -xinerama, so that at least
there was a chance that someone might look at it one day.

Thanks for your generous responses.

Cheers,
Mark