[prev in list] [next in list] [prev in thread] [next in thread]
List: systemd-devel
Subject: [systemd-devel] systemd-inhibit --what=handle-power-key broken with systemd 198
From: Manuel.Spam () nurfuerspam ! de (Manuel Reimer)
Date: 2013-03-30 11:01:41
Message-ID: kj6gmm$8sk$1 () ger ! gmane ! org
[Download RAW message or body]
Lennart Poettering wrote:
> Generally on Linux only the X session in the fg will get the
> keypresses. If you switch away with from it, the new one in the bg will
> get it instead. logind will get active hence only if there's nobody on
> that specific VT who wants to take the events.
The understanding, who processes keypresses, depends on the point of view. My
daemon just connects to an input device, so it receives the keypresses *always*
and the active VT doesn't matter.
> Well, note that these specific inhibitors are about inhibiting key
> presses, not actions. i.e. the inhibitor for logind's suspend key
> (i.e. the handling of the key) is independent of the inhibiting for the
> suspend (i.e. the action code can ask for).
Inhibiting "shutdown" would go a bit too far. I don't want to prevent shutdowns
that have been triggered by, for example, clicking a button in a GUI (KDE or
something). And I think there is no way to create a selective inhibitor that
only blocks a shutdown triggered via the power key, right?
Is there a way to enumerate the sessions, that could receive the power key, and
register an inhibitor for all of them? Maybe even with an event that tells me if
new sessions have been created?
The idea behind this was to make it easier for an user to use alternative power
key handlers. I hoped to be able to tell systemd to completely keep away from
power button events while runtime without having to tell the user that he has to
get sure that his init system ignores the power button, first (and then reboot
his system, so logind.conf is interpreted, again).
Yours
Manuel Reimer
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic