HP EliteBook X G2i - ArchWiki

Jump to content

# HP EliteBook X G2i

From ArchWiki

Hardware | PCI/USB ID | Working?
--- | --- | ---
GPU | `8086:b080` | Yes
Wi-Fi | `8086:e440` | Yes
Bluetooth | `8086:e476` | Yes
Speakers |  | No
Microphone | `8086:e428` | Yes
Webcam | `8086:b05d` | No
IR camera | I2C | Untested
Touchpad | `06cb:d02b` | Yes
Keyboard |  | Yes
Fingerprint reader | `04f3:0ca8` | Yes
TPM |  | Yes

Hardware and configuration notes for the HP EliteBook X G2i, a 14" Panther Lake (Intel Core Ultra series 3) notebook.

Most hardware works with a stock kernel. The internal speakers and the webcam do not, and both need changes that are not upstream as of Linux 7.1.8.

## Installation

This article or section needs expansion.

Reason: This device seems to ship with an UEFI so until we provide an installation medium that supports Secure Boot, we should remind readers to disable it for installation. (Discuss in Talk:HP EliteBook X G2i)

The installer runs without quirks and needs no kernel parameters. Nothing on this page is required to complete an installation.

Two devices do not work on a stock kernel, and neither failure is obvious from the installed system:

- The internal speakers produce no sound, and no Speaker device is created at all. Headphones and the microphone work, which makes this look like a routing or volume problem rather than a missing device. See #Audio.
- The webcam does not enumerate. There is no mainline IPU7 driver. See #Webcam.

Both need out-of-tree changes; see #See also. If you need working audio during installation, use headphones or a USB audio device.

## Accessibility

The firmware presents a graphical setup interface and supports a mouse. Press `Esc` during boot to open the Startup Menu, then `F10` for Setup or `F9` for Boot Options; both keys are also accepted directly during early boot.

Note Whether every setting can be changed using the keyboard alone has not been verified on this model. Mouse navigation is known to work.

Beep codes and diagnostic LED behaviour have not been documented for this model.

## Firmware

A UEFI implementation with Secure Boot support. This page was written against Y90 Ver. 01.01.18 (2026-05-21).

Note fwupd support for this model has not been tested.

## Audio

The board pairs a Realtek RT712 SDCA codec with four TI TAS2783 smart amplifiers on SoundWire link 2. Panther Lake's ACPI match table has no entry for this combination, so SOF falls back to a minimal machine driver and no Speaker device is created at all. The card appears and headphones and microphone work, which can make this look like a volume or routing problem rather than a missing device.

Two kernel changes are required.

- An entry in `sound/soc/intel/common/soc-acpi-intel-ptl-match.c` pairing `rt712-sdca` on link 3 with `tas2783` on link 2, using topology `sof-ptl-rt712-l3-tas2783-l2-dummy.tplg`. The four amplifiers must carry `name_prefix` values `tas2783-1` through `tas2783-4`: `asoc_sdw_ti_spk_rtd_init()` compares against those literals and aborts card registration otherwise.

- A `.component_name = "tas2783"` field on the TAS2783A entry in `sound/soc/sdw_utils/soc_sdw_utils.c`. Without it the card reports no `spk:` token, so ALSA cannot resolve a speaker configuration.

Verify with:

    $ amixer -c 0 info | grep Components

        Components : 'HDA:80862822,80860101,00100000  cfg-amp:4 iec61937-pcm:7,6,5 hs:rt712 mic:rt712 spk:tas2783'

Both `spk:tas2783` and `cfg-amp:4` must be present.

### UCM configuration

alsa-ucm-conf has no profile for this pairing. `sof-soundwire/HiFi.conf` includes `/sof-soundwire/${SpeakerCodecFile}.conf` unconditionally, and `SpeakerCodecFile` resolves from the `spk:tas2783` token above. A file placed at `/usr/share/alsa/ucm2/sof-soundwire/tas2783.conf` is therefore picked up by stock alsa-ucm-conf without modifying any file the package owns.

### Calibration blobs

The `tas2783` driver requests `8E86-2-9.bin`, `8E86-2-A.bin`, `8E86-2-C.bin` and `8E86-2-D.bin`. linux-firmware ships the same per-amplifier calibration blobs as `8E86-2-0x9.bin.zst` and so on. Symlink rather than copy, so a firmware update still owns the real files:

    # ln -s 8E86-2-0x9.bin.zst /lib/firmware/8E86-2-9.bin.zst

### Boot race

The amplifiers sometimes enumerate after WirePlumber has inspected the card, leaving no usable speaker route until something re-triggers it. Waiting for the TAS2783 mixer controls to appear before WirePlumber starts avoids this.

Warning If you implement this as a `systemd` `ExecStartPre` drop-in, prefix the command with `-`. WirePlumber treats a failed `ExecStartPre` as a failed start, and a failed WirePlumber is not "no speakers" but no audio at all.

## Webcam

An OmniVision OV05C10 behind an Intel IPU7 ISP. Three pieces are missing.

- No mainline IPU7 driver. `drivers/media/pci/intel/` contains ipu3, ipu6 and ivsc, but no ipu7. The out-of-tree modules from intel/ipu7-drivers are required. Build with `BUILD_INTEL_IPU_ACPI=1`, or the v4l2-async notifier in `ipu7-isys.c` is compiled out and the sensor never binds.

- No in-tree OV05C10 driver. Intel ships one in intel/ipu6-drivers as `drivers/media/i2c/ov05c10.c`. It exists in neither mainline nor the ipu7-drivers tree.

