ASUS TUF Gaming A15 FA506NC – Brightness Not Working on Linux (Fixed by Forcing PWM Backlight)

Hello everyone!

After spending several hours debugging a brightness issue on my ASUS TUF Gaming A15 FA506NC, I wanted to document both the root cause and the solution in case it helps other users running CachyOS, Arch, or any modern Linux distribution on similar hardware.

The Problem

On a fresh CachyOS installation, all brightness controls appeared to function correctly:

  • KDE brightness slider worked

  • brightnessctl worked

  • /sys/class/backlight/amdgpu_bl2/brightness changed correctly

  • actual_brightness changed correctly

However, the physical panel brightness never changed.

From the desktop environment’s perspective everything looked normal, yet the display remained at the same brightness regardless of the selected value.

Hardware

System:

  • ASUS TUF Gaming A15 FA506NC

  • BIOS: FA506NC.308

  • AMD Radeon 680M (Rembrandt)

  • NVIDIA RTX 3050 Mobile

  • Internal display connected through AMD iGPU

Panel identified as:

LM156LF-2F01 (CEC Panda)

Initial Investigation

At first glance the issue looked like a typical backlight detection problem.

I tested:

  • KDE brightness controls

  • brightnessctl

  • Multiple kernels (CachyOS and CachyOS LTS)

  • Various AMDGPU backlight parameters

  • ACPI backlight modes

  • NVIDIA WMI backlight

  • DRM connector properties

  • DebugFS backlight interfaces

All of them reported successful brightness changes.

For example:

brightnessctl -d amdgpu_bl2 s 5%

correctly updated:

brightness
actual_brightness

Yet the panel brightness remained unchanged.

Even more interesting, the AMD PWM debug values never moved:

amdgpu_target_backlight_pwm
amdgpu_current_backlight_pwm

Both remained fixed regardless of the selected brightness level.

The Breakthrough

The turning point came from enabling AMDGPU tracing.

I enabled the following tracepoint:

echo 1 > /sys/kernel/tracing/events/amdgpu_dm/amdgpu_dm_brightness/enable

After changing brightness levels, the trace output revealed:

brightness requested=25550 converted=3998 aux=true
brightness requested=511000 converted=390000 aux=true

The important detail was:

aux=true

AMDGPU was not using PWM backlight control.

Instead, it was using:

eDP AUX Backlight Control

At that moment the entire behavior suddenly made sense.

The driver was successfully receiving brightness requests and converting them correctly, but it was attempting to communicate with the panel through AUX brightness control, which apparently was not functioning properly on this panel/firmware combination.

Discovering the AMDGPU Parameter

Checking the module parameters revealed:

modinfo amdgpu

Output:

backlight:
0 = pwm
1 = aux
-1 = auto

My system was running with:

amdgpu.backlight=1

which explicitly forces AUX backlight control.

Since the trace had already confirmed:

aux=true

the next logical step was obvious.

The Fix

I changed the kernel parameter to:

acpi_backlight=native amdgpu.backlight=0

which forces PWM backlight control.

After rebooting:

  • Brightness worked immediately

  • KDE brightness controls worked

  • brightnessctl worked

  • Physical panel brightness changed correctly

Problem solved.

Final Working Configuration

Kernel command line:

acpi_backlight=native amdgpu.backlight=0

Verification:

cat /proc/cmdline

Result:

... acpi_backlight=native amdgpu.backlight=0

Backlight device:

ls /sys/class/backlight

Result:

amdgpu_bl2

Brightness now functions normally.

Conclusion

This was not a KDE issue, not a Wayland issue, not a CachyOS issue, and not a brightnessctl issue.

The root cause was AMDGPU using AUX backlight control on a panel that appears to behave incorrectly with AUX brightness commands.

Forcing PWM backlight control resolved the issue completely.

If you are running an ASUS TUF Gaming A15 FA506NC (or potentially a similar Rembrandt-based ASUS laptop) and brightness controls appear to work while the physical panel brightness never changes, try:

acpi_backlight=native amdgpu.backlight=0

It may save you several hours of debugging.

Hopefully this helps someone else.

3 Likes