## System details

ThinkPad T490 (20N2, type 20N20008US), Omarchy 4.0.4, `linux-omarchy 7.2.5-3-omarchy`, Hyprland.

## What's wrong?

The **F10 (Bluetooth) key does nothing**. Every other F-row key on this model works: F1 mute, F2/F3 volume, F4 mic mute, F5/F6 brightness, F8 airplane mode (toggles the `phy0` rfkill switch). F9/F11/F12 are Windows-only functions ("open settings", "keyboard settings", "user-defined"), so nothing to bind there.

Pressing F10 produces **no kernel log line, no rfkill state change, and no visible effect**. The Bluetooth adapter stays exactly as it was.

### Diagnosis

`thinkpad_acpi` does receive the key. Reading `/dev/input/event4` ("ThinkPad Extra Buttons") directly shows:

```
EV_MSC  MSC value=72
EV_KEY  0xed (KEY_BLUETOOTH)  value=1
EV_KEY  0xed (KEY_BLUETOOTH)  value=0
```

So the driver reports `KEY_BLUETOOTH` (237) to userspace, but it never touches the `tpacpi_bluetooth_sw` rfkill switch, which is the switch that actually powers `hci0` on this machine:

```
$ rfkill list
11: tpacpi_bluetooth_sw: Bluetooth
```

What gates the action is `hotkey_mask`. The default the driver picks is `hotkey_recommended_mask`:

```
$ cat /sys/devices/platform/thinkpad_acpi/hotkey_mask
0xff8c7ffb
```

That mask is missing the bit that corresponds to the Bluetooth hotkey on this model. Adding bit 20 (`0x00100000`) is all it takes:

```
$ echo 0xff9c7ffb | sudo tee /sys/devices/platform/thinkpad_acpi/hotkey_mask
```

After that, F10 reliably toggles the radio: `tpacpi_bluetooth_sw` flips and `hci0` appears/disappears (`bluetoothctl show` → `Powered: yes` / no controller). Verified by isolating the bit one at a time — bit 20 alone is the one that matters, and a module reload with the option below is enough to make it stick.

### Workaround in place

`/etc/modprobe.d/thinkpad-acpi.conf`:

```
options thinkpad_acpi hotkey=enable,0xff9c7ffb
```

I deliberately did **not** use `hotkey_all_mask` (`0xfffffffb`), even though it also works, because the driver docs warn against it: bits 2/15/16/17 are volume and brightness, which the firmware handles on its own on this model.

### Two things that might be worth fixing upstream

1. **The recommended mask.** For this 2018+ model the recommended mask leaves the Bluetooth hotkey masked, so the key is inert while every neighbouring key works. It looks like the recommended mask simply wasn't updated for the F-row layout of these ThinkPads.

2. **No feedback in userspace, even when it works.** With the mask open, the toggle happens entirely inside the kernel, so nothing userland can render a response. On top of that, `KEY_BLUETOOTH` (237) isn't in the XKB keymap (`/usr/share/X11/xkb/symbols` has no `I237` mapping), so libinput produces no keysym and Hyprland can't bind the key at all. The bar's Bluetooth widget does update silently when the radio state changes. Would it be reasonable for the `omarchy.bluetooth` panel to fire a notification/OSD when the adapter's power state changes, no matter who flipped it (F10, the panel, or the menu)?

Side note, possibly related: the panel toggles power through `rfkill block bluetooth` (the generic switch), while F10 flips `tpacpi_bluetooth_sw` (the ThinkPad switch). That split is what #10011 and #11739 are about — the widget becoming unreachable once rfkill cuts radio power.