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: <d8c5c530-9eea-5acb-f7f7-7f7af56e700d@redhat.com>
Date:   Wed, 18 Oct 2023 21:35:47 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     me@...jajo.com
Cc:     Corentin Chary <corentin.chary@...il.com>,
        Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
        Mark Gross <markgross@...nel.org>,
        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 James,

On 10/18/23 02:17, me@...jajo.com wrote:
> Hi Hans,
> 
> I hope you are feeling better now.
> Thank you so much for your support in resolving this.
> 
>> I assume that the first "BACKLIGHT BUTTON" is the backlight DOWN button ?
> Yes. Correct.
> 
> 
>> 2. Can you please run:
>>
>> sudo evtest and then select the "ACPI video bus" (or something
>> similar) device and see if that reports brightness up/down
>> keypresses?  And then do the same thing for the
>> "Asus WMI hotkeys" device ? I expect the Asus WMI hotkeys
>> device to only report brightness up keypresses (after my
>> hwdb "fix") while I expect brightness-up events to get
>> reported twice, by both the "ACPI video bus" device and
>> the "Asus WMI hotkeys" device.
> Done and attached.
> 
>> Can you confirm this? This also means that brightness
>> up will take bigger steps (2 steps per keypress) then
>> brightness down, right ?
> I am not sure I understand what you mean here. But I have attached the output here

The 2 evtest logs show that each brightness up/down keypress
gets reported twice, once by the "ACPI video bus" device and
once bythe "Asus WMI hotkeys" device.

This means that in e.g. GNOME the brightness will move
up / down by 2 steps for each step, reducing the amount
of steps from 20 to 10, or iow making each step twice
as big. Especially at the low end of the brightness
scale this may be an issue since steeping by 5% there
can already make a big difference and this double
key press reporting now changes this into stepping
by 10% at a time.

> After applying your patch, it seems to have fixed the issue!

Thank you for all the testing and other then the double
keypress issue + the unknown code messages everything
now looks good!

I have applied 2 more patches the first one fixes the
unknown code messages and adds a mapping for the
"Screen Capture" hotkey. The second test filters out
the duplicate (duplicate with the "ACPI video bus")
brightness up/down events.

It would be great if you can add these on top of
the previous 2 patches and then run one last
test for me:

Run evtest on the "Asus WMI hotkeys" device this should now:

1. Show no output for capslock / printscreen

2. Show KEY_SELECTIVE_SCREENSHOT events for the
   "Screen Capture" hotkey.

3. Show no output for brightness up/down,
   yet brightness up/down should still work since
   these are also reported by the "ACPI video bus"

It would be great if you can confirm for each of these
that this behaves as expected with the 2 extra patches
applied on top of the previous patches.

Regards,

Hans

View attachment "0001-platform-x86-asus-wmi-Map-0x2a-code-Ignore-0x2b-and-.patch" of type "text/x-patch" (1785 bytes)

View attachment "0002-platform-x86-asus-wmi-Do-not-report-brightness-up-do.patch" of type "text/x-patch" (2620 bytes)