You are not logged in.
Pages: 1
Hey,
So recently whenever my monitor turns on after being turned off for no activity, instead of getting i3lock lock screen what I see first is a screenshot of my workspace.
I have to press a key to see the i3lock lock screen. I didn't change anything related to DPMS or i3lock files that could've caused this.
If I manually,
i3lock && xset dpms force off
it works as it should.
Any idea whats wrong?
Last edited by 0R4bb1t (2020-06-15 07:42:03)
Offline
How did you make dpms call i3lock in the first place? Are you sure it's dpms or another trigger?
Offline
Thanks for replying,
No I don't call i3lock from dpms. Maybe I wasn't clear before. I usually lock a session manually using a keybind to i3lock, then after some minutes dpms suspends the screen.
After that whenever I press a key or move mouse to wake the screen up, instead of i3lock screen what I see is a screenshot of my workspace.
I have to press a key again to see the i3lock screen. I want to fix that and i3lock to display like it used to.
Offline
What window manager and/or compositor do you use? Also something like autorandr?
Possible scenario: The dpms deactivates the output, shrinking the root window. When it gets reactivated the root window gets resized and the i3lock window only gets display w/ an update/damage event triggered to the compositor.
Offline
What window manager and/or compositor do you use? Also something like autorandr?
Possible scenario: The dpms deactivates the output, shrinking the root window. When it gets reactivated the root window gets resized and the i3lock window only gets display w/ an update/damage event triggered to the compositor.
wm - i3-gaps
compositor - picom
no autorandr
Your explanation makes much sense. Maybe this started happening when I switched to picom from compton. If so how can we resize i3lock instead of the root window or make i3lock the root window?
Offline
I'd first try to figure whether the compositor is indeed the cause.
kill the process, lock w/o it, wait for the dpms (you can do sth. "sleep 5; xset dpms force off"), give the monitor a brief moment to adapt, then check the resulting visual behavior.
You may also want to timer a "sleep 10; xrandr -q" to see whether the dpms state has any impact on the randr configuration.
Offline
Now that I think about it, I - hazily - remember having this problem with i3, i3lock and compton a very long time ago. Maybe this behavior was fixed after the fork?
EDIT: After a quick glance at my docs, it actually wasn't compton, but xcompmgr and not even yet xcompmgr-dana.
Last edited by Awebb (2020-06-15 05:55:30)
Offline
I found the issue. It was the compositor. I re-read picom wiki and there's a fix for slock for the same problem. It worked for i3lock as well.
in ~/.config/picom/picom.conf I simply had to uncomment,
no-fading-openclose = true;
Thanks guys!
Offline
Pages: 1