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 ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
