Bar status: Steam idle-inhibit, Wi-Fi/SSID, Bluetooth alias/pairable

[Chessing234]

Summary

• Steam idle-inhibit, Wi-Fi over TUN, Bluetooth alias
• Folded Decode iw's escaped SSID before matching it against nmcli's #8235: decode iw escaped SSIDs before nmcli match
• Folded Keep the Bluetooth adapter pairable only while the panel is open #8144: Bluetooth pairable only while the panel is open

Test plan

• Spot-check each folded PR's test plan still applies

[llstrk]

Automated AI review

Community review: Independent automated community review, unaffiliated with the Omarchy team, intended to help prepare PRs for their review.

Verified: four of the five changes do what they claim. The tunnel handling in omarchy-network-status fixes the Wi-Fi-under-VPN case, but it also changes the reported network in a common docked-laptop setup where the base reported Ethernet. The pairable lifecycle has one side effect outside the panel plus an unconfirmed gap, and several new tests stay green when the behaviour they describe is removed.

Change	Result
steam_app_.* idle-inhibit rule	Verified from source: Hyprland 0.56.2 matches classes with RE2::FullMatch, so "steam" never matched games, and Proton's X11 driver sets the class steam_app_<id>. Native Linux games and Proton's Wayland driver use other class names.
omarchy-network-band SSID decode	Verified in a stubbed run: printf %b exactly inverts iw's print_ssid_escaped. Head lists 2.4 5 for accented, CJK, emoji, backslash, \x41-lookalike, edge-space and tab SSIDs, where the base lists only 5. Non-UTF-8 SSIDs still fail to match, which is pre-existing.
Bluetooth alias-first label	Verified from source: Quickshell maps name to BlueZ Alias and deviceName to Name, so a user rename is now shown.
Pairable open/close lifecycle	Verified from source for open, close, popout handoff between monitors, adapter power changes and destruction. Bar.requestPopout closes the old panel only after the new one is open, so the closing instance sees an open sibling and leaves Pairable on.

VPN over Ethernet with Wi-Fi still associated is now reported as Wi-Fi

prefer_wifi_over_tunnel swaps a tunnel route device for any connected Wi-Fi, without checking which link carries the tunnel. NetworkManager can keep Wi-Fi connected alongside Ethernet (default metrics: Ethernet 100, Wi-Fi 600), so a docked laptop running a full-tunnel VPN hits this case.

Stubbed ip/nmcli/iw and a synthetic sysfs tree (fixture names):

Scenario	base	head
WireGuard over Wi-Fi	ethernet wg0	wifi HomeNet … (the intended fix)
Ethernet, Wi-Fi associated, no tunnel	ethernet eth0	ethernet eth0
WireGuard over Ethernet, no Wi-Fi	ethernet wg0	ethernet wg0
WireGuard over Ethernet, Wi-Fi associated	ethernet wg0	wifi HomeNet …; --verbose: iface wlan0 with the idle Wi-Fi byte counters

Impact: in that last case the network panel is titled with the SSID and computes Receiving/Sending from the idle Wi-Fi counters, so it shows near-zero throughput while traffic flows over Ethernet. The speed test is also titled with the SSID. In --verbose after any substitution, ip and gateway still come from the tunnel route while iface, prefix and the counters are Wi-Fi's. The bar's own network pill is NetworkManager-driven and does not read this script, so the visible changes are in the panel, the speed test and the menu's Wi-Fi QR entry rather than the bar.

Suggested change: when the route device is a tunnel, use the device of the lowest-metric non-tunnel default route in the main table (ip -j route show table main default), or at least prefer a connected wired device before Wi-Fi. That matches the panel's own "wired is preferred when both are up" rule. Open PR #12071 ("Show physical network behind TUN routes") already takes the main-table approach for both print_status and print_verbose, and #8866 also changes tunnel handling in this script, so the two approaches probably need reconciling.

Tunnel detection misses TAP and catches modems

