Comment 37 for bug 1307545

> Why does the system suspend in test case "trusty 1b" and "utopic 2b"? The screen should be only locked and neither logind nor xfce4-power-manager should trigger suspend.

Neither does (cf. #30, its the same for utopic 2b), at least not in combination with other screen lockers. I've tested i3lock and the system does exactly as configured in xfpm.

So the questions is more specifically: why does the system suspend in those cases, *if* we use light-locker as locking application?

I've tried to dig into this issue, and this is what I've got so far:
- if set to lock sreen, xfpm calls "xflock4"
- if light-locker is running, xflock4 calls "light-locker-command -l"
- running "light-locker --debug" shows in this case (i.e. lid triggered):
gs-listener-dbus.c: obj_path=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager method=PrepareForSleep destination=(null)

- when calling "xflock4" manually, xflock4 calls "light-locker-command -l"
- running "light-locker --debug" shows now:
gs-listener-dbus.c: obj_path=/org/freedesktop/login1/session/c2 interface=org.freedesktop.login1.Session method=Lock destination=(null)

This means, that somehow in the combination xfpm + light-locker (and only in this combination) a suspend call is sent to (?) logind (and therefor a PrepareForSleep-Signal is emitted). I've been unable to identify, where the suspend call comes from.

Just to make this clear:
xfpm is setup to inhibit systemd/logind's lid handling and to lock the screen on lid close:
xfpm + i3lock -> no suspend
xflock4 + light-locker -> no suspend
xfpm + light-locker -> suspend