||This article needs additional citations for verification. (July 2011)|
Developed under the name PanoramiX by Madeline T. Asmus of the Digital Equipment Corporation's Unix X Server Engineering Group, the software was contributed to The Open Group for X11 Release 6.4 (X11R6.4) and renamed Xinerama. It was then incorporated into the XFree86 4.0 release and the Solaris 7 11/99 release. According to X Server project lead Rob Lembree, the name was inspired by the Cinerama widescreen theatre process. "We were frustrated by having big Alpha machines with multiple displays, and being unable to move applications from one to another. It was developed as much out of frustration as competitive advantage." Xinerama advantages include the ability to only maximize windows to the dimensions of the active physical display, and to allow new pop-up windows on the active physical display.
General theory of operation 
When Xinerama is enabled in the X server, multiple X screens can be unified into a single workspace. This unified work area allows windows to be transferred across X screens.
XINERAMA extension 
The Xinerama extension provides clients with information about the layout of viewports within the unified workspace. Its information regarding offset and size information allows clients to make intelligent decisions about window placement, window maximization and other user interaction events.
Use in non-XINERAMA environments 
The X server's client/server architecture allows the server to expose Xinerama information to the client regardless of whether the Xinerama infrastructure is active. RandR and NVidia's twinview utilize this feature to provide window managers and clients with information about the output layout relative to the framebuffer.
Future of XINERAMA 
An effort by the X.Org Consortium to document the Xinerama protocol and application programming interface (API) as formal standards has been discontinued. Development of the Xinerama code is now hosted on freedesktop.org, and managed by the X.Org Foundation.
||This article or section appears to contradict itself. (July 2012)|
The RANDR extension exports its CRTC geometry in the Xinerama protocol, as well as through its own protocol. This conflicts with the reference X server's Xinerama implementation when multiple graphics processing units (GPUs) are used. Work is under way to correct this.
The 1.10 X server release removes the conflict between the Xinerama rendering multiplexer and Composite extensions.
Known problems 
Common color depth 
Hardware rendering 
In some[which?] implementations, OpenGL direct-rendering only works on one screen. Windows that should show 3D graphics on other screens tend to appear black, a problem most commonly seen with 3D screen savers. The Solaris SPARC OpenGL implementation and ATI and nVidia proprietary Linux drivers support hardware-accelerated rendering of all screens in Xinerama mode.
Static configuration 
Physical screens cannot be added or removed dynamically, and there is no way to change the resolution of a screen. This is particularly difficult for mobile computer users, who may use an external physical display in addition to the computer's built-in screen, but only at certain locations. It is recommended that RandR or ATI's or nVidia's single GPU method is used in these cases. Xinerama's lack of support for adding or removing screens causes several problems:
- Windows may be drawn to a screen that is not connected to the computer. The user is required to drag these windows to the main screen, but is unable to see them.
- Video signals sent to disconnected displays use unnecessary power and may reduce battery life.
- It becomes difficult to use a device in multiple locations, where available external screens are likely to be configured differently.
These problems are related to Xinerama's implementation rather than its design, and can be corrected with further development.
Window manager support 
Some window managers and desktop environments have limited awareness of the separate physical screens in Xinerama, so that the desktop is simply stretched over the physical screens instead of arranged as a single large desktop. The window manager may place a new window on an unexpected screen, which can be confusing and annoying. Xinerama nevertheless offers the advantage that windows can be moved between screens, unlike in X.
Dead space 
The physical displays do not need to be the same resolution, and the virtual display area is not necessarily rectangular if the component physical displays are not the same size. Some window managers assume a rectangular display area, and enforce this by creating excess "dead space" at the edges of a display. The window manager needs awareness of Xinerama to avoid placing new windows in this dead space.
See also 
Asmus, Madeline T. (December 1995) "The PanoramiX Extension" THE X RESOURCE 16: A Practical Journal of the X Window System. pp. 59–73 ISBN 1-56592-166-6.
- hlanigan; jacotton, paul_anderson (2012). "Xinerama Alpha". sourceforge. Geeknet, Inc. Retrieved 29 May 2012.
- Airlie, Dave, Xinerama/RANDR integration tree, Free desktop.
- X server commit to enable Composite when Xinerama is active, Free desktop.
- fvwm (30). "FVWM - Man page - fvwm2". Official FVWM Home Page. fvwm. Retrieved 29 May 2012.
- Overview of X11R6.8 (X.Org)