After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 687586 - integrate "GNOME can't run" dialog with fail whale for no-fallback-available case
integrate "GNOME can't run" dialog with fail whale for no-fallback-available ...
Status: RESOLVED FIXED
Product: gnome-session
Classification: Core
Component: gnome-session
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Session Maintainers
Session Maintainers
: 689757 690745 (view as bug list)
Depends on:
Blocks: fallback
 
 
Reported: 2012-11-04 19:21 UTC by Colin Walters
Modified: 2013-01-25 21:52 UTC
See Also:
GNOME target: 3.8
GNOME version: ---


Attachments
Drop fallback session definition (2.09 KB, patch)
2012-11-17 04:04 UTC, Matthias Clasen
reviewed Details | Review
another patch (2.76 KB, patch)
2012-11-18 04:06 UTC, Matthias Clasen
reviewed Details | Review

Description Colin Walters 2012-11-04 19:21:52 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.
Comment 1 William Jon McCann 2012-11-09 15:45:29 UTC
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?
Comment 2 William Jon McCann 2012-11-09 15:46:06 UTC
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.
Comment 3 Bastien Nocera 2012-11-09 17:53:49 UTC
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
Comment 4 William Jon McCann 2012-11-09 18:00:49 UTC
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?
Comment 5 Bastien Nocera 2012-11-09 18:08:57 UTC
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).
Comment 6 Matthias Clasen 2012-11-17 04:04:06 UTC
Created attachment 229207 [details] [review]
Drop fallback session definition
Comment 7 Colin Walters 2012-11-17 04:21:33 UTC
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?)
Comment 8 Bastien Nocera 2012-11-17 08:03:09 UTC
(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.
Comment 9 Matthias Clasen 2012-11-18 04:06:08 UTC
Created attachment 229273 [details] [review]
another patch

This patch keeps the runnable helper.
Comment 10 Colin Walters 2012-12-27 23:11:57 UTC
*** Bug 690745 has been marked as a duplicate of this bug. ***
Comment 11 Bastien Nocera 2013-01-13 17:44:32 UTC
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.
Comment 12 Bastien Nocera 2013-01-13 18:54:32 UTC
*** Bug 689757 has been marked as a duplicate of this bug. ***