Fixing lid close suspension in 4.8.1

I never thought I would have dedicated a blog post to a single bug, but here I am. It has been quite an effort fixing that for good, but we made it, and I wanted to share some considerations we made while doing this.

Before I begin, let me say that bug was an incredible example of constructive feedback by our awesome users: we got plenty of relevant information in a ridiculous amount of time, so I want to thank anyone who replied and/or reported, and if you, dear reader, have an outstanding issue in your KDE desktop – this is a good example of what it takes on your side to get it fixed as soon as possible πŸ™‚ But let’s get to the point…

The issue

Since 4.8, as you probably already know if you follow my blog, inhibition in power management got a significant boost all over the place, but most of all started to work as it should. In addition, we enforced a policy which considered a lid close action to be implicit. We didn’t consider, though, that many application implemented inhibition before 4.8, even if in fact the whole routine was broken in a relevant number of cases. Turns out that some of them were actually doing this wrong.

In addition, we found a bug in our RandR code for detecting multiple displays connected, which triggered a persistent inhibition throughout the whole session since a second display was always detected.

So, what happened in the end? Lots of users weren’t able to suspend their laptop when closing the lid, maybe even you reader. But we tackled down every cause and fixed them.


Unfortunately, there is no way we can predict whether an application will do its job or not – we can just trust them to do it right. The good news is that our awesome users found the cause in two applications – KTorrent and Apper. While for KTorrent the inhibition feature is actually configurable, so it wasn’t really a bug but a new behavior discovered, for Apper the case was different – a bug in the inhibition routine went unnoticed, and we fixed that. I heard Daniel just released a new version which contains the fix – needless to say upgrading is highly recommended.


I am a bit sad about this since this was meant to be one of our killer features. Although, we had to face a number of problems with drivers and such when detecting a second display, as already mentioned. We managed to get to a point where most of configurations will be actually supported, and fixed a number of corner cases where inhibition was not desirable. However, in the end we will probably make this feature configurable, as some users also told us that having suspension inhibited in a multi-head setup is not what they want.

Explicit vs. Implicit

And here’s to the very root of the problem. Our power management system is smart enough to distinguish whether an event has been explicitly requested by the user, such as a button press, or it was an implicit decision from the system, such as an idle timeout. The inhibition mechanism is designed not to inhibit any explicit action, just preventing the system from undertaking an action when the user is not taking part in the decision. The reason why we considered lid as an implicit event was probably wrong, after the feedback we got; but it was mainly to prevent the system from going down when something important (software update) was going on.

Most of our users showed us that the expectation of a lid close is definitely to carry on the configured action regardless of what’s happening in your system, which is indeed something sensible. At the same time, some people were happy with the new behavior and provided some good use cases to prove this (for example, using the new applet checkbox to prevent suspension when closing the lid). In the end, my take was to make this kind of behavior configurable – in 4.8.1, the advanced options will have a checkbox which is going to define whether a lid close is going to be considered explicit or not. And by default, it will be considered explicit like in previous versions.

Conclusion (or TL;DR)

I am happy to say this annoying bug should be completely fixed in 4.8.1, and at the same time we managed to leave our users with a choice to make their PC behave as they think it should. I really hope for 4.9 we’re going to deliver a rock-solid KRandR+Power Management implementation and we’ll try really hard for that, even because that would be a neat feature for Active.

So, if you were affected by this bug and do not care about anything besides your PC suspending when your lid closes – all of this will be just a bad memory after updating to 4.8.1 without the need for you to do anything apart from the upgrade itself. Otherwise, you can restore 4.8.0’s behavior by going in the advanced options. And, in any case, do not forget to update any application which was misbehaving.

~ by Dario on 22 February, 2012.

