Comment 12 for bug 889996

Out of curiosity, how is this 4s budget defined? I assume it's from the time you enter your password in lightdm to the time you have a usable desktop? If this is the case, then it's arguable that lightdm shouldn't even be displaying "unity" as an option on displays which don't support it, let alone have it as the default option. If the unity_support_test was done as part of lightdm startup instead, and the 4s budget is defined as I assume it is, then at least the 0.8s unity_support_test delay could be moved outside of the desktop login process.

In this scenario, calling gnome-session with the '--session' parameter (as lightdm currently does) would invariably launch whatever session was specified using this parameter, and unity_support_test would never need to run or cache anything. The only time unity_support_test would be called during gnome-session startup is when it is called without the --session parameter; in this scenario, the session defaults to the value of the gsettings key "session-name" in org.gnome.desktop.session, as per current behaviour.

Of course, the next question is what this key should be by default. One option would be to have a new .session file, e.g. "unity-test.session" or similar. This session file would essentially look like the current ubuntu.session file, which performs the unity_support_test and falls back to unity-2d if it fails. (Admitedly I'm not sure what else this key is used for, so feel free to correct me if doing this would have any adverse effects).

I'm just brainstorming here - I'm happy to submit a patch if you feel that something like this would be an acceptable solution. Something needs to be done, however; the current implementation makes wild and unreasonable assumptions, is a potential security risk, and basically prevents Ubuntu from being a viable terminal server platform.