https://bugzilla.kernel.org/show_bug.cgi?id=221907
Bug ID: 221907
Summary: Acer Nitro AN515-58: internal display backlight cannot
be controlled (WMBF/WQ00 firmware bug)
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Platform_x86
Assignee: [email protected]
Reporter: [email protected]
Regression: No
Created attachment 310710
--> https://bugzilla.kernel.org/attachment.cgi?id=310710&action=edit
Full dmesg output showing WMBF/WQ00 firmware bug
Bug Report: Internal display backlight cannot be controlled on Acer Nitro
AN515-58 (Linux)
Summary
On the Acer Nitro AN515-58 (Alder Lake-P i5/i7 + NVIDIA RTX 3050, Optimus
mode), the internal
display brightness cannot be adjusted from Linux. Writing to the backlight
sysfs interface
succeeds (the value is updated and read back correctly) but the physical panel
brightness
never changes. This happens regardless of which backlight interface is forced
(`intel_backlight` via `acpi_backlight=native`, or the default
ACPI/WMI-selected interface),
and regardless of the `i915.enable_dpcd_backlight` module parameter value (-1
default, 1, or 2
all produce the same result). Brightness control DOES work correctly in Windows
on the same
machine (dual-boot), confirming the hardware/EC itself is functional and this
is a
Linux-specific driver/firmware-interface issue.
System Information
- **Model:** Acer Nitro AN515-58 (Nitro 5 series)
- **CPU:** Intel Alder Lake-P (device ID 46a6), confirmed via dmesg
- **GPU:** Intel integrated (i915) + NVIDIA RTX 3050 Mobile, BIOS Display Mode
= Optimus
- **BIOS/Firmware:** Insyde H2O, version 2.21 (latest available from Acer at
time of report)
- **Distro:** Ubuntu 26.04
- **Kernel:** 7.0.0-30-generic (also reproduced on 7.0.0-14-generic)
- **Dual-boot:** Yes, Windows on a separate NVMe drive. Brightness control
works correctly
in Windows on this same hardware.
## Steps to Reproduce
1. Boot into Ubuntu with default kernel parameters (`quiet splash`, no
backlight overrides).
2. Observe `/sys/class/backlight/` — result varies depending on kernel cmdline
(see below).
3. Attempt to change brightness via GNOME slider, or directly via:
```
sudo brightnessctl set 20%
sudo brightnessctl set 80%
```
4. Observe that the sysfs `brightness`/`actual_brightness` values change
correctly, but the
physical panel brightness does not change at all.
## Observed Behavior by Configuration
### A) Default cmdline (no acpi_backlight override)
- `/sys/class/backlight/` is **empty** — no backlight device registers at all.
- Relevant dmesg:
```
[ 1.195486] wmi_bus wmi_bus-PNP0C14:00: [Firmware Bug]: WMBF method block
execution control method not found
[ 1.196731] wmi_bus wmi_bus-PNP0C14:01: [Firmware Bug]: WQ00 data block
query control method not found
[ 3.312430] acer_wmi: Acer Laptop ACPI-WMI Extras
[ 3.312473] acer_wmi: Function bitmap for Communication Button: 0x801
[ 3.873181] i915 0000:00:02.0: [drm] Skipping intel_backlight registration
```
### B) `acpi_backlight=native`
- `/sys/class/backlight/` shows only `intel_backlight`.
- `brightnessctl set <N>%` updates `current brightness` and `actual_brightness`
correctly
(verified via `brightnessctl -l`), but the panel does not visibly change
brightness at
any percentage from 0–100%.
### C) `acpi_backlight=native i915.enable_dpcd_backlight=1`
- Same as B — sysfs values update correctly, no visible change on the panel.
### D) `acpi_backlight=native i915.enable_dpcd_backlight=2`
- Same as B/C — sysfs values update correctly, no visible change on the panel.
### E) Windows (same machine, dual-boot)
- Brightness slider and Fn+brightness hotkeys work correctly and produce a
visible change.
## Root Cause Analysis (as far as I could determine)
The kernel explicitly flags a firmware bug on this system during WMI bus
enumeration:
```
[Firmware Bug]: WMBF method block execution control method not found
[Firmware Bug]: WQ00 data block query control method not found
```
This indicates the ACPI/WMI method blocks (`WMBF`, `WQ00`) that Windows likely
uses (via a
vendor-specific WMI GUID, possibly through Acer's own driver stack /
NitroSense) to control
the panel backlight are not correctly exposed to the generic Linux ACPI-WMI
driver
(`drivers/platform/x86/wmi.c`), or are present as a data Buffer rather than a
callable Method
(similar in nature to prior firmware-bug reports on other vendors, e.g.
https://bugzilla.kernel.org/show_bug.cgi?id=207835 for a different Acer model).
I also checked `drivers/platform/x86/acer-wmi.c` in mainline (torvalds/linux)
and found this
model already has a DMI-matched quirk entry:
```c
static struct quirk_entry quirk_acer_nitro_an515_58 = {
.predator_v4 = 1,
.pwm = 1,
};
```
matched against `DMI_PRODUCT_NAME = "Nitro AN515-58"`. This quirk enables
platform-profile,
hwmon, and PWM (fan/RGB) capabilities, but does **not** set the `.brightness`
quirk field,
so `acer-wmi` does not attempt any EC-level brightness read/write for this
model. This may be
relevant if the correct fix is an acer-wmi EC quirk (similar to how
`.brightness = -1` is used
for the Aspire 1520 quirk) rather than (or in addition to) an i915/ACPI
backlight fix.
Since forcing `intel_backlight` (native PWM/DPCD via i915) also fails to move
the physical
panel, my current best guess is that on this model the eDP panel's brightness
is NOT
controlled by standard PWM or DPCD at all, but exclusively through the vendor
WMI/EC path
that is broken due to the firmware bug above — meaning i915 native control may
be
architecturally unable to reach the panel on this hardware, regardless of DPCD
mode.
## What I Have Already Tried
- `acpi_backlight=native` (forces intel_backlight to register) — no effect on
panel.
- `i915.enable_dpcd_backlight=1` and `=2` — no effect on panel.
- Updated to latest available BIOS (2.21) — no change in behavior.
- Updated kernel to 7.0.0-30-generic (also tested 7.0.0-14-generic) — no
change.
- Confirmed via `brightnessctl -l` that sysfs values do update correctly in all
configurations; only the physical panel fails to respond.
## Requested Information / Next Steps
- Could this be addressed via an `acer-wmi` EC-level brightness quirk for this
model
(similar to existing quirks for other Acer models), bypassing the broken
WMBF/WQ00 method
path?
- Alternatively, is there a known DPCD/AUX-channel quirk needed for this
specific panel that
isn't covered by `enable_dpcd_backlight=1/2`?
- Happy to provide `acpidump`, full `dmesg`, `sudo cat
/sys/kernel/debug/dri/0/i915_display_info`,
or test debug patches — please advise which is most useful.
## Attachments to Include When Filing
- [ ] Full `dmesg` output (`sudo dmesg > dmesg.log`)
- [ ] `sudo acpidump > acpi.log` (or `acpidump -d -t > DSDT.dsl` for a decoded
table)
- [ ] `sudo dmidecode > dmidecode.log` (confirms exact model/BIOS version)
- [ ] Output of `brightnessctl -l` before/after a `set` command
- [ ] `cat /proc/cmdline` for each configuration tested
## Suggested Filing Location
- https://bugzilla.kernel.org — Component: **Drivers / Platform-x86** (for the
acer-wmi /
WMI firmware-bug angle) or **ACPI/Video** (for the i915 backlight angle).
Consider filing
under Platform-x86 first since that's where the explicit `[Firmware Bug]`
originates, and
cross-reference from there if maintainers redirect it.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.