Ignore vendor hotkey keyboard devices - #9129

Reviewed at 652c0cb by Claude Opus 5.5. No second opinion: omabot review refused because the day's review budget was spent, so this review is one model's reasoning.

Since this was opened, #10670 changed the click to move every device holding the layout list, so the symptom in #8964 (a click leaves the real keyboard alone) no longer happens on a settled seat. What this pull request still fixes is the reading. I tested that on a worker running quattro, with uinput devices named acer-wireless-radio-control and acer-wmi-hotkeys and kb_layout = us,pl:

• Every device on the same layout: a click moves the keyboard and the label follows, on quattro and on this branch alike.
• After a click to Polish, then Alt+Alt back to English on the keyboard, then a shell restart: on quattro the reading picks acer-wireless-radio-control (furthest along), the label says Polish while the keyboard types English, and the next click sends every device to English, so the keyboard does not move. On this branch the reading picks the keyboard, the label says English, and the click moves it to Polish.

It also drops the two devices from keyboardCount, so a laptop whose only real keyboard is the built-in one stops running the ten-second hyprctl devices poll. The one-line regex is proportionate to that, and it matches Framework's …-wireless-radio-control and dell-wmi-hotkeys as well.

Tests on the worker: keyboard-layout-test.sh (42 passed) and hyprland-keyboard-layout-test.sh (7 passed). ./test/cli fails on vscode generated theme references current theme file, and quattro fails the same test, so it is not caused by this change.

#12350 (Apple SMC power/lid) and #6834 (T2 headset) edit the same regex line, so whichever lands second needs a rebase.

Labelled verified. It is not ready until a second opinion has reviewed this head and the suite passes, which is waiting on the next run and on that quattro failure being fixed.

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no new actionable issues were found.

Summary

Keeps vendor WMI hotkeys and wireless radio controls out of keyboard selection.

• The keyboard widget skips vendor hotkeys and radio controls.

_{Reviews (4) · Last reviewed commit: "Merge quattro into fix/filter-vendor-hot..." · Reviewed by Greptile}

Checked the pushed keyboard-label filtering on current quattro; the keyboard layout regression passes.

Reviewed again at 7b45197, which adds eventKeyboardName rejecting every name isTypedKeyboard rejects, not only hl-virtual-keyboard. Reviewed by Claude Opus 5.5, with a second opinion from Codex Medium.

The new commit is sound. selectKeyboard only ever matches the remembered name against typed keyboards, so an activelayout naming a power button or a vendor hotkey device could never be selected. All it could do was overwrite the last real keyboard's name and push the reading back onto layout progress. Now that name is kept. On a worker, key presses from uinput acer-wireless-radio-control and acer-wmi-hotkeys devices raise no activelayout at all. Those devices only raise one when something runs switchxkblayout on them, as the widget's click does.

I repeated the reproduction at this head on a worker. The seat had uinput acer-wmi-hotkeys, acer-wireless-radio-control and a keyboard, with kb_layout = us,pl. I clicked to Polish, then pressed Alt+Alt back to English on the keyboard, then took a fresh reading of Hyprland's device list. quattro's model reads acer-wmi-hotkeys (Polish), and its next click sends every device to English, so the keyboard stays put. This branch's model reads the keyboard (English), and the click moves it to Polish. The VM's two idle QEMU keyboards were left out of that list, to match a laptop with one keyboard. As Codex pointed out, the wrong reading needs a reading with no remembered keyboard name, such as after a shell restart.

Tests on the worker:

• keyboard-layout-test.sh: 44 passed on this branch, and fails with the model reverted to quattro's.
• hyprland-keyboard-layout-test.sh: 7 passed.
• ./test/cli: fails only on vscode generated theme references current theme file. quattro at f45461a fails the same test, so this change does not cause it.

Codex Medium found no defect in the diff. Its agreement is not guaranteed independent, because it can read this review's working notes.

Still labelled verified. It is not ready until the suite passes on a worker, so it is waiting on that quattro failure being fixed. Nothing is needed from the author.

This had stopped merging cleanly, so I merged quattro into the branch as a27a4d8. The only conflict was in test/shell.d/keyboard-layout-test.sh, where quattro's new table-loading test and this branch's eventKeyboardName assertions were both added at the end of the file. Both are kept, and the code change against quattro is unchanged. Reviewed by Claude Opus 5.5, with a second opinion from Codex Medium.

I checked quattro's two newer commits to the keyboard widget (#15043 and #14433) for interaction with this change. They add no new caller of isTypedKeyboard or eventKeyboardName, and the click still moves every device holding the layout list, so the change does the same thing it did before the merge.

I then verified it again at a27a4d8 on a worker running the shell from this branch. The seat had uinput acer-wmi-hotkeys, acer-wireless-radio-control and a keyboard, with kb_layout = us,pl. I moved every device to Polish, moved the keyboard alone back to English, and read Hyprland's device list. quattro's model reads acer-wmi-hotkeys (Polish), and this branch's model reads the keyboard (English). keyboard-layout-test.sh passes (71) and fails with quattro's model put back. hyprland-keyboard-layout-test.sh passes (20), and the full ./test/cli suite is green.

Codex Medium checked the merge resolution, the regex and the newer quattro commits and found no defects. It also got the same device selection when it replayed the scenario. That agrees with my conclusion, but its independence is not guaranteed.

Nothing is left for the author. This waits on the maintainer.