I have a laptop in a dock, with an external display attached to it. The external display is used, the internal one not. When doing a Skype call, I open the laptop's lid so as to not block the microphone. Then, when closing the lid again, the screen gets locked. Afterwards, after unlocking the screen, every time I change activities, upon arriving at the new activity, the screen gets locked again. This is quite bothersome. The screen should not be locked when closing the lid, of course, but it should certainly not be locked when switching activities. Reproducible: Always
This one is really interesting. I think we will have to wait for mgraesslin to return from vacation to shed some light on the issue since he is most familiar with kscreenlocker.
> The screen should not be locked when closing the lid, This is a configuration option in powerdevil > but it should certainly not be locked when switching activities. No idea what's going on there. KScreenlocker doesn't integrate with activities AFAIK.
(In reply to Martin Gräßlin from comment #2) > > The screen should not be locked when closing the lid, > > This is a configuration option in powerdevil Well, this is when attached to mains, and I don't have “Even when external monitor is attached” enabled. > > but it should certainly not be locked when switching activities. > > No idea what's going on there. KScreenlocker doesn't integrate with > activities AFAIK. While looking at the power saving config, I noticed there is a tab for activities configuration. So I assume it may be there, I'll reassign to powerdevil (if I can't, please do it for me).
I think I found the reason. When activities change PowerDevil reloads its profile (as you might have per-activity settings) and in the profile loader it has the following code: // If the lid is closed, retrigger the lid close signal if (m_backend->isLidClosed()) { Q_EMIT m_backend->buttonPressed(PowerDevil::BackendInterface::LidClose); } and then it locks the screen, it also doesn't even check whether the lid is already closed, so it does that everytime you change activities.
This doesn't change the fact that the handle button events plugin eventually discards the event when an external monitor is present, at least that's what it should do, so we have two bugs here: 1. Closing the lid triggering a screen lock although an external monitor is present which might have been caused by [1] 2. The lid closed signal being emitted unconditionally on profile load if the lid is currently closed [1] https://quickgit.kde.org/?p=powerdevil.git&a=blobdiff&h=1c3a06d9bb1bf1abade1cc02024e4bbccbf12781&hp=7e1d16e4123d1ac280ad71807f265b0859e347b9&hb=d3162725cfffb79da7bb8f276a31a915e3349dab&f=daemon%2Factions%2Fbundled%2Fhandlebuttonevents.cpp
(In reply to Kai Uwe Broulik from comment #5) > > https://quickgit.kde.org/?p=powerdevil. > git&a=blobdiff&h=1c3a06d9bb1bf1abade1cc02024e4bbccbf12781&hp=7e1d16e4123d1ac2 > 80ad71807f265b0859e347b9&hb=d3162725cfffb79da7bb8f276a31a915e3349dab&f=daemon > %2Factions%2Fbundled%2Fhandlebuttonevents.cpp Maybe it would be helpful for me to check what KScreen thinks output->type() is for me. Is there a way I could find this out?
Can you run kscreen-console and attach its output here? It should have eg. "Type: "Panel (Laptop)"" and some other information we could use to figure out why (if it does) it detects it as Unknown. Thanks!
Created attachment 100405 [details] kscreen-console output DP1 is laptop-DP and DP2 is dock-DP
Thanks a lot. Can you try if this [1] fixes it for you? The heuristic was recently changed to detect outputs that start with DP (DP2 in your case) as DisplayPort which should fix this problem. This commit should have landed in Plasma 5.7.0. [1] https://quickgit.kde.org/?p=libkscreen.git&a=commit&h=54ec74901a0fea1601f76278d6e04af4fbd4b74d
Can you try this patch https://phabricator.kde.org/D2325 please?
(In reply to Kai Uwe Broulik from comment #9) > Thanks a lot. Can you try if this [1] fixes it for you? > > [1] > https://quickgit.kde.org/?p=libkscreen. > git&a=commit&h=54ec74901a0fea1601f76278d6e04af4fbd4b74d (In reply to Kai Uwe Broulik from comment #10) > Can you try this patch https://phabricator.kde.org/D2325 please? I can try this (tomorrow, otherwise it will have to wait until late august), but only if those patches apply against 5.6.5.
(In reply to Kai Uwe Broulik from comment #10) > Can you try this patch https://phabricator.kde.org/D2325 please? I tried it (after changing some stuff in the patch to make it apply), and it works! So, I'd consider this bug fixed once that patch is committed. (Can you report back about the release version in which it will first appear? Backported?)
Git commit 48c3dca61d7cb808c904a3a3659b2cd36fba1866 by Kai Uwe Broulik. Committed on 10/08/2016 at 07:32. Pushed by broulik into branch 'Plasma/5.7'. Don't unconditionally emit buttonPressed on profile load A button press (technically the "lid closed" event is also a button press) should always be some consicious action triggered by the user. By emitting this signal unconditionally on profile load (ie. whenever changing an activity or (un)plugging AC) the session might always lock or suspend when this happens. If and only if a profile would really like to take some action or set some state depending on the lid state on profile load - which none do, the handle button press action should only react on explicit button presses anyway - it can still ask the backend for isLidClosed in its onProfileLoad method. FIXED-IN: 5.7.4 Differential Revision: https://phabricator.kde.org/D2325 M +0 -5 daemon/powerdevilcore.cpp http://commits.kde.org/powerdevil/48c3dca61d7cb808c904a3a3659b2cd36fba1866
This patch will be part of the upcoming Plasma 5.7.4 release (due 23 August) and since we also improved KScreen's output detection in the 5.7 cycle to include your DisplayPort monitor, both issues (suspend when closing the first time and when switching activities) should be fixed then \o/