Friday, 16 September 2011

OMG! I haz designed a bug fix!

In GNOME 3, we removed an option which got GNOME users hot under the collar (and gave the opportunity to the ones who weren't something to troll about): we removed the configuration option to select what happens when you close your laptop lid.

We started digging, and found out that the main reason for people wanting this feature was so that they could go from a table to another in the coffee shop, from their desk to the meeting room in the office, or a table to the next in the library, with the laptop lid closed, and your internet connection still on-going.

In that case, what's really needed is a way to disable suspending when you're moving the laptop. But having to dig in the settings would take too long anyway. And, apart from a number of tethered ones, users would live happily without that ability, so we wouldn't be adding this in the gnome-shell UI itself.

Let's add the button in a separate application. A single button isn't too interesting though. Let's make this more interesting!

Office Runner!


  • “this is the best thing ever”
  • “the most creative way I've heard of to solve a power management bug in a while”
  • “I expect people to spill their coffees over this”
What now?

The code is available in GNOME git, and we're just waiting to knock a few TODO items, and get a UI  review before releasing the first version. Patches welcome. Enjoy!


Philip Chimento said...

This is a geniusly creative solution to a contentious problem. You. Are. Awesome.

Anonymous said...

Cool hack.

One of the reasons why people want to have hibernate rather than suspend is that encrypted LVMs don't suspend. If you're in an enterprise with an encrypted laptop and only a suspend capability, GNOME3 still needs a way to detect whether an encrypted LVM is being used and just invoke hibernate rather than suspend by policy.

hadess said...

Anonymous: That's a fair point, but the same people who set up the encrypted LVM could change the default configuration.

And there's also the problem that hibernation in Linux isn't something that's remotely as reliable as suspending.

Separate problem I would guess.

Henrique said...

Isn't there a way for Network Manager to reuse the last configuration without having to reconnect?

hadess said...

Henrique: NetworkManager will happily reconnect to the network, if it's still in range. If you mean not dropping the network in the first place and hope that the TCP connections don't timeout while you're suspended, I consider that a gross hack.

Juanjo Marín said...

bug or feature ?... Probably both ;-)

Henrique said...

Yes, I agree. I thought the problem was reconnecting to the network, not active connections.

hadess said...

Henrique: I got pointed to Lenovo blog post which looks like something we could be doing, if only we had multiple levels of power savings in our platform...

ocrete said...

I have an LVM in an encrypted partition and it seems to suspend just fine.. I'm not sure what you're doing different (wrong?).

Anonymous said...

One of the use cases i read back in the heat of the moment wws wanting to chang e rooms or offices without losing irc connections and such. Will you add a keep network alive (gross hack) button? Ps cool solution

hadess said...

Anonymous: there's no need to "keep the connections alive", the laptop doesn't suspend when "Office Runner" is running, so it doesn't lose connections.

Anonymous said...

ocrete: I think the point about encrypted LVM is that when you come back from suspend the LVM partitions are still decrypted - ie. a loss of security.

wdomburg said...

In that case, what's really needed is a way to disable suspending when you're moving the laptop. But having to dig in the settings would take too long anyway.

The majority of people who have said they don't want suspend-on-close never want suspend-on-close, so there is no digging around in settings involved.

And there is another use case that I know has been brought up several times - those of us with small children who don't want our network connections severed every time a child decides it's fun to close daddy's laptop.

I've been a long time user (since 0.13) and defender of GNOME, but frankly it's crap like this (which is not far from mocking people who have expressed a reasonable need) that has me looking at alternatives.

Anonymous said...

This is no bug fix! It's a disgrace that something like this is even needed.

I want my display to shut off, but nothing else. Most of the time my notebook is stationary, but sometimes I move it indeed. Or I just close the lid to reach behind the notebook, just to open it 5 seconds later – TOO LATE! It's already going in suspend, having me wait for half a minute for it to come back up.

A reasonable solution would be to turn the display off as soon as the lid is cloded. And then WAIT! If the lid remains closed for $time then suspend, otherwise just turn the display back on.

hadess said...

wdomburg: I'm sorry if you feel we're mocking users here, we're just making a particular use case (which we feel is the single most reason to stop laptops suspending) more fun. The "child-proof" setting is still available in gnome-tweak-tool, as it was under GNOME 3.0.

Angry anonymous: As to wdomburg, the setting is as present as it was under GNOME 3, so not in the UI, but hidden.

Nobu said...

Actually, hibernate is much more reliable on my computer than suspend**. But it's a desktop, so I guess that may have something to do with it.

**More reliable, meaning:
1.) Hibernate never fails (unless I've updated a core component, like the kernel, before hibernating)
2.) Suspend fails at least 50% of the time.

