Re: [systemd-devel] [logind] retroactive lid close handle upon vt switch
On Fri, 23.01.15 15:43, b3nmore (b3nm...@googlemail.com) wrote: Why precisely does your original session inhibit the lid switch? If you want to turn off the lid switch then turn it off properly, inhibition is not really about turning something fully off. It's about temporarily making logind not process it, for example, because you want to process it yourself or so. GNOME for example never inhibits the lid switch, because there's really no reason to. Why does your DE inhibit it? xfpm (the power manager of xfce) allows to configure how the system should react to certain power events. In this case you can configure it to either suspend or hibernate or lock the screen or just switch off the screen, when the lid is closed. In order to do so, xfpm inhibits the handle of the lid switch and initiates the configured pm action on its own. It works as intended with one exception, when one uses a screen locker, which switches vt's (other lockers are o.k.). I'd strongly recommend not doing this this way. Inhibitors aren't really for that. Change logind.conf, or so, to make this a system-wide change. But doing this with inhibitors, only does this temproarily. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [logind] retroactive lid close handle upon vt switch
On Wed, 21.01.15 12:33, b3nmore (b3nm...@googlemail.com) wrote: Hello, consider two vt sessions vt1, vt2. On vt1 handle-lid-switch is inhibited. Now the lid is closed and than a vt switch takes place (e.g. sleep 10 loginctl activate vt2). Now the system suspends. I guess this is because the new active session has no inhibitor lock on handle-lid-switch and therefor retroactively reacts to the closed lid. Is this intentional or could it be changed? Yeah, this is intentional, button inhibtiros are bound to the active session, as they are about processing input keys, and only the fg session should be able to do that. Why precisely does your original session inhibit the lid switch? If you want to turn off the lid switch then turn it off properly, inhibition is not really about turning something fully off. It's about temporarily making logind not process it, for example, because you want to process it yourself or so. GNOME for example never inhibits the lid switch, because there's really no reason to. Why does your DE inhibit it? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [logind] retroactive lid close handle upon vt switch
On 01/23/2015 02:56 PM, Lennart Poettering wrote: Yeah, this is intentional, button inhibtiros are bound to the active session, as they are about processing input keys, and only the fg session should be able to do that. One could argue here, that the lid close event has been already processed by the than active session and a session, which gets activated after the event, should not react retrospectively on it(?). Why precisely does your original session inhibit the lid switch? If you want to turn off the lid switch then turn it off properly, inhibition is not really about turning something fully off. It's about temporarily making logind not process it, for example, because you want to process it yourself or so. GNOME for example never inhibits the lid switch, because there's really no reason to. Why does your DE inhibit it? xfpm (the power manager of xfce) allows to configure how the system should react to certain power events. In this case you can configure it to either suspend or hibernate or lock the screen or just switch off the screen, when the lid is closed. In order to do so, xfpm inhibits the handle of the lid switch and initiates the configured pm action on its own. It works as intended with one exception, when one uses a screen locker, which switches vt's (other lockers are o.k.). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [logind] retroactive lid close handle upon vt switch
Hello, consider two vt sessions vt1, vt2. On vt1 handle-lid-switch is inhibited. Now the lid is closed and than a vt switch takes place (e.g. sleep 10 loginctl activate vt2). Now the system suspends. I guess this is because the new active session has no inhibitor lock on handle-lid-switch and therefor retroactively reacts to the closed lid. Is this intentional or could it be changed? Background: There are screen locker, which use the display managers login screen for unlocking the session; e.g. light-locker + lightdm. Locking a session involves a vt switch to display the authentication screen. If such a locker gets started while the lid is closed, the system suspends, even if the original session inhibited the handle-lid-switch. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
