after the update to 236.1 the KMenu needs 3sec to show the "Leave" tab, when plasma is restarted (which works in the current version sys-auth/elogind-235.2-r2 without any delay) and the "Power Management" System Settings in kde takes ~30sec to get shown. As the Kmenu also shows the "Suspend" and "Hibernate" options, i think the bug is related to the energy interface. Reproducible: Always Steps to Reproduce: 1. restart plasma 2. Open Kmenu and click on the "Leave" tab 3. ait 3 secs or 1. open the System Settings 2. Select "Power Management" 3. Wait 30 sec 4. Power Management gets shown 5. Ever tab selection (Activity Settings, Adavanced Settings) in the "Power Management" Dialog takes again 10 secs
Second that. Moreover changing screen brightness level by Fn keys has that delay too.
Created attachment 531946 [details] elogind-236.dmesg.log Confirming your observations. At the same time, dmesg is seeing unusual elogind messages.
(In reply to Andreas Sturmlechner from comment #2) > Created attachment 531946 [details] > elogind-236.dmesg.log > > Confirming your observations. At the same time, dmesg is seeing unusual > elogind messages. I am not sure if it is related, but could be helpful in debugging process. I have managed to suppress those messages by removing elogind service from boot level (IIRC this is optional). According to the wiki elogind should be started as soon as the first service calls it via dbus, or if built with USE="pam" (which is my case). Obviously strange behavior stays unchanged.
(In reply to PrSo from comment #1) > Second that. > Moreover changing screen brightness level by Fn keys has that delay too. That has something to do with the latest update, I guess Powerdevil. I had used elogind-236.1 for over a week before I released it, and all was fine. Then I updated kde-frameworks, and from there on, changing the Brightness only works when the OSD with the level is faded away. However, I have had this in the past quite a few times. Annoying as hell, but has nothing to do with elogind. On https://github.com/elogind/elogind/issues/59 this is discussed already. However, it seems that the elogind update is only a small part of the problem. And I do not know yet, which. In the meantime I am working on migrating systemd commits to elogind. I'll skip 237 and go straight for 238. This will hopefully fix the current issues, as analyzing them has brought little, but cost me a lot of time already. In the meantime I have looked through the attached dmesg.log, and there is nothing unusual in there. That is a perfectly fine dbus communication between the elogind-daemon (:1.4) and a few processese. From the communication (look for 'member=' entries) it seems like kactivitymanagerd and Powerdevil are involved. However, if you look at the time stamps of the "Got message" versus "Sent message" entries with any process and their demands, you will see, that elogind always answers in less than 0.001 seconds.
Created attachment 531982 [details] dbus-monitor output (In reply to Sven Eden from comment #4) Thank you for the response. After rethinking you cold be right. In my case the problem is related with powerdevil responsiveness, but downgrading elogind _only_ to version 235.2-r2 make slowdowns go away tough. (BTW I had to remove "powermanagementprofilesrc" from .config folder to make powerdevil start again, so definitely smth has changed in power management handling). I have attached also "dbus-monitor" output taken during powerdevil startup to look for if there is something odd and if it could be related with powerdevil <-> elogind <-> dbus communication process, but I personally don't see anything strange here, or I am lacking knowledge. Anyway, I am staying on 235.2-r2 and looking forward for 238. Thanks.
This issue has been fixed in the newest releases: https://github.com/elogind/elogind/releases/tag/v236.2 https://github.com/elogind/elogind/releases/tag/v238.1 For The 235 Series, a new release fixes another two bugs found in the meantime: https://github.com/elogind/elogind/releases/tag/v235.5
It would be great to see those new versions make their way in the Gentoo repo. Any blocker that would prevent this from happening?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ff7d6a35bb2c1694949a56546011e761ee092e88 commit ff7d6a35bb2c1694949a56546011e761ee092e88 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2018-06-30 19:57:35 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2018-06-30 20:47:31 +0000 sys-auth/elogind: Drop 236.1 Bug: https://bugs.gentoo.org/655448 Package-Manager: Portage-2.3.41, Repoman-2.3.9 sys-auth/elogind/Manifest | 1 - sys-auth/elogind/elogind-236.1.ebuild | 118 ------------------------ sys-auth/elogind/files/elogind-236.1-docs.patch | 24 ----- 3 files changed, 143 deletions(-)
(In reply to Kilian Cavalotti from comment #7) > Any blocker that would prevent this from happening? Mostly that there are not enough hours in a day.
