When there's trouble, it might be good to understand what happens under the covers to sign a user into a GUI session and get a Unity (or other window manager) to bring up a desktop.
How a user GUI session get's started with Ubuntu 12.04
Here's the chain of events:
The Ubuntu Linux kernel and upstart
The kernel starts the init process as process number 1. This is upstart for Ubuntu 12.04.
Upstart jobs are in /etc/init/
Man page: http://manpages.ubuntu.com/manpages/precise/man5/init.5.html
The upstart job executes /usr/sbin/lightdm
Man page: http://manpages.ubuntu.com/manpages/precise/en/man1/lightdm.1.html
Source: man page and /var/log/lightdm/lightdm.log
Lightdm get's started fairly late in the init process, for example, the system dbus must to be already started, the filesystem has to be ready, and the graphics display system must be ready.
lightdm creates an xauthority file and then starts X, starting it on VT 7, the virtual terminal you get if you press Alt+Ctrl+F7. When X is started lightdm signals for the Plymouth splash screen program to quit. It's essential that this happens after all of the tty's (1-6) have started. Older versions of Ubuntu have experienced obtuse X crash problems while in their development phases when X was started too soon.
X attempts to use the most advanced drivers possible. It's own drivers are loaded from /usr/lib/xorg/modules/ . Note that there exist both kernel drivers and xorg drivers for many devices, with the xorg drivers almost certainly using the kernel ones. dri and glx are important features, in particular, for advanced high performance graphics. Logs are stored for X in /var/log/Xorg.0.log .
There is communications over the system dbus about this "seat" and possible user names are acquired. lightdm uses X to draw the screen. unity-greeter is used to assist in the process.
As you select the various possible userid's that userid's backgound image is used.
unity-greeter get's the names of potential window-managers/systems from /usr/share/xsessions/*.desktop.
lightdm and the greeter use PAM to authenticate the user. Once authenticated, PAM will start a gnome-keyring-daemon daemon with the --login option and feed it the user's password so that it can unlock the user's login keyring, if present. See https://live.gnome.org/GnomeKeyring/Pam and man 8 pam_unix for more information. PAM stores log information in /var/log/auth.log and is controlled by /etc/pam.conf (almost empty) and /etc/pam.d/*. In particular, see /etc/pam.d/lightdm and /etc/pam.d/lightdm-autologin.
Once the user is authenticated privileges are dropped and a file is written to ~user/.dmrc describing the session. For example:
The .desktop files from /usr/share/xsessions/*.desktop now determine the rest of the startup sequence.
For example here's the one for Unity:
The /usr/sbin/lightdm-session shell script is run with the arguments gnome-session --session=ubuntu (sic.--'ubuntu', not 'unity')
/usr/sbin/lightdm-session then takes these steps:
ssh-agent can hold onto ssh keys for the session if they are ssh-add 'ed some time during the session, but gnome-keyring-daemon does the same thing.
Finally lightdm-session starts a window manager, or for unity, starts the gnome-session session manager.
It appears that lightdm-session takes on the traditional role of xsession. Its man page is at http://manpages.ubuntu.com/manpages/precise/man5/Xsession.5.html .
gnome-session session manager (Unity and Gnome Shells)
Source: man page
gnome-session is used for Unity, but not for awesome by default, for example. See the above .desktop files.
gnome-session starts the specified program from /usr/share/gnome-session/sessions/ and starts applications from ~/.config/autostart/ and /etc/xdg/autostart.
Here's one example from /etc/xdg/autostart:
Another, /etc/xdg/autostart/gnome-keyring-ssh.desktop, starts gnome-keyring-daemon with the --start option, completing the start of that daemon process and storing important information about it in the environment for potential use by ssh.
From a ps aux list it appears that gnome-session starts window managers with dbus-launch.
Awesome Window Manager
Man page: http://manpages.ubuntu.com/manpages/precise/en/man1/awesome.1.html
Source: man page, config file examination
Here's the awesome.desktop file in /usr/share/xsessions/ used by lightdm-session:
As you can see, the entry simply causes the awesome window manager to be executed. It reads its own configuration files, including /etc/xdg/awesome/rc.lua from the awesome package. It can be configured with $HOME/.config/awesome/rc.lua.
Source: config file examination
Here's the ubuntu.desktop file in /usr/share/xsessions/ :
This starts the gnome session described in /usr/share/gnome-session/sessions/ubuntu.session
Here is that file:
The IsRunnableHelper program run by gnome-session determines whether unity can be run or whether ubuntu-2d will run. If it makes a mistake and says unity can run and it cannot, there's trouble. Choose ubuntu-2d manually in lightdm if that happens to you. While it returns a return code, we can see what it is doing by running it with the -p option.
We can see from the above files that gnome-session must start the settings daemon, and start compiz for purposes of running a window manager and any panels.
Man page: http://manpages.ubuntu.com/manpages/precise/en/man1/compiz.1.html
Once compiz is started, it runs various plugins. gnome-settings are used to define these. They can be changed with ccsm (compiz config settings manager) or with gconf-editor. The plugin settings are stored in apps/compiz-1/general/screen0/options under active_plugins. Duplicates have caused me to have segfaults with compiz. These are stored in the user's home directory in the ~/.gconf/ directory organized as above. The actual values are stored in %gconf.xml files there.
Unityshell is one of these plugins. It uses the nux project as an embeded toolkit. I understand that images are drawn on textures in 3 dimensional space with specified transparency values. These are processed by compiz and sent to advanced graphics drivers to have the graphics engines on the system's computer graphic hardware composite and render them. Generally, this is as opposed to rendering images directly to a framebuffer as was done more traditionally. This complicated chain of events is what requires more advanced drivers, and sometimes prompts the use of proprietary graphics drivers in Ubuntu.