HP Victus 16-s1xxx: opening the lid soft-blocks Wi-Fi (firmware scancode 0xd7 -> KEY_WLAN -> rfkill)

[speedybits]

Summary

On the HP Victus 16-s1xxx, opening the laptop lid soft-blocks the Wi-Fi radio. Wi-Fi stays off until it is re-enabled by hand, so the machine silently drops off the network every time the lid is opened.

This is not a driver or signal problem. The firmware injects a wireless-toggle keypress on the internal PS/2 keyboard controller during lid-open, and the kernel's rfkill-input handler does exactly what it is told.

Root cause

Full chain:

lid opens
  -> firmware injects scancode 0xd7 (e057) on the i8042 controller
  -> systemd hwdb rule "svnHP*" in 60-keyboard.hwdb maps 0xd7 -> KEY_WLAN
  -> kernel rfkill-input: rfkill_schedule_toggle(RFKILL_TYPE_WLAN)
  -> rfkill_set_block(blocked=1)
  -> radio soft-blocked, stays blocked until manually cleared

The offending mapping is systemd's generic any HP machine rule (/usr/lib/udev/hwdb.d/60-keyboard.hwdb):

evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP*:pn*:*
 KEYBOARD_KEY_d7=wlan

On most HP laptops 0xd7 is a real Fn key. On this model the firmware also emits it on lid-open, so the generic rule turns a lid event into "disable Wi-Fi".

Confirmed with an ftrace kprobe on the rfkill entry points. Stack captured at the moment of the block:

rfkill_schedule_toggle          (a1=1 = RFKILL_TYPE_WLAN)
input_handle_events_default
input_pass_values
input_event_dispose
input_handle_event
input_event
atkbd_receive_byte
ps2_interrupt
serio_interrupt
i8042_handle_data
i8042_interrupt
__handle_irq_event_percpu
...

i8042 / atkbd confirms the internal keyboard controller. A USB HID keyboard would arrive via usbhid_irq -> hid_input_report and cannot appear on this path — relevant because this machine also had a USB KVM attached, which the stack rules out.

Reading the input device directly confirms the keycode and scancode:

*** HIT keycode=238 (KEY_WLAN) value=1 scancode=0xd7

And the mapping is live on the internal keyboard:

$ udevadm info /dev/input/event2 | grep KEYBOARD_KEY_d7
E: KEYBOARD_KEY_d7=wlan

$ grep -A2 'AT Translated Set 2 keyboard' /proc/bus/input/devices
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
H: Handlers=sysrq kbd leds event2 rfkill      <-- rfkill handler bound

Timing, from a lid-open (millisecond-resolution, merged from the raw lid input device, rfkill event, and the journal):

10:27:48.174695   LID OPENED (SW_LID=0)
10:27:48.178165   kernel: wlo1: deauthenticating ... (Reason: 3=DEAUTH_LEAVING)   +3.5ms
10:27:48.230472   rfkill: idx 1 type 1 op 2 soft 1 hard 0                         +56ms
10:27:48.231728   NetworkManager: rfkill: Wi-Fi now disabled by radio killswitch
10:27:48.231764   NetworkManager: device (wlo1): activated -> unavailable
                  ... stays blocked indefinitely

Note the deauth precedes the rfkill, so simply clearing the block afterwards still costs a full re-association (~5s measured). Preventing the keypress avoids the disconnect entirely.

Affected hardware

Model	Victus by HP Gaming Laptop 16-s1xxx
Vendor / board	HP / 8C9C
BIOS	Insyde F.15 (2025-03-26)
Wi-Fi	Realtek RTL8852BE (rtw89_8852be)
Kernel	7.1.9-arch1-2
Omarchy	4.0.1-1

Steps to reproduce

1. Connect to Wi-Fi on an affected Victus.
2. Close the lid, then open it.
3. Wi-Fi is soft-blocked (rfkill list shows Soft blocked: yes for the wlan device) and stays off.

Reproduces 100% of the time here.

Proposed fix

Neutralise the scancode for this model only, following the existing install/hardware/ convention (cf. asus/fix-z13-touchpad.sh).

install/hardware/hp/fix-victus-lid-wlan.sh:

# Stop lid-open from disabling Wi-Fi on HP Victus 16-s1xxx.
#
# The firmware injects scancode 0xd7 (e057) on every lid-open. systemd's
# generic "svnHP*" rule in 60-keyboard.hwdb maps 0xd7 to KEY_WLAN, and the
# kernel's rfkill-input handler turns that keypress into a Wi-Fi soft block,
# so opening the lid drops the machine off the network until Wi-Fi is
# re-enabled by hand.

if omarchy-hw-match "Victus by HP Gaming Laptop 16-s1"; then
  if [[ ! -f /etc/udev/hwdb.d/61-omarchy-hp-victus-lid-wlan.hwdb ]]; then
    sudo mkdir -p /etc/udev/hwdb.d
    sudo tee /etc/udev/hwdb.d/61-omarchy-hp-victus-lid-wlan.hwdb >/dev/null <<'HWDB'
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHP:pnVictusbyHPGamingLaptop16-s1xxx:*
 KEYBOARD_KEY_d7=reserved
HWDB
    sudo systemd-hwdb update
    sudo udevadm trigger --subsystem-match=input --action=change
  fi
fi

Verified working on the affected machine: after applying, udevadm info /dev/input/event2 reports KEYBOARD_KEY_d7=reserved and lid-open no longer touches the radio.

Trade-off: if a physical wireless/airplane key on this model also emits 0xd7, it stops working. The Victus 16 has no dedicated wireless key as far as I can tell, and nmcli radio wifi off / the network applet are unaffected — but worth noting.

I am happy to open a PR if the approach looks right.

Upstream

The real fix arguably belongs in systemd's 60-keyboard.hwdb as a model-specific exception to the blanket svnHP* rule. Happy to file that separately; shipping the override in Omarchy fixes affected users sooner regardless.

Related

• RTL8852BE Wi-Fi dead after s2idle; rtw89 resume wedges the chip #7003 — RTL8852BE Wi-Fi dead after s2idle. Same chip, different failure (resume path); this one is purely the input/rfkill path and occurs with no suspend involved.