omarchy-pods
AirPods in the Omarchy bar: per-pod and case battery, listening mode, adaptive noise level, conversation awareness, one-bud ANC and ear detection.
What is it?
What it is
A C++ Omarchy plugin that displays AirPods status (battery, listening modes, ANC, ear detection, case lid) in the desktop bar by reading a JSON status file written by a bundled librepods daemon fork.
Why it exists
Linux lacks native AirPods support: BlueZ does not expose per-pod battery or AAP protocol data, and upstream librepods lacks the state file, control verbs, and model coverage needed for a live panel. This plugin bundles a modified daemon that fills those gaps so the bar can show real-time AirPods status.
Who should use it
Linux users with Omarchy desktop environment who need detailed AirPods monitoring and control
Who should avoid it
Users without Omarchy desktop environment, non-AirPods users, and those seeking basic audio controls (use stock Audio panel)
Stars over time
+7 stars in the last 1 day
How it works
A quick walkthrough in plain English
How omarchy-pods works
Step 1 of 3
You interact with it
Open omarchy-pods, send a request, or connect it to your stack.
Features
Advantages
- Event-driven design means zero CPU usage when idle
- Shows only controls the connected device actually supports
- Graceful degradation when daemon is unavailable with clear status message
- Best audio quality by selecting highest-bitrate codec (SBC-XQ) over AAC
- No direct Bluetooth stack interaction - uses daemon abstraction
- MIT licensed panel code allows flexible reuse
- Comprehensive documentation with troubleshooting guidance
- Separate GPL-3.0 daemon allows independent updates
- Handles stale case lid state transparently during active connection
- Service restarts automatically after reboot via graphical-session.target
Disadvantages
- Requires building and maintaining a custom forked daemon from librepods
- Case lid state holds last known value while pods stay connected
- Standard Bluetooth profiles limit microphone to 16 kHz mSBC or 8 kHz CVSD
- Daemon persists after plugin removal and must be manually uninstalled
- High-quality microphone requires separate device or unreleased AACP feature
- Many dependencies to build (cmake, ninja, qt6-connectivity, qt6-tools, qt6-declarative, pkgconf, libpulse)
- Some audio profiles missing means no HFP connection with no error logged
- Only works with specific AirPods models - older models like AirPods 1/2/3 get no panel
- Pairing secrets stored in owner-only directory that persists with plugin removal
- Upstream librepods has unmerged high-res mic implementation not yet available
Installation
native
omarchy plugin add https://github.com/thisisgm/omarchy-pods --enable ~/.config/omarchy/plugins/io.github.thisisgm.omapods/setup
FAQ
Why does the plugin need a custom daemon instead of using BlueZ or the standard librepods package?
Standard BlueZ does not expose battery information for AirPods through org.bluez.Battery1, and upstream librepods packages lack the status file, extended verbs (ca:, onebud:, adaptive:), and an up-to-date model map. This plugin's bundled daemon includes every Apple model number through 2026 AirPods Max 2, so the panel shows the correct hardware capabilities instead of staying hidden.
Why are volume, output device switching, Spatial Audio, and microphone controls not in this panel?
Volume and output device are handled by the stock Audio panel (press Tab to reach it), which manages PipeWire sinks. Spatial Audio has no Linux renderer, so there is nothing to display. Microphone mode is not an AirPods control—the AAP protocol carries no mic packet, so mic selection also belongs in the stock Audio panel.
Why does selecting the AirPods as a microphone reduce audio playback quality?
Bluetooth HFP voice profiles (headset-head-unit at 16 kHz mSBC or headset-head-unit-cvsd at 8 kHz) replace the A2DP playback profile rather than coexist with it. A card cannot offer high-quality SBC-XQ/AAC sink and a microphone simultaneously. To keep high-quality playback, use a separate microphone device and let the daemon defer profile changes while a capture is active.
Why does the case lid state sometimes stop updating?
Lid state comes from BLE advertisements, which the daemon pauses while the control link is active to prevent audio crackling. As a result, lid state holds its last value for as long as the pods stay connected. Per-pod battery, ANC, and ear detection continue refreshing over the control link.
How does the panel know which AirPods model I have and what features to show?
The panel reads the model identifier the daemon reports and looks it up in its capability map. AirPods 1, 2, 3, and plain AirPods 4 show no listening section because they lack ANC. AirPods Pro 3 dropped the Off mode, so that row does not appear. AirPods Max 2 shows Conversation Awareness but not One-Bud ANC, and no case battery.
What does it mean when the panel shows 'librepods not running'?
The plugin cannot find the librepods daemon or librepods-ctl on PATH. Without it, the panel has no battery, mode, or capability data to display. Run the setup script to build and start the daemon, or manually install the daemon and enable librepods.service.
Featured in Videos
YouTube tutorials and walkthroughs for omarchy-pods
Alternatives
Similar projects ranked by category, topics, and text overlap.