On 2020-05-21 21:02:20 +0200, Michael Biebl wrote:
> My point is: Only if I stop systemd-inhibit, the system will suspend on
> lid-close. As long as it is running, it does not.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is not what I observe (see below).
> But it might very well be, that I misunderstand what you are trying to
> say. Please try to explain it better then, in more detail.
To reproduce the issue (I've done the test after stopping the
display manager in order to make sure that it does not interfere):
1. Switch to VT 1 and log in.
2. Start a systemd-inhibit lock.
3. Close the lid.
4. Log out (from VT 1).
5. Wait a bit. Nothing happens.
6. Switch to VT 2.
After 6, the system is suspended (with my last test, immediately,
but with a similar test yesterday, this was after a few seconds).
It should not, because the systemd-inhibit lock is still running
(and this can be checked after waking up the system).
I think that the issue occurs when the VT that currently corresponds
to the display is not the one from which the systemd-inhibit lock
has been started. I think that all suspend issues I've seen until
now are in this case (I'm not 100% sure because I initially did not
think that the closed lid was the issue as it does not appear in the
journalctl logs, so that I did not pay attention to the status of
the lid; but that could be the most plausible explanation).
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
