Tensaku shows a "Pick a default annotation size factor" dialog until
its persisted state names one. Neither config.toml nor the CLI flag
suppresses it, so ship the state file itself.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Reported to suit the XPS 16 as well, so the tuning now matches both machines and
the directory is named for the pair rather than the one model.
Gating moves from the DMI product name to the product SKU, which is what Dell keys
the Cirrus speaker firmware on -- 10280db9 for the XPS 14, 10280dba for the XPS 16
-- so it identifies the speaker hardware itself instead of a marketing name. SKUs
are compared as whole values, not substrings, so this cannot widen to the rest of
the XPS line the way a short product-name match would: product_family on these
machines is "Dell Laptops".
match_sku and match_dmi are now lists, letting one tuning name every model it
covers. A plain string still works as a single entry.
The measurements in tuning.conf were taken on the XPS 14 (0DB9). The XPS 16 is
covered on report rather than measurement, and tuning.conf and the graph both say
so, because the profile's bass lift and high-pass were fitted against one
machine's excursion and distortion limits.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Laptop speakers ship voiced by the vendor's Windows DSP layer, which Linux does
not get. A tuning restores that as a PipeWire filter-chain in front of the
internal speaker sink, matched to the machine by DMI string and expected sink.
Adding a laptop is a directory under default/audio/tunings with two files and no
new code: matching is data. The XPS 14 DA14260 tuning included here was derived by
measuring the xps-audio-linux EasyEffects profile (MIT) and fitting a biquad chain
to it, so no impulse response or other upstream asset is redistributed. It measures
1.24 dB RMS against that reference, and matches its dynamic range within 0.1 LU --
the reference's multiband compressor turned out to contribute nothing, so a linear
chain replaces it. Bass Q is capped deliberately: a closer magnitude fit swung
group delay 31 ms across 63-80 Hz, which smears bass transients.
The graph runs as its own PipeWire client under its own config name rather than
loading into the audio daemon. The daemon only reads its config at startup, so a
daemon-loaded tuning could only be switched by restarting PipeWire -- which drops
every PulseAudio client's connection, and applications that do not reconnect
(Spotify) then have to be restarted by hand. Hosting it separately also contains
failure, since a malformed tuning breaks only that service.
Three things about the surrounding audio graph needed fixing for this to behave:
- Volume must live downstream of the tuning. omarchy-audio-output-sink is now the
single definition of which sink an output's volume really uses, shared by the
volume keys, the output switcher's OSD and the audio panel, so they cannot
disagree. It resolves the current default output, which keeps it correct when
headphones are selected while a tuning exists.
- The tuning's own output is a movable sink input, so rerouting "all streams" to a
newly selected output would drag the processing onto headphones, or into the
tuning's own sink, which is a cycle. It is pinned, and stream moves are limited
to streams carrying an application.name.
- The physical sink a tuning fronts is not independently selectable, since picking
it would only bypass the tuning, so it is kept out of the output list.
Applying happens at first-run, not finalize-user, because finalize-user also runs
in the ISO chroot where there is no audio server and nothing would retry.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sending the shortcut through wtype's virtual keyboard let the physically
held SUPER merge into the injected chord, so terminals saw
SUPER+CTRL+Insert instead of CTRL+Insert, and injected CTRL+V could even
trigger the SUPER+CTRL+V clipboard manager bind. Send via send_key_state
with no window target instead: explicit mods go straight to the focused
surface, layer-shell panels included.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XnMDbwJXQA3fvW8o8Pwr97
Show a bar indicator whenever tmux has flagged a window, the same state
that highlights the tab, and jump to it on click or with Super + Ctrl + J.
Tmux hooks push the state to the shell, so nothing polls while no pane is
waiting.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bring back per-theme Plymouth unlock theming, dropped when walker +
elephant were removed. Selection now uses the same image carousel as
the theme and background switchers instead of a name list.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
omarchy bar transparent now accepts toggle, flipping the current value
in one jq update (absent counts as opaque, matching the shell).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Static submenus and links now inherit visibility from their descendants,
so hardware sections like Touchpad Haptics disappear on machines without
the hardware instead of opening empty. Laptop Display and Mirror Display
are guarded by omarchy-hw-laptop.
The guard evaluator brace-wraps every when/checked condition before
silencing it, so conditions in the jsonc no longer need their own
>/dev/null plumbing, and parents no longer need to repeat their
children's guards.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Hyprland 0.56 fixed premultiplication in the color-management shader
(hyprwm/Hyprland#14403), so the same opacity values now render visibly
more transparent than on 0.55. Raise each value to its perceptual
equivalent (a^(1/2.2)) to restore the previous look.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Hyprland 0.56 fixed premultiplication in the color-management shader
(hyprwm/Hyprland#14403), so the same opacity values now render visibly
more transparent than on 0.55. Raise each value to its perceptual
equivalent (a^(1/2.2)) to restore the previous look.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Point the Emacs entry in the install-editor menu at a dedicated
omarchy-install-editor-emacs script, matching the pattern already used
for Helix, VSCode, and Zed. The script installs the omarchy-emacs AUR
package and runs its installer, which pulls in emacs-wayland, applies
the theme/font integration, and enables the user emacs.service.
This is the AUR-packaged approach dhh suggested on #4807 (superseding
the in-tree integration proposed there), now that the package exists and
is maintained on the AUR. End-user behavior is unchanged except that a
freshly installed Emacs now tracks the active Omarchy theme and font out
of the box.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
omarchy-update-user-notify.path used PathExistsGlob= on the packaged
migrations directory. That directive is level-triggered: systemd re-checks
it every time the triggered unit deactivates and fires again while the glob
still matches. Since applied migrations stay on disk forever (state lives in
~/.local/state/omarchy/migrations), the glob always matches, so the oneshot
notifier re-triggered itself in a tight loop (~26-66 starts/sec) — burning
about a core and flooding the journal for the whole session.
The loop existed since the unit was introduced, but the default start-rate
limit killed it after 5 iterations, taking the .path unit down with
'unit-start-limit-hit'. That symptom was reported as #6174 and fixed
yesterday by setting StartLimitIntervalSec=0 — which removed the only brake
and turned the capped hiccup into an unbounded busy-loop.
Fix the actual cause instead:
* Drop PathExistsGlob= from the .path unit, keeping the edge-triggered
PathModified= watch for updates that land mid-session.
* Revert the StartLimitIntervalSec=0 override; with the level trigger gone
there is no self-re-fire to trip the limit, and the default limit is a
useful backstop again.
* Preserve the once-per-login pending check the glob used to provide by
giving the service its own WantedBy=graphical-session.target, enabled at
first-run alongside the other user units.
* Add a migration that daemon-reloads, revives a rate-limit-killed .path,
restarts the watcher, and enables the login-time notifier on existing
installs.
Verified with transient path/service units: the old config runs the service
200 times in 3 seconds; the new config runs it zero times while idle and
exactly once when a new migration file lands.
Thanks to @HANCORE-Linux for finding and diagnosing the problem.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Adds shift:both_capslock alongside compose:caps so pressing both Shift
keys together toggles real Caps Lock. Caps Lock alone remains the
Compose key, and single-Shift behavior is unchanged. Provides an escape
hatch when Caps Lock gets stuck on (e.g. after an fcitx5 desync).
Closes#5981
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Brave now publishes brave-origin-bin on AUR, so use it instead of
brave-origin-beta-bin. The stable wrapper also parses flags files
correctly, so Brave Origin can use the normal chromium flags like
the other Chromium-based browsers.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Ports #6092 from master: the video-app opacity opt-out only matched
Chrome/Chromium on the default profile, so Brave, Edge, and non-default
profiles kept the translucent default-opacity styling.
Co-Authored-By: Zeus-Deus <github.commits@widow.cc>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Set misc:initial_workspace_tracking = 0 so new windows appear on the currently
active workspace rather than the one their process was first launched on.
Without this, file-picker dialogs drawn by xdg-desktop-portal-gtk (browser
Open/Save, GTK app choosers, etc.) always open on the workspace where the portal
process started at login (typically workspace 1) instead of following the app
that requested them. So a Save dialog triggered from a browser on workspace 2
pops up on workspace 1, out of view.
Trade-off: an app launched on one workspace that switches away before its window
maps will now open on the new active workspace. In practice the dialog-follows-app
behavior is the more intuitive default.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The skill still described pre-Quattro .conf files and workflows, sending
agents to inactive config files and stale commands. Now covers the Lua
config layout, o.bind/hl.unbind/hl.monitor forms, .d hook directories
with omarchy hook install, plugin cloning, and corrected command routes.
Distilled from #6310.
Co-Authored-By: ssupt <149246609+ssupt@users.noreply.github.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
