https://bugs.kde.org/show_bug.cgi?id=457859
--- Comment #9 from Jakob Petsovits <jpe...@petsovits.com> --- (In reply to Jakob Petsovits from comment #8) > (In reply to Jakob Petsovits from comment #7) > > Ah yes, you're right. Filtering out PowerDevil by "who" should do the trick. > > Thanks for the good thought, it looks like my brain isn't in top shape today > > :P > > Although there is still the issue of when to check for updates. Right now > PowerDevil monitors the "BlockInhibited" property of the logind D-Bus > interface and re-reads the current list of inhibitors when that property > changes. If an inhibitor for "handle-lid-switch" is already set, adding a > second one won't cause "BlockInhibited" to change. There is an > "NCurrentInhibitors" property which could help with this, but no D-Bus > signal is emitted when it changes. > > One could resort to polling, but that's a terrible hack and we should first > look into a proper long-term solution before considering to add this > temporarily. Again, not my brightest day. The next best thing, which should rather work out, would be not to rely on monitoring properties in the first place. We can make an extra D-Bus call right when the lid-closed event comes in, to see if any "handle-lid-switch" inhibitors other than PowerDevil's own are active at the time of lid closure. We'd still miss the removal of such inhibitors without polling, though. Perhaps if only polling while the lid is already closed and an inhibitor was previously found, the hack isn't too severe. Still, it would be nice if systemd made this easier for us. -- You are receiving this mail because: You are watching all bug changes.