• is_tunnel_iface checks <dev>/tun, which the tun driver does not create. The tun driver registers an unnamed sysfs attribute group, so a TUN/TAP device has tun_flags, owner and group directly in its directory (drivers/net/tun.c).
• TAP devices are ARPHRD_ETHER (type 1), not 65534 as the comment says. In the stubbed run, a TAP VPN over Wi-Fi with the real sysfs layout (type 1 plus tun_flags) prints ethernet tap0.
• Type 65534 also covers raw-IP QMI modems (qmi_wwan), and 512 covers PPP/PPPoE. With Wi-Fi associated, a wwan0 or ppp0 default route is replaced by Wi-Fi. Replacing PPP is deliberate in the commit, but its message implies WWAN keeps its route device.

Impact: a TAP VPN over Wi-Fi is still reported as ethernet tap0, so the fix does not reach it. With Wi-Fi associated, a raw-IP WWAN or PPPoE default route is reported as Wi-Fi. NetworkManager prefers Wi-Fi over modems anyway, so the modem case is rare, but PPPoE (metric 460) beats Wi-Fi.

Suggested change: test [[ -e $net_sysfs/$device/tun_flags ]], and fix the TUN/TAP comment. If modems and PPPoE should keep their route device, the route-based selection above also solves that, provided the tunnel test no longer treats ppp0 or a raw-IP wwan0 as a tunnel (for example by using NetworkManager's device type, as #12071 does).

Pairable off also makes pairings started from this machine non-bonding

BlueZ documents Pairable as affecting only incoming pairing, but the kernel also applies it to pairings this machine starts (Linux v7.2, source-verified, no hardware run):

Pairable=false  ->  HCI_BONDABLE cleared
  BR/EDR: IO-capability reply forced to no-bonding (hci_event.c)
          -> link key flushed at disconnect (unless the remote asks for
             dedicated bonding, or it is a legacy PIN pairing)
  LE:     SMP_AUTH_BONDING dropped from the pairing request (smp.c)
          -> keys not persistent

BlueZ's Device.Pair path does not raise Pairable.

Impact: pairing from the panel is fine while the panel is open. Pairing started with omarchy bluetooth device pair <addr>, bluetoothctl pair or another tool while the panel is closed now produces a pairing that is not kept: a Classic (BR/EDR) device loses it at disconnect, an LE device at the latest when bluetoothd restarts. So does a slow panel pairing that only begins after the panel is closed. Before this PR, Pairable stayed on while bt-agent was registered.

Suggested change: have omarchy-bluetooth-device pair turn Pairable on for the duration and restore it afterwards, or document that new devices should be paired from the panel.

Hypothesis: BlueZ can turn Pairable back on while the panel is closed

With the stock AlwaysPairable=false, BlueZ 5.87 sets the adapter bondable whenever an agent becomes the default, and clears it when the last agent goes away (src/agent.c, src/adapter.c). So when bt-agent starts after the shell's first false write, or restarts on failure, Pairable is turned back on. The panel has no onPairableChanged handler, so Pairable would then stay on with the panel closed until the next open/close. A related case: with a non-default nonzero PairableTimeout, BlueZ turns Pairable off while the panel is still open and scanning, and nothing reasserts it.

To settle: after login, without opening the panel, run bluetoothctl show | grep Pairable; then restart bt-agent and check again.

Suggested change (if confirmed): in the existing Connections { target: root.adapter }, handle onPairableChanged by restarting a 1-second single-shot timer that calls root.applyPairable() whether the panel is open or closed. Equal-value writes are already skipped by setPairable and by Quickshell, so the panel cannot loop on its own; the timer limits any tug-of-war with another tool that forces the opposite value to about one write per second.

Overlapping open PRs

• Accept device-initiated Bluetooth Just Works pairing #12897 (same author, also fixes Bluetooth remains pairable after the Omarchy panel is closed #7889) implements pairable differently (syncPairable, plus Component.onCompleted: syncPairable() without this PR's bar === null guard) and edits the same Panel.qml region. Only one of the two approaches can land as-is.
• Fix fullscreen Steam game window rules #11981 moves idle_inhibit = "fullscreen" onto the steam.* rule (which already covers steam_app_*) and removes the unqualified o.window("steam", …) rule that steam-idle-inhibit-test.sh asserts.
• Show the friendly name a Bluetooth device was given, and let it be changed #7837 also changes deviceLabel to prefer the alias, and additionally makes hasHumanName consider both names.

Optional: with the alias-first label, a device whose alias is MAC-, UUID- or whitespace-shaped while its Name is human-readable is now hidden from every panel section, including when connected (the base showed it under its Name). BlueZ never stores such an alias by itself, so this needs a client that saved one. Using the alias only when it passes the human-name check, otherwise Name, covers both directions. #7837 has the same goal but keeps the alias as the label and lets hasHumanName pass if either name is human.

Optional test improvement: these diagnostic mutants of head leave the tests green:

• network-status-tun-test.sh tests a copy of is_tunnel_iface and greps for function names. It never runs omarchy-network-status or uses the new OMARCHY_NET_SYSFS hook. It still passes with 65534 changed to 65535, with Wi-Fi never matched, and with the substitution moved after the wireless check. A stubbed run like network-band-test.sh, covering the four scenarios above, would pin the behaviour.
• The pairable regexes in bluetooth-test.sh still pass with the close-path applyPairable(), the open-path applyPairable(), onEnabledChanged or onAdapterChanged removed. The "open path" regex matches any later applyPairable() in the file. The wantedPairable truth table is behavioural and covers every branch.

network-band-test.sh and the label test fail on the base and on the matching mutants, as intended.

---

Review information

Test scope: Source review of head 33c7120c against merge-base 2fbac0c8, with upstream Hyprland 0.56.2, Linux v7.2, BlueZ 5.87, Quickshell 0.3.1, NetworkManager 1.58.1, iw and Proton source. The PR's tests, base overlays, diagnostic mutants and network-status/band scenarios ran in a sandbox with stubbed ip, nmcli, iw and a synthetic sysfs tree. There was no live Hyprland, Quickshell, BlueZ adapter, NetworkManager or radio: the Steam, label and Bluetooth findings are source-based, and the pairable hypothesis is untested.

AI process: Opus 5.5 Medium coordination and synthesis, Opus 5.5 Xhigh technical review and final fact check, GPT 6 Sol Xhigh search for related issues, Opus 5.5 Medium editorial check.

Opt out: To stop receiving these reviews, reply to this comment saying so.

[Chessing234]

vpn-over-ethernet and tap/modem selection overlap #12071; pairable-while-closed overlaps #12897. holding code changes until those land or maintainers pick a winner.

[omarchybot]

Reviewed at head 33c7120c against quattro. Opus 5.5 read this pull request alongside the open pull requests that change the same code, and Codex Medium compared them separately without seeing that answer. Both reached the same conclusion: four of the five changes here are also made by another open pull request, and in each case the other one is the better fix. The tests were not run on a worker, because a version of these changes that nobody will merge does not need verifying.

Change here	Competing PR	Finding
steam_app_.* idle-inhibit	#11981	#11981 moves idle_inhibit onto steam.*, which already matches steam_app_<id>. It also covers gamescope and stops forcing every class-steam window to float. It removes the o.window("steam", …) rule that steam-idle-inhibit-test.sh asserts, so the two conflict.
Tunnel handling in omarchy-network-status	#12071 (and #8866)	prefer_wifi_over_tunnel substitutes any connected Wi-Fi for a tunnel. A docked laptop with a VPN over Ethernet and Wi-Fi still associated then reports Wi-Fi, with Wi-Fi's idle counters. In --verbose, only iface is swapped, so ip and gateway still come from the tunnel route. is_tunnel_iface checks <dev>/tun, which the tun driver does not create (it creates tun_flags), so a TAP VPN is missed. #12071 picks the lowest-metric non-tunnel default route instead and derives address, prefix and gateway from that route.
Alias-first deviceLabel	#7837	Falling back before trimming means a whitespace alias hides a real Name. hasHumanName and sink matching still look at one name only. #7837 handles all three.
Pairable only while the panel is open	#12897	Your own #12897 reworks the agent and the same Panel.qml handlers. The two need to become one policy. The bar === null guard and the adapter-power handling here are worth carrying over into it.
SSID decode in omarchy-network-band	none	This one stands alone and looks right: printf %b undoes iw's \xNN escaping, so an SSID like Café matches nmcli's raw name again.

I agree with your note above about holding these until the overlapping pull requests are decided. Bundled, this pull request cannot land without conflicting with three others, so I have not marked it verified or ready. The maintainer decides which approach lands for each part. If the SSID decode were split back into its own pull request (as #8235 was), it could be reviewed and verified on its own.