alex said...

you see, I love my small eeepc.
I use to walk down the street with its lid_closed, listening to groovy music. well, now it's not possible anymore. I like music, my friends like my music. sad me, sad friends, sadder world :(

anyway this run button is certainly a joke, right?

gnome3 is great, but this and the power-off thing are really bugging me.. a clash between 2 designers against too many users, just for a button.

Christoph said...

What I still miss is a way to configure this depending on AC status: When my laptop is on battery, I like it to suspend when I close the lid. However when my laptop is on AC, it is most likely docked and I use a external display, mouse and keyboard. I'd like to be able to close the lid then - without having to press a button every time, no matter how awesome it's designed.

Is this really such an exotic use case that nobody thought about when GNOME 3 was designed? Is it so exotic it needs to be in gnome-tweak-tool?

BTW: I do NOT have these options in gnome-tweak-tool even though gnome-power-manager is running.

Olav Vitters said...

This makes my head spin! Really cool, but too late for feature freeze and we just closed the release-notes as well :-(

hadess said...

Nobu: if you're using in-kernel drivers, I would ask around in your distribution's forums or mailing-lists, because failing to resume from suspend is really bad, and it needs to get fixed. I use suspend on my desktop machines (mostly because the fans get clogged up and make loads of noise) and I've had no failures so far.

alex: it was possible (in GNOME 2.x), and it still is, it's just that there's no UI for it anymore. You can still use gsettings on the command-line or dconf-editor to change the behaviour though. You're lucky you can do that with your laptop, for most users, this would make their bags melt...

Christoph: you shouldn't need any settings for that, because it's the way it's supposed to work. If you have an external display connected, the laptop won't go to sleep. If it doesn't work that way for you, file a bug against gnome-settings-daemon, and we'll look into it. As for the gnome-tweak-tool options, I might have talked too fast. I hope they implement it for cases such as wdomburg's.

Olav: I'm not sure it's worth mentioning in the release notes, to be honest. I just hope people who need that functionality see the funny side.

Nobu said...

hadess: Seems more like a motherboard issue than anything else. (and, actually, it's not as bad as I remembered) nouveau drivers been kickin' ass since Fedora 13/14 (now on 15).

It suspends (screen blanks and power light begins flashing), but the fan stays on and it doesn't sound like the hard drive spins down (although, I don't know if I could even hear it if it did, with the fan so loud). As such, I don't know if it's worth it to suspend, except that the desktop comes back up much faster (less than 3 seconds, as apposed to ~25).

MB Chipset: MCP51
MB: Biostar GeForce 6100 AM2 (v 1.3)
Video Card: GeForce 7100 (NV44)

I really need to replace my case fan; it's a 120mm (or 110mm) beast, and it's cranky when it first spins up. :/

liam said...

So you fixed a bug that wasn't broken until gnome 3 removed the option?
Ignoring the limited use scope of this particular solution (objective) and its inelegance (subjective), this particular problem was one of Gnome 3's creation.
Now addressing your actual solution:
creating an application for something that is really simply a single setting is overkill and adds needless complexity (very much anti-Gnome, I'm kinda surprised this didn't bug you, in fact). This doesn't really address people who have other reasons for wanting the PM to such and such upon lid closure. This is a really personal thing b/c there are simply many more common situations that this simply doesn't cover. Suppose you are running a long compilation and have kids/animals, it is easiest to simply close the lid (and more power efficient than using a screen lock, which, BTW, would be an additional step someone would have to go through to use).
Look at the whiteboards for the power manager. Even Apple offers much more configuration possibilities in this area than we do b/c limiting PM isn't a place where design decisions should take precedence over usability. Remember Ram's 10 rules, after all. This is failing at least #5 and #10.
As for this being the kernel's/driver's/user/s fault, that is not helpful. We are all using linux. I'm using Fedora. I'm using it with a thinkpad. Suspend let alone hibernate is not reliable with the standard kernel. Tuxonice works well for me but good luck getting those changes merged. As a DE engineer you really need to work with reality not the way things should be, and I'm not sure this will force the kernel developers to move better suspend/hibernate code into the kernel where, IIRC, Linus doesn't think it belongs. The best user space solution is provided by the suspend-utils package but that is extremely hardware dependent.
In short, unless you want to make a broken by design DE you need to look at reality for the majority and that reality for other desktops is that there are more use cases than Gnome is thus far designing for.


Anonymous said...

I'd tie the non-suspend function to having the battery power estimate 'menu' dropped down. Just let that display:

"You can close the laptop lid and the computer will not go to sleep while this message is displayed."

No separate application, no separate button. And the menu will auto hide when something else is focused.

hadess said...

Nobu: Ha, self made desktop. I consistently break self-made machines, so I try to save on repairs by having somebody else build them. The easiest is probably to strip the machine down, and start adding items back in, or try unplugging as much as possible from the machine (such as USB devices). Not sure that's very helpful though.

Liam: The solution has a very limited scope, because it was trying to solve one particular problem. I don't think there are any other use cases that we want to cater for, and it was a humourous and practical solution for this problem.

You can certainly say that we created the problem by removing the settings in GNOME 3.0, but we were also able to clean up tons of code from gnome-power-manager, and created a more integrated, and removed loads of bugs and possible moving parts from the new power plugin.

As I mentioned earlier, there are other ways to disable the suspend, and that's still there, for people who need to compile things.

As for the kernel options, what we would really want is a hybrid suspend, with various levels of suspension, and thus battery usage (for mobile devices). We don't have that yet.

In the meanwhile, suspend to RAM is reliable, or it should be, and if it isn't, then you should be kicking up a fuss about the kernel sucking, not about the lack of options to avoid suspending (like fixing the blocked toilet instead of putting a sign that it doesn't flush...).

