tags: Linux

Xdmx is, according to the man page, a "Distributed Multi-head X server. ... Xdmx is a proxy X server that uses one or more other X servers as its display devices. It provides multi-head X functionality for displays that might be located on different machines." What this means: you can turn another computer (it has to have a monitor) into a another monitor for your first computer.

I really wanted it back in 2000, when monitors were still both expensive and small, and setting up dual head on Linux was nightmarish at best. These days, I have a large 4K monitor on my desk run by my laptop - but I switch off the laptop screen because I already have plenty screen real estate, so Xdmx's time has passed. And yet I kept coming back to it to see if I could make it work. It never did work ... until the last couple weeks. I noticed that Fedora 31 has an Xdmx package - they're fairly good about maintaining build quality so maybe it would be functional. My doubt stems from Debian for years shipping an Xdmx package that had apparently built properly ... but segfaulted on start. So clearly almost no one was using it and they got no bug reporting. I was using Debian in those years, which is probably part of why I never got Xdmx working previous to this.

Not sure why anyone would want to use this at this point - unless you have a strong urge to turn a really old laptop into a spare screen. But even then, it has to be a good enough computer to run a current version of Linux. And if it can do that, is this the best fate for it?

The Steps:

This didn't work the first time (different set of machines - still both Fedora 31) so I can't promise you it'll work for you. It's a finicky beast. See "Failure Mode(s)" below.

  • install Xdmx on both machines: I'd recommend matched OSes and versions
  • I used two computers: the one that's going to act as a secondary screen I'll call "slave," and the one in charge, where I use the mouse and keyboard, I'll call "master"
  • place "slave" to the right of "master"
  • log in to X on both machines (preferably, but not essentially, using the same window manager or desktop environment on both)
  • this is a secured version of how to do this: Xdmx uses port 6000, the standard X port, but opening that port to the network is Double Plus Ungood so we'll use SSH port forwarding and NOT punch a hole in the firewall
  • install a ~/.xinitrc on "master" - if you don't have a ~/.xinitrc you may get an X session without a window manager - and that's bad news (although it can still prove Xdmx works as you should have a pointer you can slide from screen to screen ... but there's no good way to exit without a WM)
  • ASIDE: the ~/.xinitrc used to be a required part of having a graphical environment on Linux ... and now no one knows what it is. No great loss. But a small explanation: if you were starting X from the text-based command line ("the way it used to be"), this was the file that told X how to make things happen
  • example simple ~/.xinitrc:
exec /usr/bin/openbox
  • make sure the called executable is a valid one - ie. if you use this example, you need to have Openbox installed
  • install sshd on master and turn it on (as root systemctl start sshd)
  • I had mixed X sessions in the end: Openbox on slave, KDE on master, final WM was Openbox across both (run on/from master)
  • on the slave open an ssh connection to master: ssh -X master.lan
  • in this SSH connection run:
$ export | grep DISP
declare -x DISPLAY="localhost:10.0"
  • the response you see above is the USUAL value, but not guaranteed: change it in the next line if needed
  • still in the SSH connection, run on master:
$ startx -- /usr/bin/Xdmx :1 +xinerama -display:0.0 -display localhost:10.0 -norender -noglproxy

What follows is debugging information and problems which may not interest you if the above line started Xdmx as you'd hoped.

Failure Mode(s)

  • I've tried Xdmx many times over many years. It's never worked before - I suspect in part because Debian was shipping a bad build for at least a couple years. Another problem I've seen more than once, including when I was experimenting with two Fedora 31 machines, is this error:

    (II) dmx: 2 devices:
    (II) dmx:   Id  Name                 Classes
    (II) dmx:    6  Mouse0               val btn fb/ptr     [i0/:0.0/id2=Virtual core pointer] core
    (II) dmx:    7  Keyboard0            key foc fb/kbd     [i0/:0.0/id3=Virtual core keyboard] core
    (II) dmx: ===== End of Summary =====
    xinit: XFree86_VT property unexpectedly has 0 items instead of 1
    xinit: connection to X server lost
    waiting for X server to shut down
    Couldn't get a file descriptor referring to the console
    • (the unique bit here is "XFree86_VT property unexpectedly has 0 items instead of 1")
    • Google searching wasn't helpful: the error shows up, but in other contexts without clear solutions
    • In fact, this turned out to be solvable: on closer examination, I found that I had an invalid ~/.xinitrc on the master - well, technically it's valid, but useless, because there were several commented-out lines AND NO VALID WINDOW MANAGER. I added exec /usr/bin/openbox to the file, and Xdmx started. Not entirely correctly: I've found another failure mode, in which the master keyboard wasn't typing anything. But I worked this one out too: I was using Synergy between the same two machines, and once I disabled Synergy and tried Xdmx again, it worked fine. (This should be obvious: don't have multiple processes fighting to control the behaviour of X.)
  • the value of the $DISPLAY variable actually changes - even on the same two machines, from one run to the next - and if you don't keep track of the changes and change it on your command line, you get more weird failures

  • if you leave a process running from a previous run, Xdmx will fail ugly on the next run

  • on one master, Openbox had a default "Terminals" menu, which showed: "LXTerminal", "XTerm", and "Konsole"
    • the first two did nothing, but "Konsole" worked
    • both the other two are installed on master and work fine when not using Xdmx
    • running them from Konsole shows:
    $ xterm &
    X Error of failed request:  BadAlloc (insufficient resources for operation)
      Major opcode of failed request:  45 (X_OpenFont)
      Serial number of failed request:  24
      Current serial number in output stream:  25
    [1]+  Exit 1                  xterm
    $ lxterminal &
    (lxterminal:30027): Gtk-WARNING **: 15:46:01.366: Theme parsing error: colors.css:71:44: Invalid number for color value
    (lxterminal:30027): Gtk-WARNING **: 15:46:01.366: Theme parsing error: colors.css:72:44: Invalid number for color value
    (lxterminal:30027): Gtk-WARNING **: 15:46:01.366: Theme parsing error: colors.css:74:53: Invalid number for color value
    (lxterminal:30027): Gtk-WARNING **: 15:46:01.366: Theme parsing error: colors.css:75:53: Invalid number for color value
    (lxterminal:30027): Gtk-WARNING **: 15:46:01.366: Theme parsing error: colors.css:76:56: Invalid number for color value
    (lxterminal:30027): Gtk-WARNING **: 15:46:01.367: Theme parsing error: colors.css:77:65: Invalid number for color value
    (lxterminal:30027): Gdk-ERROR **: 15:46:01.725: The program 'lxterminal' received an X Window System error.
    This probably reflects a bug in the program.
    The error was 'BadAlloc (insufficient resources for operation)'.
      (Details: serial 137 error_code 11 request_code 78 (core protocol) minor_code 0)
      (Note to programmers: normally, X errors are reported asynchronously;
       that is, you will receive the error a while after causing it.
       To debug your program, run it with the GDK_SYNCHRONIZE environment
       variable to change this behavior. You can then get a meaningful
       backtrace from your debugger if you break on the gdk_x_error()
    • the lack of resources isn't memory: the machine ("master") has 8G and free tells me only half of that is being used
  • Firefox video playback was slightly degraded (perhaps for lack of GLX or RENDER?) on master, and utterly appalling (a frame a second) on slave

  • Firefox crashed whenever a drag-and-drop was performed: moving a tab or dragging a bookmark

Outcomes and Assessment

  • Xdmx takes 10-15 seconds to start your Window Manager - and considering the window manager in question was Openbox, that's a long time
  • for several seconds after startup, everything is painfully sluggish
  • secondary screen lags noticeably - especially if showing "graphic" content, ie. Firefox page rendering (not talking about video here, just text/image page rendering). The lag is visible but tolerable in text-based application like a terminal
  • slave's keyboard and mouse are unresponsive, with the slave screen only answering to master (this is disconcerting if you've got an open screen on slave, but not too surprising)
  • in fact these keystrokes on the slave's keyboard are transmitted to your now-hidden original X session on "slave" so you could theoretically do damage without ever seeing it happen ...
  • I removed the Xdmx package on slave and everything still worked - contrary to my expectations. I had a lot of trouble getting Xdmx working and I thought it might be because Xdmx was only installed on "master" in that case, but this seems to prove that isn't the reason.
  • on another pair of machines, Xdmx was never installed on slave and the setup ran fine
  • I tried using ssh -C ... (turning on compression, although the ssh man page recommends against it on a fast network), but it made lag between the two machines slightly worse
  • switching the two -display options does more than swap the position of the two displays: it causes the slave's display to be the primary screen, and the slave's mouse and keyboard to be the driver's seat
  • running without -norender -noglxproxy (ie. WITH RENDER and GLX) started okay, but as soon as I right-clicked to get Openbox's menu, I got a menu devoid of text - and then X crashed. Since this left the keyboard of master in a mess (Shift keys not working!), I gave up on further experimentation
  • I assume - but didn't test - that putting "master" to sleep would sever the connection to "slave" and quite likely catastrophically killing your Xdmx session - especially since Xdmx wouldn't be aware that we're using ssh as an intermediary. Xdmx was created in a time when computers were either ON or they were OFF and since it clearly (from what's happened in my testing) doesn't support a variety of modern X and computer features, I very much doubt it supports sleep or hibernate.

My final assessment? Might have been useful 20 years ago. Couldn't make it work then. Now it works (sort of), and is essentially useless. Don't bother.