Re: [systemd-devel] Handling lid close in logind?
On Tue, 2012-09-18 at 00:28 +0200, Lennart Poettering wrote: On Mon, 03.09.12 22:10, Matthias Clasen (matthias.cla...@gmail.com) wrote: On Mon, Sep 3, 2012 at 5:17 AM, Richard Hughes hughsi...@gmail.com wrote: I don't think the desktop guys want any kind of authentication when the lid is closed. How feasible would it be to do the suspend when the inhibit is removed? I guess then it puts logind into a active but will suspend asap state which might be difficult to handle. As I said on irc, the user experience I envision in this case is: - user closes lid - polkit dialog is shown (not useful because the lid is closed) - we beep a few times to cause the user to open the lid and see the dialog - if the lid is not opened, we forcefully suspend after a few seconds A similar situation where we can't wait for a policykit dialog to be answered is emergency shutdown when the battery runs empty. So, what I wonder is: if this inhibitor is supposed to be ignored, why take it in the first place? I mean, the inhibitor is supposed to inhibit, no? To me it appears really as if the inhibitor should not have been taken in the first place/not have been allowed to be taken in the first place, rather then not being honoured after it was successfully taken. The think thats missing here is that 'click Suspend in menu' and 'close the lid' are really quite different, in terms of how we need to handle them. The first is a user action that can be handled with inhibitors just fine - we'll show the dialog, the user makes an informed decision, no harm. The second is a hardware event (admittedly triggered by user action), we really have no choice but to react to it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Handling lid close in logind?
Am 18.09.2012 14:10, schrieb Matthias Clasen: - user closes lid - polkit dialog is shown (not useful because the lid is closed) - we beep a few times to cause the user to open the lid and see the dialog - if the lid is not opened, we forcefully suspend after a few seconds Since you are talking about me (a user) and I am not sure if this is about just one possible configuration or some hardcoded behaviour: Dialogs and beeps are definitely not what I want to happen on these events. - If I close the lid I want the monitor to go off and after a short while (shorter than usual) the screen should be locked. No suspend! Would be cool if this works for text consoles, too, btw. - If I press the sleep button, I want the notebook to go to sleep as advertised - thats what I asked for, so no questions. It would be ok though to inform me if (e.g. network-) activity is detected and give an option to cancel the sleep for a short time. Could save the long running remote copy I forgot about, but the default action is just going to sleep as requested. - If the battery is nearly dangerously low I want a warning. - If the battery is dangerously low I want the notebook to hibernate. - If the notebook overheats I want a warning and power throttled. - If the notebook still overheats I want it to hibernate. Although I think this is the only reasonable setting ( :-) ), other users will want different things. Please let us have a choice. Just my 2ct ___ 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
