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

[Duncan]

Mark Knecht posted on Tue, 14 Jun 2011 08:23:46 -0700 as excerpted:

> In the end it seems that xinerama is possibly of value to some people,
> but certainly not to me, at least when using a single NVidia card that
> has multiple outputs. NVidia's TwinView does (as best I can tell) the
> same general thing as xinerama, at least as xinerama is described on its
> Wikipedia page. However TwinView does it in hardware, is faster and
> probably uses less power.

Well, xinerama these days seldom refers to xinerama extension itself, as 
it has to a large extent been deprecated in favor of the more modern RandR 
(Resize and Rotate, originally, now including Reflect, as well, xinerama 
wasn't running-X hotplug capable, RandR is), but rather, to the set of 
protocol extensions which it pioneered.

These protocol extensions describe NOT just the total bounding rectangle 
of all displays as X by itself does, but the actual pixel location and 
resolution of each display within the larger total desktop area, as well.

Consider the shape of the desktop resulting when I plug a full 1080p 
(1920x1080) monitor into my little 1024x600 resolution netbook.  If I 
choose too, of course, I can clone the smaller resolution display on the 
larger one, and/or set the larger one to the same resolution as the small 
one, thus eliminating any "holes" in the desktop if they're oriented side-
by-side or stacked.  However, if I keep the native resolution on each, 
with a non-cloned setup and assuming I didn't setup panning on the little 
one to compensate, then stacked, it'd look something like this (asci-art 
freehand, not to scale, you'll need to view with monospaced fonts to see 
it properly):

 -----------------------
|                       |
|    external           |
|          monitor      |
|                       |
 -----------------------
| builtin |    hole     |
 -----------------------

Back then, all window managers saw was the big bounding rectangle, and as 
the screen filled with windows, the unused area quickly became the hole, 
so that's where many window managers would try to put new windows, 
attempting to maximize the non-overlapping area of the windows.

But how do you interact with windows in the hole?  You can't see them!  
And what about windows maximized to the whole desktop, including the 
hole?  You can't see or interact with that part of the window!

One way around that as hinted above, would be to set the netbook to allow 
panning to the full width.  However, some people don't like panning as it 
gives them an unpleasant sensation comparable to motion sickness.  Others 
don't like it for other reasons.  And full-screening say a video or game 
has problems even with panning, because there's always SOME part of the 
overall rectangle that's not visible.

The xinerama protocol extensions allowed X to describe the layout, so a 
xinerama-compliant window manager would know about the hole, and would 
further know the size, shape and location of each of the monitors, 
resolution-wise.  Now, not only could the wm avoid placing windows in the 
hole, but it could use the additional information provided to maximize to 
a single monitor, if desired, and for various other uses that people 
quickly found for that information.  (Some of those uses kwin exposes for 
configuration via the multi-monitor kcontrol module, snap-to-edge 
windows, tracking the mouse and having new windows appear on the same 
monitor, etc.)

People quickly found this new xinerama exposed functionality useful, and 
soon it wasn't just window managers making use of it.  On the X-client 
side, video players and some games made use of it and desktops like 
plasma found it useful, as it allowed panels to dock to the internal 
monitor borders as well as those of the bounding rectangle.  X drivers 
soon began supporting it as well, particularly for multiple-output-single-
card configurations, where it was called pseudo-xinerama, because they 
exposed the same information to the window manager and other apps as 
xinerama did, but without the inefficiencies and negatives (such as 
killing OpenGL or allowing it only on one display) of xinerama on 
multiple independent graphics cards.

Meanwhile, as I said, xinerama as such has been seriously deemphasized in 
favor of randr and single-card-multi-output graphics hardware, with nVidia 
one of the first consumer market manufacturers to really sell the multi-
output feature, as Twinview, with its own driver implementation.  But it 
quickly implemented the xinerama protocol extensions for that, too, 
because it very quickly became *THE* way X window managers and other X-
client apps interacted with multiple monitors.

So today, "xinerama" very rarely refers to the original "xinerama" X 
extension, but rather, to the x-/protocol/ extensions it introduced, that 
anything X related that wants to support multimonitor today, supports.  
Even RandR built on the same protocol extensions, extending them even 
further for hotplugging and the like, but retaining the same basic 
information exposure to apps in the same way the xinerama protocol 
extensions did, for universal compatibility.

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.

Meanwhile, all the other drivers that support multiple outputs in non-
clone mode are doing the same thing, exposing information about the 
display layout for use by the apps that want/need that information for 
whatever reason, be it avoiding "holes" in the overall bounding rectangle 
that don't actually have a display covering them, maximizing to the size 
of individual displays, making sure dialog windows don't appear half on 
one monitor and half on the other, allowing panels and/or windows to snap 
to the interior borders, or whatever.

> At first I thought maybe I was losing something turning xinerama off,
> however I think I'm probably better off without it, at least for now.

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).

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.

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! =:^)

> 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.

-- 
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