[kde-linux] Re: KDE 4.6.3 update messed up my TwinView setup?
- Date: Tue, 14 Jun 2011 18:57:58 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: [kde-linux] Re: KDE 4.6.3 update messed up my TwinView setup?
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
| 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
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
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
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
> I do wonder if this should be described somewhere in the Gentoo KDE
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
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.