* Apply the Intel IPU7 camera's ISP tuning and fix its gain, range and exposure
The XPS 14 / 16 webcam looked soft and grainy because almost none of the
image pipeline was tuned:
- 0011: the graph asks for ISP tuning mode 4, which the OV08X40 tuning
does not carry, so the generic AIC found no tunings and noise
reduction, TNR and sharpening ran on library defaults. Fall back to
the tuning's default ISP container.
- 0010: AIQ emits the raw analog gain register code, which the in-tree
ov08x40 driver halves, so the sensor ran at twice the gain AE and the
ISP noise model assumed.
- 0008: the HAL ignored the requested YUV range and always produced
full-range frames that consumers decode as limited range.
- 0009 + relay config: icamerasrc pinned auto exposure to 1/30 s; a new
fps-range property lets AE lengthen frames in dim light, with gain
capped at 27 dB.
* Guard fps-range against NULL and correct two descriptions
Setting icamerasrc's new fps-range property to NULL, its own default, handed NULL to gst_camerasrc_parse_range, which crashed in strlen(). NULL now leaves the last range in effect, because the HAL has no way to drop a range once set. The value the relay sets goes through unchanged.
The relay comment said AE raises gain past 27 dB once frames reach 15 fps, but gain-range becomes a hard ISO ceiling (manual_iso_max), so gain never goes past it. The 0008 message credited the sensor JSON's yuvColorRangeMode, which only the mock HAL reads.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Free fps-range when icamerasrc is destroyed
finalize never freed the string the fps-range setter allocates, so every icamerasrc element that had the property set leaked it. The other string properties leak the same way upstream and are left to an upstream fix for all of them.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Harden IPU7 PSYS userptr pinning
(cherry picked from commit 5f1d0013b0e37d9229dfb906806dee0e98199035)
* Avoid unverified IPU7 permission assurances
(cherry picked from commit 9ce97d9788f2be508743fe785f8434ccfec7842e)
* Check IPU7 against Omarchy headers without a runtime dependency
Use linux-omarchy-headers only for check(), avoiding Arch headers on installed Omarchy systems and matching the supported kernel build configuration.
Signed-off-by: Afonso Oliveira <afonso.oliveira707@gmail.com>
(cherry picked from commit d0d382c07ea99eca5bb5c52240841db779d24b14)
* Test IPU7 build-only headers and kernel-tree selection
Signed-off-by: Afonso Oliveira <afonso.oliveira707@gmail.com>
(cherry picked from commit eb37cc828fac201a360c35aa1e87a1daf2d5fed1)
* Restrict the IPU7 PSYS node to root
Intel's PSYS driver has two buffer-lifecycle bugs that this package does not fix: a GETBUF that is never mapped leaves the buffer owned by both the PSYS handle and the exported dma-buf, so closing the two is a use-after-free and a double free, and UNMAPBUF drops its mapping reference before clearing the attachment, racing a concurrent dma-buf release. Any account that can open /dev/ipu7-psys0 can reach both.
Nothing but v4l2-relayd@ipu7, which runs as root, opens the node; applications use the v4l2loopback device. With the node at 0600 root:root the camera streams the same, so the video group and the seat user lose nothing and the bugs need root. GROUP and MODE are explicit so the upgrade's change event also tightens nodes on running machines.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Drop the DKMS Intel CVS driver now that linux-omarchy ships it
linux-omarchy and linux-omarchy-bore build drivers/media/i2c/cvs in-tree (CONFIG_VIDEO_INTEL_CVS=m) and carry the same wake-IRQ fix as our 0007 (0542), plus the Nova Lake ACPI ID (0541) that our copy lacks. The DKMS module has the same name and installs under updates/, so on every 7.2+ kernel it displaced the kernel's signed module with an unsigned, older copy: on Nova Lake that copy cannot bind the CVS device and the camera fails, and any later fix in the kernel's driver would be masked. Krzysztof Wilczyński reported the conflict on #723.
Skipping the build only on kernels that carry the driver (BUILD_EXCLUSIVE_CONFIG) would have kept it for stock Arch kernels, but the pacman dkms hook reports every such skip as "exited 77", so every Omarchy kernel update would print a warning. A stock Arch kernel left installed as the fallback boot entry now has no camera.
On upgrade the dkms hook removes intel-cvs and restores the kernel's original module. vision-drivers still covers kernels before 7.2.
* intel-ipu7-camera: build the Lunar Lake HAL plugin and stop rotating its frames
Two Panther Lake assumptions in this package break Lunar Lake boards, where it
is installed by the same hardware detection.
Build both HAL platforms. libcamhal picks its plugin by platform, and a Lunar
Lake machine asks for one that was never built:
CamHAL[ERR] HalAdaptor: load_camera_hal_library, failed to open library:
/usr/lib/libcamhal/plugins/ipu7x.so: No such file or directory
CamHAL[WAR] CameraParserInvoker: parseSensors: No sensors available
so the camera cannot work at all. The proprietary side of it is already
shipped -- libia_aic-ipu7x.so and the rest of that set come from
ipu7-camera-bins today; only the plugin the HAL loads was missing. Upstream
builds both platforms from one configure run and `make install` lays down
/etc/camera/ipu7x/ alongside ipu75xa, including the tuning this hardware
wants (OV08X40_BBG802N3_LNL.aiqb, gcss/OV08X40_BBG802N3_LNL.IPU7X.bin), so the
change is the IPU_VERSIONS list plus 0008, the ipu7x twin of 0006: the
"Intel CVS" pad formats that 1.0.6 added to the ipu75xa sensor config are
needed in the ipu7x one for the same reason, or link validation fails at
stream-on behind the Linux 7.2 bridge entity.
Pick the relay pipeline per board. v4l2-relayd-ipu7.conf rotates every frame
180 degrees, which is right where the sensor is mounted inverted and wrong
here: the sensor reports camera_sensor_rotation = 0 and camera_orientation =
Front, and the picture arrives upside down in every application. camera-init
now writes VIDEOSRC to /run based on the bridge ACPI id and the relay drop-in
reads it. Only INTC10DE takes the new path; INTC10E1, INTC10CF, INTC10E0 and
anything unrecognised keep the packaged pipeline byte for byte, and a boot
where camera-init did not run falls back to it as well.
Verified on a Dell Pro 14 Premium PA14250 (Lunar Lake, INTC10DE, OV08X40 +
HM1092) against intel-ipu7-camera 1.0.6-2 on linux-omarchy 7.2.5-3: with the
package's own intel-cvs DKMS the sensor joins the graph behind "Intel CVS",
the ipu7x plugin built from the pinned commit with 0005 and 0008 resolves
ov08x40-uf on CSI port 0, v4l2-relayd streams 30 fps to /dev/video50 and the
image is upright in a browser.
Note for reviewers: necessary but not sufficient on Lunar Lake. Three more
things this board needs are not in this PR: the sensor probe races the
bridge's runtime suspend (camera-init's `sleep 2` lands while the I2C bus is
still owned by the bridge firmware and ov08x40 reads its chip id as -110),
the in-tree cvs driver's quirk for the Synaptics SVP7500 (06cb:0701) hands
the privacy LED to the host so it never lights, and ipu-bridge before 7.3
does not know the HM1092 IR sensor. Details in #366.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
(cherry picked from commit 9be51b47104da9d115a7d79e04bc2ae5445809fc)
* Derive the Lunar Lake relay pipeline from the packaged one
camera-videosrc-init wrote VIDEOSRC for every board, with a copy of the pipeline the relay config carried when it was written, and its file is read after /etc/v4l2-relayd.d/ipu7.conf. On Panther Lake that replaced this branch's fps-range, gain-range and color-range settings with the old sharpness=80 ev=-1 saturation=10 pipeline. It now writes nothing unless the board is Lunar Lake, and there it takes the packaged pipeline and drops only the rotation, so a later change to the relay config reaches both platforms. It also removes a file left by an earlier run, which camera-init's restart on resume would otherwise keep.
The ipu7x CVS format patch becomes 0012: 0008 is already the YUV range patch.
* Regenerate the Lunar Lake pipeline on every relay start
camera-videosrc-init ran from camera-init.service and sourced /etc/v4l2-relayd.d/ipu7.conf as bash. A config that is valid for systemd but not for bash, such as an unquoted VIDEOSRC, made it fail and Lunar Lake fell back to the rotated pipeline; and because camera-init stays active, editing the config and restarting only the relay kept the override cached since boot.
It now runs as the relay's ExecStartPre, where systemd hands it VIDEOSRC already parsed from the relay's own environment files, and writes the override quoted for systemd's parser. ExecStart re-reads the drop-in's EnvironmentFile and ExecStopPost removes it, so each start sees the current config.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Scale the Lunar Lake ov08x40's analog gain codes too
The Lunar Lake tuning (OV08X40_BBG802N3_LNL.aiqb) carries the same CMC gain table as the Panther Lake one, 1x = code 256, and both platforms use the same in-tree ov08x40 driver, which takes 1x = 128. Without the shift a 4x request ran the Lunar Lake sensor at 8x, the mismatch 0010 fixes on Panther Lake. 0010 now sets analogGainCodeShift in the ipu7x sensor config as well.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Remove the Lunar Lake override before the generator runs
systemd passes ExecStartPre the unit's environment files as they stand when
that command starts, so the generator saw a /run override left behind by a
crash or SIGKILL (anything that skipped ExecStopPost) and took its VIDEOSRC
for the configured one: an edited /etc/v4l2-relayd.d/ipu7.conf would lose to
the stale file. Removing the file in its own ExecStartPre first means the
generator's environment is re-read without it.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Author the HAL and icamerasrc patches from the Omarchy address
---------
Signed-off-by: Afonso Oliveira <afonso.oliveira707@gmail.com>
Co-authored-by: Codex XHigh <noreply@openai.com>
Co-authored-by: Afonso Oliveira <afonso.oliveira707@gmail.com>
Co-authored-by: Kolbas <pkolbas@pm.me>
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
A copy under /usr/lib/node_modules belongs to pacman, and upstream's updater refuses to write there, so neither `openclaw update` nor the Control UI's Update Gateway worked. The package now carries the release instead: the sha256-pinned npm tarball and the install-cli.sh that came in it, from which Omarchy seeds a copy under ~/.openclaw that updates itself.
omacom/omarchy#13362 (d0b94d98c) dropped the omarchy-hw-platform copy
omarchy-settings shipped beside its platform guard. Its 00-omarchy-hooks.conf
now asks the runtime's own detector on PATH, and keeps the busybox line where
there is none. The aarch64 settings recipes still refused any source whose
baseline names omarchy-hw-platform without that copy, so every aarch64 build
of quattro would fail once #13362 merges.
Both recipes drop that check. The copy is still installed when a source ships
the guard, as before. The test fixture follows #13362's current baseline, and
the split-layout test checks the package builds from it and ships no copy.
gliff now lives at omacom/gliff and cuts tagged releases, so build
the tag archive instead of a pinned commit and watch its tags.
The codec moved to VA-API: add libva, and dbus for notifications.
Install the launcher entry and icon, with the icon cache hook, and
ship the OpenH264 license.
The package builds mil-hwxc from a joshuaswarren/mil-hwx-compiler
release. It compiles textual MIL into ANEC and HWX programs for the
Apple Neural Engine. aarch64 and edge only.
The compiler needs the libobjc2 runtime and a gnustep-base built for
it. Arch's gnustep-base uses gcc's libobjc, so the recipe builds both
from the commits the release pins and ships their runtime libraries in
/usr/lib/mil-hwx-compiler. mil-hwxc finds them through its RUNPATH.
check() runs the release's Linux verifier.
The watch follows published GitHub releases after 24 hours, on the
reviewed lane.
* Accept the fifth Hermes desktop launch option
Hermes now returns five values from _desktop_launch_options(), appending the renderer accessibility switch. The launcher unpacked exactly four, so once a user's runtime updated, every launch died with "too many values to unpack" before the app opened. The launcher now takes the first four and reads the fifth when present, so it keeps working with the packaged release and with newer runtimes, and it bridges an explicit accessibility opt-out the same way Hermes' own launcher does. The launch check now also runs a five-value helper, which fails against the previous launcher.
Fixesbasecamp/omarchy#13491
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* hermes-desktop: launch against the installed runtime, accept the helper's new arity
_desktop_launch_options() returns five values since Hermes grew a trailing
renderer_accessibility field, so the launcher died with "too many values to
unpack (expected 4)" before os.execve — and gtk-launch discards stderr, so the
app icon became a silent no-op that left no process and no log line behind.
The launcher also exported HERMES_DESKTOP_IGNORE_EXISTING=1 unconditionally
while preferring the runtime's own app binary a few lines above it: with a
runtime installed, Desktop skipped that runtime and offered first-run setup
instead of the user's sessions. Ignoring an existing runtime is only correct for
the bundled /opt app, which is built from the package's release commit and
cannot drive a runtime built from another one.
pkgrel bumped for the changed artifact.
* Tell only the packaged Hermes Desktop to skip an existing install
The runtime's own app now finds its runtime the way `hermes desktop` launches it, through the installed-runtime lookup, instead of being pinned to it with HERMES_DESKTOP_HERMES_ROOT. That variable is upstream's developer override: it resolves before the lookup that Repair install bypasses, so pinning the runtime turned a hard repair into a restart against the same broken venv. HERMES_DESKTOP_IGNORE_EXISTING is set only when the launcher falls back to the packaged /opt app, and an explicit value in the environment still wins, so the in-app updater's relaunch of the runtime app no longer inherits it.
The fifth launch option is read the way it was accepted in the previous commit but one, with the checksums the two earlier commits left stale brought up to date. runtime-test.py now records both variables, so it fails if the unconditional export or the root pin comes back.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Codex XHigh <noreply@openai.com>
---------
Co-authored-by: manuaudio <manu@arimaka.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Omni <omni@omninova.com.mx>
Co-authored-by: Codex XHigh <noreply@openai.com>
cua-hyprland-plugin 0.26.1-6 pins glibc=2.44+r24+g16be1518495f-1 exactly. Arch core has moved to 2.44+r50+g1848099f063e-1, so on any upgraded edge system pacman refuses the plugin with "unable to satisfy dependency", even though cua-driver-bin installs.
Derive a new profile, omarchy-edge-20260928-remaps, that pins the current glibc and takes its source from the Driver 0.28.2 release that cua-driver-bin ships. The plugin files in that release are byte-identical to 0.26.1 and 0.27.0, so the keymap patch applies unchanged and only the upstream base in DOWNSTREAM-PROVENANCE.json moves. The download wrapper now substitutes the 0.28.2 archive and manifest into the verified upstream kit and renders the recipe from the kit's own PROFILE-PKGBUILD.in, so the derived kit is one Cua's profile_verify.py accepts as complete.
pkgrel starts at 2 because profile validation refuses package release 1.
#638 gave omarchy-settings this and -dev was never ported, so edge, the only
channel aarch64 machines are qualified for, still stripped zram, oomd, zswap,
the sysctl tuning and USB autosuspend there: on Snapdragon, migration
1790328426 installs zram-generator, finds no dev-zram0.swap and completes
without zram. A source with default/settings-runtime-profile now gets the same
files, backup and optdepends on aarch64 as on x86_64, Thunderbolt drop-in
included, and its HOOKS files ship as they are. Older sources, including the
current quattro pin, keep today's aarch64 package. The platform guard and its
detector check stay aarch64-only (#691, #694). The keyboard backlight unit
first-run enables ships whenever the source has it, as in omarchy-settings.
tests/settings-runtime-profile.sh now runs both recipes. pkgrel 5 so the
recipe change builds; the payload from the current pin is unchanged.
* Add disktree
* disktree-bin: 0.9.1
* disktree-bin: 0.10.1, for aarch64 too
0.10.1 ships gpui-omarchy 0.1.3, and the release now builds an aarch64
Linux tarball, so the recipe and the upstream asset map cover both.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* voxtype-bin: update to 1.1.0
Ship the signed 1.1.0 release assets, baseline and ARM binaries, and the complete Quickshell and OSD style trees. Add OpenVINO optional dependencies from #526 and select the baseline binary automatically on pre-AVX2 hosts.
* voxtype-bin: bump pkgrel past the published 1.1.0-1
voxtype-bin 1.1.0-1 is already published to edge, rc and stable from master's upstream sync. This branch changes that package's contents (baseline binary, OSD styles and recipes, the install hook, OpenVINO optdepends) without changing its version, so publish.yml would call it already published and skip it, and publish-artifact refuses different bytes under an existing filename. pacman would not offer it as an upgrade either.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* voxtype-bin: list accelerator optdepends for x86_64 only
makepkg appends optdepends_$CARCH to optdepends rather than replacing it, so optdepends_aarch64 did not drop the Vulkan, CUDA, ROCm and MIGraphX entries on aarch64: it listed all sixteen shared ones and then eleven of them a second time. The accelerator runtimes move to optdepends_x86_64 beside the OpenVINO ones, and the aarch64 array goes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* voxtype-bin: move pre-AVX2 hosts to the baseline build on upgrade
The baseline pick in _set_default_backend only runs when no backend was saved, which is a fresh install. Every release before 1.1.0 gave a CPU without AVX2 voxtype-avx2, and pre_upgrade saves that path, so post_upgrade restored the build the host cannot run and the machines the baseline binary exists for never reached it. A saved AVX2 or AVX-512 build whose instruction set the CPU lacks is now picked again; GPU and ONNX choices are left alone.
tests/voxtype-bin-install.sh covers the fresh-install pick and the upgrade cases, and runs with the other self-tests. It borrows the hook's fixed /tmp/.voxtype-backend-upgrade, so it refuses to start when anything is already there, a dangling symlink included: CI runs it as root, and writing through a planted link would land outside the test.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Codex XHigh <noreply@openai.com>
* tests: keep voxtype-bin-install's upgrade state out of /tmp
The test borrowed the hook's /tmp/.voxtype-backend-upgrade and checked it was free only once, so a real voxtype-bin upgrade writing its state during the run could have that state overwritten or deleted, and the hook would then lose the user's backend. The test now redefines the sourced _preserve_or_set_backend with the path moved into its own directory, and fails outright if the hook stops using that path rather than passing without reading it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Codex XHigh <noreply@openai.com>
* tests: never parse voxtype-bin-install's temp path as code
The redefined _preserve_or_set_backend went through eval with the mktemp path pasted in, so a TMPDIR holding shell syntax -- a directory named $HOME, or $(...) -- was expanded or run when the function was called. It now carries a reference to $SAVED, which expands to the path only at run time.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Codex XHigh <noreply@openai.com>
---------
Co-authored-by: Spencer Bull <spencer@omarchy.org>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Codex XHigh <noreply@openai.com>
The guard and its detector copy now ship on aarch64 only (#691), so the check that 00-omarchy-hooks.conf has its detector failed every x86_64 build from a source that carries the HOOKS baseline. x86_64 keeps the busybox line without a detector. Same scoping as omarchy-settings in #638.
Build it in edge and promote through rc to stable like other packages,
matching cua-hyprland-plugin, which left the fast ring in #432.
#693 held upstream sync while 0.28.3+ breaks screenshots. Make that the
standing policy: Omarchy bumps the driver by hand, so the PKGBUILD no
longer says to re-enable sync after the fix, and docs/upstream-sources.md
records the hold. The hook and min_release_age stay, so lifting the hold
is a one-line revert.
Publish as 0.28.2-3 so the PR builds; the payload is unchanged.
No platform package is built for x86_64, so an x86 machine has nothing to
guard. The check that 00-omarchy-hooks.conf has its detector copy follows it:
without the copy, x86_64 keeps the busybox line it would have anyway, and
leaving the check unscoped would fail every x86_64 build from a source that
asks omarchy-hw-platform. Taken from #691, which keeps the -dev recipe.
No platform package is built for x86_64 and pacman refuses another architecture's package there, so x86 transactions gain nothing from the guard. The x86 HOOKS baseline keeps the busybox line without a detector, so the detector copy goes too. omarchy-settings gets the same change in #638.
A source with default/settings-runtime-profile decides at runtime which
platform-specific files apply, so its aarch64 package now gets the same files,
backup and optdepends as x86_64: the Thunderbolt request and the memory stack
stay, and its HOOKS files ship as they are. The check that a Mac's asahi line
survives still runs on every aarch64 build. Older sources, including the pinned
v4.0.4, keep #380's aarch64 package: Thunderbolt removed, the HOOKS line guarded
for asahi, the memory stack stripped. The keyboard backlight unit first-run
enables ships whenever the source has it.
pkgrel 4 so the recipe change builds: edge already holds 4.0.4-3 on both
architectures. The payload built from v4.0.4 is unchanged.
Ryan Hughes