https://wiki.archlinux.org/api.php?action=feedcontributions&user=Skwuent&feedformat=atomArchWiki - User contributions [en]2024-03-29T11:04:16ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Window_manager&diff=330051Window manager2014-08-12T23:45:45Z<p>Skwuent: Noted that XMonad config file is a Haskell file.</p>
<hr />
<div>[[Category:Window managers]]<br />
[[ar:Window Manager]]<br />
[[es:Window Manager]]<br />
[[it:Window Manager]]<br />
[[ja:Window Manager]]<br />
[[uk:Window Manager]]<br />
[[zh-CN:Window Manager]]<br />
{{Related articles start}}<br />
{{Related|Desktop environment}}<br />
{{Related|Display manager}}<br />
{{Related|Xorg}}<br />
{{Related|xinitrc}}<br />
{{Related|Start X at Login}}<br />
{{Related articles end}}<br />
<br />
A [[Wikipedia:Window manager|window manager]] (WM) is system software that controls the placement and appearance of windows within a windowing system in a graphical user interface (GUI). It can be part of a [[desktop environment]] (DE) or be used standalone.<br />
<br />
== Overview ==<br />
<br />
Window managers are X clients that control the appearance and behaviour of the frames ("windows") where the various graphical applications are drawn. They determine the border, titlebar, size, and ability to resize windows, and often provide other functionality such as reserved areas for sticking [http://dockapps.windowmaker.org/ dockapps] like [[Window Maker]], or the ability to tab windows like [[Fluxbox]]. Some window managers are even bundled with simple utilities like menus to start programs or to configure the WM itself.<br />
<br />
The [http://standards.freedesktop.org/wm-spec/wm-spec-latest.html Extended Window Manager Hints] specification is used to allow window managers interact in standard ways with the server and the other clients.<br />
<br />
Some window managers are developed as part of a more comprehensive [[desktop environment]], usually allowing the other provided applications to better interact with each other, giving a more consistent experience to the user, complete with features like desktop icons, fonts, toolbars, wallpapers, or desktop widgets.<br />
<br />
Some window managers are instead designed to be used ''standalone'', giving the user complete freedom over the choice of the other applications to be used. This allows the user to create a more lightweight and customized environment, tailored to his/her own specific needs. "Extras" like desktop icons, toolbars, wallpapers, or desktop widgets, if needed, will have to be added with additional dedicated applications.<br />
<br />
Some standalone WMs can be also used to replace the default WM of a DE, just like some DE-oriented WMs can be used standalone too.<br />
<br />
Prior to installing a window manager, a functional X server installation is required. See [[Xorg]] for detailed information.<br />
<br />
=== Types ===<br />
<br />
* [[#Stacking window managers|Stacking]] (aka floating) window managers provide the traditional desktop metaphor used in commercial operating systems like Windows and OS X. Windows act like pieces of paper on a desk, and can be stacked on top of each other. For available Arch Wiki pages see [[:Category:Stacking WMs]].<br />
* [[#Tiling window managers|Tiling]] window managers "tile" the windows so that none are overlapping. They usually make very extensive use of key-bindings and have less (or no) reliance on the mouse. Tiling window managers may be manual, offer predefined layouts, or both. For available Arch Wiki pages see [[:Category:Tiling WMs]].<br />
* [[#Dynamic window managers|Dynamic]] window managers can dynamically switch between tiling or floating window layout. For available Arch Wiki pages see [[:Category:Dynamic WMs]].<br />
<br />
See [[Comparison of Tiling Window Managers]] and [[Wikipedia:Comparison of X window managers]] for comparison of window managers.<br />
<br />
== List of window managers==<br />
<br />
=== Stacking window managers ===<br />
<br />
* {{App|[[2bwm]]|Fast floating WM, with the particularity of having 2 borders, written over the XCB library and derived from mcwm written by Michael Cardell. In 2bwm everything is accessible from the keyboard but a pointing device can be used for move, resize and raise/lower. The name has recently changed from mcwm-beast to 2bwm.|https://github.com/venam/2bwm|{{AUR|2bwm}}}}<br />
<br />
* {{App|aewm|Modern, minimal window manager for X11. It is controlled entirely with the mouse, but contains no visible UI apart from window frames. The command set is sort of like vi: designed back in the dawn of time (1997) to squeeze speed out of low-memory machines, completely unintuitive and new-user-hostile, but quick and elegant in its own way.|http://www.red-bean.com/decklin/aewm/|{{AUR|aewm}}}}<br />
<br />
* {{App|[[Wikipedia:AfterStep|AfterStep]]|Window manager for the Unix X Window System. Originally based on the look and feel of the NeXTStep interface, it provides end users with a consistent, clean, and elegant desktop. The goal of AfterStep development is to provide for flexibility of desktop configuration, improving aesthetics, and efficient use of system resources.|http://www.afterstep.org/|{{AUR|afterstep}}}}<br />
<br />
* {{App|[[Wikipedia:Blackbox|Blackbox]]|Fast, lightweight window manager for the X Window System, without all those annoying library dependencies. Blackbox is built with C++ and contains completely original code (even though the graphics implementation is similar to that of WindowMaker).|http://blackboxwm.sourceforge.net/|{{Pkg|blackbox}}}}<br />
<br />
* {{App|[[Compiz]]|OpenGL compositing manager that uses GLX_EXT_texture_from_pixmap for binding redirected top-level windows to texture objects. It has a flexible plug-in system and it is designed to run well on most graphics hardware.|https://launchpad.net/compiz|{{AUR|compiz}}}}<br />
<br />
* {{App|[[cwm]]|Originally deriving from evilwm, but later re-written from scratch. cwm aims to be simple, and offers helpful features such as searching for windows.|http://monkey.org/~marius/cwm/cwm.1.a|{{AUR|cwm}}}}<br />
<br />
* {{App|[[Enlightenment]]|Enlightenment is not just a window manager for Linux/X11 and others, but also a whole suite of libraries to help you create beautiful user interfaces with much less work than doing it the old fashioned way and fighting with traditional toolkits, not to mention a traditional window manager.|http://www.enlightenment.org/|{{Pkg|enlightenment}}}}<br />
<br />
* {{App|[[evilwm]]|Minimalist window manager for the X Window System. 'Minimalist' here does not mean it is too bare to be usable - it just means it omits a lot of the stuff that make other window managers ''un''usable.|http://www.6809.org.uk/evilwm/|{{AUR|evilwm}}}}<br />
<br />
* {{App|[[Fluxbox]]|Window manager for X that was based on the Blackbox 0.61.1 code. It is very light on resources and easy to handle but yet full of features to make an easy and extremely fast desktop experience. It is built using C++ and licensed under the MIT License.|http://www.fluxbox.org/|{{Pkg|fluxbox}}}}<br />
<br />
* {{App|[[Wikipedia:FLWM|Flwm]]|Attempt to combine the best ideas I have seen in several window managers. The primary influence and code base is from wm2 by Chris Cannam.|http://flwm.sourceforge.net/|{{AUR|flwm}}}}<br />
<br />
* {{App|[[FVWM]]|Extremely powerful ICCCM-compliant multiple virtual desktop window manager for the X Window system. Development is active, and support is excellent.|http://www.fvwm.org/|{{Pkg|fvwm}}}}<br />
<br />
* {{app|[http://elementaryos.org/journal/meet-gala-window-manager Gala]|A beautiful Window Manager from elementaryos, part of [[Pantheon]]. Also as a compositing manager, based on libmutter.|https://launchpad.net/gala|{{aur|gala-bzr}}}}<br />
<br />
* {{App|Goomwwm|X11 window manager implemented in C as a cleanroom software project. It manages windows in a minimal floating layout, while providing flexible keyboard-driven controls for window switching, sizing, moving, tagging, and tiling. It is also fast, lightweight, modeless, Xinerama-aware, and EWMH compatible wherever possible.|http://aerosuidae.net/goomwwm/|{{AUR|goomwwm}}}}<br />
<br />
* {{App|[[IceWM]]|Window manager for the X Window System. The goal of IceWM is speed, simplicity, and not getting in the user's way.|http://www.icewm.org/|{{Pkg|icewm}}}}<br />
<br />
* {{App|[[JWM]]|Window manager for the X11 Window System. JWM is written in C and uses only Xlib at a minimum.|http://joewing.net/programs/jwm/|{{Pkg|jwm}}}}<br />
<br />
* {{App|Karmen|Window manager for X, written by Johan Veenhuizen. It is designed to "just work." There is no configuration file and no library dependencies other than Xlib. The input focus model is click-to-focus. Karmen aims at ICCCM and EWMH compliance.|http://karmen.sourceforge.net/|{{AUR|karmen}}}}<br />
<br />
* {{App|[[Wikipedia:KWin|KWin]]|The standard KDE window manager in KDE 4.0, ships with the first version of built-in support for compositing, making it also a compositing manager. This allows KWin to provide advanced graphical effects, similar to Compiz, while also providing all the features from previous KDE releases (such as very good integration with the rest of KDE, advanced configurability, focus stealing prevention, a well-tested window manager, robust handling of misbehaving applications/toolkits, etc.).|http://techbase.kde.org/Projects/KWin|{{Pkg|kdebase-workspace}} {{aur|kwin-git}}}}<br />
<br />
* {{App|lwm|Window manager for X that tries to keep out of your face. There are no icons, no button bars, no icon docks, no root menus, no nothing: if you want all that, then other programs can provide it. There is no configurability either: if you want that, you want a different window manager; one that helps your operating system in its evil conquest of your disc space and its annexation of your physical memory.|http://www.jfc.org.uk/software/lwm.html|{{Pkg|lwm}}}}<br />
<br />
* {{App|[[Wikipedia:Metacity|Metacity]]|This window manager strives to be quiet, small, stable, get on with its job, and stay out of your attention.|http://blogs.gnome.org/metacity/|{{Pkg|metacity}}}}<br />
<br />
* {{App|[[Wikipedia:Mutter (window manager)|Mutter]]|Window and compositing manager for GNOME, based on Clutter, uses OpenGL.|http://git.gnome.org/browse/mutter/|{{Pkg|mutter}}}}<br />
<br />
* {{App|[[Openbox]]|Highly configurable, next generation window manager with extensive standards support. The *box visual style is well known for its minimalistic appearance. Openbox uses the *box visual style, while providing a greater number of options for theme developers than previous *box implementations. The theme documentation describes the full range of options found in Openbox themes.|http://openbox.org/wiki/Main_Page|{{Pkg|openbox}}}}<br />
<br />
* {{App|[[pawm]]|Window manager for the X Window system. So it is not a 'desktop' and does not offer you a huge pile of useless options, just the facilities needed to run your X applications and at the same time having a friendly and easy to use interface.|http://www.pleyades.net/pawm/|{{Pkg|pawm}}}}<br />
<br />
* {{App|[[pekwm]]|Window manager that once upon a time was based on the aewm++ window manager, but it has evolved enough that it no longer resembles aewm++ at all. It has a much expanded feature-set, including window grouping (similar to Ion, PWM, or Fluxbox), auto-properties, Xinerama, keygrabber that supports keychains, and much more.|http://www.pekwm.org/projects/pekwm|{{Pkg|pekwm}}}}<br />
<br />
* {{App|[[Sawfish]]|Extensible window manager using a Lisp-based scripting language. Its policy is very minimal compared to most window managers. Its aim is simply to manage windows in the most flexible and attractive manner possible. All high-level WM functions are implemented in Lisp for future extensibility or redefinition.|http://sawfish.wikia.com/wiki/Main_Page|{{AUR|sawfish}}}}<br />
<br />
* {{App|TinyWM|Tiny window manager that I created as an exercise in minimalism. It is also maybe helpful in learning some of the very basics of creating a window manager. It is only around 50 lines of C. There is also a Python version using python-xlib.|http://incise.org/tinywm.html|{{AUR|tinywm}}}}<br />
<br />
* {{App|[[twm]]|Window manager for the X Window System. It provides titlebars, shaped windows, several forms of icon management, user-defined macro functions, click-to-type and pointer-driven keyboard focus, and user-specified key and pointer button bindings.|http://cgit.freedesktop.org/xorg/app/twm/|{{Pkg|xorg-twm}}}}<br />
<br />
* {{App|[[Wikipedia:UDE|UWM]]|The ultimate window manager for UDE.|http://udeproject.sourceforge.net/|{{Pkg|ude}}}}<br />
<br />
* {{App|[[WindowLab]]|Small and simple window manager of novel design. It has a click-to-focus but not raise-on-focus policy, a window resizing mechanism that allows one or many edges of a window to be changed in one action, and an innovative menubar that shares the same part of the screen as the taskbar. Window titlebars are prevented from going off the edge of the screen by constraining the mouse pointer, and when appropriate the pointer is also constrained to the taskbar/menubar in order to make target menu items easier to hit.|http://nickgravgaard.com/windowlab/|{{Pkg|windowlab}}}}<br />
<br />
* {{App|[[Window Maker]]|X11 window manager originally designed to provide integration support for the GNUstep Desktop Environment. In every way possible, it reproduces the elegant look and feel of the NEXTSTEP user interface. It is fast, feature rich, easy to configure, and easy to use. It is also free software, with contributions being made by programmers from around the world.|http://windowmaker.org/|{{Pkg|windowmaker}}}}<br />
<br />
* {{App|WM2|Window manager for X. It provides an unusual style of window decoration and as little functionality as its author feels comfortable with in a window manager. wm2 is not configurable, except by editing the source and recompiling the code, and is really intended for people who do not particularly want their window manager to be too friendly. |http://www.all-day-breakfast.com/wm2/|{{AUR|wm2}}}}<br />
<br />
* {{App|[[Xfwm]]|The [[Xfce]] window manager manages the placement of application windows on the screen, provides beautiful window decorations, manages workspaces or virtual desktops and natively supports multiscreen mode. It provides its own compositing manager (from the X.Org Composite extension) for true transparency and shadows. The Xfce window manager also includes a keyboard shortcuts editor for user specific commands and basic windows manipulations and provides a preferences dialog for advanced tweaks.|http://www.xfce.org/projects/xfwm4/|{{pkg|xfwm4}}}}<br />
<br />
=== Tiling window managers ===<br />
<br />
* {{App|[[Bspwm]]|bspwm is a tiling window manager that represents windows as the leaves of a full binary tree. It has support for EWMH and multiple monitors, and is configured and controlled through messages.|https://github.com/baskerville/bspwm|{{AUR|bspwm}}}}<br />
<br />
* {{App|dswm|Deep Space Window Manager is an offshoot of [[Stumpwm]].|https://github.com/dss-project/dswm|{{AUR|dswm}}}}<br />
<br />
* {{App|[[Herbstluftwm]]|Manual tiling window manager for X11 using Xlib and Glib. The layout is based on splitting frames into subframes which can be split again or can be filled with windows (similar to i3/ musca). Tags (or workspaces or virtual desktops or …) can be added/removed at runtime. Each tag contains an own layout. Exactly one tag is viewed on each monitor. The tags are monitor independent (similar to xmonad). It is configured at runtime via ipc calls from herbstclient. So the configuration file is just a script which is run on startup. (similar to wmii/musca).|http://herbstluftwm.org|{{AUR|herbstluftwm-git}}}}<br />
<br />
* {{App|[[Ion3]]|Tiling tabbed X11 window manager designed with keyboard users in mind. It was one of the first of the “new wave" of tiling windowing environments (the other being LarsWM, with quite a different approach) and has since spawned an entire category of tiling window managers for X11 – none of which really manage to reproduce the feel and functionality of Ion. It uses Lua as an embedded interpreter which handles all of the configuration. |http://tuomov.iki.fi/software|{{AUR|ion3}}}}<br />
<br />
* {{App|[[Notion]]|Tiling, tabbed window manager for the X window system that utilizes 'tiles' and 'tabbed' windows.<br />
** Tiling: you divide the screen into non-overlapping 'tiles'. Every window occupies one tile, and is maximized to it<br />
** Tabbing: a tile may contain multiple windows - they will be 'tabbed'.<br />
** Static: most tiled window managers are 'dynamic', meaning they automatically resize and move around tiles as windows appear and disappear. Notion, by contrast, does not automatically change the tiling.<br />
: Notion is a fork of Ion3.|http://notion.sf.net/|{{Pkg|notion}}}}<br />
<br />
* {{App|[[Ratpoison]]|Simple Window Manager with no fat library dependencies, no fancy graphics, no window decorations, and no rodent dependence. It is largely modeled after GNU Screen which has done wonders in the virtual terminal market. Ratpoison is configured with a simple text file. The information bar in Ratpoison is somewhat different, as it shows only when needed. It serves as both an application launcher as well as a notification bar. Ratpoison does not include a system tray.|http://www.nongnu.org/ratpoison/|{{Pkg|ratpoison}}}}<br />
<br />
* {{App|[[Stumpwm]]|Tiling, keyboard driven X11 Window Manager written entirely in Common Lisp. Stumpwm attempts to be customizable yet visually minimal. It does have various hooks to attach your personal customizations, and variables to tweak, and can be reconfigured and reloaded while running. There are no window decorations, no icons, no buttons, and no system tray. Its information bar can be set to show constantly or only when needed.|http://www.nongnu.org/stumpwm/|{{AUR|stumpwm-git}}}}<br />
<br />
* {{App|[[subtle]]|Manual tiling window manager with a rather uncommon approach of tiling: Per default there is no typical layout enforcement, windows are placed on a position (gravity) in a custom grid. The user can change the gravity of each window either directly per grabs or with rules defined by tags in the config. It has workspace tags and automatic client tagging, mouse and keyboard control as well as an extendable statusbar. |http://subforge.org/projects/subtle|{{Pkg|subtle}}}}<br />
<br />
* {{App|[[WMFS]]|Window Manager From Scratch is a lightweight and highly configurable tiling window manager for X. It can be configured with a configuration file, supports Xft (FreeType) fonts and is compliant with the Extended Window Manager Hints (EWMH) specifications, Xinerama and Xrandr. WMFS can be driven with Vi based commands (ViWMFS).|https://github.com/xorg62/wmfs|{{AUR|wmfs}}}}<br />
<br />
* {{App|[[WMFS2|WMFS<sup>2</sup>]]|Incompatible successor of WMFS. It's even more minimalistic and brings some new stuff.|https://github.com/xorg62/wmfs|{{AUR|wmfs2-git}}}}<br />
<br />
=== Dynamic window managers ===<br />
<br />
* {{App|[[awesome]]|Highly configurable, next generation framework window manager for X. It is very fast, extensible and licensed under the GNU GPLv2 license. Configured in Lua, it has a system tray, information bar, and launcher built in. There are extensions available to it written in Lua. Awesome uses XCB as opposed to Xlib, which may result in a speed increase. Awesome has other features as well, such as an early replacement for notification-daemon, a right-click menu similar to that of the *box window managers, and many other things. |http://awesome.naquadah.org/|{{Pkg|awesome}}}}<br />
<br />
* {{App|[[catwm]]|Small window manager, even simpler than dwm, written in C. Configuration is done by modifying the config.h file and recompiling.|https://github.com/pyknite/catwm|{{AUR|catwm-git}}}}<br />
<br />
* {{App|[[dwm]]|Dynamic window manager for X. It manages windows in tiled, monocle and floating layouts. All of the layouts can be applied dynamically, optimising the environment for the application in use and the task performed. does not include a tray app or automatic launcher, although dmenu integrates well with it, as they are from the same author. It has no text configuration file. Configuration is done entirely by modifying the C source code, and it must be recompiled and restarted each time it is changed.|http://dwm.suckless.org/|{{Pkg|dwm}}}}<br />
<br />
* {{App|[[echinus]]|Simple and lightweight tiling and floating window manager for X11. Started as a dwm fork with easier configuration, echinus became full-featured re-parenting window manager with EWMH support. It has an EWMH-compatible panel/taskbar, called {{AUR|ourico}}.|http://plhk.ru/echinus|{{AUR|echinus}}}}<br />
<br />
* {{App|euclid-wm|Simple and lightweight tiling and floating window manager for X11, with support for minimizing windows. A text configuration file controls key bindings and settings. It started as a dwm fork with easier configuration, and became a full-featured reparenting window manager with EWMH support. It has an EWMH-compatible panel/taskbar called {{AUR|ourico}}.| http://euclid-wm.sourceforge.net/index.php|{{AUR|euclid-wm}}}}<br />
<br />
* {{App|[[i3]]|Tiling window manager, completely written from scratch. i3 was created because wmii, our favorite window manager at the time, did not provide some features we wanted (multi-monitor done right, for example) had some bugs, did not progress since quite some time and was not easy to hack at all (source code comments/documentation completely lacking). Notable differences are in the areas of multi-monitor support and the tree metaphor. For speed the Plan 9 interface of wmii is not implemented. |http://i3wm.org/|{{Pkg|i3-wm}}}}<br />
<br />
* {{App|[[monsterwm]]|Minimal, lightweight, tiny but monsterous dynamic tiling window manager. It will try to stay as small as possible. Currently under 700 lines with the config file included. It provides a set of four different layout modes (vertical stack, bottom stack, grid and monocle/fullscreen) by default, and has floating mode support. It also features multi-monitor support. Each monitor and virtual desktop have their own properties, unaffected by other monitors' or desktops' settings. Configuration is done entirely by modifying the C source code, and it must be recompiled and restarted each time it is changed. There are many available patches supported upstream, in the form of different git branches.|https://github.com/c00kiemon5ter/monsterwm|{{AUR|monsterwm-git}}}}<br />
<br />
* {{App|[[Musca]]|Simple dynamic window manager for X, with features nicked from ratpoison and dwm. Musca operates as a tiling window manager by default. The user determines how the screen is divided into non-overlapping frames, with no restrictions on layout. Application windows always fill their assigned frame, with the exception of transient windows and popup dialog boxes which float above their parent application at the appropriate size. Once visible, applications do not change frames unless so instructed.|http://aerosuidae.net/musca.html|{{AUR|musca}}}}<br />
<br />
* {{App|[[snapwm]]|Lightweight dynamic tiling window manager with an emphasis on easy configurability and choice. It has a built in bar with clickable workspaces and space for external text. There's five tiling modes: vertical, fullscreen, horizontal, grid and stacking. It has other features, like color support, independent desktops, choice of window placement strategy, reloadable config files, transparency support, dmenu integration, multi monitor support and more. |https://github.com/moetunes/Nextwm|{{AUR|snapwm-git}}}}<br />
<br />
* {{App|[[spectrwm]]|Small dynamic tiling window manager for X11, largely inspired by xmonad and dwm. It tries to stay out of the way so that valuable screen real estate can be used for much more important stuff. It has sane defaults and is configured with a text file. It was written by hackers for hackers and it strives to be small, compact and fast. It has a built-in status bar fed from a user-defined script.|https://opensource.conformal.com/wiki/spectrwm|{{Pkg|spectrwm}}}}<br />
<br />
* {{App|[[Qtile]]|Full-featured, hackable tiling window manager written in Python. Qtile is simple, small, and extensible. It's easy to write your own layouts, widgets, and built-in commands.It is written and configured entirely in Python, which means you can leverage the full power and flexibility of the language to make it fit your needs. |https://github.com/qtile/qtile|{{AUR|qtile-git}}}}<br />
<br />
* {{App|[[Wingo]]|Fully featured true hybrid window manager that supports per-monitor workspaces, and neither the floating or tiling modes are after thoughts. This allows one to have tiling on one workspace while floating on the other. Wingo can be scripted with its own command language, is completely themeable, and supports user defined hooks. Wingo is written in Go and has no runtime dependencies. |https://github.com/BurntSushi/wingo|{{AUR|wingo-git}}}}<br />
<br />
* {{App|[[wmii]]|Small, dynamic window manager for X11. It is scriptable, has a 9P filesystem interface and supports classic and tiling (Acme-like) window management. It aims to maintain a small and clean (read hackable and beautiful) codebase. The default configuration is in bash and [http://rc.cat-v.org rc (the Plan 9 shell)], but programs exist written in ruby, and any program that can work with text can configure it. It has a status bar and launcher built in, and also an optional system tray ({{ic|witray}}). |http://wmii.suckless.org/|{{Pkg|wmii}}}}<br />
<br />
* {{App|[[xmonad]]|Dynamically tiling X11 window manager that is written and configured in Haskell. In a normal WM, you spend half your time aligning and searching for windows. Xmonad makes work easier, by automating this. XMonad is configured in Haskell. For all configuration changes, xmonad must be recompiled, so the Haskell compiler (over 100MB) must be installed. A large library called {{Pkg|xmonad-contrib}} provides many additional features|http://xmonad.org/|{{Pkg|xmonad}}}}<br />
<br />
== See also ==<br />
<br />
* http://www.gilesorr.com/wm/</div>Skwuenthttps://wiki.archlinux.org/index.php?title=Multihead&diff=311583Multihead2014-04-23T17:25:54Z<p>Skwuent: /* Window managers */ Updated date since XMonad still works as described</p>
<hr />
<div>[[Category:X Server]]<br />
{{Related articles start}}<br />
{{Related|Xorg}}<br />
{{Related|xrandr}}<br />
{{Related|NVIDIA#Multiple monitors}}<br />
{{Related|Nouveau#Dual Head}}<br />
{{Related|AMD Catalyst#Double Screen (Dual Head / Dual Screen / Xinerama)}}<br />
{{Related|ATI#Dual Head setup}}<br />
{{Related articles end}}<br />
<br />
'''Multi-head''', '''multi-screen''', '''multi-display''' or '''multi-monitor''' represent a setup when multiple display devices are attached to a computer. This article provides general description of multiple multi-head setup methods, and provides some examples of configuration.<br />
<br />
{{Note|The terms used in this article are very specific to avoid confusion:<br />
* '''Monitor''' refers to a physical display device, such as an LCD panel.<br />
* '''Screen''' refers to an X-Window screen (that is: a '''monitor''' attached to a '''display''').<br />
* '''Display''' refers to a collection of '''screens''' that are in use at the same time showing parts of a single desktop (you can drag windows among all '''screens''' in a single '''display''').<br />
}}<br />
<br />
== Historical background ==<br />
<br />
X Window System is the underlying graphical interface of most if not all Unix/Linux computers providing a GUI. It was developed in 1984 at MIT. After about 35 years of development, tweaking and adding of new features and ideas, it is generally acknowledged to be a bit of a beast. It should be remembered that the common configuration at time of development was a single running X providing individual views to Xterminals in a [[Wikipedia:Time-sharing|time-sharing]] system. Nowadays the standard is X providing a single screen on a desktop or laptop.<br />
<br />
{{Note|There is still a rare configuration often called [[Wikipedia:Multiseat configuration|Zaphod display]], which allows multiple users of a single computer to each have an independent set of display, mouse, and keyboard, as though they were using separate computers, but at a lower per-seat cost.}}<br />
<br />
All of this means that there are many ways of achieving the same thing and many slightly different things that can meet the same purpose. In modern X versions sometimes you can get away with limited or no configuration. In the last few years the boast is that X is self configuring. Certainly the best practice rule of thumb is less configuration is better - that is ''only configure what is wrong''.<br />
<br />
== Separate screens ==<br />
<br />
This is the original way of configuring multiple monitors with X, and it has been around for decades. Each physical monitor is assigned as an X screen, and while you can move the mouse between them, they are more or less independent.<br />
<br />
Normally the X display has a single identifier such as {{ic|:0}} set in the {{ic|DISPLAY}} environment variable, but in this configuration each screen has a different {{ic|$DISPLAY}} value. The first screen is {{ic|:0.0}}, the second is {{ic|:0.1}} and so on.<br />
<br />
With this configuration it is not possible to move windows between screens, apart from a few special programs like GIMP and Emacs which have multi-screen support. For most programs you must change the {{ic|DISPLAY}} environment variable when launching to have the program appear on another screen:<br />
<br />
# Launch a terminal on the second screen<br />
$ DISPLAY=:0.1 urxvt &<br />
<br />
Alternatively if you have a terminal on each screen launching programs will inherit the {{ic|DISPLAY}} value and appear on the same screen they were launched on. But moving an application between screens involves closing it and reopening it again on the other screen.<br />
<br />
Working this way does have certain advantages, such as windows popping up on one screen won't steal the focus away from you if you are working on another screen - each screen is quite independent.<br />
<br />
== Xinerama ==<br />
{{Warning|1=As of August 2013, Xinerama is broken when using the proprietary NVIDIA driver from 319 upwards. Users wishing to use Xinerama with the NVIDIA driver should use the NVIDIA 313 driver, which works only with Linux kernels earlier than 3.10. See [https://bbs.archlinux.org/viewtopic.php?id=163319 this thread] for more information.}}<br />
<br />
[[Wikipedia:Xinerama|Xinerama]] is the old way of doing genuine multihead X. Xinerama combines all monitors into a single screen ({{ic|:0}}) making it possible to drag windows between screens.<br />
<br />
Xinerama is configured via custom [[Xorg#Configuration|X configuration files]]. Here are some examples:<br />
<br />
This is a ServerLayout section which controls where each monitor sits relative to the others.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/90-serverlayout.conf|<br />
Section "ServerLayout"<br />
Identifier "Main"<br />
Screen 0 "Primary"<br />
Screen 1 "DellPortraitLeft" RightOf "Primary"<br />
Screen 2 "Wacom" RightOf "DellPortraitLeft"<br />
Screen 3 "U2412" LeftOf "Primary"<br />
Option "Xinerama" "1" # enable XINERAMA extension. Default is disabled.<br />
EndSection<br />
}}<br />
<br />
Each Screen in the above section is defined in a separate file, such as this one:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/30-screen-dell2001.conf|<br />
# Define the monitor's physical specs<br />
Section "Monitor"<br />
Identifier "Dell 2001FP"<br />
VertRefresh 60<br />
Option "dpms" "on"<br />
<br />
# Modelines are probably unnecessary these days, but it does give you fine grained control<br />
<br />
# 1600x1200 @ 60.00 Hz (GTF) hsync: 74.52 kHz; pclk: 160.96 MHz<br />
Modeline "1600x1200" 160.96 1600 1704 1880 2160 1200 1201 1204 1242 -HSync +Vsync<br />
EndSection<br />
<br />
# Define a screen that uses the above monitor. Note the Monitor value matches the above<br />
# Identifier value, and the Device value matches one of the video cards defined below<br />
# (the card and connector this monitor is actually plugged in to.)<br />
Section "Screen"<br />
Identifier "DellPortraitLeft"<br />
Device "GeForce 8600GTb"<br />
Monitor "Dell 2001FP"<br />
DefaultDepth 24<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1600x1200"<br />
ViewPort 0 0<br />
Virtual 1600 1200<br />
EndSubsection<br />
<br />
# This screen is in portrait mode<br />
Option "Rotate" "left"<br />
EndSection<br />
}}<br />
<br />
You will need to create a {{ic|Device}} section for each '''monitor''', i.e. a dual head video card will have two Device sections. The following example shows how to configure two video cards each providing two outputs, for a total of four monitors.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-nvidia.conf|<br />
# First head of first video card in the system<br />
Section "Device"<br />
Identifier "GeForce 8600GT"<br />
Driver "nvidia"<br />
<br />
# If you have multiple video cards, the BusID controls which one this definition refers<br />
# to. You can omit it if you only have one card.<br />
BusID "PCI:1:0:0"<br />
<br />
# Need to flag this as only referring to one output on the card<br />
Screen 0<br />
<br />
# For nVidia devices, this controls which connector the monitor is connected to.<br />
Option "UseDisplayDevice" "DFP-0"<br />
<br />
# We want control!<br />
Option "DynamicTwinView" "FALSE"<br />
<br />
# Various performance and configuration options<br />
Option "AddARGBGLXVisuals" "true"<br />
Option "UseEDIDDpi" "false"<br />
Option "DPI" "96 x 96"<br />
Option "Coolbits" "1"<br />
EndSection<br />
<br />
# Second head of same video card (note different Identifier but same BusID.) We can omit<br />
# the UseDisplayDevice option this time as it will pick whichever one is remaining.<br />
Section "Device"<br />
Identifier "GeForce 8600GTb"<br />
Driver "nvidia"<br />
BusID "PCI:1:0:0"<br />
# This is the second output on this card<br />
Screen 1<br />
<br />
# Same config options for all cards<br />
Option "AddARGBGLXVisuals" "true"<br />
Option "UseEDIDDpi" "false"<br />
Option "DPI" "96 x 96"<br />
Option "Coolbits" "1"<br />
Option "DynamicTwinView" "FALSE"<br />
EndSection<br />
<br />
# First head of second video card, note different BusID.<br />
Section "Device"<br />
Identifier "G210"<br />
Driver "nvidia"<br />
BusID "PCI:2:0:0"<br />
Screen 0<br />
<br />
# Same config options for all cards<br />
Option "AddARGBGLXVisuals" "true"<br />
Option "UseEDIDDpi" "false"<br />
Option "DPI" "96 x 96"<br />
Option "Coolbits" "1"<br />
Option "DynamicTwinView" "FALSE"<br />
EndSection<br />
<br />
# Second head of second video card. Output connector is set here, which means the previous<br />
# Device will use the other connector, whatever it may be.<br />
Section "Device"<br />
Identifier "G210b"<br />
Driver "nvidia"<br />
BusID "PCI:2:0:0"<br />
Screen 1<br />
Option "UseDisplayDevice" "DFP-1"<br />
<br />
# Same config options for all cards<br />
Option "AddARGBGLXVisuals" "true"<br />
Option "UseEDIDDpi" "false"<br />
Option "DPI" "96 x 96"<br />
Option "Coolbits" "1"<br />
Option "DynamicTwinView" "FALSE"<br />
EndSection<br />
}}<br />
<br />
== TwinView ==<br />
<br />
TwinView is nVidia's extension which makes two monitors attached to a video card appear as a single screen. TwinView provides Xinerama extensions so that applications are aware there are two monitors connected, and thus it is incompatible with Xinerama. However if you only have two monitors and they are both connected to the same nVidia card, there is little difference between TwinView and Xinerama (although in this situation TwinView may offer slightly better performance.)<br />
<br />
If you wish to attach more than two monitors or monitors attached to other video cards, you will need to use Xinerama instead of TwinView. Likewise as of April 2012, both monitors must be in the same orientation - you cannot have one in landscape and the other in portrait mode.<br />
<br />
In the past, TwinView was the only way to get OpenGL acceleration with nVidia cards while being able to drag windows between screens. However modern versions of the nVidia closed-source driver are able to provide OpenGL acceleration even when using Xinerama.<br />
<br />
See [[NVIDIA#TwinView]] for an example configuration.<br />
<br />
== RandR ==<br />
<br />
[[Wikipedia:RandR|RandR]] ('''R'''otate '''and''' '''R'''esize) is an [[Wikipedia:X Window System|X Window System]] extension, which allows clients to dynamically change (e.g. resize, rotate, reflect) screens. In most cases, it can fully replace the old Xinerama setup. See [http://i3wm.org/docs/multi-monitor.html#_the_explanation an explanation] why RandR is better than Xinerama.<br />
<br />
RandR can be configured via the [[xrandr]] tool or an [[Xorg#Configuration|xorg.conf]] file.<br />
<br />
{{Note|There are multiple ways to configure the same thing, you might have to experiment a little before you find the best configuration.}}<br />
<br />
=== Configuration using xrandr ===<br />
<br />
{{Note|This section assumes that you have read the [[xrandr]] page for basic info about ''xrandr''.}}<br />
<br />
You may arrange your screens either relatively to each other (using the {{ic|--right-of}}, {{ic|--left-of}}, {{ic|--above}}, {{ic|--below}} options), or by absolute coordinates (using the {{ic|--pos}} option; note that in this case you usually need to know resolutions of your monitors). See {{ic|man xrandr}} for details. Some frequently used settings are described below.<br />
<br />
==== VGA1 left of HDMI1 at their preferred resolutions ====<br />
<br />
$ xrandr --output VGA1 --auto --output HDMI1 --auto --right-of VGA1<br />
<br />
{{ic|--right-of}} places the previous screen ({{ic|HDMI1}}) to the right of the specified screen ({{ic|VGA1}}).<br />
<br />
==== VGA1 right of HDMI1 at fixed resolutions ====<br />
<br />
$ xrandr --output VGA1 --mode 1024x768 --pos 1920x0 --output HDMI1 --mode 1920x1080 --pos 0x0<br />
<br />
or<br />
<br />
$ xrandr --output VGA1 --mode 1024x768 --output HDMI1 --mode 1920x1080 --left-of VGA1<br />
<br />
{{ic|--left-of}} places the previous screen ({{ic|HDMI1}}) to the left of the specified screen ({{ic|VGA1}}).<br />
<br />
=== Configuration using xorg.conf ===<br />
<br />
This is similar to using ''xrandr'', separate {{ic|Monitor}} section is needed for each screen. As an {{ic|Identifier}}, the same value as reported by {{ic|xrandr -q}} is used (i.e. {{ic|Identifier "VGA1"}} is used instead of {{ic|--output VGA1}}).<br />
<br />
The examples below are self-explanatory:<br />
<br />
==== Example: dualhead configuration using relative coordinates ====<br />
<br />
{{hc|/etc/X11/xorg.conf|<br />
Section "Monitor"<br />
Identifier "VGA1"<br />
Option "Primary" "true"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "HDMI1"<br />
Option "RightOf" "VGA1"<br />
EndSection<br />
}}<br />
<br />
==== Example: dualhead configuration using absolute coordinates ====<br />
<br />
{{hc|/etc/X11/xorg.conf|<br />
Section "Monitor"<br />
Identifier "VGA1"<br />
Option "PreferredMode" "1024x768"<br />
Option "Position" "1920 0"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "HDMI1"<br />
Option "PreferredMode" "1920x1080"<br />
Option "Position" "0 0"<br />
EndSection<br />
}}<br />
<br />
== Application support ==<br />
<br />
{{Out of date|This section contains outdated information, mostly specific to Xinerama.}}<br />
<br />
This section lists tips for individual applications.<br />
<br />
* mplayer: use {{ic|-xineramascreen 1}} to make the video play on screen #1 (the second screen.) Add {{ic|1=xineramascreen=1}} to {{ic|~/.mplayer/config}} to make permanent.<br />
* Xonotic: if you are playing across multiple screens and you are unable to turn left/right properly, set {{ic|vid_stick_mouse}} to 1 in {{ic|~/.xonotic/data/config.cfg}}<br />
<br />
=== Window managers ===<br />
<br />
This section lists window managers and how they cope with multiple monitors.<br />
<br />
* [[Awesome]] - Works<br />
* [[FVWM]] - Works. Has support for Xinerama and multi-screen display, such as Single Logical Screen. <br />
* [[KDE]] - Works<br />
* [[MATE]] - Works<br />
* [[i3]] - Works<br />
* [[XMonad]] - Works (screens are different workspaces, both accessible and switching is possible by both keyboard and mouse) - as of April 2014<br />
<br />
=== Display managers ===<br />
<br />
* [[GDM]]: gdm is not configured by gnome display settings, resulting in the login screen not being displayed on the primary monitor. A workaround is explained [https://bbs.archlinux.org/viewtopic.php?pid=1262282#p1262282 here]. It just consists in copying the user monitor configuration file to gdm's.<br />
<br />
=== Full screen games ===<br />
<br />
Many games require their window to appear at (0,0) when running in full-screen. If the screen you have at (0,0) - the left-most one - is not one you wish to game on, it is almost impossible to move a full-screen game onto a different screen.<br />
<br />
A workaround for this is to create a separate X11 configuration (a new '''layout''') just for playing games, which may have less (or only one) screen configured. You can then launch games using this separate layout, while normal desktop work uses the original multihead configuration.<br />
<br />
To create a new layout, copy {{ic|/etc/X11/xorg.d/90-serverlayout.conf}} and call it {{ic|91-serverlayout-gaming.conf}}. It is important to use a number larger than 90, as the one with the lowest number will become the default used when you first load X.<br />
<br />
Adjust this new configuration file to your preferred gaming configuration. Here is an example (based on the example Xinerama configuration above) with only one screen defined, noting that the screen specifics (such as resolution) are defined in other files and are unchanged from and shared with the normal configuration:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/91-serverlayout-gaming.conf|<br />
# New screen layout only using a single screen called "Primary"<br />
Section "ServerLayout"<br />
Identifier "Gaming"<br />
Screen 0 "Primary" Absolute 0 0<br />
EndSection<br />
}}<br />
<br />
{{Tip|While it's easiest to just reuse the existing screen definitions, you can of course define new ones if you wish to have a different set of screen resolutions available.}}<br />
<br />
To use this new layout, launch the game via the {{ic|startx}} script:<br />
<br />
# Launch Xonotic on a new X11 display using the "Gaming" layout<br />
startx /usr/bin/xonotic-glx -fullscreen -- :1 -layout Gaming<br />
<br />
Note that:<br />
* You must specify the full path to the command to run, here {{ic|/usr/bin/xonotic-glx}}.<br />
* The {{ic|:1}} must refer to an empty unused display. The first display you are likely using for your desktop is {{ic|:0}}, so {{ic|:1}} will be fine for most people. But should you want to launch a second game at the same time, you would have to change this to {{ic|:2}}.<br />
* Just as you can switch between text consoles with Alt+Ctrl+F1 and back to X with Alt+Ctrl+F7, the new display will sit on Alt+Ctrl+F8. So you can switch back to your desktop with Alt+Ctrl+F7 and back to the game with Alt+Ctrl+F8. This is because you are running an independent X desktop, so if you switch out of the game with Alt+Tab or equivalent there will be an empty desktop with no window manager running.<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=652861 'How I got Dual Monitors with Nouveau Driver' forums thread]</div>Skwuent