HP EliteBook, Spectre, Envy and Omen on Omarchy Linux

Verdict

Bronze. These machines install and run, but nothing in Omarchy is written for them, and several of the problems people hit are real and still open on 4.0.4.

There is no HP entry anywhere in the hardware enablement tree. Grepping install/hardware/, bin/ and migrations/ in the v4.0.4 snapshot for EliteBook, Spectre, Envy, Omen, Victus or hp_wmi returns nothing. Compare that with ASUS, Framework, Dell XPS, Surface, Apple and Lenovo Yoga, which all have named scripts. On an HP you get the generic path: the Intel or AMD kernel drivers, network.sh, fix-fkeys.sh, bluetooth.sh, nvidia.sh on the Omen and Victus, and whatever the Intel subdirectory decides applies.

Evidence here is uneven. Thirty-three issues in the tracker snapshot name an EliteBook, Spectre, Envy, Omen or Victus, and all but one of those are a real HP machine rather than a Spectre V2 mitigation log line. Most of them are software reports that would read the same on any laptop: a slow launcher, a Chromium crash, an emoji that will not paste. Fourteen are hardware reports, and this page is built on those. The EliteBook, Spectre x360 and Victus lines carry all but one of them, the odd one out being an Envy x360. The Omen name turns up six times: five software reports and a keyboard request filed from a Victus, never a hardware fault on an Omen itself, so treat the Omen as unrated in practice.

What works

Nobody has filed a graphics driver complaint on an integrated HP. On the AMD EliteBook 845 G10 the journal in issue #11332 shows amdgpu resuming normally across most suspend cycles, including the SMU. On the Intel Spectre x360 14-ef1xxx in issue #10170 the i915 backlight resume returns 0 and the machine is fully responsive after wake. That is the absence of a complaint in two reports filed about something else, not a positive result, which is why the GPU line reads partial rather than works. The discrete side is a different story, and it is below.

Installation itself is not a topic. No HP reporter has filed a failed install, and the Envy boot hang in issue #3829 is firmware behaviour rather than an installer problem.

Everything else on this list is unknown rather than proven good. The tracker only tells you what broke. Bluetooth, touchpad, battery life and hibernation have no HP-specific reports either way, which is mildly encouraging and not evidence.

What breaks

Suspend on the AMD EliteBook 845 G10. Issue #11332, open, filed on 4.0.3 with Linux 7.2.3 and BIOS V82. Closing the lid intermittently leaves the machine unable to resume; the lid, the power button and everything else are dead until you hold power down. The reporter counted his own journals: about 6 percent of suspends left no matching PM: suspend exit on Linux 7.1.9, and about 31 percent on 7.2.3. Since 4.0.4 ships the bespoke linux-omarchy kernel to every machine, and the stable channel is on 7.2.5 as of this check, this is a risk worth knowing about before you update. The machine exposes only [s2idle] in /sys/power/mem_sleep, so there is no S3 to fall back on. See /fix/suspend-wont-resume-s2idle/.

A dark panel after lid-open on a laptop with no external monitor. Issue #10170, open, from a Spectre x360 14-ef1xxx on 4.0.2. The lock screen blanks the panel five seconds after locking, and the only two code paths that re-enable DPMS are a keypress on the lock screen password field and the clamshell reconciler, which does nothing when no external monitor was ever attached. Press any key and the screen usually comes back. The power button will not do it, because logind swallows it, which is what makes this look like a dead machine rather than a blank one. A second reporter on the thread found even the keypress did nothing, because the lock screen password field had lost keyboard focus across the suspend.

