[RFC 0/3] platform/x86: asus-wmi: Only map brightness codes when using asus-wmi backlight control

[RFC 0/3] platform/x86: asus-wmi: Only map brightness codes when using asus-wmi backlight control

[Hans de Goede]

Hi All,

Here is a series to address the issue of some newer Asus laptop models
sending 0x2a - 0x2c events for various keys which fall within
the NOTIFY_BRNDOWN_MIN - NOTIFY_BRNDOWN_MAX range causing these to
wrongly get translated to KEY_BRIGHTNESSDOWN events.

To fix this change the NOTIFY_BRNUP_MIN - NOTIFY_BRNUP_MAX +
NOTIFY_BRNDOWN_MIN - NOTIFY_BRNDOWN_MAX key-mapping to only apply
to old models which use the vendor specific asus-wmi interface for
backlight control.

This series is marked as RFC because I still need to hear back
from the reporter if this series actually fixes things.

Regards,

Hans


Hans de Goede (3):
  platform/x86: asus-wmi: Change ASUS_WMI_BRN_DOWN code from 0x20 to
    0x2e
  platform/x86: asus-wmi: Only map brightness codes when using asus-wmi
    backlight control
  platform/x86: asus-wmi: Map 0x2a code, Ignore 0x2b and 0x2c events

 drivers/platform/x86/asus-nb-wmi.c |  3 +++
 drivers/platform/x86/asus-wmi.c    | 15 ++++-----------
 drivers/platform/x86/asus-wmi.h    |  2 +-
 3 files changed, 8 insertions(+), 12 deletions(-)

-- 
2.41.0

[RFC 1/3] platform/x86: asus-wmi: Change ASUS_WMI_BRN_DOWN code from 0x20 to 0x2e

[Hans de Goede]

Older Asus laptops change the backlight level themselves and then send
WMI events with different codes for different backlight levels.

The asus-wmi.c code maps the entire range of codes reported on
brightness down keypresses to an internal ASUS_WMI_BRN_DOWN code:

define NOTIFY_BRNUP_MIN                0x11
define NOTIFY_BRNUP_MAX                0x1f
define NOTIFY_BRNDOWN_MIN              0x20
define NOTIFY_BRNDOWN_MAX              0x2e

        if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
                code = ASUS_WMI_BRN_UP;
        else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
                code = ASUS_WMI_BRN_DOWN;

Before this commit all the NOTIFY_BRNDOWN_MIN - NOTIFY_BRNDOWN_MAX
aka 0x20 - 0x2e events were mapped to 0x20.

This mapping is causing issues on new laptop models which actually
send 0x2b events for printscreen presses and 0x2c events for
capslock presses, which get translated into spurious brightness-down
presses.

The plan is disable the 0x11-0x2e special mapping on laptops
where asus-wmi does not register a backlight-device to avoid
the spurious brightness-down keypresses. New laptops always send
0x2e for brightness-down presses, change the special internal
ASUS_WMI_BRN_DOWN value from 0x20 to 0x2e to match this in
preparation for fixing the spurious brightness-down presses.

This change does not have any functional impact since all
of 0x20 - 0x2e is mapped to ASUS_WMI_BRN_DOWN first and only
then checked against the keymap code and the new 0x2e
value is still in the 0x20 - 0x2e range.

Reported-by: James John <me@donjajo.com>
Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/
Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/platform/x86/asus-wmi.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index 5fbdd0eafa02..adb67c925724 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -18,7 +18,7 @@
 #include <linux/i8042.h>
 
 #define ASUS_WMI_KEY_IGNORE (-1)
-#define ASUS_WMI_BRN_DOWN	0x20
+#define ASUS_WMI_BRN_DOWN	0x2e
 #define ASUS_WMI_BRN_UP		0x2f
 
 struct module;
-- 
2.41.0

[RFC 2/3] platform/x86: asus-wmi: Only map brightness codes when using asus-wmi backlight control

[Hans de Goede]

Older Asus laptops change the backlight level themselves and then send
WMI events with different codes for different backlight levels.

The asus-wmi.c code maps the entire range of codes reported on
brightness down keypresses to an internal ASUS_WMI_BRN_DOWN code:

define NOTIFY_BRNUP_MIN                0x11
define NOTIFY_BRNUP_MAX                0x1f
define NOTIFY_BRNDOWN_MIN              0x20
define NOTIFY_BRNDOWN_MAX              0x2e

        if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
                code = ASUS_WMI_BRN_UP;
        else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
                code = ASUS_WMI_BRN_DOWN;

This mapping is causing issues on new laptop models which actually
send 0x2b events for printscreen presses and 0x2c events for
capslock presses, which get translated into spurious brightness-down
presses.

This mapping is really only necessary when asus-wmi has registered
a backlight-device for backlight control. In this case the mapping
was used to decide to filter out the keypresss since in this case
the firmware has already modified the brightness itself and instead
of reporting a keypress asus-wmi will just report the new brightness
value to userspace.

OTOH when the firmware does not adjust the brightness itself then
it seems to always report 0x2e for brightness-down presses and
0x2f for brightness up presses independent of the actual brightness
level. So in this case the mapping of the code is not necessary
and this translation actually leads to spurious brightness-down
presses being send to userspace when pressing printscreen or capslock.

Modify asus_wmi_handle_event_code() to only do the mapping
when using asus-wmi backlight control to fix the spurious
brightness-down presses.

