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 ? 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 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 7. Can you run: sudo acpidump -o acpidump.txt And then email me the generated acpidump.txt file in a private email ? > but the event is not caught by the system > (more precisely, dmesg is complaining of unknown key codes): > >> [ 3167.842213] asus_wmi: Unknown key code 0x29 >> [ 3168.105096] asus_wmi: Unknown key code 0x28 >> [ 3168.142526] asus_wmi: Unknown key code 0x27 >> [ 3168.178860] asus_wmi: Unknown key code 0x26 >> [ 3168.216027] asus_wmi: Unknown key code 0x25 >> [ 3168.256511] asus_wmi: Unknown key code 0x24 >> [ 3168.292907] asus_wmi: Unknown key code 0x23 >> [ 3168.329704] asus_wmi: Unknown key code 0x22 >> [ 3168.366554] asus_wmi: Unknown key code 0x21 >> [ 3168.406681] asus_wmi: Unknown key code 0x20 >> [ 3168.443330] asus_wmi: Unknown key code 0x20 >> [ 3168.480900] asus_wmi: Unknown key code 0x20 >> [ 3168.516326] asus_wmi: Unknown key code 0x20 >> [ 3168.554006] asus_wmi: Unknown key code 0x20 >> [ 3168.593320] asus_wmi: Unknown key code 0x20 >> [ 3168.630108] asus_wmi: Unknown key code 0x20 >> [ 3168.670110] asus_wmi: Unknown key code 0x20 >> [ 3168.943217] asus_wmi: Unknown key code 0x11 >> [ 3169.203349] asus_wmi: Unknown key code 0x12 >> [ 3169.243239] asus_wmi: Unknown key code 0x13 >> [ 3169.279881] asus_wmi: Unknown key code 0x14 >> [ 3169.316311] asus_wmi: Unknown key code 0x15 >> [ 3169.352887] asus_wmi: Unknown key code 0x16 >> [ 3169.392806] asus_wmi: Unknown key code 0x17 >> [ 3169.429301] asus_wmi: Unknown key code 0x18 >> [ 3169.465843] asus_wmi: Unknown key code 0x19 >> [ 3169.502404] asus_wmi: Unknown key code 0x1a >> [ 3169.542308] asus_wmi: Unknown key code 0x1a >> [ 3169.578938] asus_wmi: Unknown key code 0x1a >> [ 3169.615506] asus_wmi: Unknown key code 0x1a >> [ 3169.652002] asus_wmi: Unknown key code 0x1a >> [ 3169.692280] asus_wmi: Unknown key code 0x1a > > In this case it seems that the backlight-down codes go from 0x20 to 0x29 while > the -up from 0x11 to 0x1a, so assuming they are not clamped somewhere else > they should not conflict with the ones used on newer models. 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
