zenbook-duo-suppress-rfkill-on-kbd-connect.patch

diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index fceffe2082ec..ed3633c5955d 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -145,6 +145,10 @@ static struct quirk_entry quirk_asus_ignore_fan = {
 	.wmi_ignore_fan = true,
 };
 
+static struct quirk_entry quirk_asus_zenbook_duo_kbd = {
+	.ignore_key_wlan = true,
+};
+
 static int dmi_matched(const struct dmi_system_id *dmi)
 {
 	pr_info("Identified laptop model '%s'\n", dmi->ident);
@@ -516,6 +520,15 @@ static const struct dmi_system_id asus_quirks[] = {
 		},
 		.driver_data = &quirk_asus_ignore_fan,
 	},
+	{
+		.callback = dmi_matched,
+		.ident = "ASUS Zenbook Duo UX8406MA",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "UX8406MA"),
+		},
+		.driver_data = &quirk_asus_zenbook_duo_kbd,
+	},
 	{},
 };
 
@@ -630,7 +643,12 @@ static void asus_nb_wmi_key_filter(struct asus_wmi_driver *asus_wmi, int *code,
 	case 0x32: /* Volume Mute */
 		if (atkbd_reports_vol_keys)
 			*code = ASUS_WMI_KEY_IGNORE;
-
+		break;
+	case 0x5D: /* Wireless console Toggle */
+	case 0x5E: /* Wireless console Enable */
+	case 0x5F: /* Wireless console Disable */
+		if (quirks->ignore_key_wlan)
+			*code = ASUS_WMI_KEY_IGNORE;
 		break;
 	}
 }
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index cc30f1853847..a6ee9440d932 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -50,6 +50,7 @@ struct quirk_entry {
 	 */
 	int no_display_toggle;
 	u32 xusb2pr;
+	bool ignore_key_wlan;
 };
 
 struct asus_wmi_driver {

There is a problem with this patch that on ASUS Zenbook Duo UX8406MA you can't detect integrated keyboard attach/detach event anymore. It would be imho better to not to ignore the WMI code 0x5e but to change it to some meaninful code which can be later remapped (using asus_nb_wmi_keymap) to KEY_xy other then KEY_WLAN to not toggle wifi on/off.

In my setup (Fedora 40) I'm using systemd hwdb to remap 0x5e WMI key to KEY_CONFIG which is later used in Cinnamon desktop manager to trigger a script handling duo's screens (https://github.com/alesya-h/zenbook-duo-2024-ux8406ma-linux/).

/etc/udev/hwdb.d/61-asus-duo.hwdb:

evdev:input:b0019v0000p0000e0000-*
KEYBOARD_KEY_5e=config

As your patch is already in 6.10.12 kernel I have to revert it using dkms built asus_nb_wmi.ko module with your back deactivated in order to get keyboard events back :-)

@nalim I'm sorry that this patch broke your workflow and the inconvenience that has caused.

I would suggest that using udev rules is probably the normal way to detect hardware being connected and disconnected, rather than looking for keypresses. I don't have perfect udev rules for this, but I do have these rules. The imperfect part is that multiple devices are matched by this rule (the internal keyboard hub, keyboard, and trackpad, I believe), causing the udev command to be run multiple times, but it could either work for your case or potentially be refined:

ACTION=="add",    ATTRS{idVendor}=="0b05", ATTRS{idProduct}=="1b2c", RUN+="..."
ACTION=="remove", ATTRS{idVendor}=="0b05", ATTRS{idProduct}=="1b2c", RUN+="..."

@mfenniak no need for sorry, many thanks for your work. I just thought the patch can be made more inline with how this work under Windows/WMI, it means to use 0x5e key to trigger changes in display configuration.

@mfenniak

I' ve created a simple experimental patch which make use of a generic input subsystem tablet switch support already impemented in asus_wmi modules and which is being used by quirks for Asus Transformer series (T100, T101HA, T200TA). With this patch enabled input events EV_SW/SW_TABLET_MODE are generated each tiime the keyboard is (det)attached. No KEY_WLAN is generated as 0x5e WMI code is consumed in the process of generating SW_TABLET_MODE event. What are your thougs about this concept?

diff -up orig/asus-nb-wmi.c new/asus-nb-wmi.c
--- orig/asus-nb-wmi.c	2024-10-08 10:18:04.000000000 +0200
+++ new/asus-nb-wmi.c	2024-10-08 10:15:52.141120621 +0200
@@ -146,7 +146,11 @@ static struct quirk_entry quirk_asus_ign
 };
 
 static struct quirk_entry quirk_asus_zenbook_duo_kbd = {
-	.ignore_key_wlan = true,
+	/* ignore_key_wlan = true, */
+	.tablet_switch_mode = asus_wmi_kbd_dock_devid,
+	.tablet_switch_devid = 0x00050051,
+	.tablet_switch_event_code = 0x5e,
+	.tablet_switch_not_inverted = true,
 };
 
 static int dmi_matched(const struct dmi_system_id *dmi)
