It looks like the kernel/driver resets brightness on every plug/unplug. /sys/class/backlight/ contains two directories: acpi_video0/ & radeon_bl0/ Full brightness: $ cat /sys/class/backlight/*/brightness 24 255 Zero brightness: $ cat /sys/class/backlight/*/brightness 0 255 The reset doesn't actually change any value (or so it seems), even /sys/devices/virtual/thermal/cooling_device1/, which contains the brightness, doesn't change. But I tried changing the brightness manually and comparing and it looks like it resets it to this position, even though it doesn't show it: $ cat /sys/class/backlight/*/brightness 10 255
Created attachment 180531 [details] Output of acpidump
The fact that the backlight level changed but the sysfs file value didn't suggests that the change is done by firmware, instead of the drivers. BTW, for plug/unplug, do you mean the AC adapter?
Yes. Also, one if the first things I did when I got this laptop (1 year back) was to update it's BIOS to F21 (latest version). I am not sure, but I think this bug didn't happen in earlier versions.
I'll test this in Windows if the bug is present there also.
(In reply to Juraj Fiala from comment #4) > I'll test this in Windows if the bug is present there also. That would be good to know, thanks.
OK, tried it in Windows, and there are several things I learned: 1. The brightness keys don't work at all (and I don't even remember them working). 2. There are only 11 brightness levels, whereas on Linux there are 25. 3. The brightness changing (via the GUI) is MUCH more responsive. 4. On un/plug the brightness goes to **maximum** with the GUI responding shortly afterwards.
(In reply to Juraj Fiala from comment #6) > OK, tried it in Windows, and there are several things I learned: > > 1. The brightness keys don't work at all (and I don't even remember them > working). OMG, that's even worse than Linux? > 2. There are only 11 brightness levels, whereas on Linux there are 25. Don't know why this can happen... > 3. The brightness changing (via the GUI) is MUCH more responsive. The backlight change through acpi_video interface is done through SMI, maybe Windows isn't using the ACPI interface? Which Windows version are you using? Please also try to disable acpi_video by adding cmdline option: acpi_backlight=native if you are using the latest v4.2-rc kernel; if you are using a previous kernel, that should be: video.use_native_backlight=1 You can confirm if the above option works by checking if there is only the raedon_bl0 directory under /sys/class/backlight > 4. On un/plug the brightness goes to **maximum** with the GUI responding > shortly afterwards. It doesn't seem like a good idea to set brightness to maximum on AC unplug.
(In reply to Aaron Lu from comment #7) > (In reply to Juraj Fiala from comment #6) > > OK, tried it in Windows, and there are several things I learned: > > > > 1. The brightness keys don't work at all (and I don't even remember them > > working). > > OMG, that's even worse than Linux? It's Vista, so not surprised. > > 2. There are only 11 brightness levels, whereas on Linux there are 25. > > Don't know why this can happen... Probably Windows's fault. Vista as done much worse things than that. > > 3. The brightness changing (via the GUI) is MUCH more responsive. > > The backlight change through acpi_video interface is done through SMI, maybe > Windows isn't using the ACPI interface? Which Windows version are you using? > Please also try to disable acpi_video by adding cmdline option: > acpi_backlight=native if you are using the latest v4.2-rc kernel; if you are > using a previous kernel, that should be: video.use_native_backlight=1 > You can confirm if the above option works by checking if there is only the > raedon_bl0 directory under /sys/class/backlight Oops, sorry, it's gnome's fault that the brightness changes slower. It works fine with other utilities. > > 4. On un/plug the brightness goes to **maximum** with the GUI responding > > shortly afterwards. > > It doesn't seem like a good idea to set brightness to maximum on AC unplug. Again, Vista. How does it behave on other laptops? Maybe not touching the brightness would be the best idea?
(In reply to Juraj Fiala from comment #8) > (In reply to Aaron Lu from comment #7) > > It doesn't seem like a good idea to set brightness to maximum on AC unplug. > > Again, Vista. How does it behave on other laptops? Maybe not touching the > brightness would be the best idea? The ACPI backlight has a way to let firmware express the desired backlight level when AC is plugged in and out, and that two levels are stored in a ACPI control method callaed _BCL. When the AC is plugged in/out, firmware will do nothing related to backlight. In the meantime, the AC plug in/out event is sent to OS by firmware. The in kernel driver video gets the notification of AC plugged in/out, it will set backlight to the level expressed by the firmware and people will notice a change in backlight, normally, the value is 100% on AC in and 50% on AC out, let's call this case 1. Another case is, the firmware will do things on its own that on AC plug in/out, it will set backlight level directly to some values, let's call this case 2. I think what happens under Linux with your laptop is case 2, because if case 1 happened, the /sys/class/backlight/acpi_video0/brightness value will change accordingly, since the change is done by video module, it will take care of the sysfs file value. But if the backlight level change is directly done by firmware, the sysfs file value will not be changed accordingly since video module doesn't know backlight level has changed.
I'll close it as WILL_NOT_FIX as we do not have a way to control the behavior of the firmware.