Thank you for the reply, and sorry for the delay. As I was gathering the information you asked for I realized that the behavior has changed in the meantime, and I am not sure of the reason why (but I guess due to some package update, possibly unrelated to this). If I understand correctly, now the events are no longer reported by the Asus WMI driver, but by the Intel backlight driver. Because of this the backlight variations are once again reported by the DM (KDE Plasma 5, on Arch Linux) in 5% increments, and no longer seem to be under EC control (i.e. the backlight is no longer adjustable during boot, before the DE is up). The new behavior persist even downgrading the kernel and the firmware package, so I'm not sure which package may be responsible for the change. Booting into Debian Bookworm (v6.1.0-13) the old behavior is restored (i.e. the one before the previous patches), with Asus-WMI once again in control (so I guess that at least the change do not persist across reboots). November 25, 2023 at 15:25, "Hans de Goede" <hdegoede@xxxxxxxxxx> wrote: > > Hi Juri, > > On 11/24/23 16:54, Juri Vitali wrote: >> >> >> Hi, >> Unfortunately those patches have broken the backlight reporting on older >> laptops, which do rely on the old mechanism. >> > > Thank you for reporting this and sorry about the regression. > > And thank you for writing a good bug report with as much info > included as possible, that is much appreciated. > >> >> For instance, on my Asus UX32A/VD when pressing the backlight up/down button >> the backlight changes accordingly, >> > > Ok, so the embedded-controller (EC) is adjusting the brightness > itself in reaction to the key presses, which means that > the old behavior of sending KEY_BRIGHTNESSDOWN / > KEY_BRIGHTNESSUP was not really correct because that will > cause e.g. GNOME to then increase the brightness itself > which means that if the new brightness is correctly reflected > when reading it GNOME may increase the brightness an > additional step on top of the step it has already been > increased by the EC itself. > > Which makes me wonder how to properly solve this, > so I have a bunch of questions: > > 1. What desktop environment are you using ? > > 2. Assuming you are using GNOME (for now) I guess that with older > kernels you got an on-screen-display (OSD) notification about > the brightness changing? Do you notice any difference in how > many total steps you have going from min to max with older > kernels vs the new kernel ? If the double increase problem > happens I guess you only get 5 brightness levels in GNOME / > 4 steps from going from minimal to maximum ? > For the aforementioned reasons I can no longer reproduce the issue on the original environment (KDE Plasma 5 on Arch Linux) but the behavior on Gnome on Debian is basically the same as before, so I'll be using that. In both cases (now on Debian, and previously on Arch) the brightness has a granularity on 10-ish steps (0-100% in increments of 10% for KDE Plasma on Arch, and 9 unnamed steps on Gnome on Debian), and no "double-change" seem to be occurring. > > Note below questions should all be answered with the new kernel > with the unknown key messages in dmesg. > > 3. Can you do: > > ls /sys/class/backlight > On Debian: > > $ ls -l /sys/class/backlight/ > total 0 > lrwxrwxrwx 1 root root 0 Dec 4 00:26 acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0 > lrwxrwxrwx 1 root root 0 Dec 4 00:26 acpi_video1 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video1 On Arch: > ls -l /sys/class/backlight/ > totale 0 > lrwxrwxrwx 1 root root 0 4 dic 00.43 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card1/card1-eDP-1/intel_backlight > > And let me know the output, I wonder what method is being > used to control backlight on your machine. > > 4. Can you do: > > cat /sys/class/backlight/$name/max_brightness > > What does this say? > > With $name being the name from 3. > > 5. Can you do: > > cat /sys/class/backlight/$name/brightness > > And then change the brightness using the keys, and then > again do: > > cat /sys/class/backlight/$name/brightness > > What are the values shown before / after changing it ? > > 6. Can you repeat 5 but then do: > > cat /sys/class/backlight/$name/actual_brightness > On Debian: * `max_brightness` is `10` on both devices; * `brightness` goes from 1 to 10 following the screen brighness only for `acpi_video0`, while in `acpi_video1` it is stuck at `10`; * `actual_brightness` follows the screen brightness on both devices. On Arch: * `max_brighness` is 4296; * `brightness` changes in steps of 215 units for each 5% reported increment; * `actual_brightness` is the same as `brighness`. Notice that before the latest change in behavior the output on Arch was IIRC the same as now on Debian, but unfortunately I haven't recorded it so I cannot say with absolute certainty. > > 7. Can you run: > > sudo acpidump -o acpidump.txt > > And then email me the generated acpidump.txt file > in a private email ? > I'll send you a mail with the output on both Debian and Arch, in case there should be any significant differences. > > Thanks, that (the codes not overlapping with newer models codes) is > useful information to have. With that it should be easy to restore > the old behavior of sending KEY_BRIGHTNESSDOWN / UP, my questions > above are mainly because I wonder if that is the right thing to do > taking into account that the EC already adjusts the brightness itself. > >> >> By the way, I only found those codes to be reported by asus-wmi, while other >> inputs remain silent while pressing those keys. >> > > Yes that is expected, for unknown asus-wmi events no events > are send to userspace. > > Regards, > > Hans > Thank you again, and let me know if there is anything missing! Juri
