Comment 50 for bug 1307545

> Yes, we know this. The logjnd-handle-lid-switch property is being used as "fix" for the blank screen bug. If logind handles the lid event, it will send two separate signals which control light-locker (lock session before suspend, switch to unlock screen on resume).

Ah, I suspected something of the kind.

Here is a summary of the issues (as I understand it): The vt switching by light-locker (or rather lightdm) is the root cause for two issues, which were attributed to xfpm, but have nothing to do with xfpm:
1) system suspends in certain situations, although xfpm is configured not to suspend in those situations
2) in certain situations the screen stays switched off after unlocking

Besides the trivial case for 1), cf. comment #48, both issues arise, if the lid is closed when the vt switch happens. If we call the user session vt1 and the unlock screen session vt2, the event chains look (approximately) as followed:
1) lid close on vt1 -> xfpm blocks logind and executes as configured -> screen locks and switches to vt2 -> vt2 has no logind inhibitor log -> logind suspends the system.
2) lid close on vt1 -> xserver (?) switches the screen off for vt1 -> screen locks and switches to vt2 -> user wants to unlock -> screen gets switched on on current active sesion, i.e vt2 -> authentication -> switch to vt1 -> turned off screen, because on vt1 it was never switched on again

If this analysis is correct, we have two approaches to solve both issues:
a) adapt light-locker to never make a vt switch while the lid is closed. That would be something like making late-locking a general behavior.
b) adapt light-locker (or maybe even lightdm) to tackle each problem on its own. E.g. the unlock screen session needs an inhibitor lock too and possibly turn on the screen of the session it switches to after unlocking.