HP EliteBook X G2i

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)