- ipu-bridge link frequency. The `OVTI05C1` entry in the in-tree `drivers/media/pci/intel/ipu-bridge.c` lists only 480 MHz. The sensor also needs 900 MHz, or probing fails with `no link frequency 900000000 supported`. Intel's patch is in `ipu6-drivers` under `patch/`.

Note Patch `ipu-bridge.c` in tree rather than shipping a DKMS copy of it. A DKMS module that rebuilds that file forks it and freezes every other sensor's entry in the table.

### Getting frames

Intel's CamHAL does not produce usable frames on this machine: psys reports `frame id N is done` and the output is uniformly black. The cause is not established.

Tip The `Isp raw crop [0, 88, -56, 88]` line in CamHAL's debug output is not evidence of a bug, despite appearances. Those four numbers are edge insets rather than a rectangle, and every Intel sensor uses the same idiom, including ones that work. The rule is `out = ALIGN(in, 64)`.

libcamera's `simple` pipeline handler already lists `intel-ipu7` and drives this sensor end to end, debayering on the GPU through EGL. Two things are worth knowing:

- libcamera 0.7.2 has no `CameraSensorHelper` for `ov05c10`, so AGC treats the raw `V4L2_CID_ANALOGUE_GAIN` code as a gain multiplier and runs over a nominal range of 16–248 instead of 1–15.5. The gain is linear in 1/16 steps; the driver's own `MAX_ANA_GAIN 0xf8 // 15.5x` and `MIN_ANA_GAIN 0x10 // 1x` give the divisor.

- Request the sensor's native 2888x1808. Asking for 1920x1080 makes libcamera select sensor mode 2800x1576, which never delivers a buffer and wedges the ISYS capture node.

The sensor applies a fixed black level of 64 at 10 bits, which is 4096 at the 16-bit width libcamera expects. Measured on dark frames at minimum exposure and minimum analogue gain.

Warning Do not `rmmod` the `intel_ipu7*` modules on a running system. Unloading `intel_ipu7_psys` while active hard-hangs the machine with no panic logged.

### Colour

HP ships factory calibration in `ov05c10_CJFPE50_PTL.aiqb` on the Windows partition, an Intel CPF/LARD/MKN container. It holds six colour conversion matrices (illuminants A, F4, F11, F3, D50 and D65), per-module lens shading tables, and a black level that independently agrees with the measured value above.

Note libcamera's `estimateCCT` reads this sensor 380–760 K high, because it converts to XYZ using a fixed sRGB-primaries matrix that does not describe raw sensor primaries. The colour matrix chosen is therefore always bluer than the scene warrants, worst at warm colour temperatures.

## Fingerprint reader

An Elan match-on-chip sensor, `04f3:0ca8`, reported by USB as `ELAN:ARM-M4`. It needs no out-of-tree code: libfprint drives it with the `elanmoc` driver and fprintd reports it as `Elan MOC Sensors` with a `press` scan type, so touch the sensor rather than swiping.

Install fprintd and enroll:

    $ fprintd-enroll

Confirm:

    $ fprintd-list $USER

    found 1 devices
    Fingerprints for user username on Elan MOC Sensors (press):
     - #0: right-index-finger

Then wire it into PAM as described in fprint#PAM for whichever of `sudo`, `polkit-1` and your screen locker you want it to cover.

Note Match-on-chip means the templates are stored on the sensor itself, not under `/var/lib/fprint`. Clearing prints from the BIOS security menu erases them, and they cannot be backed up or migrated between installs.
Tip Some desktop tooling gates its fingerprint setup on the device's USB product string containing `fingerprint` or `biometric`. This sensor reports neither — it identifies as `ELAN:ARM-M4` — so such a check must match that string explicitly or it will conclude the machine has no reader.

## Slow resume

Suspend and power management themselves work. The delay on wake is caused by the audio amplifiers, and it is visible as a black screen for roughly ten seconds: userspace stays frozen until every resume callback returns, so nothing redraws until the last one finishes.

    # dmesg | grep tas2783

    slave-tas2783 sdw:0:2:0102:0000:01:9: resume: initialization timed out
    slave-tas2783 sdw:0:2:0102:0000:01:9: PM: acpi_subsys_resume returned -110 after 6805123 usecs

`tas2783_sdca_dev_resume()` waits on `initialization_complete` with a five-second timeout. One amplifier does not re-enumerate and burns the full timeout, and a second adds a further two seconds. Every other device on the machine, GPU included, resumes in under 400 ms.

The same wait pattern is used by rt700, rt711, rt712, rt715, rt721 and rt722, and the RT712 on this same bus resumes in microseconds, so the pattern is not the problem. One amplifier failing to re-attach is. Blacklisting `snd_soc_tas2783_sdw` restores fast wake at the cost of the internal speakers.

## Function keys

The marked `Fn` combinations on the top row behave as their symbols indicate and need no configuration.

This article or section needs expansion.

Reason: The individual keys have not been captured with wev or xorg-xev, so the emitted X keysyms are not documented here. See Help:Laptop page guidelines#Capturing function keys for the procedure. (Discuss in Talk:HP EliteBook X G2i)

## See also

The audio and webcam changes described above are packaged, with the kernel patches, the out-of-tree sensor driver and the libcamera additions all in one place:

- omarchy-pkgs#124 — `linux-ptl` kernel patches (ASoC match entry, TAS2783A component name, ipu-bridge link frequency), the `ov05c10` sensor driver, IPU7 DKMS modules, and a libcamera build carrying an OV05C10 sensor helper
- omarchy#6596 — hardware detection and the speaker tuning

The patches apply to Linux 7.1.8 and are distribution-independent, though the packaging around them is specific to Omarchy.

Category:

- HP

Hidden category:

- Pages or sections flagged with Template:Expansion

HP EliteBook X G2i
Add topic