hadess said...

Anonymous: Using the same "Alt" behaviour as the main menu has its uses indeed. The problem is that, again, it would be "hidden" (probably too hidden), and it would lack the limited time it works (10 minutes max in Office Runner, so it suspends instead of overheating if you're going out for lunch from the meeting instead of back to your desk).

I'd be happy to see somebody experiment with a gnome-shell extension for that.

Máirín Duffy said...

Hey Bastien, I love how you solved the problem with a game :) Some ideas for further development!!

* Time how long it takes to get to the meeting and have a 'HI-SCORE' list!

* Alternatively, give a time challenge? Not sure what the prize would be though.

* If the laptop has some kind of accelerometer... it could be a challenge, e.g., there is an egg on top of a table, if you can keep your laptop flat the whole time, then the egg stays on the table and when you open your laptop lid back up you see the egg's okay, punch in that you made it to your meeting, and you get a bonus time deduction. If you tilt the laptop while getting to your meeting, when you get back to the screen the egg will have rolled off and broken, and you get a cracked egg time penalty.

Okay, these are maybe too silly but were fun to think about :)

Nobu said...

Actually, bought it put together. Did get to choose the case, PSU, CPU, DVD/combo drive and HDD that came with it, though. It was cheep, but works decent.

Back on topic: it's an interesting application. Think you could make it play music (something dramatic) while the lid is closed? ;-)

Anonymous said...

Having this as a separate application seems excessive; this functionality ought to integrate with the power icon, so that I can click the "don't suspend" button from the power icon's menu.

Also, having a 10-minute limit means this doesn't actually solve the problem for me. When I say "don't suspend", I mean "don't suspend", not "make me rush so I don't lose my network connections". My laptop battery lasts for hours, not minutes; if I want to stop and chat with someone for a while, holding the laptop under an arm, I still don't want the laptop suspending. If I want to suspend my laptop, I'll do so.

In any case, this still means I have one more step I have to perform every time I close the lid of my laptop, but as a hack it'll suffice until a better solution comes along.

If you feel the need to have a "thermal shutdown" mechanism to prevent overheating laptops, how about addressing that separately? You've said before that you prefer to solve the root problem rather than hacking around it.

liam said...


Thanks for the reply!
I realise, and appreciate, the humorous aspect. I was merely pointing out that the other DEs (even Apple) realise that PM is important enough that people should manage it on their own. Provide sensible defaults (something Gnome is usually amongst the best anywhere at doing) but realise that no design handles every situation. I don't think this solution in particular solves even a majority of cases where someone doesn't want to suspend with the lid closed, but I'd be willing to be shown otherwise.

As for code clean-up, how much code does it add to provide checkbox (or slider) that toggles off suspend/hibernate on battery when laptop lid closes? As you said, the option is still there, just not shown and this application you wrote adds how many lines of code? Over 400 lines (even the bits that are simply fun add to maintenance, surely) that are essentially acting as a timer and working with gsettings. To add the toggle box would result in far less code addition, and be more consistent with the GS interface.

Apple has shown that PM options can be given and things still look elegant. This is a time when looking to them is not a bad thing.

Lastly, the kernel is the kernel. We simply don't have choices there b/c Linus is just not going to add this in, and the best user space option I'm aware of (the previously mentioned suspend-utils) is too dependent on kernel/hardware. Perhaps Gnome should tie itself to another kernel since Gnome is no longer willing to work around the reality of the kernel. If Gnome wants to provide the whole stack then they should recommend the tuxonice kernel.