diff -up orig/asus-wmi.c new/asus-wmi.c
--- orig/asus-wmi.c	2024-10-08 10:18:04.000000000 +0200
+++ new/asus-wmi.c	2024-10-08 10:10:56.471851626 +0200
@@ -609,8 +609,10 @@ static int asus_wmi_input_init(struct as
 	case asus_wmi_no_tablet_switch:
 		break;
 	case asus_wmi_kbd_dock_devid:
-		asus->tablet_switch_inverted = true;
-		asus_wmi_tablet_sw_init(asus, ASUS_WMI_DEVID_KBD_DOCK, NOTIFY_KBD_DOCK_CHANGE);
+		pr_info("asus_wmi_kbd_dock_devid: %x %x\n", asus->driver->quirks->tablet_switch_devid, asus->driver->quirks->tablet_switch_event_code);
+		/* asus->tablet_switch_inverted = true; */
+		asus->tablet_switch_inverted = !asus->driver->quirks->tablet_switch_not_inverted;
+		asus_wmi_tablet_sw_init(asus, asus->driver->quirks->tablet_switch_devid ? asus->driver->quirks->tablet_switch_devid : ASUS_WMI_DEVID_KBD_DOCK, asus->driver->quirks->tablet_switch_event_code ? asus->driver->quirks->tablet_switch_event_code : NOTIFY_KBD_DOCK_CHANGE);
 		break;
 	case asus_wmi_lid_flip_devid:
 		asus_wmi_tablet_sw_init(asus, ASUS_WMI_DEVID_LID_FLIP, NOTIFY_LID_FLIP);
diff -up orig/asus-wmi.h new/asus-wmi.h
--- orig/asus-wmi.h	2024-10-08 10:18:04.000000000 +0200
+++ new/asus-wmi.h	2024-10-08 10:10:06.854522495 +0200
@@ -42,6 +42,8 @@ struct quirk_entry {
 	bool filter_i8042_e1_extended_codes;
 	bool ignore_key_wlan;
 	enum asus_wmi_tablet_switch_mode tablet_switch_mode;
+	int tablet_switch_devid, tablet_switch_event_code;
+	bool tablet_switch_not_inverted;
 	int wapf;
 	/*
 	 * For machines with AMD graphic chips, it will send out WMI event

@nalim It seems to make sense to me. I don't feel that I have any expertise in this area, but triggering a "tablet mode" capability like that seems logical, and, if it doesn't result in the rfkill system being triggered since the event is consumed that still addresses my major annoyance.

Just so you're fully aware, I'm not a maintainer in any of these areas being patched -- I followed the standard kernel patch process to submit mine upstream to the platform-x86 maintainer who merged it. I would happily test the full patch to help support your change, and if any questions arise on the flip-flop from one behavior to another I'd contribute my 👍 to changing to this approach.