Sorry, this is long. I can tell you how the process works, but I haven’t gone through all of the setup and so it just gives you a starting point. The bottom line is you probably need to run both a regular X server and a virtual X server (versus configuring it all in a single xorg.conf for a single server).
The config in “/etc/X11/” is for the default system startup server. When you try to put config of two different setups in one config it is expected for the system to become a bit confused. You should run two independent X servers rather than replacing the default server with the virtual server if you want both to work. One X server will be associated with one DISPLAY. The other X server will be associated with another DISPLAY. There may be some obscure way to use a single X config file for two independent servers, but I don’t know of such. In your case you replaced the xorg.conf content with either a case of supporting the virtual server or supporting the case of the real server (there probably is a way to make these live together, I don’t know what it is).
A quick note: When Linux starts it reaches a point where users can interact. The getty program (or some variant) spawns login management. Usually (this can be changed) there are 7 login locations for 7 independent logins (there would be 7 copies of login programs running…each is independent of the other). Or one could limit logins by running only three instances. Or you could have 12 instances if you ran 12 (“ALT-F1” through “ALT-F12”). If currently in text mode and you enter “ALT-F5”, then you go to the fifth…if you enter “ALT-F6”, then you go to the sixth. You might learn a bit if you look at files from:
sudo find /etc -name '*getty*'
(which in this case turns out to be controlled by systemd)
Whether that login manager is text only console, or instead GUI just depends which login manager type is run (X display manager is one possibility…and if set up as such, then all 7 could be X GUI…quite useful if your computer has 7 video cards…or 7 virtual equivalents to a video card…or even just the one video card if no two sessions will conflict). If the login manager is a GUI, then that runs. If you are on the GUI at “ALT-F1”, then you would have to add “CTRL” to get to “ALT-F5”…it would become “CTRL-ALT-F5”. Then, in the console at F5, you would use “ALT-F2” to get back to the second login (“ALT-F#” if already in a console, “CTRL-ALT-F#” is you are in a GUI).
Whenever X software runs it associates with the correct server via the DISPLAY environment variable. In the past “echo $DISPLAY” inside of a GUI session would by default be “:0”. I’ve noticed recently this has defaulted to “:1” (also, instead of the GUI being on CTRL-ALT-F1 it is on CTRL-ALT-F2, so perhaps it was called “:1” since it is accessed with “CTRL-ALT-F2” instead of “F1”…numbering order isn’t enforced, it is just tradition). So if I were to ssh in from the outside world without being associated with the GUI and try to run GUI software, then it would complain about not finding an X session or server. If I first “export DISPLAY=:1”, then the running X software would cause it to pop up in the “:1” GUI (this assume someone is logged in at “:1”…the DISPLAY doesn’t exist until there is a running session).
The DISPLAY number designation does not have any requirements of being in order. When you use software like “startx” you can specify a DISPLAY or allow it to set the DISPLAY itself (startx is a human readable bash shell script…starting X is complicated, and this script is a utility to make manual startup easier). Check “man startx”. “startx” will log in as whichever user ran the startx command. If for example you run startx as user ubuntu, tell it to use DISPLAY of “:10” (export the environment variable befor running any command), and name the virtual server and an alternate xorg.conf, then both servers would run at the same time…the default system server with a real monitor…and your virtual server. If user ubuntu then runs this command (just naming xterm as an example) from a non-gui location, then it will appear on the regular default desktop with a real monitor:
# example in a single line and specifying DISPLAY for a single use only:
DISPLAY=<b>:1</b> xterm
# example where all commands after this go to the ":1" server:
export DISPLAY=<b>:1</b>
xterm
Similar, these would be associated with and display to the virtual server running on “:10”:
# example in a single line and specifying DISPLAY for a single use only:
DISPLAY=<b>:10</b> xterm
# example where all commands after this go to the ":1" server:
export DISPLAY=<b>:10</b>
xterm
You could run the virtual setup as launched from “/etc/rc.local” or some other means (such as startx and naming this server as a different DISPLAY…you’d have this one as “DISPLAY=:1” and the default as “DISPLAY=:0” or something similar). I couldn’t tell you all of the alternate ways to start an X server or modify the existing systemd configuration, but what makes rc.local nice (provided you have a working “startx” command line) is that rc.local runs as root. Within rc.local you can use “sudo -u some_other_user startx …”, and because it is running as root it should not ask for a password to sudo to the other user’s ownership of the server run via startx.
Server, Virtual Server, and Virtual Desktop
There is a difference between the terms “server”, “virtual server”, and “virtual desktop”. A server is any X server. That server provides an environment capable of display. If the server is “ordinary”, then the display is real hardware, i.e., there is a physical monitor attached (and most likely a user interacts with this through a window manager). If the server is “virtual”, then the monitor is fake/synthetic and there is no physical monitor…but any software using the server won’t know the display is synthetic. A virtual desktop can be used with either a real physical display server or with a virtual server.
A virtual desktop is capable of describing a logged in desktop to a virtual desktop client. That client is how a remote system can see and manipulate a desktop. The virtual desktop client is more or less a distributed description for interaction with a desktop…but the client neither knows nor cares if the other end is monitoring a setup with a real monitor or a virtual monitor.
Note that if you only run CUDA, then you don’t need a desktop. You don’t need a window manager for CUDA, you don’t need a mouse or keyboard to interact. If you do not intend to display the work done by CUDA (e.g., output is to a file or network stream), then not only can the X server be virtual, the virtual server can also skip running any kind of desktop manager or windowing system.
