• ×
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
  • ×
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
Guidelines
Join the HP Community Solve‑a‑thon | Help Others & Share Your Solutions | Live on Zoom | 2:30 PM to 2:30 AM IST | Every Wednesday Click here to know more
HP Recommended
HP Spectre x360 13.5 inch 2-in-1 Laptop PC 14-ef2000 (771X2AV)
Ubuntu LTS

Summary for support staff

The BIOS of this model contains an error in the display configuration table (VBT) that the graphics driver reads at boot. The table declares two built-in display panels although the machine has only one. Under Linux this makes the screen stay permanently black after every resume from sleep — the only way out is a forced power-off, which has repeatedly corrupted the filesystem.

The error has been isolated to a single table entry and confirmed by correcting it: with a corrected copy of the table the machine resumes normally. The fix on HP's side is a two-byte change in one BIOS data structure — no code change, and no behavioural change for Windows users.

I would like to ask for this to be forwarded to the firmware team.

Affected product

Model            HP Spectre x360 2-in-1 Laptop 14-ef2xxx
Board            8BA2
Product family   103C_5335M8 HP Spectre
BIOS             F.11 (2026-04-01) - the latest offered for this model
CPU              Intel Core i7-1355U
GPU              Intel Iris Xe (Raptor Lake-P, 8086:a7a1)
Panel            single internal eDP panel, 3000x2000, connected to DDI A

The defect

The VBT is delivered through the ACPI OpRegion (RVDA) and identifies itself as "$VBT ALDERLAKE-P", BDB version 251 — Intel's reference table for the platform, adapted by HP for this board.

In BDB block 2 ("General Definitions"), the child device list contains:

entry 0:  handle 0x0008 (LFP1)  device_type 0x1806  dvo_port 0x0a (DP-A)
entry 1:  handle 0x0080 (LFP2)  device_type 0x1806  dvo_port 0x07 (DP-B)
entry 2:  handle 0x0004 (EFP1)  device_type 0x0000  dvo_port 0x07 (DP-B)
entry 3:  handle 0x0040 (EFP2)  device_type 0x68c6  dvo_port 0x0d (DP-F)

LFP means Local Flat Panel, i.e. an internal display. Entry 1 declares a second internal panel on port B. There is no such panel. The Type-C ports (entry 3 onwards) are configured correctly, so this looks like a leftover from Intel's reference table, where the panel can optionally sit on either port A or port B.

Why it breaks

The graphics driver allocates a panel power sequencer per declared internal panel. With two declared panels sharing one physical one, the assignment is lost across a sleep cycle. After resume the driver reports panel power as applied (PP_STATUS 0x80000008) while the panel does not answer at all: 69 consecutive AUX timeouts (status 0x7d40023f — TIME_OUT_ERROR set, RECEIVE_ERROR clear), followed by "Failed to enable link training". The screen stays black.

Intel's Windows driver evidently tolerates the duplicate entry — no symptom is visible under Windows. That does not make the table correct.

Intel's own i915 maintainer identified the same pattern on another vendor's machine in 2022 and named it directly: "The VBT looks incorrect enabling eDP both on port A and B." (freedesktop.org drm/i915 issue 4950). That report was closed after the vendor shipped a corrected BIOS. The same correction has not been made for this model.

The requested change

In the VBT child device list, entry 1 (LFP2, DP-B) should not declare an internal panel. Setting its device_type to 0x0000 is sufficient — that is exactly how the same table already marks three other unused connectors (see entry 2 above).

Verification

I extracted the VBT from the running machine, set that one field to 0x0000 — two bytes, nothing else changed — and had the driver load the corrected copy instead of the BIOS one. Result:

                                   BIOS table     corrected table
AUX timeouts after resume          69             0
Link training                      fails          clean
Driver warning at boot             every boot     gone
Phantom port B in the log          present        gone
Screen after resume                black          back

This is a local workaround and not something ordinary users can be expected to do. The correct fix belongs in the BIOS.

Diagnostic data

Full driver traces before and after the change, the extracted original and corrected VBT, and decoded dumps of both are available on request.


Diagnosis and this report were produced by Claude, an AI assistant by Anthropic, working on the affected machine at my request. All hardware identifiers, table entries, register values and log excerpts were read from the running system. I have reviewed the report and can be contacted for further data or test runs.

1 REPLY 1
HP Recommended

Interim workaround for other affected users

Read this first. This is a local workaround, not a fix. It makes the graphics driver load a corrected copy of the display configuration table instead of the one in the BIOS. The BIOS itself is unchanged, so this has to be redone if the files are lost, and it only helps Linux — Windows is unaffected by the bug anyway. The kernel will be marked as "tainted" because a driver option flagged as dangerous is used. Use at your own risk.

Do not copy anyone else's patched file. The table also contains your panel's timing, brightness and PWM parameters, and this model ships with several different panels. Dump and patch your own table. The script below refuses to touch a table that does not match the expected pattern.

Step 1 — install the decoding tool (optional, only used to look at the table):

sudo apt install intel-gpu-tools        # Debian/Ubuntu
sudo dnf install igt-gpu-tools          # Fedora
sudo pacman -S igt-gpu-tools            # Arch

Step 2 — dump your own table:

sudo sh -c 'for d in /sys/kernel/debug/dri/*; do
  [ -e "$d/i915_vbt" ] && cat "$d/i915_vbt" > /tmp/vbt-original.bin && break
done'
ls -l /tmp/vbt-original.bin

Step 3 — save this script as vbtfix.py:

import struct, sys
inp, outp = sys.argv[1], sys.argv[2]
d = bytearray(open(inp, 'rb').read())
if d[:4] != b'$VBT': sys.exit("Not a VBT file")
bdb = struct.unpack_from('<I', d, 28)[0]
pos = bdb + struct.unpack_from('<H', d, bdb + 18)[0]
end = bdb + struct.unpack_from('<H', d, bdb + 20)[0]
blk = None
while pos < end - 3:
    bid, blen = d[pos], struct.unpack_from('<H', d, pos + 1)[0]
    if bid == 2: blk = (pos + 3, blen); break
    pos += 3 + blen
if not blk: sys.exit("BDB block 2 not found")
data, blen = blk
csize, start = d[data + 4], data + 5
lfp = []
for i in range((blen - 5) // csize):
    o = start + i * csize
    h, dt = struct.unpack_from('<HH', d, o)
    if dt and (dt & 0x1000):        # DEVICE_TYPE_INTERNAL_CONNECTOR
        lfp.append((i, o, h, dt, d[o + 16]))
print("Internal panels declared in your VBT:")
for i, o, h, dt, p in lfp:
    print("  entry %d: handle 0x%04x  device_type 0x%04x  dvo_port 0x%02x" % (i, h, dt, p))
if len(lfp) != 2:
    sys.exit("Expected exactly 2 -> your VBT differs, do NOT patch it blindly.")
keep, drop = lfp
if keep[4] != 0x0a or drop[4] != 0x07:
    sys.exit("Ports are not DP-A/DP-B as expected -> stopping.")
struct.pack_into('<H', d, drop[1] + 2, 0)
open(outp, 'wb').write(bytes(d))
print("\nDisabled entry %d (port DP-B). Wrote %s" % (drop[0], outp))

Step 4 — check whether you are affected, and patch:

python3 vbtfix.py /tmp/vbt-original.bin /tmp/vbt-fixed.bin

If it lists two internal panels, one on port 0x0a and one on port 0x07, you have the same defect and the corrected file is written. If it stops with a message instead, your table is different — do not go further.

Step 5 — install the corrected table:

sudo mkdir -p /lib/firmware/i915
sudo install -m 644 /tmp/vbt-fixed.bin /lib/firmware/i915/vbt-fixed.bin

Step 6 — make sure it is inside the initramfs. This step is easy to skip and then nothing works: the driver is usually loaded early from the initramfs, and if the file is missing there the request fails silently and the BIOS table is used again.

# dracut (Fedora, and Ubuntu 25.10 and newer):
echo 'install_items+=" /lib/firmware/i915/vbt-fixed.bin "' | sudo tee /etc/dracut.conf.d/95-vbt.conf
sudo dracut --force --regenerate-all

# initramfs-tools (older Debian/Ubuntu): create /etc/initramfs-tools/hooks/vbt
#!/bin/sh
[ "$1" = prereqs ] && { echo; exit 0; }
. /usr/share/initramfs-tools/hook-functions
copy_file firmware /lib/firmware/i915/vbt-fixed.bin
# then:  sudo chmod +x /etc/initramfs-tools/hooks/vbt && sudo update-initramfs -u -k all

Step 7 — tell the driver to use it. Add this to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, then run sudo update-grub and reboot:

i915.vbt_firmware=i915/vbt-fixed.bin

Step 8 — verify after the reboot:

grep -o 'vbt_firmware=[^ ]*' /proc/cmdline
sudo dmesg | grep -c "DDI B/PHY B"

The first command must show the parameter, the second must print 0. Before the change, every boot logged "[ENCODER:...:DDI B/PHY B] failed to retrieve link info, disabling eDP". If that line is gone and no VBT error appears in dmesg, the corrected table is in use. Note that the confirmation message "Found valid VBT in firmware blob" is a debug-level message and normally not visible — its absence is not a problem, an error message would be.

To undo: remove the parameter from /etc/default/grub, run sudo update-grub, delete /lib/firmware/i915/vbt-fixed.bin and the initramfs snippet from step 6, and rebuild the initramfs.

Again: this is a stopgap. The defect is in the BIOS and should be corrected there.


This procedure was worked out and tested by Claude, an AI assistant by Anthropic, on my machine and at my request. It has been verified on exactly one unit — an HP Spectre x360 14-ef2xxx with BIOS F.11 running Ubuntu 26.04, kernel 7.0.0-30 — where it turns a permanently black screen after resume into a normal one. It has not been tested on any other configuration, which is why the script refuses to modify a table that does not match the expected pattern. If it stops with a message on your machine, please post what it printed rather than working around the check.

† The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the <a href="https://www8.hp.com/us/en/terms-of-use.html" class="udrlinesmall">Terms of Use</a> and <a href="/t5/custom/page/page-id/hp.rulespage" class="udrlinesmall"> Rules of Participation</a>.
-->