Re: [systemd-devel] [RFC] logind lid switch inhibitors
On Tue, 18.09.12 19:28, David Herrmann (dh.herrm...@googlemail.com) wrote: Heya, - logind from now on handles lid switch/suspend key/power key in all cases, even if a graphical DE is running. In fact, any special handling of graphical DEs in logind is removed entirely. I don't use any DEs but often close the lid while some background job is running (compiler or whatever). Does that mean systemd would suspend the machine in this case? I don't think I can convince the GCC people to use systemd inhibitors (or do they already provide that?). I would actually like to see an option (probably /etc/systemd/logind.conf) that disables this automatic power-management. Sure, there already has been the logind.conf option to disable logind's handling of the keys, and that option will continue to exist. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC] logind lid switch inhibitors
Heya, Currently, logind expects that the DE in the foreground handles the lid switch, the sleep and power keys of the machine. The idea was that the DE would handle the key presses on its own and then issue the right action to logind on the user's behalf. There turned out to be two problems with this approach: - The GNOME folks believe that the user clicking on suspend in the menu and the user closing the lid switch should be two different things. The former should honour inhibitors, possibly showing a dialog to override them (of privs are available). In the latter case the suspend should happen, in any case, ignoring all inhibits. Currently the latter logic is not supported with logind. - People who use minimal DEs wo do not handle power/sleep/lid switch key events do not get handling of these keys and still end up installing acpid to make the keys work. We'd now like to propose the following new logic to deal with both these issues: - logind from now on handles lid switch/suspend key/power key in all cases, even if a graphical DE is running. In fact, any special handling of graphical DEs in logind is removed entirely. - If a desktop wants to intercept some of the keys it needs to take a new inhibitor of types INHIBIT_POWER_KEY_HANDLE, INHIBIT_SLEEP_KEY_HANDLE and INHIBIT_LID_SWITCH_HANDLE. If an inhibit of this kind is taken logind won't handle the respective events. - If GNOME wants to handle power key/sleep key on its own it would just take the two inhinbitor locks for that and be on its own - If GNOME detects that a second screen is plugged in and wants to ensure that in such a case a closed lid should not result in system suspend it also takes appropriate INHIBIT_LID_SWITCH_HANDLE for it. - DEs which cannot handle any of the three events don't have to do anything, as logind will do all handling for them. We think this would solve the two issues nicely, would allow us to remove special magic for graphical logins and would be quite secure, since we don't have to allow sessions to override suspend inhibitors at free will. Only logind itself can choose to ignore inhibitor locks, nobody else. Comments, suggestions? If everybody is happy I'll hack this up tomorrow, and this should hit F18 within the week. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] logind lid switch inhibitors
Hi Lennart On Tue, Sep 18, 2012 at 7:17 PM, Lennart Poettering lenn...@poettering.net wrote: Heya, We'd now like to propose the following new logic to deal with both these issues: - logind from now on handles lid switch/suspend key/power key in all cases, even if a graphical DE is running. In fact, any special handling of graphical DEs in logind is removed entirely. I don't use any DEs but often close the lid while some background job is running (compiler or whatever). Does that mean systemd would suspend the machine in this case? I don't think I can convince the GCC people to use systemd inhibitors (or do they already provide that?). I would actually like to see an option (probably /etc/systemd/logind.conf) that disables this automatic power-management. Or do you intend to add a special target lid-close.target and pull in a system-suspend via wants? This would allow me to simply disable the system-suspend via systemctl but still be able to add other stuff there. Regards David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] logind lid switch inhibitors
On 09/18/2012 05:17 PM, Lennart Poettering wrote: Comments, suggestions? Dont forget the use cases where users simply want to close the lid but still have the machine running with all network connections and what not still running... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] logind lid switch inhibitors
On Tue, Sep 18, 2012 at 8:28 PM, David Herrmann dh.herrm...@googlemail.com wrote: I don't use any DEs but often close the lid while some background job is running (compiler or whatever). Does that mean systemd would suspend the machine in this case? I don't think I can convince the GCC people to use systemd inhibitors (or do they already provide that?). There's always `systemd-inhibit --what=sleep make`... -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] logind lid switch inhibitors
2012/9/18 Mantas Mikulėnas graw...@gmail.com: On Tue, Sep 18, 2012 at 8:28 PM, David Herrmann dh.herrm...@googlemail.com wrote: I don't use any DEs but often close the lid while some background job is running (compiler or whatever). Does that mean systemd would suspend the machine in this case? I don't think I can convince the GCC people to use systemd inhibitors (or do they already provide that?). There's always `systemd-inhibit --what=sleep make`... Doing that for every long running job is cumbersome. Making that configurable on the system(d) level as David suggests, would be an option. Either via a global on/off switch which disables the power management options completely or more fine-grained, like e.g. ActionSleepKey=ignore|sleep|hibernate|poweroff; ActionLidClose=ignore|sleep|hibernate|poweroff; ... -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] logind lid switch inhibitors
David Herrmann dh.herrm...@googlemail.com wrote: I don't use any DEs but often close the lid while some background job is running (compiler or whatever). Do you do that while on battery? If not, then I'd say that a good idea would be to suspend only if closing the lid while on battery, or if removing AC power while the lid is closed. Would that be OK for you? -- Alexander E. Patrakov Sent from Nokia N900 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
