linux-kernel - Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS Lock and PrntScrn on Zenbook S 13 UX5304VA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <93b172c0-79ad-47d0-9948-e286917c18bb@redhat.com>
Date:   Mon, 4 Dec 2023 14:54:52 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     juri@...idebyzero.it, James John <me@...jajo.com>,
        Corentin Chary <corentin.chary@...il.com>,
        Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
        Mark Gross <markgross@...nel.org>
Cc:     platform-driver-x86@...r.kernel.org,
        acpi4asus-user@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: PROBLEM: asus_nb_wmi sends KEY_BRIGHTNESSDOWN on pressing CAPS
 Lock and PrntScrn on Zenbook S 13 UX5304VA

Hi,

On 12/4/23 14:06, juri@...idebyzero.it wrote:
> December 4, 2023 at 01:32, juri@...idebyzero.it wrote:
>>
>> 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.
>>
> 
> Investigating further I found that that the change was not due to an updated package, but because I mistakenly removed a kernel cmdline argument, i.e. `"acpi_osi=!Windows 2012"`. Restoring it the behavior returns to the same as before. 
> 
>> 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).
>>
>> 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.
> 
>> 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
>>>
>>
>> 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.
> 
> Restoring `"acpi_osi=!Windows 2012"`, on Arch Linux the result is:
>> % uname -a                                                                                                                                                            
>> Linux Arch-Zenbook 6.1.64-1-lts #1 SMP PREEMPT_DYNAMIC Tue, 28 Nov 2023 19:37:35 +0000 x86_64 GNU/Linux
>> % ls -l /sys/class/backlight                                                                                                                                        
>> totale 0
>> lrwxrwxrwx 1 root root 0  4 dic 13.41 acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0
>> lrwxrwxrwx 1 root root 0  4 dic 13.41 acpi_video1 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video1
> 
> * `max_brightness` is `10` on both devices;
> * `brighness` is stuck at `10` on both;
> * `actual_brightness` goes from 0 to 10 only on `acpi_video1`, while is stuck at 10 on `acpi_video0`.
> 
> Notice that with this kernel and configuration I again have the `unknown key code` messages and no OSD feedback, which I wasn't able to replicate in the previous message.

Ok, that is good to know. Is there any specific reason why you are passing
"acpi_osi=!Windows 2012" on the kernel commandline?

Generally speaking passing any other kernel arguments then those used
to specify the root filesystem and things like "quiet" is not advisable.

Everything should just work without passing any special options and if things
do not work without special options then that is a bug which needs to be fixed.

Regards,

hans