]> git.sur5r.net Git - i3/i3/blobdiff - docs/multi-monitor
Merge pull request #3144 from DebianWall/guaketilda
[i3/i3] / docs / multi-monitor
index 9affb0cc4fdd79cf51c235c9066f3c732172cef8..cafe569103b6c3f88a08615b697c4f176bb9c137 100644 (file)
@@ -1,24 +1,28 @@
 The multi-monitor situation
 ===========================
-Michael Stapelberg <michael+i3@stapelberg.de>
-March 2010
+Michael Stapelberg <michael@i3wm.org>
+April 2013
 
-…or: oh no, I have an nvidia graphics card!
+Please upgrade your nVidia driver to version 302.17 or newer and i3 will just
+work. This document is kept around for historic reasons only.
 
 == The quick fix
 
-If you are using the nvidia binary graphics driver, you need to use the
-+--force-xinerama+ flag when starting i3, like so (in your xsession):
+If you are using the nVidia binary graphics driver (also known as 'blob')
+before version 302.17, you need to use the +--force-xinerama+ flag (in your
+.xsession) when starting i3, like so:
 
 .Example:
 ----------------------------------------------
-exec i3 --force-xinerama -V >>~/.i3/i3log 2>&1 
+exec i3 --force-xinerama -V >>~/.i3/i3log 2>&1
 ----------------------------------------------
 
+…or use +force_xinerama yes+ in your configuration file.
+
 == The explanation
 
 Starting with version 3.ε, i3 uses the RandR (Rotate and Resize) API instead
-of Xinerama. This is due to the reason that RandR provides more information
+of Xinerama. The reason for this, is that RandR provides more information
 about your outputs and connected screens than Xinerama does. To be specific,
 the code which handled on-the-fly screen reconfiguration (meaning without
 restarting the X server) was a very messy heuristic and most of the time did
@@ -27,30 +31,35 @@ Xinerama offers (just a list of screen resolutions, no identifiers for the
 screens or any additional information). Xinerama simply was not designed
 for dynamic configuration.
 
-So, RandR came up as a more powerful alternative (RandR 1.2 to be specific).
+So RandR came along, as a more powerful alternative (RandR 1.2 to be specific).
 It offers all of Xinerama’s possibilities and lots more. Using the RandR API
 made our code much more robust and clean. Also, you can now reliably assign
 workspaces to output names instead of some rather unreliable screen identifier
 (position inside the list of screens, which could change, and so on…).
 
-As RandR is around for about three years, it seemed like a very good idea to
-us and it still is a very good one. What we did not expect, however, was the
-nVidia binary driver. It still does not support RandR (as of March 2010), even
-though nVidia announced that it will support RandR eventually. What does this
-mean for you, if you are stuck with the binary driver for some reason (say
-the free drivers don’t work with your card)? First of all, you are stuck with
-TwinView and cannot use +xrandr+. While this ruins the user experience, the
-more grave problem is that the nVidia driver not only does not support dynamic
-configuration using RandR, it also does not even expose correct multi-monitor
-information via the RandR API. So, in some setups, i3 will not find any
-screens, in others it will find one large screen which actually contains both
-of your physical screens (but it will not know that these are two screens).
+As RandR has been around for about three years as of this writing, it seemed
+like a very good idea to us, and it still is a very good one. What we did not
+expect, however, was the nVidia binary driver. It still does not support RandR
+(as of March 2010), even though nVidia has announced that it will support RandR
+eventually. What does this mean for you, if you are stuck with the binary
+driver for some reason (say the free drivers don’t work with your card)? First
+of all, you are stuck with TwinView and cannot use +xrandr+. While this ruins
+the user experience, the more grave problem is that the nVidia driver not only
+does not support dynamic configuration using RandR, it also does not expose
+correct multi-monitor information via the RandR API. So, in some setups, i3
+will not find any screens; in others, it will find one large screen which
+actually contains both of your physical screens (but it will not know that
+these are two screens).
 
 For this very reason, we decided to implement the following workaround: As
 long as the nVidia driver does not support RandR, an option called
-+--force-xinerama+ is available in i3. This option gets the list of screens
-*once* when starting and never updates it. As the nVidia driver cannot do
-dynamic configuration anyways, this is not a big deal.
++--force-xinerama+ is available in i3 (alternatively, you can use the
++force_xinerama+ configuration file directive). This option gets the list of
+screens *once* when starting, and never updates it. As the nVidia driver cannot
+do dynamic configuration anyways, this is not a big deal.
+
+Also note that your output names are not descriptive (like +HDMI1+) when using
+Xinerama, instead they are counted up, starting at 0: +xinerama-0+, +xinerama-1+, …
 
 == See also