Extreme Multihead

From ArchWiki

Related articles

Merge-arrows-2.pngThis article or section is a candidate for merging with Multihead.Merge-arrows-2.png

Notes: only a specific case of Multihead. (Discuss in Talk:Extreme_Multihead#Multihead_Consolidation)

Several monitors can be attached to a single computer system. Many years ago this was only possible by installing two or more video cards in a computer. Then some high-end video cards began appearing with outputs for two monitors. Nowadays, most laptops come with a main display and a socket for an external monitor while the integrated video cards on desktop systems provide VGA + DVI + HDMI outputs as standard. If you plug in multiple monitors to whatever video sockets you have available, they will more often than not "just work" - offering two or more versions of the same display. In some cases this is exactly what is required; allowing the same desktop to be viewed from different directions.

It is also possible to have these multiple monitors work together as an extended single desktop. It is even possible to join the displays from several computers - each with single or multiple monitors - into one very large extended desktop.

This document describes how to configure such a system.

Experimenting with multiple monitors

The easiest way to begin experimenting with multiple monitors is start with a system which has a working X set-up supporting a single monitor. If you already have the additional equipment installed

  • a video card with multiple video outputs or multiple video cards
  • monitors plugged into each of the video outputs

When everything is on you should see the same output on each monitor. The desktop is "cloned" on to the secondary monitors. If all the monitors are not exactly the same shape or support different resolutions you may only see portions of the main desktop display.

The best tool to experiment with configuring your monitors to display as you want is xrandr. This may already installed as part of your Xorg installation from either the xorg or xorg-apps groups.

Use xrandr to experiment with different configurations until you arrive at settings you want to make permanent. The DualScreen and xrandr pages, the man page and various locations on the web provide more information on using the tool.

For example, the following command configures my dual monitor set-up: 

$ xrandr --output VGA-1 --rotate left --output VGA-1 --pos 0x0 --output DVI-0 --rotate left  --output DVI-0 --pos 1080x0

I have two monitor devices with the logical names VGA-1 and DVI-0. These names can be determined using the command xrandr -q or even searching through the X.org log-file /var/log/Xorg.0.log. Both monitors are identical (with a resolution of 1920x1080) and can rotate or pivot from a landscape to a portrait orientation.

  1. VGA-1 is rotated 90 counter-clockwise from landscape to portrait --output VGA-1 --rotate left
  2. VGA-1 is the main display, the position of other monitors will be measured relative to its top, left corner --output VGA-1 --pos 0x0
  3. DVI-0 is also rotated --output DVI-0 --rotate left
  4. DVI-0 sits immediately to the right of VGA-1 --output DVI-0 --pos 1080x0

If you have not done so already, create a simple batch script containing your desired xrandr command. Save it somewhere useful; /usr/local/bin perhaps. Your system can then be configured to call this script as you login to your account as your window manager starts. There are different locations for saving initialisation commands and indeed some Settings tools can add these commands in place for you.

Loading configuration at X start

Add the command to either to individual or system xinitrc scripts. Add a line after the window manager has been started but before any applications are called. Execution of the command is usually quite noticeable as the monitors change from the basic cloned, landscape display to the independent portrait mode.

Note: This will only work if X is started manually, not from a display manager such as gdm, sddm, slim or whatever.
  • system-wide initialisation file is /etc/X11/xinit/xinitrc
  • a user's personal initialisation file is ~/.xinitrc

Make settings the default

Now you have your regular desktop spanning multiple monitors, it would be better if

  • the irritating flicker as the monitors change did not happen as you login
  • the login manager was also set to span multiple monitors; this is especially irritating if your monitors are rotated, like mine, so you have to turn your head 90 as you login

All that has to be done is to create an Xorg configuration file that serves the same purpose as the xrandr command; easy now we know what the configuration should be.

We need to create two files:

  • 05-device.conf to specify how the monitor configuration can be found for the video device
  • 10-monitor to specify the actual configuration of the monitors

These configuration files, and others you may need to manage your keyboard, mouse and other devices have a multitude of options available described in Multihead and Xorg documentation; the examples below are offered to illustrate a particular solution.

Note: Since Xorg moved away from a monolithic configuration file that required every option to be spelled out to the lighter multiple configuration files only over-riding a default configuration, you only need to be concerned with specifying the exact changes you want; do not simply copy from these examples

05-device.conf

This is used to reference the individual monitor configurations by naming the devices. This configuration files should be loaded before the monitor file and so has a lower number ""05"" 

Section "Device"
    Identifier "radeon"
    Driver "ati"
    Option "monitor-VGA-1" "VGA"
    Option "monitor-DVI-0" "DVI"
EndSection

The Identifier should match the actual video device; check /var/log/Xorg.0.log to confirm this. Similarly, Driver corresponds to the driver. Then we reference the two monitors by name pointing to relevant sections in the 10-monitor.conf file

  • monitor-VGA-1 specifies the name that Xorg will detect the monitors as; the same names the xrandr -q reported to us; the name is prefixed with "monitor-"
  • VGA specifies the identifier we will use to refer to this monitor

Essentially we are specifying a relationship between the actual device and its configuration.

10-monitor.conf

This file then specifies how we want the monitors to be configured. The file name is not important other than ensuring to is loaded after the device file. The important elements are the Section name and its Identifier: 

Section "Monitor"
    Identifier "VGA"
    Option "Rotate" "Left"
EndSection

Section "Monitor"
    Identifier "DVI"
    Option "Rotate" "Left"
    Option "RightOf " "VGA"
EndSection
  • Option "Rotate" "Left" rotates each monitor counter-clockwise 90
  • Option "RightOf" VGA places the monitor identified as DVI to the right of the monitor whose Identifier is VGA. Other possibilities include "LeftOf", "Above" and "Below"

With these configuration files in place and all references to xrandr removes, the display manager can be restarted and

  1. the display manager should start with all monitors correctly placed and oriented
  2. user login will no longer flash as xrandr executes

When you login, some window managers may attempt to reset this configuration with the result that your logged-in desktop has reverted to a pair of cloned displays and in some cases a panel stretching to a now, non-existent monitor. The 4.10 & 4.11 versions of XFCE4 will do this. This bad behaviour can usually be resolved by configuring your monitor set-up using the window manager tools and configuration files. For XFCE4, this is explained in Xfce#Multiple monitors

Extending a desktop beyond the local system

The previous section outlined how to access other systems usually not close to your desktop. This section examines how to access systems which are very close to your desktop in such a way that it appears your desktop has been extended still further to incorporate these additional monitors. There are two possibilities

  • synergy this tool allows your keyboard and mouse to access remote systems by making your desktop seem to extend onto the remote desktop. Simply by moving your mouse off the edge of your desktop it will appear on a remote system where both mouse and keyboard can interact with the remote systems GUI (i.e. synergy can connect Macs and Windows systems too). Windows cannot be dragged across system boundaries and indeed applications launched through a remote systems GUI, run on the remote system. For an integrated Linux desktop, disk shares also need to be set-up
  • Xdmx a proxy server for X allows the X server on remote systems to contribute its monitor to the desktop of a master system. In this case the destop is genuinely extending onto remote systems; windows can be dragged across system boundaries and applications launched from a remote monitor run on the local, master system. In this environment, the remote systems need only provide sufficient resources to run an X session.

Sharing mouse and keyboard

Using a tool called Synergy it is possible for a single keyboard and mouse to access several systems as though all their monitors were a single desktop.

quicksynergyAUR provides a convenient wrapper for the application.

Alternatively, there is barrier, a fork of Synergy.

Xdmx

Xdmx is a proxy server for X. Using it, the monitors from any number of systems can be consolidated into a single desktop or constructed as a wall of monitors.

To establish an Xdmx desktop involves the following steps automated so that the construction appears transparent:

  1. on each system configure and initiate a minimal X session; a minimal twm session is enough
  2. authorise the master system to access X resources on each remote system (use xhost +)
  3. install xorg-server-xdmx-devAUR on the master system
  4. initiate a minimal X session on the master system
  5. configure the desired Xdmx session
  6. initiate the Xdmx session with an appropriate window manager as a working desktop

At present either Xdmx itself or the current state of window managers do not work well together for complex arrangements of multihead set-ups; the server tends to crash as soon as window drawing is required after the integrated desktop has been established.

VNC

Using X11vnc, TigerVNC and Xrandr it is possible to create and share virtual monitors for display on the local network.

To create a virtual screen of resolution HxW and refersh rate or X Hz one needs to create a "modeline", i.e. using the gtf utility {{cl| 

gtf 1280 800 120
 # 1280x800 @ 120.00 Hz (GTF) hsync: 102.96 kHz; pclk: 181.21 MHz
 Modeline "1280x800_120.00"  181.21  1280 1376 1520 1760  800 801 804 858  -HSync +Vsync

will create the modeline for a screen of 1280x800 pixels with a refresh rate of 120Hz. Using a high refresh rate can improve the responsiveness over a sufficiently fast network.

This modeline can be configured with xrandr using the command 

xrandr --newmode "1280x800_120.00"  "181.21  1280 1376 1520 1760  800 801 804 858  -HSync +Vsync

The mode can then be assigned to an output and activated using two commands 

xrandr --addmode OUTPUT "1280x800_120.00"
xrandr --output OUTPUT --mode  "1280x800_120.00" --right-of MAIN_SCREEN --auto

MAIN_SCREEN is the main screen, it can be calle eDP-1 or eDP1 depending on the driver, it is usually easy to identify using xrandr as it is listed first and has a lot of modelines.

OUTPUT can be a virtual (recommended if possible) or real output accepted by the xog driver. There are three possible scenarios:

Using a virtual output

Some drivers, like the old "intel" driver, support virtual displays. In this case, create at-least one virtual display in xorg 

/etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
    Identifier "intelgpu0"
    Driver "intel"
    Option "VirtualHeads" "1"
EndSection

The name of the output will normally be VIRTUAL1 (you can check with xrandr without any argument). The virtual display can then be activated using. 

$ xrandr --output VIRTUAL1 --mode<resolution>

Using an HDMI output

Most drivers these days, including the nVidia proprietary driver and the new Intel recommended "modesetting" driver do not support virtual outputs. In this case it is normally possible to use a free HDMI output (i.e. HDMI-1 or HDMI-2). This will mostly work, you will be able to move windows to the virtual screen and export it with VNC.

Some userspace programs (notably KDE, LibreOffice Impress, Zoom) do not recognize the screen properly and will not work in "dual screen mode" or may cause some glitches. You can work around this problem by forcing the HDMI output to be enabled, via the /sys/debug interface by running: 

# echo on > /sys/kernel/debug/dri/0/OUTPUT/force

where OUTPUT can be HDMI-A-1, or HDMI-A-2, or other, depending on which output you are using. Note that the name is different from that used by xrandr. This may also enable the audio output of the HDMI port, redirecting your system audio to the fake output. In this case, you may want to revert to the previous audio output.

Using the EVDI driver

In the exceptional case where there is no spare HDMI output, one can abuse the evdi to create more outputs as explained here. Note that at the moment, this method has the same drawbacks as using an HDMI output, i.e. the output will not appear as "connected" and may not be properly recognized and used by some applications.

Using the xorg dummy driver

xorgs ships with a dummy driver which is designed to be used for headless servers that export a graphical interface via VNC. It is in principle possible to set up a dummy device alongside a real device by adding a dummy device and xinerama configuration to xorg. It is tricky to have this configuration working properly, and it is not ideal for laptops, as you will not be able to hotplug monitors).

Sharing the screen

To share the display using X11vnc, one can specify explicitly the screen area to share: 

$ x11vnc -display :0 -clip <resolution>+<offset>

or tell x11vnc to share the second (or third..) screen 

$ x11vnc -display :0 -clip xinerama1

This vnc instance can then be displayed on the remote machine by running 

$ vncviewer -shared -ViewOnly -Fullscreen <host ip>

While functional, this can suffer from poor performance over low-bandwidth connections.

If the external screen is an Android device, one can use a USB cable to get better bandwidth. After pluggin the cable and activating USB debug mode in Android, one can setup a network socket via USB using the adb tool:

enable the USB connection 

adb usb

verify that it is up 

adb devices|grep "device$"

setup the socket 

 adb reverse tcp:5900 tcp:5900

Then you will be able to connect to localhost:5900

Useful x11vnc options

Some options x11vnc can be very effective at reducing the perceived lag or fixing small annoyances:

  • -repeat: to prevent x11vnc to disable automatic keystroke repetition.
  • -forever: by default, x11vnc accepts a single remote connection and quits when the remote client disconnects. This can actually be the desired behavior in a script, but you can use this option to make it stay up
  • -xdamage -xd_area 1024 -xd_mem 1.5 x11vnc uses the X11 "damage" extension, which alerts it of the part of the screen which have been modified. Unfortunately, most applications do not implement it properly, and may indicate very large areas, or even the entire window, as modified at every keystroke. This option will tell x11vnc to not trust the damage information when it covers an area larger than 1024 pixels (i.e. 32x32)
  • -nonap when there is no input and no screen change, x11vnc will stop monitoring the screen for longer and longer periods of time, which means that if you take a minute reading a document it will take several seconds before it wakes up. If you find this annoying, you can use this option.

Mouse pointer options. In order to reduce lag, vnc cients draw the mouse cursor on their own and only transmit the cursor position to the server (this can make the cursor look ugly if it has transparencies).

  • -nocursorpos: per default, x11vnc keeps the cursor position synchronized on all server and the client. I.e. you can move the mouse on the PC to move the cursor in the virtual screen. If you use this option, it will only be possible to move the cursor on the virtual screen by acting on the vnc client, i.e. by touch if it is a tablet.
  • -multiptr tell x11vnc that the client will use its own mouse cursor. In practice, you will have two pointers: one that is controlled with the mouse from the main PC, the other that is controlled by touch or a mouse on the client. This can be intuitive or confusing. If used in conjunction with -nocursorpos, you will only be able to use the local mouse on the local screen and the remote mouse (or touch) on the vnc screen.
  • -noxfixes: tell x11vnc to not send the cursor image to the client. Useful if it looks very ugly or if you only use touch and would rather have no cursor image at all.