Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
KDE Power management disable suspend on lid close
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
hACknAT
n00b
n00b


Joined: 17 Aug 2006
Posts: 4

PostPosted: Sun Nov 04, 2018 9:34 pm    Post subject: KDE Power management disable suspend on lid close Reply with quote

Hi All,

I lost the function of KDE Power management to prevent suspending when my laptop lid is closed and external monitor is connected.
The menus in System settings are still there but changing anyone of them doesn't prevent the suspending of the laptop.
I have 2 external monitors and often need to close the lid and use external monitor + kbd + mouse.

I'm not exactly shure which one of the 120 packages world upgrade caused this.
I'm currently using plasma-meta-5.14.2-r2
The above mentioned upgrade also included.
New version of Qt package
New version of xorg
New version of eudev

I have tried to emerge the old version of kde-plasma/powerdevil but this also did not solve my issue.

Please let me know if anyone of you have some suggestions how to fix this issue.
Back to top
View user's profile Send private message
Gh0str1d3r
Guru
Guru


Joined: 27 May 2008
Posts: 411

PostPosted: Mon Nov 05, 2018 10:18 pm    Post subject: Reply with quote

I have a similar problem: The setting "When power button pressed" is completely ignored and the computer powers off when I press the button. This behavior came with the last KDE update a few days ago.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13485

PostPosted: Tue Nov 06, 2018 3:01 am    Post subject: Reply with quote

In both cases, I suggest you start with identifying which component takes the unwanted action. Are you using an ACPI listener? If yes, does it have configured actions for these events? If yes, are those configured actions responsible for the unwanted action?
Back to top
View user's profile Send private message
hACknAT
n00b
n00b


Joined: 17 Aug 2006
Posts: 4

PostPosted: Tue Nov 06, 2018 8:13 am    Post subject: KDE Power management disable suspend on lid close Reply with quote

In my case it looks like the kernel is directly responsible for the suspension of the laptop.
I stoped the acpid service today and close and open the lid which leads to this lines in my /var/log/messages

Nov 6 09:06:30 Gentoo kernel: [13814]: Lid closed.
Nov 6 09:06:30 Gentoo kernel: [13814]: Suspending...
Nov 6 09:06:32 Gentoo kernel: [13814]: Suspending system...
Nov 6 09:06:32 Gentoo kernel: PM: suspend entry (deep)
.... and 100 more of suspending different devices
Nov 6 09:06:42 Gentoo kernel: [13814]: System resumed.
Nov 6 09:06:42 Gentoo kernel: [13814]: Lid opened.

I believe this is a normal behavior of the kernel, but KDE Power management should prevent it when KDE is working.
I also have the power button issue as Gh0str1d3r as well.

Do i need to pass the kernel events to acpdi to handle it ?
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13485

PostPosted: Wed Nov 07, 2018 3:23 am    Post subject: Reply with quote

I don't see the C string Lid closed anywhere in the current kernel source. That text appears in a few places, but none that could become printable strings written to a log file. What kernel version are you using?
Back to top
View user's profile Send private message
Gh0str1d3r
Guru
Guru


Joined: 27 May 2008
Posts: 411

PostPosted: Wed Nov 07, 2018 9:32 am    Post subject: Reply with quote

I have the same entries, with standard gentoo kernel 4.18.3:

