Commit 68c33889 authored by 157.24.24.192's avatar 157.24.24.192
Browse files

finish rewrite

parent 292339e4
= Introduction =
= Introduction to Multiple Monitors in X =
== The X Protocol Screen ==
......@@ -14,28 +14,25 @@ The above limitation with SCREENs and applications is very inconvenient, when on
Along with the Xinerama feature came the Xinerama extension, which allows applications to query the physical monitor configuration. For instance, a Xinerama-aware window manager can maximize a window to fit one monitor instead of covering all monitors. For applications (window managers), there is the Xinerama library, {{{libXinerama}}} for using the Xinerama extension.
The drawbacks of Xinerama are noticeable. Xinerama is implemented as a big shadow framebuffer that covers all monitors. The framebuffer is in system RAM, not in the graphics cards' VRAM. This means that practically all acceleration done on graphics cards (2D drawing, 3D rendering, video overlays, Xv) must be disabled, since they do not work with system RAM. Originally this was not a big issue, since acceleration on GPU was not that big of a deal as it is now. Another minor annoyance is, that the DPI (dots-per-inch) resolution is fixed to the same value over all monitors.
The drawbacks of Xinerama are noticeable. Xinerama is implemented as a big shadow framebuffer that covers all monitors. The shadow framebuffer is in system RAM, not in the graphics cards' VRAM. This means that practically all acceleration done on graphics cards (2D drawing, 3D rendering, video overlays, Xv) must be disabled, since they do not work with system RAM. Originally this was not a big issue, since acceleration on GPU was not that big of a deal as it is now. Another slowdown with Xinerama is, that updates to the shadow framebuffer must be copied to the right graphics card's VRAM. One more annoyance is, that the DPI (dots-per-inch) resolution is fixed to the same value over all monitors.
== Dual-head Graphics Cards ==
Add a dual-head graphics card. Suddenly there is a single card with two physical monitors, and things get complicated. One solution for a driver (DDX) is to create one SCREEN per head, which is called Zaphod mode (after Zaphod Beeblebrox, from the Hitchhiker's Guide to the Galaxy). Another solution is to pretend that there is only one monitor, and use just one SCREEN, which is what the Nvidia TwinView mode does. The third and the only proper way to deal with it is the Randr extension, which is a relatively new invention. Randr exposes the dual-head card as a single SCREEN, yet having a standard way of managing the multiple monitors.
Then came dual-head graphics cards with two physical monitor connections and things got complicated. It did not fit the one SCREEN, one card, one monitor scheme, so drivers had to invent ways to circumvent the X server architecture limitations.
Unfortunately, Randr does not help with multiple graphics cards, yet. Each card is forced to be a separate SCREEN. However, the Xinerama feature changes that. (Xinerama is an older invention than Randr.)
One solution for a driver (DDX) is to create one SCREEN per head, which is called Zaphod mode (after Zaphod Beeblebrox, from the Hitchhiker's Guide to the Galaxy). This has the drawbacks of multiple SCREENs, but you get the DPI right.
= Multi-monitor desktop with Nouveau =
If you have a single GPU with multiple heads, it should all just work for you with [[Randr12|RandR 1.2]] and offer full (whatever is implemented) graphics acceleration. This page describes the situation for multiple GPUs, which considers both multiple cards and multi-GPU cards.
Another solution is to pretend that there is only one monitor, and use just one SCREEN, which is what the Nvidia !TwinView mode does. !TwinView avoids the drawbacks of the Xinerama feature, but has a completely non-standard way of configuring it. Plus, it is proprietary.
A multi-head card is normally managed as a single X protocol screen (SCREEN), controlled via RANDR extension (the command {{{xrandr}}}). The default configuration is cloned views. There exists an experimental configuration option {{{ZaphodHeads}}} with which you can configure a dual-head card to expose two (more than one) SCREENs.
The third and the only proper way to deal with it is the Randr extension, which is a relatively new invention. Randr exposes the dual-head card as a single SCREEN, yet having a standard way of managing the multiple monitors. It avoids the Xinerama feature drawbacks, but uses the Xinerama extension to provide applications information about the physical monitor layout. Randr configuration can be controlled on the fly with the command {{{xrandr}}}, and it can be written to the X configuration file. The default configuration is cloned views, i.e. all heads show the same image.
Separate graphics cards are normally configured as separate SCREENs. Each SCREEN is independent, and can have its own color depth. They are distinguished in the DISPLAY environment variable, which specifies for applications which X server and SCREEN to use. Generally, windows cannot be moved from one SCREEN to another. For now, there is no way to configure separate cards as a single, uniform desktop via RANDR.
== Xinerama ==
= Multi-monitor desktop with Nouveau =
Xinerama is many things: a library, an X extension, a protocol. The Xinerama protocol (used via the Xinerama library) allows an application to query the monitor configuration and is useful especially when one SCREEN spans more than one monitor.
If you have a single graphics card (GPU) with multiple heads, it should all just work for you with [[Randr12|RandR 1.2]] and offer full (whatever is implemented) graphics acceleration. If you really want multiple SCREENs on a dual-head card, there exists the experimental configuration option {{{ZaphodHeads}}}.
The Xinerama X server feature allows to combine what otherwise would be several SCREENs, into a single SCREEN, in theory offering a uniform desktop. However, it fits poorly to modern graphics. Xinerama sets up a shadow framebuffer, which is large enough to contain all monitors in the specified configuration. The shadow framebuffer is in system RAM, and when it changes, the changes are copied to the VRAM of the proper graphics cards. In other words, graphics cannot be accelerated by a GPU at all.
If you have multiple graphics cards, the only way to combine them into a single SCREEN is the Xinerama feature, and all the drawbacks listed for it apply. No acceleration whatsoever. Notice, that a card with multiple GPUs counts as multiple cards. The end result depends on which outputs are driven by which GPUs.
== Multiple cards and dual-head cards in Xinerama ==
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment