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 <krishna.chomal108@gmail.com>]

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.