Comment 5 for bug 812394

(1) Of course I don't know percentages, but all of the four laptops that I had so far, and the ~ 5 laptops of other people that run ubuntu or that I tried a live system on had no problem with suspend. I didn't hear a lot of complaints about suspend being broken on UDSes or sprints. That's of course far from representative, but the best I can offer as knowledge. Also, we don't get any bug reports about suspend breakage at upstream pm-utils any more for a year or two; we used to get many, but with the advent of KMS and more drivers supporting it it has become pretty much a non-issue. (This partly ties into (2), too).

What does remain as a complaint that I did hear on UDS was that on some models suspend draws a lot of battery live, due to BIOS or driver bugs. This issue remains, of course.

(2) I seriously doubt that white/blacklisting for hibernate would make any improvement. Most hibernation failures I ran into were due to too little swap space (a problem that should not occur any more since lucid or so, since pm-utils carefully checks swap), unusual partitioning (using LVM, or unsupported crypto schemes). It is very conceivable that e. g. USB devices don't properly restore their state on resuming either. However, none of these problems are tied to the hardware platform itself. Unlike suspend, the process of hibernation is actually quite hardware independent. Hibernation is essentially writing the RAM and state to disk, and for resuming you just to a regular boot all the way until initramfs.

(3) I agree to the statement, I disagree that maintaining a whitelist and only enabling models on it is the, or even a good solution.

(4) Yes, that's feasible.

(5) I see little value in lecturing everyone about the potential failure. On the machines where it works it is confusing at best, and on the machines where it sometimes fails it doesn't help you (as we can't predict when it fails), and on machines where it doesn't work at all, users will quickly learn to "don't do that then" anyway. The second case (works most of the time) is certainly the most frustrating one, but again isn't helped by a whitelist as even on certified models it just tends to fail from time to time (like on many Thinkpads).

My feeling about this is:

 * Suspend: I don't think a whitelist is very helpful here, but if we want to have one, it seems fine to me. I strongly disagree about disabling it by default on non-whitelisted models, though. It doesn't make sense to punish the majority of users on uncertified hardware where suspend is working, just because it doesn't or might not work on some models. If at all, we should blacklist these.

 * Hibernate: As explained above, I don't think a white/blacklist makes sense here. We should enable or disable it by default, but this shouldn't be model specific. (in other words: it sucks on all computers). I have no strong opinion about disabling it or not, and would be fine with either.

As for the can-suspend/can-hibernate properties and the recent g-c-c patch: These flags have been there for a long time, and earlier Ubuntu versions used them as well. (Like the session indicator, gnome-power-manager, etc.). The cited commit just fixes a regression that occured from moving gnome-power-manager functionality into settings-daemon and control-center, so it's nothing new.