BTW, shooting for the Apple default of hybrid suspend is laudable but the Linus tree is not going to get this for a long time (again, tuxonice has hybrid suspend, and no I am not affiliated with the project:) ).

Sorry to keep saying this but Gnome really needs to consider reality when it comes to making these decisions.

Perhaps a quick glance at Gnome Shell Principles would be a useful reminder. Specifically, 1. this isn't designed with an understanding that a users requirements change; in fact, it is so rigid it allows (not always, but nevertheless in some important cases) no other way of doing something and 2. this single button window is not consistent with the least astonishment principle (granted it is a simple UI, but still, it is anomalous).

Thanks again,

Anonymous said...

Why you, the gnome developers, just dont ask users about what their want?

Why are you breaking your own principles?


Emmanuele said...

Liam: for all your mentions of power management on OS X, I just checked (Lion, here, but I'm pretty sure Snow Leopard was the same); in the Power Saving section of the system settings you cannot change the action on lid-close. there is no option whatsoever. the design team worked on the various similarities and differences of different operating systems, as you can see here:

Anonymous said...

I can't see the posted image but taking a swirl at the comments, I probably should not

(which we feel is the single most reason to stop laptops suspending)

This is the difference between (you) GNOME developers and (we) interface designers. We usually know what we are doing, and don't guess or feel.

Your friendly Julian said...

I'm not really convinced by the idea. Wouldn't it be much easier to just modify the default behaviour so the laptop just suspends after 5 (or 10) minutes after closing the lid? That way you wouldn't even require the user to do anything at all to move his laptop.

liam said...


I am going by the picture that is listed in the gnome shell pages, but I've no doubt you are right (I haven't been able to find pics of the entirety of Mac's power settings). My point wasn't so much copy Apple but only that even Apple offers far more options to the user when it comes to power management (here is a link for any interested: their scheduling feature looks interesting). More important than that, however, what it offers it can actually do. Macs can suspend and hibernate reliably thus they have designed for that. To make something the default that is widely known to be unreliable is not a good design decision. I am not trying to be harsh and I like much of GS so please don't think I'm one of the "grumble grumble grumble.. Gnome 2 was the best possible DE why change it... etc" types. I know Apple is well thought of by the Gnome designers but I wish the reality of our particulars would guide their decisions.

Anonymous said...

way to troll your own userbase, you condescending asshole

Luciana Fujii said...

I do understand I'm not the target user of GNOME settings, but I would be much more happy if people writing about that wouldn't repeat the same mistakes every time. I've said it, many people have said it before: "no one would change settings just before closing the lid of the laptop to avoid it suspending, it's something you want to change once".

You see, laptops have a suspend button, so if I want my laptop to suspend I can just use that. If I close my laptop lid I'm just doing that, because I don't want people to watch my screen, because it's easier to carry to another room or because I don't want the keyboard to get dust. If people would account for that, and say that's not a common use case, fine. But talking about changing settings before changing rooms is just not a real use case, seriously. Show me one person that uses the laptop like that or just please stop using that as an example, even for jokes.

lucaugusto said...

This video says all that need to be said about gnome 3...

Anonymous said...

The fact that this hack is needed is why Linux on the desktop is doomed to irrelevance.

Johnny Bit said...

Hahaha... ow wow... now I know why I stopped caring about GNOME. Since version 3 it's broken and to fix it it needs a lot of "cool apps" like this one. Congratulations! Start selling them right away in GNOME "cool apps" store. I'm saying with Xfce now - where designers don't screw up so badly.

Colin Guthrie said...

Just so people know, suspending and then rapidly connecting back to the network again is something which I believe is called something like DHCP fast start. Basically Apple does this on OSX and it's the ability to reconnect to the network really quickly without actually doing the full DHCP process. You simply send some ARP messages (or something like that) and if the IP you were using is still available, just keep using it... no need to go through the whole request, response system. This solves a lot of the cases of slowdowns on resume from suspend.

My laptop for example resumes in about 2s but the network lags behind by quite a bit.

In the not too distant future, I believe the tools needed to implement this feature will start getting rolled out and we can look forward to a much faster suspend.

I know many Mac users for example who happily suspend and resume their laptops even for < 1 minute... "Oh wait I forgot..." and it's really no problem.

So I agree that this is a setting that should be kept hidden. We need instead to push the lower levels to deal with things more quickly and more efficiently for us so the whole problem becomes moot!

Disclaimer, I've likely got some of the terminology wrong, but the concepts I'm pretty certain of :)

Anonymous said...
This comment has been removed by a blog administrator.
Juan Camilo Prada said...
This comment has been removed by the author.