Commit 0509d2ee authored by 157.24.24.192's avatar 157.24.24.192
Browse files

corrections by ajax

parent 7b0566fa
......@@ -16,7 +16,8 @@ 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 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.
The drawbacks of Xinerama are noticeable. When any accelerated 2D rendering operation (core, Render, or Xv) is performed, it must be executed on every card. Each card maintains its own copy of all the rendering state, which means that all pixmaps (images) must be copied to every card, too. Because the X server is single-threaded, rendering takes more time by the number of cards. Furthermore, Xinerama does not handle GLX, so 3D acceleration is disabled.
One more annoyance is, that the DPI (dots-per-inch) resolution is fixed to the same value over all monitors.
== Dual-head Graphics Cards ==
......@@ -34,7 +35,7 @@ The third and the only proper way to deal with it is the Randr extension, which
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}}}.
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.
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. 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