The webcam on Meteor Lake Spectre x360. Issue #7697, open. Omarchy’s ipu7-camera.sh installs intel-ipu7-camera whenever ACPI HID OVTI08F4 is present, but that sensor is paired with IPU6 on Meteor Lake. The IPU7 package ships only the ipu75xa HAL, so icamerasrc finds no plugin and the v4l2loopback device serves a black frame. PR #7773 rewrites the gate to match the Panther Lake controller 8086:b05d instead; it was still open and unmerged when checked. Nothing in it uninstalls the package where it already landed, so clearing it is still yours to do with omarchy-pkg-drop intel-ipu7-camera. Older AMD EliteBooks have their own webcam report, issue #4529 on an 835 G8, closed with no confirmed fix after a contributor said his own camera was fine.

Fingerprint readers. Omarchy’s detector keys on USB vendor IDs, and Validity’s 138a is on the list, so an EliteBook 8470w with a VFS491 passes the gate, installs packages, then fails to enroll with NoSuchDevice because libfprint carries no driver for that sensor. That is issue #10892, open. A separate EliteBook report, issue #8747, found the lock screen hanging 25 to 30 seconds after resume when the fprintd daemon restarts under it; the reporter closed it himself after fixing it at the driver level by enabling open-fprintd-suspend and open-fprintd-resume. See /fix/fingerprint-enrollment-fails/ and the manual chapter on hardware authentication.

Audio and the mute keys. On a Meteor Lake Spectre x360 with dual CS35L41 amplifiers, issue #11611 describes the ALSA sink stuck in SUSPENDED and the top bar showing a permanent muted glyph with no way back. The reporter is clear that the root cause is a driver bug going upstream, not Omarchy. Separately, the microphone mute key on a Spectre x360 13-aw0xxx emits an ACPI event rather than a keycode, issue #5127, filed on 3.4.0 and still open; the reporter works around it with an acpid handler calling wpctl. Take that one with a pinch of salt on 4.x: later commenters pinned the same symptom on a SwayOSD bug, and Quattro removed SwayOSD entirely. The EliteBook 845 G10 mic-mute report, issue #4570, was the same SwayOSD regression, confirmed by rolling back to 0.2.1, and closed for that reason.

Wi-Fi dies on lid-open on a Victus 16-s1xxx. Issue #9198, open, filed on 4.0.1 and one of the best-diagnosed HP reports on the tracker. The firmware injects scancode 0xd7 on the internal i8042 keyboard controller every time the lid opens. Systemd’s 60-keyboard.hwdb carries a blanket svnHP* rule mapping 0xd7 to KEY_WLAN, the kernel’s rfkill-input handler does what it is told, and the radio is soft-blocked until you clear it by hand. The reporter caught it with an ftrace kprobe, confirmed the scancode on the internal keyboard, and showed the deauth landing 3.5 ms after the lid switch. His own fix is a KEYBOARD_KEY_d7=reserved override in /etc/udev/hwdb.d/, matched to that one product name; Omarchy ships nothing of the kind, so on this model it is yours to install. He notes the trade-off: if a physical wireless key on the machine also emits 0xd7, it stops working.

The hybrid GPU toggle wedges on a Victus 16-e0xxx. Issue #10445, open, on 4.0.2 with an RTX 3060 Mobile. Switching to integrated mode unloads every NVIDIA module cleanly, then supergfxd blocks forever in snd_card_free while it unbinds the dGPU’s HDA audio function, because PipeWire had opened that ALSA card 200 microseconds earlier. The daemon sits in uninterruptible sleep holding its D-Bus name, so the Omarchy toggle hangs and reports that supergfxd is not responding. The dGPU never gets powered down, which costs you the HDMI outputs wired to it and the battery drain at the same time. On a Victus or Omen, read /hardware/hybrid-gpu/ before you touch that toggle.

Envy x360 boot delay. Issue #3829, from a 15m-bq121dx on 3.2.2: the ACPI NVS and AMD fTPM regions overlap, tpm_crb fails to probe with -EBUSY, systemd waits the device out, and boot takes 90 extra seconds. This is firmware, not Omarchy. The usual advice is memmap= kernel parameters carving the TPM CRBs out of the NVS region, but the reporter tried exactly that and it did not help him, and the addresses are machine-specific anyway. The issue was closed with no documented fix.

