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…
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.