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

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

[sjunhyuk1]

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
>50W boost never works here, but Power Management Object reads N/A in
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.

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

[sjunhyuk1]

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.

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

[Krishna Chomal]

On Tue, Sep 22, 2026 at 03:23:12PM -0400, sjunhyuk1@gmail.com wrote:
>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)
>
[snip]
>
>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
>>50W boost never works here, but Power Management Object reads N/A in
>both the 25W and 65W states, so it doesn't explain this particular
>25W/65W split.

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/20260203164832.40514-1-plotnikovanton@gmail.com
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/hp/hp-wmi.c?id=729ffcffa73069cb066fd54a2bc7b09e5f782d48

>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.

Re: [BUG] HP OMEN Transcend 14 (board 8E41): GPU power ceiling on 65W USB-C charger is non-deterministic

[BurningHoryd]

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.

Re: [BUG] HP OMEN Transcend 14 (board 8E41): GPU power ceiling on 65W USB-C charger is non-deterministic

[Krishna Chomal]

On Fri, Sep 25, 2026 at 09:41:48AM -0400, BurningHoryd wrote:
>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 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?

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