What Omarchy does for this model

Nothing by name. There is no omarchy-hw-hp-* script, no HP branch in install/hardware/all.sh, and no DMI match string for an HP product anywhere in v4.0.4. omarchy-hw-match exists and is called for the Framework 16, Dell XPS OLED, haptics and text scaling, the Surface, three ASUS models and one Lenovo Yoga. No caller passes an HP string.

What does touch these machines is generic: install/hardware/intel/ipu7-camera.sh (the webcam problem above), install/hardware/intel/sof-firmware.sh, install/hardware/intel/lpmd.sh and thermald.sh on Intel models, install/hardware/nvidia.sh on Omen and Victus, and install/hardware/speaker-tuning.sh, which only installs the LV2 plugins when omarchy-audio-tuning match finds a tuning. No shipped tuning matches an HP, so the CS35L41 amplifiers in the Spectre x360 get no speaker profile.

The one rule anywhere on the stack that does single out HP is not Omarchy’s. Systemd’s 60-keyboard.hwdb ships an evdev:atkbd:dmi:...:svnHP* entry that maps scancode 0xd7 to KEY_WLAN on every HP machine, which is the whole mechanism behind the Victus lid-open Wi-Fi drop above. Omarchy inherits it from the systemd package and overrides nothing.

The RGB keyboard on Victus and Omen has no control. Issue #4987 offered a kbdcolor helper driving /sys/class/leds/hp::kbd_backlight/multi_intensity and was closed without landing. omarchy-brightness-keyboard only handles brightness, not colour.

Variants

Prefer the Intel Spectre x360 generations before Meteor Lake if the webcam matters, or accept removing the IPU7 package. The script only fires on the OVTI08F4 sensor, so a machine without that sensor never gets the wrong stack installed. Treat that as a reason to expect less trouble rather than a guarantee: nobody has written down a working camera on any HP.

The AMD EliteBook 800 series is the best-documented HP here, but the 845 G10 carries the open s2idle resume problem. If you buy one, budget time on sleep testing before you trust it to a lid close.

Avoid assuming the fingerprint reader works. Check the USB ID first. Validity VFS491 and the 138a:00ab sensor both needed work; neither is driven by stock libfprint out of the box.

The Victus is better documented than its owners would like: Wi-Fi dropping on lid-open, a hybrid GPU toggle that deadlocks, and a fan-control complaint, issue #2719, that a maintainer closed as firmware’s job rather than Omarchy’s. The Omen has no hardware report of its own, so it inherits the Victus picture by family resemblance and nothing stronger. On both, the NVIDIA side matters more than the HP side. Read /hardware/nvidia/ and /hardware/hybrid-gpu/ before you buy one.

Before you install

Check cat /sys/power/mem_sleep. If it prints only [s2idle], read /hardware/suspend-sleep/ and plan for the possibility that lid-close sleep is unreliable.

Run lsusb | grep -iE '138a|27c6|06cb' in a live session and look your reader up in libfprint’s supported list before you count on fingerprint unlock.

On a Meteor Lake Spectre, check lsmod | grep intel_ipu after install. If intel_ipu6 is loaded and intel-ipu7-camera is installed, drop the package.

On a Victus, close and open the lid once and run rfkill list. If the Wi-Fi line says Soft blocked: yes, you have issue #9198 and you need the hwdb override.

Update your BIOS from the vendor first. The EliteBook report was on a current BIOS and still failed, but firmware is the cheapest variable to eliminate.

Read /upgrade/before-you-update-checklist/ before taking 4.0.4, since it is the release that puts the linux-omarchy kernel on every machine, and the one open HP suspend report blames a kernel bump.

Related

/hardware/suspend-sleep/, /hardware/webcam/, /hardware/fingerprint/, /hardware/audio/, /fix/suspend-wont-resume-s2idle/, /fix/webcam-not-detected/, /fix/fingerprint-enrollment-fails/, /hardware/submit/.