Code:
[   76.819734] [2133]: Lid closed.
[   76.822561] [2133]: Suspending...
[   76.825185] [2133]: Suspending system...
[   76.825221] PM: suspend entry (deep)
[   76.825223] PM: Syncing filesystems ... done.
[   76.946443] Freezing user space processes ... (elapsed 0.146 seconds) done.
[   77.092609] OOM killer disabled.
[   77.092610] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[   77.094086] Suspending console(s) (use no_console_suspend to debug)
[   77.094487] wlp58s0: deauthenticating from 0c:68:03:5f:c4:01 by local choice (Reason: 3=DEAUTH_LEAVING)
[   77.747729] ACPI Error: Cannot release Mutex [PATM], not acquired (20180531/exmutex-359)
[   77.747733] ACPI Error: Method parse/execution failed \_SB.PCI0.LPCB.ECDV._Q66, AE_AML_MUTEX_NOT_ACQUIRED (20180531/psparse-516)
[   79.446921] ACPI: EC: interrupt blocked
[   79.473321] ACPI: Preparing to enter system sleep state S3
[   79.476789] ACPI: EC: event blocked
[   79.476789] ACPI: EC: EC stopped
[   79.476790] PM: Saving platform NVS memory
[   79.476811] Disabling non-boot CPUs ...
[   79.483543] smpboot: CPU 1 is now offline
[   79.495532] smpboot: CPU 2 is now offline
[   79.506213] smpboot: CPU 3 is now offline
[   79.508829] ACPI: Low-level resume complete
[   79.508892] ACPI: EC: EC started
[   79.508892] PM: Restoring platform NVS memory
[   79.509536] Enabling non-boot CPUs ...
[   79.509582] x86: Booting SMP configuration:
[   79.509583] smpboot: Booting Node 0 Processor 1 APIC 0x2
[   79.510102]  cache: parent cpu1 should not be sleeping
[   79.510262] CPU1 is up
[   79.510308] smpboot: Booting Node 0 Processor 2 APIC 0x1
[   79.510783]  cache: parent cpu2 should not be sleeping
[   79.510936] CPU2 is up
[   79.510976] smpboot: Booting Node 0 Processor 3 APIC 0x3
[   79.511448]  cache: parent cpu3 should not be sleeping
[   79.511601] CPU3 is up
[   79.514864] ACPI: Waking up from system sleep state S3
[   79.542937] ACPI: EC: interrupt unblocked
[   79.607172] ACPI: EC: event unblocked
[   79.607344] usb usb1: root hub lost power or was reset
[   79.607346] usb usb2: root hub lost power or was reset
[   79.941388] usb 1-3: reset full-speed USB device number 3 using xhci_hcd
[   80.182425] usb 1-4: reset full-speed USB device number 4 using xhci_hcd
[   80.422319] usb 1-1: reset full-speed USB device number 2 using xhci_hcd
[   80.640357] psmouse serio1: synaptics: queried max coordinates: x [..5666], y [..4734]
[   80.662308] usb 1-5: reset high-speed USB device number 5 using xhci_hcd
[   80.676469] psmouse serio1: synaptics: queried min coordinates: x [1276..], y [1118..]
[   80.755386] ACPI Error: Cannot release Mutex [PATM], not acquired (20180531/exmutex-359)
[   80.755391] ACPI Error: Method parse/execution failed \_SB.PCI0.LPCB.ECDV._Q66, AE_AML_MUTEX_NOT_ACQUIRED (20180531/psparse-516)
[   80.858422] OOM killer enabled.
[   80.858423] Restarting tasks ... done.
[   80.886760] Bluetooth: hci0: read Intel version: 370810011003110e00
[   80.886765] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
[   80.951302] PM: suspend exit
[   80.951327] [2133]: System resumed.
[   80.951887] [2133]: Lid opened.


In addition to the failure to respond to ACPI events as defined in the kde system settings, my pc also became unstable since the last kde update (froze / crashed 3 times in 3 days). This might or might not be related.
Back to top
View user's profile Send private message
mahdi1234
Guru
Guru


Joined: 19 Feb 2005
Posts: 537
Location: far from new world orderia

PostPosted: Mon Nov 26, 2018 7:07 pm    Post subject: Reply with quote

Are you guys by any chance using Skype? I saw this strange behavior after today's kernel update, but since it was the same after booting previous one I had look thru suspicious updates in the last month and Skype stand out as it requires now elogind to work.

