-
Notifications
You must be signed in to change notification settings - Fork 404
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure people use xss-lock -l #207
Comments
That sounds like a real hack(?) |
Absolutely. But this is the best way I can think of to make users aware of this misconfiguration. If you have any other suggestions, let me know :) |
I'd probably question why xss-lock not only allows locking after suspension (is there a point to that?), but also why that is the default. I mean this doesn't just affect i3lock specifically, right? |
The -l option enables readiness notifications, which must explicitly be supported by the locker. xss-lock can’t enable it by default without breaking all existing lockers that don’t support it. I also can’t think of a way to re-design the protocol in such a way that it would negotiate with the locker whether readiness notifications are supported. |
Lock before suspending/hibernating, see i3/i3lock#207.
This comment has been minimized.
This comment has been minimized.
Let’s keep your discussion in #275 please. |
Or if you wanna combine blanking as well as locking, you can do that. Just pipe i3lock & dpms standby in one timer. Lock possible on manual suspend too. Also when you exit i3, make sure to kill xidlehook, since you don't wanna have multiple instances on re-login. |
When using xss-lock, the -l flag should be used so that the screen is locked before the machine is suspended. Otherwise, at least on some machines, there’s a race where users can interact with the running applications (e.g. enter “ls” into a terminal) before the screen is locked.
We should:
The text was updated successfully, but these errors were encountered: