HP OMEN Transcend 14 (board 8E41): GPU power ceiling on 65W USB-C charger is non-deterministic across sessions (25W vs ~65W)

Reporting a non-deterministic GPU power ceiling on a 65W USB-C charger, in case it's useful alongside other recent reports of EC/PD-controller firmware state issues (Legion Pro 7 16IAX10H, ASUS Vivobook K3605ZV). I'm not certain this belongs to USB Type-C / UCSI rather than hp-wmi, so I've sent it to both lists; happy to be redirected.

System
------

Model:  HP OMEN Transcend Gaming Laptop 14-fb1013dx (B94GQUA#ABA)
Board:  8E41
BIOS:   F.05 (confirmed latest via fwupd/LVFS)
GPU:    NVIDIA GeForce RTX 5060 Laptop GPU, VBIOS 98.06.2A.80.62
Driver: NVIDIA Open 610.57.04
Kernel: 7.2.5-3 (Arch, Omarchy)

Symptom
-------
On the OEM-rated 65W USB-C charger, nvidia-smi's "Current Power Limit" lands on either 25.00W or ~60-65W depending on the boot/reconnect session, and stays fixed at whichever value for the rest of that session. A 140W charger reliably gives 50W (VBIOS default TGP); battery-only reliably gives 40W. Confirmed under gpu_burn 100% load in both 65W-charger outcomes:

25W outcome: 24.7-25.5W draw, clock unstable 200-500MHz 65W outcome: 59.4-64.9W draw, clock stable 1630-1860MHz

Which outcome a given session lands on appears session-scoped, not a fixed hardware fault: the same physical charger, same port, same cable produces either result depending on boot/reconnect history.

Ruled out
---------
- Kernel version: same kernel (7.2.5-3-omarchy) produced both the 25W and 65W outcomes on different boots.
- Battery charge state: tested 0%, 79%, 98%, 100% within one boot session, all still 25W.
- BIOS setting/update: F.05 confirmed latest via fwupd/LVFS; no relevant USB-C/adapter option in BIOS setup.
- ucsi_acpi driver presence: blacklisted it entirely, then re-ran the known-bad trigger (hot-swap the charger while powered on) - still landed on 25W. So the driver being loaded/unloaded is not itself the deciding factor.
- HP WMI GPU boost flags (commandtype 0x21/0x22 under command HPWMI_GM in hp-wmi.c, the CTGP/PPAB fields of struct victus_gpu_power_modes): wrote a read-only probe module issuing only the 0x21 GET across all four power states (battery/25W/65W/ 140W-triggered-50W). Raw response was byte-identical (00 01 01 57) in every state.
- HP WMI legacy "Smart Adapter" query (commandtype 0x0F under command HPWMI_READ; not defined in mainline hp-wmi.c's enum hp_wmi_commandtype, but present in a third-party Windows tool as a "smart power adapter status" query): also GET-only, also byte-identical (05 1c 1c 0d) between the 25W and 65W states.

Workarounds found
------------------
1. Full poweroff, physically unplug/replug the charger, then power on. Reliably restores ~65W in testing so far (recovers even from a 25W-clamped state). An OS reboot alone, with the charger left connected, does not help; nor does hot-swapping the charger while powered on (that's actually the known trigger for landing on 25W).

2. Live driver reload with no reboot:

       sudo modprobe -r ucsi_acpi && sudo modprobe ucsi_acpi

From a ~50W "in-between" state reached via a hot-swap, this recovered to 65W in 2/2 attempts within a few seconds. From the classic 25.00W clamp, it did not help in 2/2 attempts. A battery-only control (40W, no charger) showed no change either way, suggesting the effect is specific to USB-C PD renegotiation rather than a general power-limit reset - but it is clearly not a general substitute for (1).

Separately, this board also reproduces the NPCF ACPI-binding issue described in NVIDIA/open-gpu-kernel-modules#1162 (Power Management Object stays N/A, Dynamic Boost above the 50W base TGP never activates) - confirmed via acpidump/iasl decompile, same topology and field structure as reported there for board 8D40. That explains why

both the 25W and 65W states, so it doesn't explain this particular 25W/65W split.

Full write-up with raw capture data:
https://claude.ai/artifact/WDAN76AWk1JpW49ZSGc2Cr

Happy to gather more diagnostics (EC register snapshots, more repro counts, anything else useful) if that would help narrow this down.

Important correction to my earlier report: I ran the same charger through HP's OMEN Gaming Hub on Windows (same laptop, dual-boot) and found this is very likely *intended* HP behavior, not a bug:

"Performance settings are overridden by system defaults while using battery or a low-power AC adapter. Connect a compatible AC adapter to restore normal system performance."

HP's own first-party software explicitly classifies the 65W charger as a "low-power AC adapter" and documents that it intentionally overrides performance down. So the 25W ceiling itself is apparently by design, not a fault.

More importantly: **it also reproduces on Windows.** Same laptop, same 65W charger, Windows test session: 25W ceiling from cold boot, OMEN Gaming Hub's presence/absence made no difference, and the full poweroff+physical-unplug/replug workaround that reliably restored 65W on Linux did *not* recover it on Windows in this test (stayed at 25W for a 60-second FurMark run, 60/60 samples). So my claim that "I don't see this at all under Windows" was wrong - apologies for the bad data point.

What's still odd, and still possibly Linux/kernel-relevant: on Linux, the same 65W charger sometimes lands on ~65W instead of the (apparently intended) 25W, non-deterministically across boots/ reconnects, and stays fixed at whichever value for the rest of that session. If 25W is the intended default for this adapter class, the ~65W outcome looks like an unintended bypass of HP's low-power- adapter policy rather than a "fix" - I just don't yet know whether that bypass happens on Windows too (only tested one Windows boot session so far, which stayed at 25W throughout).

So the interesting question is probably no longer "why is this laptop sometimes clamped to 25W" (looks intended) but "what makes the negotiated result non-deterministic instead of consistently matching HP's stated policy" - which could still be something in the UCSI/PD negotiation path. Sorry for the noise, and thanks for reading this far.

[snip]

Hi,

While I am not sure why it switches between 25W/65W, I can take a look at why Dynamic Boost failing. Can you share acpidump please?

Also Ilpo Järvinen, I just observed: when support for their board (8E41) was added in hp-wmi, the patch missed the Signed-off-by tag [1] [2]. I am not sure what we can do now, but just informing you.

[1]: https://lore.kernel.org/all/[email protected]
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/hp/hp-wmi.c?id=729ffcffa73069cb066fd54a2bc7b09e5f782d48

Krishna,

Thanks for taking a look. The acpidump is already up -- BIOS is still F.05 (same as when I captured it on 8E41), so a fresh dump would be byte-identical to what I already have; no need to redo it.

Full acpidump + decompiled SSDT23 (the table with the NPCF device) is attached to my earlier comment on the NVIDIA issue:

https://github.com/NVIDIA/open-gpu-kernel-modules/issues/1162#issuecomment-5779711336

Same topology as board 8D40 from that issue: NPCF sits under \_SB as a peer of the GPU rather than as its PCIe child, which is why the open kernel module's NPCF binding misses it and Power Management Object stays N/A. That explains why >50W Dynamic Boost never works here, but it's a separate mechanism from the 25W/65W split on the 65W charger -- PMO is N/A in both states, so it can't be what's flipping that.

Happy to attach the raw acpidump/ssdt23-acpi.zip directly to this thread instead of linking out, if that's easier for you to work with -- just say the word.

Thanks for flagging the missing Signed-off-by on the other 8E41 patch too.

Thanks but I can only find SSDT23, I wanted to take a look at the HP WMI side too. Is it possible for you to attach the full acpidump instead?