https://bugzilla.kernel.org/show_bug.cgi?id=221648
--- Comment #1 from [email protected] ([email protected]) --- UPDATE — Revised diagnosis after full ACPI table analysis and empirical kernel-parameter testing (kernel 7.0.13-200.fc44, NVIDIA 595.80 open module) Following up on my original report, I have now performed a complete extraction and disassembly of ALL ACPI tables (DSDT + 24 SSDTs) and a systematic, reversible test of every standard Linux backlight mechanism. The picture is more complex than my initial DSDT-only analysis suggested, and I want to correct and expand the record. === CORRECTION TO THE ORIGINAL DIAGNOSIS === My first report stated that the brightness methods (_BCL/_BCM/_BQC) were located ONLY under the NVIDIA PCIe subtree, and that relocating them to GFX0 would fix the issue. Full table analysis shows this was incomplete: The brightness methods DO exist under the Intel node. In SSDT14, under Scope (\_SB.PC00.GFX0), there are two display devices (DD1F and DD2F) that each define a complete _BCL / _BCM / _BQC set: Scope (\_SB.PC00.GFX0) Device (DD1F) { _BCL, _BCM, _BQC } Device (DD2F) { _BCL, _BCM, _BQC } So the methods are NOT missing from the Intel side. The ACPI tree is more layered than a DSDT-only view revealed (methods appear in both DSDT and SSDT14). === WHAT ACTUALLY HAPPENS (empirically verified) === 1. Only one backlight interface is registered by default: intel_backlight (type raw, on the Intel iGPU eDP, card1-eDP-1, PCI 0000:00:02.0). 2. Writing to that interface is accepted by the kernel but produces NO physical change: echo 10000 > /sys/class/backlight/intel_backlight/brightness → value stored, panel unchanged. 3. There are TWO eDP endpoints, one per GPU: card0-eDP-2 → NVIDIA (0000:01:00.0) card1-eDP-1 → Intel (0000:00:02.0) The only backlight interface lives on the Intel eDP, but the physical panel is driven/routed through the NVIDIA side. 4. The NVIDIA WMI EC backlight path cannot bind: nvidia_wmi_ec_backlight loads but the firmware does NOT expose the required WMI GUID (603E9613-EF25-4338-A3D0-C46177516DB7). /sys/class/wmi is effectively without it, and modprobe creates no interface. 5. Firmware WMI errors remain present at every boot: ACPI Error: Aborting method \_SB.WMID.WQBZ (AE_AML_BUFFER_LIMIT) ACPI Error: Aborting method \_SB.WMID.WQBE (AE_AML_BUFFER_LIMIT) === KERNEL PARAMETERS TESTED (all applied via grubby, all reverted, none worked) === acpi_backlight=native → only intel_backlight, no physical effect acpi_backlight=vendor → backlight list becomes EMPTY (worse) acpi_backlight=video → acpi_video0 + acpi_video1 appear, KDE slider and Fn keys respond (scale 0–100), but physical brightness still does NOT change i915.enable_dpcd_backlight=1 → no change (interface stays raw, no effect) nvidia.NVreg_RegistryDwords=EnableBrightnessControl=1 → parameter active in /proc/cmdline, no NVIDIA backlight interface created, no effect Note: nvidia.NVreg_EnableBacklightHandler is NOT available in the 595.80 open module (removed by NVIDIA; confirmed absent via modinfo). Also, the RTX 5060 is Blackwell — per NVIDIA docs, Blackwell is supported ONLY by the open kernel module, so there is no proprietary/closed branch to switch to for different backlight behaviour. === REVISED ROOT CAUSE === The problem is not simply the location of the ACPI methods in the tree. Even with _BCL/_BCM/_BQC present under GFX0, no standard Linux mechanism controls the physical backlight, because: - The physical panel's backlight control path is on the NVIDIA side. - The firmware does not expose the WMI GUID that nvidia_wmi_ec_backlight requires to drive it. - Some HP WMI methods abort with AE_AML_BUFFER_LIMIT, indicating a firmware-level WMI/buffer defect. === REVISED REQUEST TO HP === A BIOS/firmware update that either: (a) exposes the NVIDIA WMI EC backlight GUID (603E9613-EF25-4338-A3D0-C46177516DB7) so the in-kernel nvidia_wmi_ec_backlight driver can bind and drive the panel; and/or (b) fixes the WMI methods that currently abort with AE_AML_BUFFER_LIMIT (\_SB.WMID.WQBZ / WQBE); and/or (c) ensures a working ACPI/PWM backlight control path for the panel that is reachable by the Intel i915 driver on the eDP it actually drives. Simply relocating the ACPI methods to GFX0 (as I originally requested) is likely NOT sufficient on its own, since the panel's control path is on the NVIDIA side and the WMI bridge Linux needs is absent from the firmware. A full, reproducible diagnostic report (all commands, outputs, and ACPI findings) is available and can be attached to a bug tracker on request. System: OMEN 16-am0015ns, BIOS F.14 (latest), Fedora 44 KDE (Wayland), kernel 7.0.13-200.fc44, NVIDIA 595.80 open, Secure Boot disabled, nouveau/nova_core blacklisted. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
