(SOLVED) Weird Wi-Fi behaviour when closing laptop lid

Seacat17 · 2025-08-19 15:44:00

I have this weird issue that persists no matter what settings I change.

When I have Wi-Fi enabled it stays on no matter what I do, be it rebooting or locking my device.

However, when I close my laptop lid and open it again, Wi-Fi gets disabled. All the settings related to laptop lid are set to "Do nothing"

What is even weirder is that when I close and open the lid again, Wi-Fi turns itself on again.

It's almost as if closing and opening the lid acted as a Wi-Fi toggle.

journalctl tells me that it has something to do with rfkill.

Aug 19 17:42:46 seacat17-laptop systemd-logind[641]: Lid closed.
Aug 19 17:42:47 seacat17-laptop kscreenlocker_greet[4574]: qt.virtualkeyboard.hunspell: Hunspell dictionary is missing for "en_US". Search paths QList("/usr/share/qt6/qtvirtualkeyboard/hunspell", "/usr/share/hunspell", "/usr/share/mysp>
Aug 19 17:42:47 seacat17-laptop systemd-logind[641]: Lid opened.
Aug 19 17:42:47 seacat17-laptop systemd-networkd[555]: wlan0: Link DOWN
Aug 19 17:42:47 seacat17-laptop wpa_supplicant[708]: rfkill: WLAN soft blocked
Aug 19 17:42:47 seacat17-laptop systemd[1]: Starting Load/Save RF Kill Switch Status...
Aug 19 17:42:47 seacat17-laptop NetworkManager[635]: <info>  [1755618167.8007] device (wlan0): supplicant interface state: disconnected -> interface_disabled
Aug 19 17:42:47 seacat17-laptop NetworkManager[635]: <info>  [1755618167.8007] device (p2p-dev-wlan0): supplicant management interface state: disconnected -> interface_disabled
Aug 19 17:42:47 seacat17-laptop NetworkManager[635]: <info>  [1755618167.8018] manager: rfkill: Wi-Fi now disabled by radio killswitch
Aug 19 17:42:47 seacat17-laptop NetworkManager[635]: <info>  [1755618167.8018] device (wlan0): state change: disconnected -> unavailable (reason 'none', managed-type: 'full')
Aug 19 17:42:47 seacat17-laptop wpa_supplicant[708]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all
Aug 19 17:42:47 seacat17-laptop NetworkManager[635]: <info>  [1755618167.8044] device (p2p-dev-wlan0): state change: disconnected -> unavailable (reason 'supplicant-failed', managed-type: 'full')
Aug 19 17:42:47 seacat17-laptop systemd[1]: Started Load/Save RF Kill Switch Status.
Aug 19 17:42:47 seacat17-laptop wpa_supplicant[708]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all
Aug 19 17:42:47 seacat17-laptop wpa_supplicant[708]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Aug 19 17:42:49 seacat17-laptop systemd-logind[641]: Lid closed.
Aug 19 17:42:50 seacat17-laptop systemd-logind[641]: Lid opened.
Aug 19 17:42:50 seacat17-laptop NetworkManager[635]: <info>  [1755618170.4053] manager: rfkill: Wi-Fi now enabled by radio killswitch
Aug 19 17:42:50 seacat17-laptop systemd-networkd[555]: wlan0: Link UP

What can be the source of the issue?

EDIT1: I got into /etc/systemd/logind.conf and completely disabled everything related to lid switch, setting it all to "ignore". The behavior is still the same even though the lines systemd-logind[641]: Lid closed. and systemd-logind[641]: Lid opened. no longer appear.

Last edited by Seacat17 (2025-09-05 21:39:33)

seth · 2025-08-19 20:03:22

Please post the output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

You've at least systemd-networkd and networkmanager enabled and it should at most be one of those.

Seacat17 · 2025-08-21 18:50:26

seth wrote:

Please post the output of
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
You've at least systemd-networkd and networkmanager enabled and it should at most be one of those.

[seacat17@seacat17-laptop ~]$ find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
bluetooth.service                        | bluetooth.target.wants
dbus-org.bluez.service                   | system
dbus-org.freedesktop.home1.service       | system
dbus-org.freedesktop.network1.service    | system
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.oom1.service        | system
dbus-org.freedesktop.resolve1.service    | system
dbus-org.freedesktop.timesync1.service   | system
default.target                           | system
display-manager.service                  | system
fstrim.timer                             | timers.target.wants
gcr-ssh-agent.socket                     | sockets.target.wants
getty@tty1.service                       | getty.target.wants
NetworkManager.service                   | multi-user.target.wants
NetworkManager-wait-online.service       | network-online.target.wants
nvidia-hibernate.service                 | systemd-hibernate.service.wants
nvidia-resume.service                    | systemd-hibernate.service.wants
nvidia-resume.service                    | systemd-suspend.service.wants
nvidia-resume.service                    | systemd-suspend-then-hibernate.service.wants
nvidia-suspend.service                   | systemd-suspend.service.wants
p11-kit-server.socket                    | sockets.target.wants
pipewire-pulse.socket                    | sockets.target.wants
pipewire-session-manager.service         | user
pipewire.socket                          | sockets.target.wants
remote-fs.target                         | multi-user.target.wants
speech-dispatcher.socket                 | sockets.target.wants
sshd.service                             | multi-user.target.wants
systemd-homed-activate.service           | systemd-homed.service.wants
systemd-homed.service                    | multi-user.target.wants
systemd-networkd.service                 | multi-user.target.wants
systemd-networkd.socket                  | sockets.target.wants
systemd-networkd-wait-online.service     | network-online.target.wants
systemd-network-generator.service        | sysinit.target.wants
systemd-oomd.service                     | multi-user.target.wants
systemd-resolved.service                 | sysinit.target.wants
systemd-timesyncd.service                | sysinit.target.wants
wireplumber.service                      | pipewire.service.wants
xdg-user-dirs-update.service             | default.target.wants
[seacat17@seacat17-laptop ~]$

seth · 2025-08-21 21:39:51

If you intend to use networkmanager, stop & disable all the systemd-networkd* ones - does that change anything about the behavior?

Seacat17 · 2025-08-21 22:50:54

seth wrote:

If you intend to use networkmanager, stop & disable all the systemd-networkd* ones - does that change anything about the behavior?

I owe you the biggest hug I can give. Disabling systemd-networkd solved the issue. Now Wi-Fi stays on or off no matter what I do with the lid.

Why on Earth were they both enabled by default in ArchInstall tho?
That's not my business I guess.

Problem is solved <3

Seacat17 · 2025-08-28 01:03:34

seth wrote:

If you intend to use networkmanager, stop & disable all the systemd-networkd* ones - does that change anything about the behavior?

Systemd networkd is disabled. The issue resurfaced again.

Aug 28 02:59:13 seacat17-laptop NetworkManager[626]: <info>  [1756342753.7120] manager: NetworkManager state is now CONNECTED_SITE
Aug 28 02:59:13 seacat17-laptop NetworkManager[626]: <info>  [1756342753.7124] device (wlan0): Activation: successful, device activated.
Aug 28 02:59:13 seacat17-laptop systemd-resolved[554]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 10.20.34.140.
Aug 28 02:59:13 seacat17-laptop systemd-resolved[554]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 10.20.34.140.
Aug 28 02:59:14 seacat17-laptop NetworkManager[626]: <info>  [1756342754.0116] manager: NetworkManager state is now CONNECTED_GLOBAL
Aug 28 02:59:16 seacat17-laptop NetworkManager[626]: <info>  [1756342756.3937] audit: op="statistics" interface="wlan0" ifindex=3 args="2000" pid=997 uid=1000 result="success"
Aug 28 02:59:16 seacat17-laptop NetworkManager[626]: <info>  [1756342756.4002] audit: op="statistics" interface="wlan0" ifindex=3 args="500" pid=1122 uid=1000 result="success"
Aug 28 02:59:21 seacat17-laptop systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Aug 28 02:59:21 seacat17-laptop sudo[32969]: seacat17 : TTY=pts/1 ; PWD=/home/seacat17 ; USER=root ; COMMAND=/usr/bin/journalctl -f
Aug 28 02:59:21 seacat17-laptop sudo[32969]: pam_unix(sudo:session): session opened for user root(uid=0) by seacat17(uid=1000)
Aug 28 02:59:23 seacat17-laptop systemd-logind[633]: Lid closed.
Aug 28 02:59:23 seacat17-laptop systemd-logind[633]: Lid opened.
Aug 28 02:59:23 seacat17-laptop kernel: wlan0: deauthenticating from CENSORED by local choice (Reason: 3=DEAUTH_LEAVING)
Aug 28 02:59:23 seacat17-laptop wpa_supplicant[694]: wlan0: CTRL-EVENT-DISCONNECTED bssid=CENSORED reason=3 locally_generated=1
Aug 28 02:59:23 seacat17-laptop wpa_supplicant[694]: wlan0: Added BSSID CENSORED into ignore list, ignoring for 10 seconds
Aug 28 02:59:23 seacat17-laptop wpa_supplicant[694]: rfkill: WLAN soft blocked
Aug 28 02:59:23 seacat17-laptop NetworkManager[626]: <info>  [1756342763.6539] device (wlan0): ip:dhcp4: restarting
Aug 28 02:59:23 seacat17-laptop NetworkManager[626]: <info>  [1756342763.6621] dhcp4 (wlan0): canceled DHCP transaction
Aug 28 02:59:23 seacat17-laptop NetworkManager[626]: <info>  [1756342763.6621] dhcp4 (wlan0): activation: beginning transaction (timeout in 45 seconds)
Aug 28 02:59:23 seacat17-laptop NetworkManager[626]: <info>  [1756342763.6621] dhcp4 (wlan0): state changed no lease
Aug 28 02:59:23 seacat17-laptop NetworkManager[626]: <info>  [1756342763.6621] dhcp4 (wlan0): activation: beginning transaction (timeout in 45 seconds)
Aug 28 02:59:23 seacat17-laptop NetworkManager[626]: <info>  [1756342763.6626] manager: rfkill: Wi-Fi now disabled by radio killswitch
Aug 28 02:59:23 seacat17-laptop NetworkManager[626]: <info>  [1756342763.6626] device (wlan0): state change: activated -> unavailable (reason 'none', managed-type: 'full')
Aug 28 02:59:23 seacat17-laptop NetworkManager[626]: <info>  [1756342763.6627] dhcp4 (wlan0): canceled DHCP transaction
Aug 28 02:59:23 seacat17-laptop NetworkManager[626]: <info>  [1756342763.6627] dhcp4 (wlan0): state changed no lease
Aug 28 02:59:23 seacat17-laptop systemd-resolved[554]: wlan0: Bus client set default route setting: no
Aug 28 02:59:23 seacat17-laptop systemd-resolved[554]: wlan0: Bus client reset DNS server list.
Aug 28 02:59:23 seacat17-laptop NetworkManager[626]: <info>  [1756342763.7051] device (wlan0): set-hw-addr: set MAC address to CENSORED (scanning)
Aug 28 02:59:23 seacat17-laptop NetworkManager[626]: <info>  [1756342763.7054] manager: NetworkManager state is now DISCONNECTED
Aug 28 02:59:23 seacat17-laptop wpa_supplicant[694]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all
Aug 28 02:59:23 seacat17-laptop NetworkManager[626]: <info>  [1756342763.7073] device (p2p-dev-wlan0): state change: disconnected -> unavailable (reason 'supplicant-failed', managed-type: 'full')
Aug 28 02:59:23 seacat17-laptop systemd[1]: Starting Network Manager Script Dispatcher Service...
Aug 28 02:59:23 seacat17-laptop wpa_supplicant[694]: wlan0: Removed BSSID CENSORED from ignore list (clear)
Aug 28 02:59:23 seacat17-laptop wpa_supplicant[694]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all
Aug 28 02:59:23 seacat17-laptop wpa_supplicant[694]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Aug 28 02:59:23 seacat17-laptop systemd[1]: Started Network Manager Script Dispatcher Service.
Aug 28 02:59:23 seacat17-laptop kscreenlocker_greet[32974]: qt.virtualkeyboard.hunspell: Hunspell dictionary is missing for "en_US". Search paths QList("/usr/share/qt6/qtvirtualkeyboard/hunspell", "/usr/share/hunspell", "/usr/share/myspell/dicts")
Aug 28 02:59:24 seacat17-laptop systemd-resolved[554]: Switching to fallback DNS server 1.1.1.1#cloudflare-dns.com.
Aug 28 02:59:33 seacat17-laptop systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.

I think I am beginning to lose my mind :')

seth · 2025-08-28 08:00:18

Aug 28 02:59:14 seacat17-laptop NetworkManager[626]: <info>  [1756342754.0116] manager: NetworkManager state is now CONNECTED_GLOBAL
Aug 28 02:59:16 seacat17-laptop NetworkManager[626]: <info>  [1756342756.3937] audit: op="statistics" interface="wlan0" ifindex=3 args="2000" pid=997 uid=1000 result="success"
Aug 28 02:59:16 seacat17-laptop NetworkManager[626]: <info>  [1756342756.4002] audit: op="statistics" interface="wlan0" ifindex=3 args="500" pid=1122 uid=1000 result="success"
Aug 28 02:59:21 seacat17-laptop systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Aug 28 02:59:21 seacat17-laptop sudo[32969]: seacat17 : TTY=pts/1 ; PWD=/home/seacat17 ; USER=root ; COMMAND=/usr/bin/journalctl -f
Aug 28 02:59:21 seacat17-laptop sudo[32969]: pam_unix(sudo:session): session opened for user root(uid=0) by seacat17(uid=1000)
Aug 28 02:59:23 seacat17-laptop systemd-logind[633]: Lid closed.
Aug 28 02:59:23 seacat17-laptop systemd-logind[633]: Lid opened.
Aug 28 02:59:23 seacat17-laptop kernel: wlan0: deauthenticating from CENSORED by local choice (Reason: 3=DEAUTH_LEAVING)
Aug 28 02:59:23 seacat17-laptop wpa_supplicant[694]: wlan0: CTRL-EVENT-DISCONNECTED bssid=CENSORED reason=3 locally_generated=1
Aug 28 02:59:23 seacat17-laptop wpa_supplicant[694]: wlan0: Added BSSID CENSORED into ignore list, ignoring for 10 seconds
Aug 28 02:59:23 seacat17-laptop wpa_supplicant[694]: rfkill: WLAN soft blocked

If the order there isn't off, you connected, 5s later the NM dispatcher scripts had finished (doesn't mean much, they trail) and you started to follow the journal.
The closed and pretty much immediately opened the lid and that led to a disconnect and software rfkill and then wpa_supplicant went scanning on the NIC (what would require it to get unblocked but that's not in the posted snippet)

1. did you (intentionally) flap the lid?
2. is that a requirement to trigger this behavior?
3. disable NM, make sure acpid isn't enabled either (if you have it installed), connect to the wifi manually or using wifi-menu from the netctl package - can you still trigger this?
4. if yes, install and enabled acpid and monitor the events w/ acpi_listen and see whether the rfkill gets logged there
5. add "rfkill.default_state=1 rfkill.master_switch_mode=0" to the https://wiki.archlinux.org/title/Kernel_parameters (this will enable radio by default and ideally deactivate the acpi event. idk whether you can then still manually toggle rfkill w/ the cli tool, you'll have to try.

Seacat17 · 2025-08-28 17:10:02

seth wrote:

Aug 28 02:59:14 seacat17-laptop NetworkManager[626]: <info>  [1756342754.0116] manager: NetworkManager state is now CONNECTED_GLOBAL
Aug 28 02:59:16 seacat17-laptop NetworkManager[626]: <info>  [1756342756.3937] audit: op="statistics" interface="wlan0" ifindex=3 args="2000" pid=997 uid=1000 result="success"
Aug 28 02:59:16 seacat17-laptop NetworkManager[626]: <info>  [1756342756.4002] audit: op="statistics" interface="wlan0" ifindex=3 args="500" pid=1122 uid=1000 result="success"
Aug 28 02:59:21 seacat17-laptop systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Aug 28 02:59:21 seacat17-laptop sudo[32969]: seacat17 : TTY=pts/1 ; PWD=/home/seacat17 ; USER=root ; COMMAND=/usr/bin/journalctl -f
Aug 28 02:59:21 seacat17-laptop sudo[32969]: pam_unix(sudo:session): session opened for user root(uid=0) by seacat17(uid=1000)
Aug 28 02:59:23 seacat17-laptop systemd-logind[633]: Lid closed.
Aug 28 02:59:23 seacat17-laptop systemd-logind[633]: Lid opened.
Aug 28 02:59:23 seacat17-laptop kernel: wlan0: deauthenticating from CENSORED by local choice (Reason: 3=DEAUTH_LEAVING)
Aug 28 02:59:23 seacat17-laptop wpa_supplicant[694]: wlan0: CTRL-EVENT-DISCONNECTED bssid=CENSORED reason=3 locally_generated=1
Aug 28 02:59:23 seacat17-laptop wpa_supplicant[694]: wlan0: Added BSSID CENSORED into ignore list, ignoring for 10 seconds
Aug 28 02:59:23 seacat17-laptop wpa_supplicant[694]: rfkill: WLAN soft blocked
If the order there isn't off, you connected, 5s later the NM dispatcher scripts had finished (doesn't mean much, they trail) and you started to follow the journal.
The closed and pretty much immediately opened the lid and that led to a disconnect and software rfkill and then wpa_supplicant went scanning on the NIC (what would require it to get unblocked but that's not in the posted snippet)
1. did you (intentionally) flap the lid?
2. is that a requirement to trigger this behavior?
3. disable NM, make sure acpid isn't enabled either (if you have it installed), connect to the wifi manually or using wifi-menu from the netctl package - can you still trigger this?
4. if yes, install and enabled acpid and monitor the events w/ acpi_listen and see whether the rfkill gets logged there
5. add "rfkill.default_state=1 rfkill.master_switch_mode=0" to the https://wiki.archlinux.org/title/Kernel_parameters (this will enable radio by default and ideally deactivate the acpi event. idk whether you can then still manually toggle rfkill w/ the cli tool, you'll have to try.

1. Yes;
2. No, the requirement is to just close and open it, the interval does not matter. The moment I OPEN the lid, Wi-Fi state flips;
3. Did what you said here. The Wi-Fi state still flips on and off;
4. Flipped the lid two times, got this:

[seacat17@seacat17-laptop ~]$ acpi_listen
button/wlan WLAN 00000080 00000000 K
button/wlan WLAN 00000080 00000000 K

EDIT: Connected to my PC thru SSH with my phone and got this:

[seacat17@seacat17-laptop ~]$ acpi_listen
button/lid LID close
button/lid LID open
button/wlan WLAN 00000080 00000000 K
button/lid LID close
button/lid LID open
button/wlan WLAN 00000080 00000000 K

5. Will try this now.

EDIT: I have EFI boot stub and I guess I'm too dumb for my own good. Is there any way to ignore this particular ACPI event? I was toying with my computer while looking at my phone with SSH and it seems like there is a "button" in ACPI part of it's firmware that flips the Wi-FI state each time I open the lid. There's loads of buttons, MUTE, UP/DOWN/LEFT/RIGHT, VOLDN/VOLUP, ect. and all of these are responsible for actual physical buttons on this laptop, while WLAN button gets triggered when I open the lid. Is there any way for me to make my computer just ignore this nonexistent button?

Last edited by Seacat17 (2025-08-28 17:32:47)

seth · 2025-08-28 20:33:55

"rfkill.master_switch_mode=0"
https://wiki.archlinux.org/title/EFI_bo … _boot_stub - efibootmgr, bcfg or startup.nsh ?

But since and as long rfkill is not built-in, you can use https://wiki.archlinux.org/title/Kernel … modprobe.d (in doubt you might have to regenerate the initramfs) - nb. that the syntax is slightly different.
The

cat /proc/cmdline # check the bootloader command line
systool -vm rfkill # check the module parameters, though the master_switch_mode might not be exposed

bumbledbees · 2025-08-29 21:10:23

Seacat17 wrote:

EDIT: I have EFI boot stub and I guess I'm too dumb for my own good. Is there any way to ignore this particular ACPI event? I was toying with my computer while looking at my phone with SSH and it seems like there is a "button" in ACPI part of it's firmware that flips the Wi-FI state each time I open the lid. There's loads of buttons, MUTE, UP/DOWN/LEFT/RIGHT, VOLDN/VOLUP, ect. and all of these are responsible for actual physical buttons on this laptop, while WLAN button gets triggered when I open the lid. Is there any way for me to make my computer just ignore this nonexistent button?

I remember encountering a very similar issue semi-recently on Debian with an HP laptop. Apparently, certain hardware events such as the lid opening/closing send keycodes that are processed like keyboard inputs. According to this article, which I came across when debugging this problem, these keycodes are e057 and e058. You should be able to ignore these by mapping keycodes e057 and e058 to keycode 240 (no-op). The OP in the linked article accomplished this by creating a oneshot systemd service in /etc/systemd/system/hp-keycodes.service, as such:

[Unit]
Description=HP setkeycodes fix

[Service]
Type=oneshot
Restart=no
RemainAfterExit=no
ExecStart=/usr/bin/setkeycodes e057 240 e058 240

[Install]
WantedBy=rescue.target
WantedBy=multi-user.target
WantedBy=graphical.target

Then start/enable the service with

# systemctl daemon-reload
# systemctl enable --now hp-keycodes.service

If this doesn't work, you could try to figure out which keycodes are being sent upon lid open/close by running xev (under X11) or wev (under Wayland) and changing the values of e057/e058 in the above service file to whatever that keycode is on your laptop. Best of luck, hope this helps! :)

Seacat17 · 2025-09-05 21:35:38

bumbledbees wrote:

Seacat17 wrote:
EDIT: I have EFI boot stub and I guess I'm too dumb for my own good. Is there any way to ignore this particular ACPI event? I was toying with my computer while looking at my phone with SSH and it seems like there is a "button" in ACPI part of it's firmware that flips the Wi-FI state each time I open the lid. There's loads of buttons, MUTE, UP/DOWN/LEFT/RIGHT, VOLDN/VOLUP, ect. and all of these are responsible for actual physical buttons on this laptop, while WLAN button gets triggered when I open the lid. Is there any way for me to make my computer just ignore this nonexistent button?
I remember encountering a very similar issue semi-recently on Debian with an HP laptop. Apparently, certain hardware events such as the lid opening/closing send keycodes that are processed like keyboard inputs. According to this article, which I came across when debugging this problem, these keycodes are e057 and e058. You should be able to ignore these by mapping keycodes e057 and e058 to keycode 240 (no-op). The OP in the linked article accomplished this by creating a oneshot systemd service in /etc/systemd/system/hp-keycodes.service, as such:
[Unit]
Description=HP setkeycodes fix

[Service]
Type=oneshot
Restart=no
RemainAfterExit=no
ExecStart=/usr/bin/setkeycodes e057 240 e058 240

[Install]
WantedBy=rescue.target
WantedBy=multi-user.target
WantedBy=graphical.target
Then start/enable the service with
# systemctl daemon-reload
# systemctl enable --now hp-keycodes.service
If this doesn't work, you could try to figure out which keycodes are being sent upon lid open/close by running xev (under X11) or wev (under Wayland) and changing the values of e057/e058 in the above service file to whatever that keycode is on your laptop. Best of luck, hope this helps!

Dude. Dude! DUDE!

I've done the thing, did your solution, and now I'm playing with my computer while watching acpi_listen on my phone and this is what I get now!

[seacat17@seacat17-laptop ~]$ sudo acpi_listen
button/lid LID close
button/lid LID open
button/lid LID close
jack/headphone HEADPHONE plug
jack/headphone HEADPHONE unplug
jack/headphone HEADPHONE plug
button/lid LID open

As you can see, I even toyed with my headphone jack to see if it's not glitching out. It seems like it's not. I've also rebooted my computer multiple times and checked the Wi-Fi behaviour and it's all good now. The issue is gone for good. Thank you.

May I make a Wiki page about this issue? Or could someone with more experience make it so other people with this problem can find the solution quickly?

EDIT: Yeah no, I'm too scared to do this the wrong way. I'm not touching the Wiki unless you guys want me to.

Last edited by Seacat17 (2025-09-05 21:46:18)

seth · 2025-09-05 22:07:41

The correct™ way to go about this would be wiki.archlinux.org/title/Map_scancodes_to_keycodes#Disable_key
You'd make an entry for your model in https://wiki.archlinux.org/title/Laptop/HP (the Victus 15-ec2008ax actually has this behavior recorded), note the problem and link back to this thread for discussed solutions.

Arch Linux

#1 2025-08-19 15:44:00

(SOLVED) Weird Wi-Fi behaviour when closing laptop lid

#2 2025-08-19 20:03:22

Re: (SOLVED) Weird Wi-Fi behaviour when closing laptop lid

#3 2025-08-21 18:50:26

Re: (SOLVED) Weird Wi-Fi behaviour when closing laptop lid

#4 2025-08-21 21:39:51

Re: (SOLVED) Weird Wi-Fi behaviour when closing laptop lid

#5 2025-08-21 22:50:54

Re: (SOLVED) Weird Wi-Fi behaviour when closing laptop lid

#6 2025-08-28 01:03:34

Re: (SOLVED) Weird Wi-Fi behaviour when closing laptop lid

#7 2025-08-28 08:00:18

Re: (SOLVED) Weird Wi-Fi behaviour when closing laptop lid

#8 2025-08-28 17:10:02

Re: (SOLVED) Weird Wi-Fi behaviour when closing laptop lid

#9 2025-08-28 20:33:55

Re: (SOLVED) Weird Wi-Fi behaviour when closing laptop lid

#10 2025-08-29 21:10:23

Re: (SOLVED) Weird Wi-Fi behaviour when closing laptop lid

#11 2025-09-05 21:35:38

Re: (SOLVED) Weird Wi-Fi behaviour when closing laptop lid

#12 2025-09-05 22:07:41

Re: (SOLVED) Weird Wi-Fi behaviour when closing laptop lid

Board footer