Re: [PATCH 2/7] hid-asus: Add missing Zenbook Duo hotkeys

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The 'MyASUS' key (0x86) mapping is inconsistent with the existing Asus WMI driver.
--

commit ee67c289461b2da1755d4534b96e25db841e41d8
Author: Joshua Leivenzon <hacker1024@users.sourceforge.net>

hid-asus: Add missing Zenbook Duo hotkeys

This commit adds input mappings for several missing Zenbook Duo hotkeys,
including the MyASUS key, screen swap, and ROG Ally buttons, handling
them through the hid-asus driver.

> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index ce246efba74d3..cba638b19465f 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -1046,6 +1046,7 @@ static int asus_input_mapping(struct hid_device *hdev,
>  		case 0x6c: asus_map_key_clear(KEY_SLEEP);		break;
>  		case 0x7c: asus_map_key_clear(KEY_MICMUTE);		break;
>  		case 0x82: asus_map_key_clear(KEY_CAMERA);		break;
> +		case 0x86: asus_map_key_clear(KEY_CONTROLPANEL);	break; /* MyASUS */

Is it intentional to map the MyASUS key to KEY_CONTROLPANEL here?

The existing asus-nb-wmi driver maps the identical 0x86 hardware event
for the MyASUS key to KEY_PROG1.

Mapping this to KEY_CONTROLPANEL in the HID driver might introduce an
inconsistent contract for user-space, where the exact same physical
button on Asus devices yields different keycodes depending on whether the
event is routed through the HID or WMI subsystem.

Could this cause issues for desktop environments attempting to bind
device-specific hotkeys consistently?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513163248.16483-1-p.pisati@gmail.com?part=2