## 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`:

```bash
# 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

- #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.