Reported-by: James John <me@donjajo.com>
Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/
Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/platform/x86/asus-wmi.c | 15 ++++-----------
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 928fc74e79b4..6a79f16233ab 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3950,7 +3950,6 @@ static void asus_wmi_handle_event_code(int code, struct asus_wmi *asus)
 {
 	unsigned int key_value = 1;
 	bool autorelease = 1;
-	int orig_code = code;
 
 	if (asus->driver->key_filter) {
 		asus->driver->key_filter(asus->driver, &code, &key_value,
@@ -3959,16 +3958,10 @@ static void asus_wmi_handle_event_code(int code, struct asus_wmi *asus)
 			return;
 	}
 
-	if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX)
-		code = ASUS_WMI_BRN_UP;
-	else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX)
-		code = ASUS_WMI_BRN_DOWN;
-
-	if (code == ASUS_WMI_BRN_DOWN || code == ASUS_WMI_BRN_UP) {
-		if (acpi_video_get_backlight_type() == acpi_backlight_vendor) {
-			asus_wmi_backlight_notify(asus, orig_code);
-			return;
-		}
+	if (acpi_video_get_backlight_type() == acpi_backlight_vendor &&
+	    code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNDOWN_MAX) {
+		asus_wmi_backlight_notify(asus, code);
+		return;
 	}
 
 	if (code == NOTIFY_KBD_BRTUP) {
-- 
2.41.0

[RFC 3/3] platform/x86: asus-wmi: Map 0x2a code, Ignore 0x2b and 0x2c events

[Hans de Goede]

Newer Asus laptops send the following new WMI event codes when some
of the F1 - F12 "media" hotkeys are pressed:

0x2a Screen Capture
0x2b PrintScreen
0x2c CapsLock

Map 0x2a to KEY_SELECTIVE_SCREENSHOT mirroring how similar hotkeys
are mapped on other laptops.

PrintScreem and CapsLock are also reported as normal PS/2 keyboard events,
map these event codes to KE_IGNORE to avoid "Unknown key code 0x%x\n" log
messages.

Reported-by: James John <me@donjajo.com>
Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/
Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/platform/x86/asus-nb-wmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index d85d895fee89..df1db54d4e18 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -531,6 +531,9 @@ static void asus_nb_wmi_quirks(struct asus_wmi_driver *driver)
 static const struct key_entry asus_nb_wmi_keymap[] = {
 	{ KE_KEY, ASUS_WMI_BRN_DOWN, { KEY_BRIGHTNESSDOWN } },
 	{ KE_KEY, ASUS_WMI_BRN_UP, { KEY_BRIGHTNESSUP } },
+	{ KE_KEY, 0x2a, { KEY_SELECTIVE_SCREENSHOT } },
+	{ KE_IGNORE, 0x2b, }, /* PrintScreen (also send via PS/2) on newer models */
+	{ KE_IGNORE, 0x2c, }, /* CapsLock (also send via PS/2) on newer models */
 	{ KE_KEY, 0x30, { KEY_VOLUMEUP } },
 	{ KE_KEY, 0x31, { KEY_VOLUMEDOWN } },
 	{ KE_KEY, 0x32, { KEY_MUTE } },
-- 
2.41.0

Re: [RFC 0/3] platform/x86: asus-wmi: Only map brightness codes when using asus-wmi backlight control

[Hans de Goede]

Hi All,

On 10/17/23 11:07, Hans de Goede wrote:
> Hi All,
> 
> Here is a series to address the issue of some newer Asus laptop models
> sending 0x2a - 0x2c events for various keys which fall within
> the NOTIFY_BRNDOWN_MIN - NOTIFY_BRNDOWN_MAX range causing these to
> wrongly get translated to KEY_BRIGHTNESSDOWN events.
> 
> To fix this change the NOTIFY_BRNUP_MIN - NOTIFY_BRNUP_MAX +
> NOTIFY_BRNDOWN_MIN - NOTIFY_BRNDOWN_MAX key-mapping to only apply
> to old models which use the vendor specific asus-wmi interface for
> backlight control.
> 
> This series is marked as RFC because I still need to hear back
> from the reporter if this series actually fixes things.

Ok, so this has been tested now and since this is being hit by
multiple users (also see: https://bbs.archlinux.org/viewtopic.php?pid=2123716 )
I have decided to push this to pdx86/fixes now.

Note there is a chance that this may lead to regressions where
the brightness hotkeys stop working on some really old Asus laptop
models, in case they do report the NOTIFY_BRNUP_MIN - NOTIFY_BRNUP_MAX +
NOTIFY_BRNDOWN_MIN - NOTIFY_BRNDOWN_MAX keys even though another
method (acpi_video / GPU-native) is used to control the backlight.

This would be weird, but not entirely unsurprising.

Unfortunately the only way to find out if this is the case is to try,
so I've decided to move ahead with this series to fix the known issues
caused without it on newer models. I will deal with any regressions
on older models if / when they get reported.

Regards,

Hans



> Hans de Goede (3):
>   platform/x86: asus-wmi: Change ASUS_WMI_BRN_DOWN code from 0x20 to
>     0x2e
>   platform/x86: asus-wmi: Only map brightness codes when using asus-wmi
>     backlight control
>   platform/x86: asus-wmi: Map 0x2a code, Ignore 0x2b and 0x2c events
> 
>  drivers/platform/x86/asus-nb-wmi.c |  3 +++
>  drivers/platform/x86/asus-wmi.c    | 15 ++++-----------
>  drivers/platform/x86/asus-wmi.h    |  2 +-
>  3 files changed, 8 insertions(+), 12 deletions(-)
>