GNOME Bugzilla – Bug 687586
integrate "GNOME can't run" dialog with fail whale for no-fallback-available case
Last modified: 2013-01-25 21:52:53 UTC
As part of dropping fallback mode, we need to change the dialog to say that we can't run at all, not that you're in a degraded experience. Potentially other things should change too.
In what cases would that occur? I suppose: * Starting the live installer * After performing an upgrade (we should check before the upgrade) * After video capabilities changed (how?) Anything else?
We probably need a separate bug for adding some kind of feedback for what happens to someone when they upgrade and had previously used the forced fallback.
There's very few cases where you would get a complete failure to start. Some cases would be: - Missing components on system (no llvmpipe driver, or similar) - VNC server (Xvnc) without compositing Both of the above should be detectable. There's a couple of cases where it starts or would start, but is buggy (case 1 or 4 [1], bug 646280), or refuses to start (multiple screens, bug 648156, case 2 [1]). But as Owen mentioned on IRC, there should be no cases where we *have* to show the fail whale unless software is missing (as mentioned above). Unless your install broke because nobody did QA, you shouldn't get a failure where it used to start. [1]: https://mail.gnome.org/archives/desktop-devel-list/2012-October/msg00135.html
In addition to "complete failure to start" there is "boy this is going to suck and you're going to hate us for it". What do we do about that? Can we differentiate incapable systems from broken systems?
Incapable in what sense? CPU is far too slow to cope for example? I don't know, we can do a number of checks, but the amount of heuristics needed to do this right isn't the best (especially if you're asking people to add their systems to a blacklist of computers that aren't fast enough for example). We could certainly switch to disabling animations if the CPU is too slow (and llvmpipe is in use). See bug 680195. For the multiple screens case ajax mentioned, even when we've fixed it, the experience is going to be degraded from fallback. It used to run on all the heads, now it only runs on one head. Pretty much everything else is just rendering bugs that need to get fixed (and that we can't really catch with a failwhale).
Created attachment 229207 [details] [review] Drop fallback session definition
Review of attachment 229207 [details] [review]: Hrm, but don't we actually need the check-accelerated helper to run, since it sets X properties that we then use? I suppose it should be integrated into gnome-session to run as the very first thing, before anything else (even gnome-settings-daemon?)
(In reply to comment #7) > Review of attachment 229207 [details] [review]: > > Hrm, but don't we actually need the check-accelerated helper to run, since it > sets X properties that we then use? Yes. See _GNOME_MAX_SCREEN_SIZE.
Created attachment 229273 [details] [review] another patch This patch keeps the runnable helper.
*** Bug 690745 has been marked as a duplicate of this bug. ***
Comment on attachment 229273 [details] [review] another patch I had a similar patch in my tree. I would make the main.c changes separately though.
*** Bug 689757 has been marked as a duplicate of this bug. ***