25 Responses to “Fixing lid close suspension in 4.8.1”

  1. Compliments for this post, very detailed and interesting.

    I can’t wait for KDE 4.8.1 release!

  2. Compliments for this post, very detailed and interesting.

    I can’t wait for KDE 4.8.1 release!

  3. Great news!
    /me rebuilding kde-workspace

    • If you are building master, note that I’ve merged the fix onto master just now, whereas before it was just in KDE/4.8 πŸ™‚

  4. > I really hope for 4.9 we’re going to deliver a rock-solid KRandR+Power Management implementation

    And me really hopes the KRandR fixes won’t be limited to power management issues πŸ™‚ From looking at the bug reports, multi-monitor support still isn’t “right” (forgets configuration, Plasma sizing issues etc.)

    Thanks, Keep rocKing.

  5. Thanks for your work in fixing the bug… and thanks for this post, quite interesting indeed. I wonder if a short extract of it – the distinction between explicit and implicit events – could make it into a readme somewhere…

    • If you think it might be useful, indeed. But it’s mostly a relevant information for anyone developing on it or users interested in the underlying mechanisms… maybe Techbase?

  6. Dario the only thing I really miss in PowerDevil is the ability to make the power button to turn off the PC, yes there is a Shutdown option but it does not confirm, so if I accidentally hit the power button it will shutdown immediately. You know you just need to change the KWorkSpace thing about to ask confirmation πŸ˜€
    IMO this should be the default action since for me and most users I’ve talked to when you press the power button you expect it to power either ON or OFF …
    BTW thanks for this lovely app πŸ˜€

    • Hmm, are we talking about “Show log out dialog”, or “Shutdown” just showing the dialog instead? If the second, can you please open a bug? Thanks πŸ™‚

  7. How to develop a KDE core piece of software:
    Imagine we create a NetworkManager assistant called KConnect for “KDE 8”. It’s a very important part of KDE. *

    – You create it for KDE 8.0.
    – It doesn’t work. So a “slightly” fixed version will be out for KDE 8.0.1 and we all hope it will be completely fixed for KDE 8.1.
    – In KDE 8.1, it doesn’t work well but at least it’s better. We’ll wait for 8.2, it should fixed in that version!
    – Everyone expected KConnect to be almost perfect for KDE 8.2, but that application no longer exists, it has been replaced by KLink whose goal and features are the same, but has even more bugs than KConnect had in KDE 8.0.
    – Repeat.

    * As a side and not-so-funny note, we already have a NetworkManager assistant. It’s an ugly plasmoid that never works well.

    • Weak trolling attempt, just like your reading skills. I suggest to improve them, as the step I’ve been repeating here are:

      – You create it for KDE 8.0.
      – It doesn’t work. So a completely fixed version will be out for KDE 8.0.1 thanks to a relevant effort from developers and users.

      You can go back sitting in your corner, thanks.

      • It’s not a weak trolling attempt, but a somewhat destructive comment.

        I’m not a KDE enemy, just a KDE user that wants to cry every time he uses the desktop environment that was once the best.

      • I understand your feelings – it’s really hard to read what you use everyday has been improved. Don’t worry, we’ll manage to break things again, I promise. Maybe in 4.9?

      • I don’t think he is trolling just saying how he perceives that KDE manages new features and I tend to agree with him.
        In the Linux kernel, they have a policy that every new feature is disabled by default for at least one release, that would be a very significant improvement for KDE: ship a new version of KDE with new features disabled by default and with the release text describing them, how to enable them and how to report feedback.
        If no bad feedback received, enable the new feature in the next stable release.

      • The point is that we are not talking about new features but a change of behavior here, if you read the post correctly, and bugs exist in the Linux kernel as well. Here we are talking about a bug introduced by a number of causes which could not have been foreseen for obvious reasons.

        That said, comparing the development workflow of a kernel and a desktop environment doesn’t really scale, but still for new features which could have introduced regressions (see KSecretService) we adopted a similar policy. Again, I think you guys missed the point of this post (and I still have to realize why people are whining over the news of a solved issue).

  8. @Iierh, fill a bug for what is not working and keep in mind that there are several bugs I cannot reproduce so I cannot fix them. Ranting in somebody’s else blog will not make them disappear. Since I am the responsible for Plasma NM now you should have ranted in *my* blog πŸ™‚

  9. Apparently I am hit by this bug. I am on KDE 4.8.0, this is how my advanced settings look like and I do not see anything relevant here. What do I do next?

  10. Thanks Dario.
    I’m glad that this bug got high priority and got fixed so fast.
    But as always if an bug is bugging you then you need to help to trace it down or it won’t be fixed.

    And thanks a lot for this blog post explaining it from your point of view.

  11. A case where there is no clear-cut right answer but where good design can lead to a much better experience. Thanks for your work

    The thing I have found strange but, I admit, have never filed a bug for, is that if I shut down my laptop, I have to wait for it to finish shutting down before I close the lid or it will suspend in the middle of shutting down, so when I next go to use it I have to wait for it to finish shutting down before I can stat up again.

    • I know – and unfortunately it is a bug. I tried to fix it multiple times but we need more changes to the shutdown procedure for fixing this completely. There is already a bug somewhere I’m pretty sure, but I’ll surely blog about it as soon as I’ll be able to fix that.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: