You are not logged in.
Pages: 1
Hi all,
I seem to be having a similar problem as the user in this post here, except their fix doesn't apply as (to my knowledge) I'm using i3 without a compositor.
To verify this I ran ps and grepped for common compositors, to no result.
As with the linked post, if I shut my laptop lid or wait for the screen to automatically dim, upon waking I see my windows before a key input causes i3lock to render.
However when I tested the command they said fixes their issue, the screen locked twice for some reason? The first lock worked as expected but upon unlocking that I saw my windows and i3lock was triggered on any key press.
Here are the relevant lines in my i3 config.
# Makes closing the lid not crash
exec --no-startup-id xss-lock --transfer-sleep-lock -- ~/.lock.sh
# Keybind to lock screen
bindsym $mod+l exec --no-startup-id loginctl lock-session
#!/bin/bash
amixer get Master | sed '6q;d' | grep -q '\[on\]'
sound=$?
if [ "$sound" -eq 0 ]; then
amixer set Master off
fi
i3lock -n -e --color=000000ff \
--inside-color=00000000 --ring-color=ffffffff \
--keyhl-color=20d020ff --bshl-color=d02020ff \
--line-uses-inside --separator-color=00000000 \
--insidever-color=1858dcff --ringver-color=ffffffff \
--insidewrong-color=d02020ff --ringwrong-color=ffffffff \
--ind-pos="x+86:y+1003" --radius=15 \
--verif-text="" --wrong-text="" --noinput-text=""
if [ "$sound" -eq 0 ]; then
amixer set Master on
fi
Any help is much appreciated!
Last edited by woa183 (2024-07-11 00:02:51)
Offline
Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General
Offline
Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General
Here is the log file I found after rebooting the system and triggering the bug.
It doesn't seem useful to me, have I got the wrong file? /var/log/Xorg.0.log didn't exist.
Offline
[ 16.840] (==) Log file: "/home/chris/.local/share/xorg/Xorg.0.log", Time: Wed Jul 10 14:41:32 2024
Is proper log, but unfortunately a single IGP w/ a single output running on the modesetting driver (I had hoped fro xf86-video-intel and then told you to remove that…)
Back to your condition: you're running i3lock in repsonse to a sleep/dpms and the command in the other thread first calls i3lock and then triggers the dpms (the latter will run i3lock for you again)
Why are you specifying 4-byte colors?
Is this some i3lock fork?
Do you get the same issues w/ merely "i3lock" and no parameters at all? Or with slock?
Offline
[ 16.840] (==) Log file: "/home/chris/.local/share/xorg/Xorg.0.log", Time: Wed Jul 10 14:41:32 2024
Is proper log, but unfortunately a single IGP w/ a single output running on the modesetting driver (I had hoped fro xf86-video-intel and then told you to remove that…)
Back to your condition: you're running i3lock in repsonse to a sleep/dpms and the command in the other thread first calls i3lock and then triggers the dpms (the latter will run i3lock for you again)
Why are you specifying 4-byte colors?
Is this some i3lock fork?
Do you get the same issues w/ merely "i3lock" and no parameters at all? Or with slock?
Hi, thanks for the reply.
Sorry for not clarifying, I'm using i3lock-color instead of vanilla i3lock.
It seems that right now, if I lock the system before letting the screen dim naturally, no problem occurs (I could swear this was happening earlier but doesn't matter right now.)
If I run i3lock with no arguments (that is, replace my lock script in my i3config with i3lock) the error still occurs.
However there's no such issue with slock, although my keybind to run "loginctl lock-session" is no longer working (though the same command in the terminal is fine.)
I assume that this is an issue with i3lock then?
Offline
However there's no such issue with slock, although my keybind to run "loginctl lock-session" is no longer working
slock will fail to grab the keyboard while your shortct is active.
=> what if you add a strategic "sleep 1" before running i3lock?
Offline
However there's no such issue with slock, although my keybind to run "loginctl lock-session" is no longer working
slock will fail to grab the keyboard while your shortct is active.
=> what if you add a strategic "sleep 1" before running i3lock?
Assuming you meant adding sleep 1 to the start of my lock script, nothing changes.
Offline
Does it allow you to use the shortcut with slock?
You could test the vanilla i3lock, does i3lock-color support background images (incl. a snapshot of the desktop)?
Offline
After further research I found this post (which I note you were a participant of!) and the fix here: notably, --composite - worked for me. Sorry for wasting your time by not searching thoroughly enough! I will be marking this issue as SOLVED.
Offline
Pages: 1