[SOLVED] i3lock and DPMS

0R4bb1t · 2020-06-13 10:45:59

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)

Awebb · 2020-06-13 11:06:05

How did you make dpms call i3lock in the first place? Are you sure it's dpms or another trigger?

0R4bb1t · 2020-06-14 17:19:08

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.

seth · 2020-06-14 20:56:57

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.

0R4bb1t · 2020-06-15 01:59:13

seth wrote:

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?

seth · 2020-06-15 05:33:37

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.

Awebb · 2020-06-15 05:53:32

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)

0R4bb1t · 2020-06-15 07:40:40

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!

Arch Linux

#1 2020-06-13 10:45:59

[SOLVED] i3lock and DPMS

#2 2020-06-13 11:06:05

Re: [SOLVED] i3lock and DPMS

#3 2020-06-14 17:19:08

Re: [SOLVED] i3lock and DPMS

#4 2020-06-14 20:56:57

Re: [SOLVED] i3lock and DPMS

#5 2020-06-15 01:59:13

Re: [SOLVED] i3lock and DPMS

#6 2020-06-15 05:33:37

Re: [SOLVED] i3lock and DPMS

#7 2020-06-15 05:53:32

Re: [SOLVED] i3lock and DPMS

#8 2020-06-15 07:40:40

Re: [SOLVED] i3lock and DPMS

Board footer