You are not logged in.
Pages: 1
Hey!
After 2 system updates recently, my i3 install has begun to fail. Every 10 minutes or so, windows stop responding to the keyboard and mouse, as if they are unfocused. The keybinds for volume and such also become "sticky" as if the key is still being pressed after release. The only way I can fix this is by switching to another tty and switching back, and it gets very irritating. Also recently, everytime I close my lid, my computer freezes completely, and betterlockscreen's clock stops updating. Anyone have any idea how to fix this? Thanks.
The pacman logs from both upgrades:
https://pastebin.com/Q6Tpx3ut
Output of systemctl list-dependencies sleep.target --all:
https://pastebin.com/TgMBMVMH
Output of i3 --moreversion
Binary i3 version: 4.22-34-gfde43a07 © 2009 Michael Stapelberg and contributors
Running i3 version: 4.22-34-gfde43a07 (pid 835)
Loaded i3 config:
/home/sawntoe/.config/i3/config (main) (last modified: Tue May 16 17:46:16 2023, 332205 seconds ago)
The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3Replicating the closing lid problem:
https://pastebin.com/mSc4dtYV
It seems that my computer thinks it's overheating, and I can assure you that that is most certainly not the case.
Edit: "echo 'disabled' > /sys/class/thermal/thermal_zone0/mode" has solved the second issue.
Last edited by sawntoe (2023-05-23 13:56:23)
Offline
updates for linux and xf86-input-libinput, you could try the lts kernel.
The situation sounds a bit like an active grab (as eg. popups would cause)
/etc/X11/xorg.conf.d/10-server.conf
Section "ServerFlags"
Option "AllowDeactivateGrabs" "true" # also run setxkbmap -option grab:break_actions
Option "AllowClosedownGrabs" "true"
EndSectionnb. the setxkbmap requirement!
This will allow to break grabs w/ Ctrl+Alt+Keypad-Divide and kill the grabbing client w/ Ctrl+Alt+Keypad-Multiply
Pop up a context window, break the grab and try to close the popup by clicking outside the window - should no longer work.
THIS IS A MAJOR SECURITY RISK as screenlockers will rely on grabbing the input to protect the session, but w/ this in place you can simply kill the locker.
So this is ONLY for debugging, to figure whether and maybe which client actively grabs the input.
The cause might be hardware (ie. some modifier key actually sticks)
Offline
Hey! Thanks for the reply.
Switching to the LTS kernel seems to do nothing.
I managed to log the grabs active when the problem happens. May I ask if you happen to see anything wrong with it? Thanks!
Offline
[ 17903.395] client pid 920 i3 -a --restart /run/user/1000/i3/restart-state.920
[ 17903.395] at 17882207 (from passive grab) (device thawed, state 1)
[ 17903.395] core event mask 0x3
[ 17903.395] passive grab type 2, detail 0x7a, activating key 122
[ 17903.395] owner-events false, kb 1 ptr 0, confine 0, cursor 0x0
[ 17903.395] (II) End list of active device grabsWell, there certainly is an active grab.
It's held by i3 itself and the triggering key 122 would by default be XF86AudioLowerVolume - check your i3 config what that might do.
Offline
Oh, that lowers the volume on my computer. The sticky keys problem I was relating to earlier was referring to the volume keys specifically, so I think the two things may be related.
In my i3 config:
bindsym XF86AudioRaiseVolume exec --no-startup-id "volume --inc"
bindsym XF86AudioLowerVolume exec --no-startup-id "volume --dec"In volume:
#!/bin/bash
# icons
iDIR='/usr/share/icons/dunst'
# Get Volume
get_volume() {
volume=`amixer get Master | tail -n1 | awk -F ' ' '{print $5}' | tr -d '[]'`
echo "$volume"
}
# Get icons
get_icon() {
vol="$(get_volume)"
current="${vol%%%}"
if [[ "$current" -eq "0" ]]; then
icon="$iDIR"/volume-mute.png
elif [[ ("$current" -ge "0") && ("$current" -le "30") ]]; then
icon="$iDIR"/volume-low.png
elif [[ ("$current" -ge "30") && ("$current" -le "60") ]]; then
icon="$iDIR"/volume-mid.png
elif [[ ("$current" -ge "60") && ("$current" -le "100") ]]; then
icon="$iDIR"/volume-high.png
fi
}
# Notify
notify_vol() {
get_icon && dunstify -u low --replace=69 -i "$icon" "Volume : $(get_volume)"
}
# Increase Volume
inc_volume() {
amixer -Mq set Master,0 5%+ unmute && notify_vol
}
# Decrease Volume
dec_volume() {
amixer -Mq set Master,0 5%- unmute && notify_vol
}
# Toggle Mute
toggle_mute() {
amixer get Master | grep '\[on\]' &>/dev/null
if [[ "$?" == 0 ]]; then
amixer set Master toggle && dunstify -u low --replace=69 -i '/usr/share/icons/dunst/volume-mute.png' "Mute"
else
amixer set Master toggle && get_icon && dunstify -u low --replace=69 -i "$icon" "Unmute"
fi
}
# Toggle Mic
toggle_mic() {
amixer get Capture | grep '\[on\]' &>/dev/null
if [[ "$?" == 0 ]]; then
amixer -D pulse sset Capture toggle && dunstify -u low --replace=69 -i "$iDIR/microphone-mute.png" "Microphone Switched OFF"
else
amixer -D pulse sset Capture toggle && dunstify -u low --replace=69 -i "$iDIR/microphone.png" "Microphone Switched ON"
fi
}
# Execute accordingly
if [[ "$1" == "--get" ]]; then
get_volume
elif [[ "$1" == "--inc" ]]; then
inc_volume
elif [[ "$1" == "--dec" ]]; then
dec_volume
elif [[ "$1" == "--toggle" ]]; then
toggle_mute
elif [[ "$1" == "--toggle-mic" ]]; then
toggle_mic
else
get_volume
fi(The code for volume isn't mine, it's yoinked from adi1090x)
Last edited by sawntoe (2023-05-21 06:33:25)
Offline
I guess it's more likely to happen if you just keep the key pressed on autorepeat?
These things can be slow af, so in my shortcut bound volume script I start w/
[ -e /tmp/.notify.vol.lock ] && exit
touch /tmp/.notify.vol.lockand end w/
rm /tmp/.notify.vol.lockto limit the frequency to the script execution.
(The code inbetween is relatively slow for me because it looks for (active) media players or the active window to add a "now playing" like hint)
Offline
Hey thanks! It does seem to be caused by my volume script.
Is there any chance you could send yours? Thanks! The vol.lock doesn't seem to fix the problem for me.
Offline
It might be more i3 tripping over itself, try to fire on "bindsym --release"
Offline
After doing that, the volume script doesn't seem to fire anymore ![]()
After pressing the volume keys, the grab problem comes back very quickly.
This time, the activating key is 123, my vol up key.
Last edited by sawntoe (2023-05-21 08:02:02)
Offline
That would indicate the key failign to release.
What happens if you skip dunst and bind the keys to amixer (only)
bindsym XF86AudioRaiseVolume exec --no-startup-id "amixer -Mq set Master,0 5%+ unmute"
bindsym XF86AudioLowerVolume exec --no-startup-id "amixer -Mq set Master,0 5%- unmute"Edit:
xmodmap -pk | grep -i 123XF86AudioRaiseVolume doesn't do much different.
Last edited by seth (2023-05-21 08:02:22)
Offline
It seems to work perfectly fine! I don't get the grab issue. How do I incorporate notifications back in without causing the issue again, though?
Offline
It's possibly an interaction between i3 and the dunst window (showing up/disappeaing) that causes this.
Try to use the script again but comment away the dunstify call in notify_vol() (still keep get_icon)
Is the dunst window floating?
Offline
Oops, I managed to reproduce the issue with the new script after spamming bot volume keys at the same time.
Testing with dunstify -t 10000 test and xprop, I get this:
_NET_WM_WINDOW_OPACITY(CARDINAL) = 4294967200
_NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NOTIFICATION, _NET_WM_WINDOW_TYPE_UTILITY
WM_CLASS(STRING) = "Dunst", "Dunst"
_NET_WM_NAME(UTF8_STRING) = "Dunst"
WM_NAME(STRING) = "Dunst"Last edited by sawntoe (2023-05-21 08:38:05)
Offline
Oops, I managed to reproduce the issue with the new script after spamming bot volume keys at the same time.
So not dunst, i3.
Still, does the dunstify-less script act on "bindsym --release"?
What if you explicitly for the scritp (though I'd assume that i3 has to do that anyway)
bindsym XF86AudioRaiseVolume exec --no-startup-id "volume --inc &"
bindsym XF86AudioLowerVolume exec --no-startup-id "volume --dec &"Offline
It seems to work fine too!
Offline
So it solves the original problem?
Offline
Let me try it with dunst on. If it works, I'll mark it as solved! Thanks so much for your help!
UPDATE: It works!
Last edited by sawntoe (2023-05-23 13:55:39)
Offline
You might want to record yoru findings in https://wiki.archlinux.org/title/I3#Troubleshooting
Offline
Pages: 1