Removed that crap both skype and elogind and it works as before (don't have KDE though). Also I'm using openrc should that matter, which I think is not probably that friendly with elogind shite.
_________________
http://gentoo.mahdi.cz <-- gentoo package search engine
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 6822
Location: Austria

PostPosted: Mon Nov 26, 2018 7:51 pm    Post subject: Reply with quote

mahdi1234 wrote:
Removed that crap both skype and elogind and it works as before (don't have KDE though). Also I'm using openrc should that matter, which I think is not probably that friendly with elogind shite.

You should not have more than exactly one session manager on your system, is all there is to say to that. elogind is *exactly* made for non-systemd init like openrc.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
mahdi1234
Guru
Guru


Joined: 19 Feb 2005
Posts: 537
Location: far from new world orderia

PostPosted: Mon Nov 26, 2018 8:04 pm    Post subject: Reply with quote

asturm wrote:
mahdi1234 wrote:
Removed that crap both skype and elogind and it works as before (don't have KDE though). Also I'm using openrc should that matter, which I think is not probably that friendly with elogind shite.

You should not have more than exactly one session manager on your system, is all there is to say to that. elogind is *exactly* made for non-systemd init like openrc.

I'm not using any login manager just plain startx, so I don't understand your comment or maybe I'm wrong and startx counts. Crap here stands for skype to be clear as it required elogind (which I obviously don't need for anything).

It would be more interesting why this caused sleep on lid close? When I tried /etc/inid.d/elogind status it was not even running, this might help someone else who needs skype if you have more insights.
_________________
http://gentoo.mahdi.cz <-- gentoo package search engine
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 6822
Location: Austria

PostPosted: Mon Nov 26, 2018 8:06 pm    Post subject: Reply with quote

Even if you use only startx you need exactly-one-of ( consolekit elogind systemd ) on DEs like Plasma or stuff requiring privileges won't work. But yes, skype as an application requiring logind is a first (to me, at least).
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
mahdi1234
Guru
Guru


Joined: 19 Feb 2005
Posts: 537
Location: far from new world orderia

PostPosted: Mon Nov 26, 2018 9:05 pm    Post subject: Reply with quote

Good to know ... but then shouldn't this be handled by portage?

I seem to have one package with consolekit use flag which is pambase and polkit depends on consolekit as well which in turn lxsession requires (LXDE user) .. what I mean this dep of skype on elogind will cause trouble to people with consolekit installed and there's no blocking message from portage, I had to learn hard way (and probably those guys above suffering from the same). If there's only-one-of-those and I have to choose between lxsession and skype and I knew that before hand, well you know the answer anyway :)
_________________
http://gentoo.mahdi.cz <-- gentoo package search engine
Back to top
View user's profile Send private message
hACknAT
n00b
n00b


Joined: 17 Aug 2006
Posts: 4

PostPosted: Tue Nov 27, 2018 12:47 am    Post subject: Reply with quote

mahdi1234 wrote:
Are you guys by any chance using Skype? I saw this strange behavior after today's kernel update, but since it was the same after booting previous one I had look thru suspicious updates in the last month and Skype stand out as it requires now elogind to work.

Removed that crap both skype and elogind and it works as before (don't have KDE though). Also I'm using openrc should that matter, which I think is not probably that friendly with elogind shite.


Actually i just tried the think you suggest and finally everything is back to normal.
I strugle with this issue for a long time and keep trying to remove and reinstall diffrent kind of packages without any work.
Today i first remove Skype only which doesnt remove the issue, but after removing elogind my KDE Powermanager is back to normal.
But the question is do i really need elogind ?

* These packages depend on elogind:
net-misc/networkmanager-1.14.4 (elogind ? >=sys-auth/elogind-219)
sys-apps/accountsservice-0.6.50-r1 (elogind ? >=sys-auth/elogind-229.4)
sys-apps/dbus-1.12.10 (elogind ? sys-auth/elogind)
sys-auth/pambase-20150213-r2 (elogind ? sys-auth/elogind[pam])
sys-auth/polkit-0.115-r1 (elogind ? sys-auth/elogind)
sys-fs/udisks-2.8.1 (elogind ? >=sys-auth/elogind-219)
sys-process/procps-3.3.15-r1 (elogind ? sys-auth/elogind)
x11-misc/sddm-0.18.0 (elogind ? sys-auth/elogind)

Regards and thanks you.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13485

PostPosted: Tue Nov 27, 2018 1:54 am    Post subject: Reply with quote

As I understand it, this problem cannot be directly handled by Portage. Portage would do well if it were reasonable to say that you cannot install more than one member. For example, if they all insist on installing /usr/bin/session-management-daemon, then you cannot install more than one at once because they would collide over which package gets to use that name. Per asturm's comment, you must run exactly one member from the set. However, it's perfectly legal to install more than one member, provided that you do not run more than one at a time. You might do this if you want to use systemd sometimes, and openrc other times. In that case, you need one of the other tools when you run without systemd. You don't want to remove/reinstall those tools every time you reboot between systemd and openrc. You might also do this if you have two users on the system (or two user accounts, say one for personal/entertainment and one for work) and one of those accounts wants to use consolekit dependent programs and the other wants to use elogind dependent programs.
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2858
Location: Bay Area, CA

PostPosted: Thu Dec 06, 2018 7:45 pm    Post subject: Reply with quote

mahdi1234 wrote:
Good to know ... but then shouldn't this be handled by portage?

I seem to have one package with consolekit use flag which is pambase and polkit depends on consolekit as well which in turn lxsession requires (LXDE user) .. what I mean this dep of skype on elogind will cause trouble to people with consolekit installed and there's no blocking message from portage, I had to learn hard way (and probably those guys above suffering from the same). If there's only-one-of-those and I have to choose between lxsession and skype and I knew that before hand, well you know the answer anyway :)
I spent the better half of day troubleshooting random suspend failures and KDE power mgmt failures because of this. I think portage should have blocked skype because elogind is not my USE flags but consolekit is.

skype ebuild also has a bug. It hard depends on elogind||systemd, and just pulls it. It should use the elogind USE flag. I would have got a block while retrying skype.

I have now masked elogind.
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2273
Location: Bardowick, Germany

PostPosted: Fri Dec 07, 2018 12:56 pm    Post subject: Reply with quote

devsk wrote:
mahdi1234 wrote:
Good to know ... but then shouldn't this be handled by portage?

I seem to have one package with consolekit use flag which is pambase and polkit depends on consolekit as well which in turn lxsession requires (LXDE user) .. what I mean this dep of skype on elogind will cause trouble to people with consolekit installed and there's no blocking message from portage, I had to learn hard way (and probably those guys above suffering from the same). If there's only-one-of-those and I have to choose between lxsession and skype and I knew that before hand, well you know the answer anyway :)
I spent the better half of day troubleshooting random suspend failures and KDE power mgmt failures because of this. I think portage should have blocked skype because elogind is not my USE flags but consolekit is.

skype ebuild also has a bug. It hard depends on elogind||systemd, and just pulls it. It should use the elogind USE flag. I would have got a block while retrying skype.

I have now masked elogind.
The dependency of skype is either systemd or elogind. It is sad that they do not support ConsoleKit2. Hopefully they do that someday.

In the meantime it would be good if the ebuild would display a big fat warning if neither systemd nor elogind are in the set USE flags.

The problem with pulling in elogind when it isn't used globally is, that any process that requests org.freedesktop.login1 from dbus will cause an elogind daemon to get started by dbus if none is running.
And that elogind daemon will happily intercept your lid event and send your laptop to sleep.

Solution: Edit /etc/elogind/logind.conf and tell elogind to not care about power events. Then you should not have any problems with it being pulled in by skype.
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum