Inconsistency in the displayed lock screen...
mpolidori opened this issue · 14 comments
Sometimes, when I come back from sleep, the lock screen is invisible. I can see the screen as I left it, but everything is locked until I enter my password. Working as expected.
Other times, in the same situation, the entire screen is black, with a password prompt (which I'm guessing is the default?). Again, working as expected.
I'm using GNOME on Arch
What version of physlock? How is it started? Are there any error messages?
Current version is 11, from AUR.
It's initiated in /etc/systemd/system/lock.service
[Unit]
Description=Lock the screen on resume from suspend
[Service]
User=p
Environment=DISPLAY=:0
ExecStart=/usr/bin/physlock
[Install]
WantedBy=suspend.target
I don't see any error messages. It is still functioning as intended, other than what's displayed on the screen. I've searched all over for similar problems and couldn't find any solutions.
Is this reproducible when you start physlock manually from a terminal?
I just tried from the terminal. I can't reproduce it. It consistently shows a black screen with the password prompt. Does that mean it's an issue with some external source? Do you have any ideas about what could be inconsistently preventing physlock from being visible?
I haven't observed a pattern.
The only pattern I noticed is that this happens if my laptop is in sleep/suspend mode for long periods
Can you please test it with the [Service] section of your service file changed to:
[Service]
User=p
Environment=DISPLAY=:0
Type=forking
ExecStart=/usr/bin/physlock -d
I tried the above settings. They didn't solve the problem. I have tried variations based on the arch wiki and forums. I also tried adding sleep 1, 2, and 3 to the config, hoping the delay would fix it. If there is anything else I can try, let me know.
mpolidori, have you tried using xss-lock (available in Arch's [community] repo) to handle automating running physlock on suspend? It deals with all the finicky dbus stuff to inhibit the actual suspend until physlock has a chance to run.
Let me know if that solves your issue; if so, I can add xss-lock to the optdepends in the physlock package newly added to Arch's [community].
So far, it's working for me with the invocation "xss-lock physlock &" in my xinitrc.
I set it up with xss-lock as recommended and it seems to have solved the problem for me. 24 hours without any issues.
Glad to hear that, mpolidori!
muennich, do you consider the existence of a third-party wrapper program for this sort of thing to be sufficient to close the bug, or would you prefer for someone to submit patches adding dbus suspend to physlock?
Instead of implementing the Inhibitor Interface in physlock itself, I would rather refer to xss-lock which does exactly that. From my understanding, the inhibitor interface would also require that physlock is running all the time and activates the lock screen as a rection to certain dbus events.
But I still hope that a simple ordering in the .service file can fix this. Something like:
[Unit]
Description=Lock the screen on suspend
Before=systemd-suspend.service
[Service]
Type=forking
User=p
Environment=DISPLAY=:0
ExecStart=/usr/bin/physlock -d
[Install]
WantedBy=suspend.target
@mpolidori can you please try that service file without xss-lock?
@muennich unfortunately that config doesn't fix it
mpolidori, because with systemd, typically DISPLAY=:$XDG_VTNR, try that file without setting "Environment=..." at all. If that doesn't work, try substituting "DISPLAY=:1" for "DISPLAY=:0" in that service file.
I‘m closing this due to inactivity. It‘s related to systemd and xss-lock fixes it.