[PATCH v2 0/3] dell platform driver tweaks v2

[PATCH v2 0/3] dell platform driver tweaks v2

[Andy Lutomirski]

Here's v2.

I'm still hoping to hear more details about the rfkill button.
Meanwhile, let's at least wire up the WMI decoding stuff and
get the rest in.

Changes from v1:
 - The new hotkey code matches reality better.
 - Don't send key events for the new hotkeys (yet?)
 - Improve warning formatting.

Andy Lutomirski (3):
  dell-wmi: Use a C99-style array for bios_to_linux_keycode
  dell-wmi: Support new hotkeys on the XPS 13 9350 (Skylake)
  dell-wmi: Improve unknown hotkey handling

 drivers/platform/x86/dell-wmi.c | 143 +++++++++++++++++++++++++++++++---------
 1 file changed, 112 insertions(+), 31 deletions(-)

-- 
2.5.0

[PATCH v2 1/3] dell-wmi: Use a C99-style array for bios_to_linux_keycode

[Andy Lutomirski]

It's currently hard to follow what maps to what, and it's hard to edit
the array.  Redo it as a C99-style array.

I generated this using emacs regexes and a python one-liner.
objdump says this didn't change the table.

Acked-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 drivers/platform/x86/dell-wmi.c | 61 +++++++++++++++++++++++++++--------------
 1 file changed, 40 insertions(+), 21 deletions(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index f2d77fe696ac..ad6e965c5862 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -119,27 +119,46 @@ struct dell_bios_hotkey_table {
 static const struct dell_bios_hotkey_table *dell_bios_hotkey_table;
 
 static const u16 bios_to_linux_keycode[256] __initconst = {
-
-	KEY_MEDIA,	KEY_NEXTSONG,	KEY_PLAYPAUSE, KEY_PREVIOUSSONG,
-	KEY_STOPCD,	KEY_UNKNOWN,	KEY_UNKNOWN,	KEY_UNKNOWN,
-	KEY_WWW,	KEY_UNKNOWN,	KEY_VOLUMEDOWN, KEY_MUTE,
-	KEY_VOLUMEUP,	KEY_UNKNOWN,	KEY_BATTERY,	KEY_EJECTCD,
-	KEY_UNKNOWN,	KEY_SLEEP,	KEY_PROG1, KEY_BRIGHTNESSDOWN,
-	KEY_BRIGHTNESSUP,	KEY_UNKNOWN,	KEY_KBDILLUMTOGGLE,
-	KEY_UNKNOWN,	KEY_SWITCHVIDEOMODE,	KEY_UNKNOWN, KEY_UNKNOWN,
-	KEY_SWITCHVIDEOMODE,	KEY_UNKNOWN,	KEY_UNKNOWN, KEY_PROG2,
-	KEY_UNKNOWN,	KEY_UNKNOWN,	KEY_UNKNOWN,	KEY_UNKNOWN,
-	KEY_UNKNOWN,	KEY_UNKNOWN,	KEY_UNKNOWN,	KEY_MICMUTE,
-	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	0, 0, 0, 0, 0, 0, 0, 0, 0, KEY_PROG3
+	[0]	= KEY_MEDIA,
+	[1]	= KEY_NEXTSONG,
+	[2]	= KEY_PLAYPAUSE,
+	[3]	= KEY_PREVIOUSSONG,
+	[4]	= KEY_STOPCD,
+	[5]	= KEY_UNKNOWN,
+	[6]	= KEY_UNKNOWN,
+	[7]	= KEY_UNKNOWN,
+	[8]	= KEY_WWW,
+	[9]	= KEY_UNKNOWN,
+	[10]	= KEY_VOLUMEDOWN,
+	[11]	= KEY_MUTE,
+	[12]	= KEY_VOLUMEUP,
+	[13]	= KEY_UNKNOWN,
+	[14]	= KEY_BATTERY,
+	[15]	= KEY_EJECTCD,
+	[16]	= KEY_UNKNOWN,
+	[17]	= KEY_SLEEP,
+	[18]	= KEY_PROG1,
+	[19]	= KEY_BRIGHTNESSDOWN,
+	[20]	= KEY_BRIGHTNESSUP,
+	[21]	= KEY_UNKNOWN,
+	[22]	= KEY_KBDILLUMTOGGLE,
+	[23]	= KEY_UNKNOWN,
+	[24]	= KEY_SWITCHVIDEOMODE,
+	[25]	= KEY_UNKNOWN,
+	[26]	= KEY_UNKNOWN,
+	[27]	= KEY_SWITCHVIDEOMODE,
+	[28]	= KEY_UNKNOWN,
+	[29]	= KEY_UNKNOWN,
+	[30]	= KEY_PROG2,
+	[31]	= KEY_UNKNOWN,
+	[32]	= KEY_UNKNOWN,
+	[33]	= KEY_UNKNOWN,
+	[34]	= KEY_UNKNOWN,
+	[35]	= KEY_UNKNOWN,
+	[36]	= KEY_UNKNOWN,
+	[37]	= KEY_UNKNOWN,
+	[38]	= KEY_MICMUTE,
+	[255]	= KEY_PROG3,
 };
 
 static struct input_dev *dell_wmi_input_dev;
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] dell-wmi: Use a C99-style array for bios_to_linux_keycode

[Darren Hart]

On Mon, Nov 30, 2015 at 05:01:59PM -0800, Andy Lutomirski wrote:
> It's currently hard to follow what maps to what, and it's hard to edit
> the array.  Redo it as a C99-style array.
> 
> I generated this using emacs regexes and a python one-liner.
> objdump says this didn't change the table.
> 
> Acked-by: Pali Rohár <pali.rohar@gmail.com>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>

I already have this one in next and I don't see a per-patch changelog for this
one - has it changed?

-- 
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] dell-wmi: Use a C99-style array for bios_to_linux_keycode

[Andy Lutomirski]

On Thu, Dec 3, 2015 at 3:32 PM, Darren Hart <dvhart@infradead.org> wrote:
> On Mon, Nov 30, 2015 at 05:01:59PM -0800, Andy Lutomirski wrote:
>> It's currently hard to follow what maps to what, and it's hard to edit
>> the array.  Redo it as a C99-style array.
>>
>> I generated this using emacs regexes and a python one-liner.
>> objdump says this didn't change the table.
>>
>> Acked-by: Pali Rohár <pali.rohar@gmail.com>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>
> I already have this one in next and I don't see a per-patch changelog for this
> one - has it changed?
>

No, it hasn't.  I didn't actually mean to include it in the series.
Whoops!  Please just pretend that I only sent patch 2 onward.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] dell-wmi: Use a C99-style array for bios_to_linux_keycode

[Darren Hart]

On Thu, Dec 03, 2015 at 03:45:36PM -0800, Andy Lutomirski wrote:
> On Thu, Dec 3, 2015 at 3:32 PM, Darren Hart <dvhart@infradead.org> wrote:
> > On Mon, Nov 30, 2015 at 05:01:59PM -0800, Andy Lutomirski wrote:
> >> It's currently hard to follow what maps to what, and it's hard to edit
> >> the array.  Redo it as a C99-style array.
> >>
> >> I generated this using emacs regexes and a python one-liner.
> >> objdump says this didn't change the table.
> >>
> >> Acked-by: Pali Rohár <pali.rohar@gmail.com>
> >> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> >
> > I already have this one in next and I don't see a per-patch changelog for this
> > one - has it changed?
> >
> 
> No, it hasn't.  I didn't actually mean to include it in the series.
> Whoops!  Please just pretend that I only sent patch 2 onward.

:-) Done.

-- 
Darren Hart
Intel Open Source Technology Center

[PATCH v2 2/3] dell-wmi: Support new hotkeys on the XPS 13 9350 (Skylake)

[Andy Lutomirski]

The XPS 13 9350 sends WMI keypress events that aren't enumerated in
the DMI table.  Add a table listing them.  To avoid breaking things
that worked before, these un-enumerated hotkeys won't be used if the
DMI table maps them to something else.

FWIW, it appears that the DMI table may be a legacy thing and we
might want to rethink how we handle events in general.  As an
example, a whole lot of things map to KEY_PROG3 via the DMI table.

So far, this doesn't send keypress events for any of the new
events.  Depnding on whether we figure out exactly what needs to
happen to get the wireless button working in time for Linux 4.5,
we might want to temporarily handle it in dell-wmi.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 drivers/platform/x86/dell-wmi.c | 59 ++++++++++++++++++++++++++++++++++++-----
 1 file changed, 52 insertions(+), 7 deletions(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index ad6e965c5862..baff658a3621 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -161,6 +161,27 @@ static const u16 bios_to_linux_keycode[256] __initconst = {
 	[255]	= KEY_PROG3,
 };
 
+/* These are applied if the hk table is present and doesn't override them. */
+static const struct key_entry dell_wmi_extra_keymap[] __initconst = {
+	/* Fn-lock */
+	{ KE_IGNORE, 0x151, { KEY_RESERVED } },
+
+	/* Change keyboard illumination */
+	{ KE_IGNORE, 0x152, { KEY_KBDILLUMTOGGLE } },
+
+	/*
+	 * Radio disable (notify only -- there is no model for which the
+	 * WMI event is supposed to trigger an action.
+	 */
+	{ KE_IGNORE, 0x153, { KEY_RFKILL } },
+
+	/* RGB keyboard backlight control */
+	{ KE_IGNORE, 0x154, { KEY_RESERVED } },
+
+	/* Stealth mode toggle */
+	{ KE_IGNORE, 0x155, { KEY_RESERVED } },
+};
+
 static struct input_dev *dell_wmi_input_dev;
 
 static void dell_wmi_process_key(int reported_key)
@@ -319,9 +340,10 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
 	int hotkey_num = (dell_bios_hotkey_table->header.length - 4) /
 				sizeof(struct dell_bios_keymap_entry);
 	struct key_entry *keymap;
-	int i;
+	int i, pos = 0, num_bios_keys;
 
-	keymap = kcalloc(hotkey_num + 1, sizeof(struct key_entry), GFP_KERNEL);
+	keymap = kcalloc(hotkey_num + ARRAY_SIZE(dell_wmi_extra_keymap),
+			 sizeof(struct key_entry), GFP_KERNEL);
 	if (!keymap)
 		return NULL;
 
@@ -333,14 +355,37 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
 				    KEY_RESERVED;
 
 		if (keycode == KEY_KBDILLUMTOGGLE)
-			keymap[i].type = KE_IGNORE;
+			keymap[pos].type = KE_IGNORE;
 		else
-			keymap[i].type = KE_KEY;
-		keymap[i].code = bios_entry->scancode;
-		keymap[i].keycode = keycode;
+			keymap[pos].type = KE_KEY;
+		keymap[pos].code = bios_entry->scancode;
+		keymap[pos].keycode = keycode;
+
+		pos++;
+	}
+
+	num_bios_keys = pos;
+
+	for (i = 0; i < ARRAY_SIZE(dell_wmi_extra_keymap); i++) {
+		int j;
+
+		/*
+		 * Check if we've already found this scancode.  This takes
+		 * quadratic time, but it doesn't matter unless the list
+		 * of extra keys gets very long.
+		 */
+		for (j = 0; j < num_bios_keys; j++)
+			if (keymap[j].code == dell_wmi_extra_keymap[i].code)
+				goto skip;
+
+		keymap[pos] = dell_wmi_extra_keymap[i];
+		pos++;
+
+skip:
+		;
 	}
 
-	keymap[hotkey_num].type = KE_END;
+	keymap[pos].type = KE_END;
 
 	return keymap;
 }
-- 
2.5.0

Re: [PATCH v2 2/3] dell-wmi: Support new hotkeys on the XPS 13 9350 (Skylake)

[Mario Limonciello]

On 11/30/2015 07:02 PM, Andy Lutomirski wrote:
> The XPS 13 9350 sends WMI keypress events that aren't enumerated in
> the DMI table.  Add a table listing them.  To avoid breaking things
> that worked before, these un-enumerated hotkeys won't be used if the
> DMI table maps them to something else.
>
> FWIW, it appears that the DMI table may be a legacy thing and we
> might want to rethink how we handle events in general.  As an
> example, a whole lot of things map to KEY_PROG3 via the DMI table.
>
> So far, this doesn't send keypress events for any of the new
> events.  Depnding on whether we figure out exactly what needs to
> happen to get the wireless button working in time for Linux 4.5,
> we might want to temporarily handle it in dell-wmi.
>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
>  drivers/platform/x86/dell-wmi.c | 59 ++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 52 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
> index ad6e965c5862..baff658a3621 100644
> --- a/drivers/platform/x86/dell-wmi.c
> +++ b/drivers/platform/x86/dell-wmi.c
> @@ -161,6 +161,27 @@ static const u16 bios_to_linux_keycode[256] __initconst = {
>  	[255]	= KEY_PROG3,
>  };
>  
> +/* These are applied if the hk table is present and doesn't override them. */
> +static const struct key_entry dell_wmi_extra_keymap[] __initconst = {
> +	/* Fn-lock */
> +	{ KE_IGNORE, 0x151, { KEY_RESERVED } },
> +
> +	/* Change keyboard illumination */
> +	{ KE_IGNORE, 0x152, { KEY_KBDILLUMTOGGLE } },
> +
> +	/*
> +	 * Radio disable (notify only -- there is no model for which the
> +	 * WMI event is supposed to trigger an action.
> +	 */
> +	{ KE_IGNORE, 0x153, { KEY_RFKILL } },
> +
> +	/* RGB keyboard backlight control */
> +	{ KE_IGNORE, 0x154, { KEY_RESERVED } },
> +
> +	/* Stealth mode toggle */
> +	{ KE_IGNORE, 0x155, { KEY_RESERVED } },
> +};
> +
>  static struct input_dev *dell_wmi_input_dev;
>  
>  static void dell_wmi_process_key(int reported_key)
> @@ -319,9 +340,10 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
>  	int hotkey_num = (dell_bios_hotkey_table->header.length - 4) /
>  				sizeof(struct dell_bios_keymap_entry);
>  	struct key_entry *keymap;
> -	int i;
> +	int i, pos = 0, num_bios_keys;
>  
> -	keymap = kcalloc(hotkey_num + 1, sizeof(struct key_entry), GFP_KERNEL);
> +	keymap = kcalloc(hotkey_num + ARRAY_SIZE(dell_wmi_extra_keymap),
> +			 sizeof(struct key_entry), GFP_KERNEL);
>  	if (!keymap)
>  		return NULL;
>  
> @@ -333,14 +355,37 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
>  				    KEY_RESERVED;
>  
>  		if (keycode == KEY_KBDILLUMTOGGLE)
> -			keymap[i].type = KE_IGNORE;
> +			keymap[pos].type = KE_IGNORE;
>  		else
> -			keymap[i].type = KE_KEY;
> -		keymap[i].code = bios_entry->scancode;
> -		keymap[i].keycode = keycode;
> +			keymap[pos].type = KE_KEY;
> +		keymap[pos].code = bios_entry->scancode;
> +		keymap[pos].keycode = keycode;
> +
> +		pos++;
> +	}
> +
> +	num_bios_keys = pos;
> +
> +	for (i = 0; i < ARRAY_SIZE(dell_wmi_extra_keymap); i++) {
> +		int j;
> +
> +		/*
> +		 * Check if we've already found this scancode.  This takes
> +		 * quadratic time, but it doesn't matter unless the list
> +		 * of extra keys gets very long.
> +		 */
> +		for (j = 0; j < num_bios_keys; j++)
> +			if (keymap[j].code == dell_wmi_extra_keymap[i].code)
> +				goto skip;
> +
> +		keymap[pos] = dell_wmi_extra_keymap[i];
> +		pos++;
> +
> +skip:
> +		;
>  	}
>  
> -	keymap[hotkey_num].type = KE_END;
> +	keymap[pos].type = KE_END;
>  
>  	return keymap;
>  }
I agree, if you don't come up with a solution for using INT33D5 for 4.5,
you may as well repurpose the WMI notification temporarily.

Re: [PATCH v2 2/3] dell-wmi: Support new hotkeys on the XPS 13 9350 (Skylake)

[Darren Hart]

On Mon, Nov 30, 2015 at 05:02:00PM -0800, Andy Lutomirski wrote:
> The XPS 13 9350 sends WMI keypress events that aren't enumerated in
> the DMI table.  Add a table listing them.  To avoid breaking things
> that worked before, these un-enumerated hotkeys won't be used if the
> DMI table maps them to something else.
> 
> FWIW, it appears that the DMI table may be a legacy thing and we
> might want to rethink how we handle events in general.  As an
> example, a whole lot of things map to KEY_PROG3 via the DMI table.
> 
> So far, this doesn't send keypress events for any of the new
> events.  Depnding on whether we figure out exactly what needs to
> happen to get the wireless button working in time for Linux 4.5,
> we might want to temporarily handle it in dell-wmi.
> 
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
>  drivers/platform/x86/dell-wmi.c | 59 ++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 52 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
> index ad6e965c5862..baff658a3621 100644
> --- a/drivers/platform/x86/dell-wmi.c
> +++ b/drivers/platform/x86/dell-wmi.c
> @@ -161,6 +161,27 @@ static const u16 bios_to_linux_keycode[256] __initconst = {
>  	[255]	= KEY_PROG3,
>  };
>  
> +/* These are applied if the hk table is present and doesn't override them. */


Please do not abbreviate in comments.


> +static const struct key_entry dell_wmi_extra_keymap[] __initconst = {
> +	/* Fn-lock */
> +	{ KE_IGNORE, 0x151, { KEY_RESERVED } },
> +
> +	/* Change keyboard illumination */
> +	{ KE_IGNORE, 0x152, { KEY_KBDILLUMTOGGLE } },
> +
> +	/*
> +	 * Radio disable (notify only -- there is no model for which the
> +	 * WMI event is supposed to trigger an action.
> +	 */
> +	{ KE_IGNORE, 0x153, { KEY_RFKILL } },
> +
> +	/* RGB keyboard backlight control */
> +	{ KE_IGNORE, 0x154, { KEY_RESERVED } },
> +
> +	/* Stealth mode toggle */
> +	{ KE_IGNORE, 0x155, { KEY_RESERVED } },
> +};
> +
>  static struct input_dev *dell_wmi_input_dev;
>  
>  static void dell_wmi_process_key(int reported_key)
> @@ -319,9 +340,10 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
>  	int hotkey_num = (dell_bios_hotkey_table->header.length - 4) /
>  				sizeof(struct dell_bios_keymap_entry);
>  	struct key_entry *keymap;
> -	int i;
> +	int i, pos = 0, num_bios_keys;
>  
> -	keymap = kcalloc(hotkey_num + 1, sizeof(struct key_entry), GFP_KERNEL);
> +	keymap = kcalloc(hotkey_num + ARRAY_SIZE(dell_wmi_extra_keymap),
> +			 sizeof(struct key_entry), GFP_KERNEL);

Did something change since our last round of review making the +1 for KE_END
no longer necessary? It looks like it should be possible to use all the bios
hotkey keymap and all the extra keymap, so we would still need +1 for KE_END.

>  	if (!keymap)
>  		return NULL;
>  
> @@ -333,14 +355,37 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
>  				    KEY_RESERVED;
>  
>  		if (keycode == KEY_KBDILLUMTOGGLE)
> -			keymap[i].type = KE_IGNORE;
> +			keymap[pos].type = KE_IGNORE;
>  		else
> -			keymap[i].type = KE_KEY;
> -		keymap[i].code = bios_entry->scancode;
> -		keymap[i].keycode = keycode;
> +			keymap[pos].type = KE_KEY;
> +		keymap[pos].code = bios_entry->scancode;
> +		keymap[pos].keycode = keycode;
> +
> +		pos++;
> +	}
> +
> +	num_bios_keys = pos;
> +
> +	for (i = 0; i < ARRAY_SIZE(dell_wmi_extra_keymap); i++) {
> +		int j;
> +
> +		/*
> +		 * Check if we've already found this scancode.  This takes
> +		 * quadratic time, but it doesn't matter unless the list
> +		 * of extra keys gets very long.
> +		 */
> +		for (j = 0; j < num_bios_keys; j++)
> +			if (keymap[j].code == dell_wmi_extra_keymap[i].code)
> +				goto skip;
> +
> +		keymap[pos] = dell_wmi_extra_keymap[i];
> +		pos++;
> +
> +skip:
> +		;
>  	}
>  
> -	keymap[hotkey_num].type = KE_END;
> +	keymap[pos].type = KE_END;
>  
>  	return keymap;
>  }
> -- 
> 2.5.0
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v2 2/3] dell-wmi: Support new hotkeys on the XPS 13 9350 (Skylake)

[Andy Lutomirski]

On Thu, Dec 3, 2015 at 3:52 PM, Darren Hart <dvhart@infradead.org> wrote:
> On Mon, Nov 30, 2015 at 05:02:00PM -0800, Andy Lutomirski wrote:
>> The XPS 13 9350 sends WMI keypress events that aren't enumerated in
>> the DMI table.  Add a table listing them.  To avoid breaking things
>> that worked before, these un-enumerated hotkeys won't be used if the
>> DMI table maps them to something else.
>>
>> FWIW, it appears that the DMI table may be a legacy thing and we
>> might want to rethink how we handle events in general.  As an
>> example, a whole lot of things map to KEY_PROG3 via the DMI table.
>>
>> So far, this doesn't send keypress events for any of the new
>> events.  Depnding on whether we figure out exactly what needs to
>> happen to get the wireless button working in time for Linux 4.5,
>> we might want to temporarily handle it in dell-wmi.
>>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>> ---
>>  drivers/platform/x86/dell-wmi.c | 59 ++++++++++++++++++++++++++++++++++++-----
>>  1 file changed, 52 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
>> index ad6e965c5862..baff658a3621 100644
>> --- a/drivers/platform/x86/dell-wmi.c
>> +++ b/drivers/platform/x86/dell-wmi.c
>> @@ -161,6 +161,27 @@ static const u16 bios_to_linux_keycode[256] __initconst = {
>>       [255]   = KEY_PROG3,
>>  };
>>
>> +/* These are applied if the hk table is present and doesn't override them. */
>
>
> Please do not abbreviate in comments.

Will fix for v3.

>
>
>> +static const struct key_entry dell_wmi_extra_keymap[] __initconst = {
>> +     /* Fn-lock */
>> +     { KE_IGNORE, 0x151, { KEY_RESERVED } },
>> +
>> +     /* Change keyboard illumination */
>> +     { KE_IGNORE, 0x152, { KEY_KBDILLUMTOGGLE } },
>> +
>> +     /*
>> +      * Radio disable (notify only -- there is no model for which the
>> +      * WMI event is supposed to trigger an action.
>> +      */
>> +     { KE_IGNORE, 0x153, { KEY_RFKILL } },
>> +
>> +     /* RGB keyboard backlight control */
>> +     { KE_IGNORE, 0x154, { KEY_RESERVED } },
>> +
>> +     /* Stealth mode toggle */
>> +     { KE_IGNORE, 0x155, { KEY_RESERVED } },
>> +};
>> +
>>  static struct input_dev *dell_wmi_input_dev;
>>
>>  static void dell_wmi_process_key(int reported_key)
>> @@ -319,9 +340,10 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
>>       int hotkey_num = (dell_bios_hotkey_table->header.length - 4) /
>>                               sizeof(struct dell_bios_keymap_entry);
>>       struct key_entry *keymap;
>> -     int i;
>> +     int i, pos = 0, num_bios_keys;
>>
>> -     keymap = kcalloc(hotkey_num + 1, sizeof(struct key_entry), GFP_KERNEL);
>> +     keymap = kcalloc(hotkey_num + ARRAY_SIZE(dell_wmi_extra_keymap),
>> +                      sizeof(struct key_entry), GFP_KERNEL);
>
> Did something change since our last round of review making the +1 for KE_END
> no longer necessary? It looks like it should be possible to use all the bios
> hotkey keymap and all the extra keymap, so we would still need +1 for KE_END.

No, my bad.  That's embarrassing :(

--Andy

Re: [PATCH v2 2/3] dell-wmi: Support new hotkeys on the XPS 13 9350 (Skylake)

[Pali Rohár]

On Monday 30 November 2015 17:02:00 Andy Lutomirski wrote:
> +		/*
> +		 * Check if we've already found this scancode.  This takes
> +		 * quadratic time, but it doesn't matter unless the list
> +		 * of extra keys gets very long.
> +		 */
> +		for (j = 0; j < num_bios_keys; j++)
> +			if (keymap[j].code == dell_wmi_extra_keymap[i].code)
> +				goto skip;
> +

Still, my comment about moving this loop into function is valid...

> +		keymap[pos] = dell_wmi_extra_keymap[i];
> +		pos++;
> +
> +skip:
> +		;
>  	}

-- 
Pali Rohár
pali.rohar@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] dell-wmi: Support new hotkeys on the XPS 13 9350 (Skylake)

[Andy Lutomirski]

On Dec 4, 2015 1:03 AM, "Pali Rohár" <pali.rohar@gmail.com> wrote:
>
> On Monday 30 November 2015 17:02:00 Andy Lutomirski wrote:
> > +             /*
> > +              * Check if we've already found this scancode.  This takes
> > +              * quadratic time, but it doesn't matter unless the list
> > +              * of extra keys gets very long.
> > +              */
> > +             for (j = 0; j < num_bios_keys; j++)
> > +                     if (keymap[j].code == dell_wmi_extra_keymap[i].code)
> > +                             goto skip;
> > +
>
> Still, my comment about moving this loop into function is valid...
>

Whoops!  Queued for v3.

--Andy

[PATCH v2 3/3] dell-wmi: Improve unknown hotkey handling

[Andy Lutomirski]

If DMI lists a hotkey that we don't recognize, log and ignore it
instead of trying to map it to keycode 0.  I haven't seen this happen,
but it will help maintain the key map in the future and it will help
avoid sending bogus events.

This also improves the message that we log when we get an unknown key
event.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 drivers/platform/x86/dell-wmi.c | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index baff658a3621..7c3ebda811ca 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -118,6 +118,7 @@ struct dell_bios_hotkey_table {
 
 static const struct dell_bios_hotkey_table *dell_bios_hotkey_table;
 
+/* Uninitialized entries here are KEY_RESERVED == 0. */
 static const u16 bios_to_linux_keycode[256] __initconst = {
 	[0]	= KEY_MEDIA,
 	[1]	= KEY_NEXTSONG,
@@ -191,7 +192,8 @@ static void dell_wmi_process_key(int reported_key)
 	key = sparse_keymap_entry_from_scancode(dell_wmi_input_dev,
 						reported_key);
 	if (!key) {
-		pr_info("Unknown key %x pressed\n", reported_key);
+		pr_info("Unknown key with scancode 0x%x pressed\n",
+			reported_key);
 		return;
 	}
 
@@ -350,9 +352,24 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
 	for (i = 0; i < hotkey_num; i++) {
 		const struct dell_bios_keymap_entry *bios_entry =
 					&dell_bios_hotkey_table->keymap[i];
-		u16 keycode = bios_entry->keycode < 256 ?
-				    bios_to_linux_keycode[bios_entry->keycode] :
-				    KEY_RESERVED;
+
+		/* Uninitialized entries are 0 aka KEY_RESERVED. */
+		u16 keycode = (bios_entry->keycode <
+			       ARRAY_SIZE(bios_to_linux_keycode)) ?
+			bios_to_linux_keycode[bios_entry->keycode] :
+			KEY_RESERVED;
+		BUILD_BUG_ON(KEY_RESERVED != 0);
+
+		/*
+		 * Log if we find an entry in the DMI table that we don't
+		 * understand.  If this happens, we should figure out what
+		 * the entry means and add it to bios_to_linux_keycode.
+		 */
+		if (keycode == KEY_RESERVED) {
+			pr_info("firmware scancode 0x%x maps to unrecognized keycode 0x%x\n",
+				bios_entry->scancode, bios_entry->keycode);
+			continue;
+		}
 
 		if (keycode == KEY_KBDILLUMTOGGLE)
 			keymap[pos].type = KE_IGNORE;
-- 
2.5.0

Re: [PATCH v2 3/3] dell-wmi: Improve unknown hotkey handling

[Darren Hart]

On Mon, Nov 30, 2015 at 05:02:01PM -0800, Andy Lutomirski wrote:
> If DMI lists a hotkey that we don't recognize, log and ignore it
> instead of trying to map it to keycode 0.  I haven't seen this happen,
> but it will help maintain the key map in the future and it will help
> avoid sending bogus events.
> 
> This also improves the message that we log when we get an unknown key
> event.
> 
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---

Please include the individual patch changelogs here under --- in the patch
itself - this helps me build confidence that I am indeed looking at the right
patch and the expected changes are here.

Pali, this appears to have the one change you asked for (0x%x instead of %d).
I've added the Reviewed-by: Pali Rohár <pali.rohar@gmail.com> you provided
previously pending this change.

Queued to testing, thanks.

>  drivers/platform/x86/dell-wmi.c | 25 +++++++++++++++++++++----
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
> index baff658a3621..7c3ebda811ca 100644
> --- a/drivers/platform/x86/dell-wmi.c
> +++ b/drivers/platform/x86/dell-wmi.c
> @@ -118,6 +118,7 @@ struct dell_bios_hotkey_table {
>  
>  static const struct dell_bios_hotkey_table *dell_bios_hotkey_table;
>  
> +/* Uninitialized entries here are KEY_RESERVED == 0. */
>  static const u16 bios_to_linux_keycode[256] __initconst = {
>  	[0]	= KEY_MEDIA,
>  	[1]	= KEY_NEXTSONG,
> @@ -191,7 +192,8 @@ static void dell_wmi_process_key(int reported_key)
>  	key = sparse_keymap_entry_from_scancode(dell_wmi_input_dev,
>  						reported_key);
>  	if (!key) {
> -		pr_info("Unknown key %x pressed\n", reported_key);
> +		pr_info("Unknown key with scancode 0x%x pressed\n",
> +			reported_key);
>  		return;
>  	}
>  
> @@ -350,9 +352,24 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void)
>  	for (i = 0; i < hotkey_num; i++) {
>  		const struct dell_bios_keymap_entry *bios_entry =
>  					&dell_bios_hotkey_table->keymap[i];
> -		u16 keycode = bios_entry->keycode < 256 ?
> -				    bios_to_linux_keycode[bios_entry->keycode] :
> -				    KEY_RESERVED;
> +
> +		/* Uninitialized entries are 0 aka KEY_RESERVED. */
> +		u16 keycode = (bios_entry->keycode <
> +			       ARRAY_SIZE(bios_to_linux_keycode)) ?
> +			bios_to_linux_keycode[bios_entry->keycode] :
> +			KEY_RESERVED;
> +		BUILD_BUG_ON(KEY_RESERVED != 0);
> +
> +		/*
> +		 * Log if we find an entry in the DMI table that we don't
> +		 * understand.  If this happens, we should figure out what
> +		 * the entry means and add it to bios_to_linux_keycode.
> +		 */
> +		if (keycode == KEY_RESERVED) {
> +			pr_info("firmware scancode 0x%x maps to unrecognized keycode 0x%x\n",
> +				bios_entry->scancode, bios_entry->keycode);
> +			continue;
> +		}
>  
>  		if (keycode == KEY_KBDILLUMTOGGLE)
>  			keymap[pos].type = KE_IGNORE;
> -- 
> 2.5.0
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v2 3/3] dell-wmi: Improve unknown hotkey handling

[Andy Lutomirski]

On Thu, Dec 3, 2015 at 3:38 PM, Darren Hart <dvhart@infradead.org> wrote:
> On Mon, Nov 30, 2015 at 05:02:01PM -0800, Andy Lutomirski wrote:
>> If DMI lists a hotkey that we don't recognize, log and ignore it
>> instead of trying to map it to keycode 0.  I haven't seen this happen,
>> but it will help maintain the key map in the future and it will help
>> avoid sending bogus events.
>>
>> This also improves the message that we log when we get an unknown key
>> event.
>>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>> ---
>
> Please include the individual patch changelogs here under --- in the patch
> itself - this helps me build confidence that I am indeed looking at the right
> patch and the expected changes are here.

Will do in the future -- different maintainers have different
preferences here, I think.

--Andy

Re: [PATCH v2 3/3] dell-wmi: Improve unknown hotkey handling

[Darren Hart]

On Thu, Dec 03, 2015 at 03:45:11PM -0800, Andy Lutomirski wrote:
> On Thu, Dec 3, 2015 at 3:38 PM, Darren Hart <dvhart@infradead.org> wrote:
> > On Mon, Nov 30, 2015 at 05:02:01PM -0800, Andy Lutomirski wrote:
> >> If DMI lists a hotkey that we don't recognize, log and ignore it
> >> instead of trying to map it to keycode 0.  I haven't seen this happen,
> >> but it will help maintain the key map in the future and it will help
> >> avoid sending bogus events.
> >>
> >> This also improves the message that we log when we get an unknown key
> >> event.
> >>
> >> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> >> ---
> >
> > Please include the individual patch changelogs here under --- in the patch
> > itself - this helps me build confidence that I am indeed looking at the right
> > patch and the expected changes are here.
> 
> Will do in the future -- different maintainers have different
> preferences here, I think.

Oh really?

This is the documented process in Documentation/SubmittingPatches Section 14)
The canonical patch format...

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v2 3/3] dell-wmi: Improve unknown hotkey handling

[Andy Lutomirski]

On Thu, Dec 3, 2015 at 4:07 PM, Darren Hart <dvhart@infradead.org> wrote:
> On Thu, Dec 03, 2015 at 03:45:11PM -0800, Andy Lutomirski wrote:
>> On Thu, Dec 3, 2015 at 3:38 PM, Darren Hart <dvhart@infradead.org> wrote:
>> > On Mon, Nov 30, 2015 at 05:02:01PM -0800, Andy Lutomirski wrote:
>> >> If DMI lists a hotkey that we don't recognize, log and ignore it
>> >> instead of trying to map it to keycode 0.  I haven't seen this happen,
>> >> but it will help maintain the key map in the future and it will help
>> >> avoid sending bogus events.
>> >>
>> >> This also improves the message that we log when we get an unknown key
>> >> event.
>> >>
>> >> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>> >> ---
>> >
>> > Please include the individual patch changelogs here under --- in the patch
>> > itself - this helps me build confidence that I am indeed looking at the right
>> > patch and the expected changes are here.
>>
>> Will do in the future -- different maintainers have different
>> preferences here, I think.
>
> Oh really?
>
> This is the documented process in Documentation/SubmittingPatches Section 14)
> The canonical patch format...
>

Ingo and the other -tip maintainers seem to like all the comments up
front on the cover letter.  Or at least they haven't complained yet.

Anyway, I'm giving 'git notes' a try to generate nice change comments for v3.

--Andy

Re: [PATCH v2 3/3] dell-wmi: Improve unknown hotkey handling

[Darren Hart]

On Thu, Dec 03, 2015 at 04:10:49PM -0800, Andy Lutomirski wrote:
> On Thu, Dec 3, 2015 at 4:07 PM, Darren Hart <dvhart@infradead.org> wrote:
> > On Thu, Dec 03, 2015 at 03:45:11PM -0800, Andy Lutomirski wrote:
> >> On Thu, Dec 3, 2015 at 3:38 PM, Darren Hart <dvhart@infradead.org> wrote:
> >> > On Mon, Nov 30, 2015 at 05:02:01PM -0800, Andy Lutomirski wrote:
> >> >> If DMI lists a hotkey that we don't recognize, log and ignore it
> >> >> instead of trying to map it to keycode 0.  I haven't seen this happen,
> >> >> but it will help maintain the key map in the future and it will help
> >> >> avoid sending bogus events.
> >> >>
> >> >> This also improves the message that we log when we get an unknown key
> >> >> event.
> >> >>
> >> >> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> >> >> ---
> >> >
> >> > Please include the individual patch changelogs here under --- in the patch
> >> > itself - this helps me build confidence that I am indeed looking at the right
> >> > patch and the expected changes are here.
> >>
> >> Will do in the future -- different maintainers have different
> >> preferences here, I think.
> >
> > Oh really?
> >
> > This is the documented process in Documentation/SubmittingPatches Section 14)
> > The canonical patch format...
> >
> 
> Ingo and the other -tip maintainers seem to like all the comments up
> front on the cover letter.  Or at least they haven't complained yet.
> 

Ugh, well, I don't like to ask contributors to treat this subsystem special by
sticking to the documentation as much as possible. I really do find the
per-patch changelog to be very useful. Thanks for working with me on that.

> Anyway, I'm giving 'git notes' a try to generate nice change comments for v3.

If you get a good solution, that would be nice to add to the documentation to
help automate the process. Anything we can do to avoid mechanical errors here is
goodness.

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v2 3/3] dell-wmi: Improve unknown hotkey handling

[Pali Rohár]

On Thursday 03 December 2015 15:38:56 Darren Hart wrote:
> Pali, this appears to have the one change you asked for (0x%x instead of %d).
> I've added the Reviewed-by: Pali Rohár <pali.rohar@gmail.com> you provided
> previously pending this change.

Ok.

> > +		/* Uninitialized entries are 0 aka KEY_RESERVED. */
> > +		u16 keycode = (bios_entry->keycode <
> > +			       ARRAY_SIZE(bios_to_linux_keycode)) ?
> > +			bios_to_linux_keycode[bios_entry->keycode] :
> > +			KEY_RESERVED;
> > +		BUILD_BUG_ON(KEY_RESERVED != 0);

Anyway, Darren what do you think is that BUILD_BUG_ON check needed?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH v2 3/3] dell-wmi: Improve unknown hotkey handling

[Andy Lutomirski]

On Fri, Dec 4, 2015 at 12:39 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 03 December 2015 15:38:56 Darren Hart wrote:
>> Pali, this appears to have the one change you asked for (0x%x instead of %d).
>> I've added the Reviewed-by: Pali Rohár <pali.rohar@gmail.com> you provided
>> previously pending this change.
>
> Ok.
>
>> > +           /* Uninitialized entries are 0 aka KEY_RESERVED. */
>> > +           u16 keycode = (bios_entry->keycode <
>> > +                          ARRAY_SIZE(bios_to_linux_keycode)) ?
>> > +                   bios_to_linux_keycode[bios_entry->keycode] :
>> > +                   KEY_RESERVED;
>> > +           BUILD_BUG_ON(KEY_RESERVED != 0);
>
> Anyway, Darren what do you think is that BUILD_BUG_ON check needed?
>

Sorry, my bad.  IIRC Darren made that change, I made the other change,
and then I resent and we lost this one.

Darren, want to fix it in your tree?  If not, I'll include the
BUILD_BUG_ON deletion in v3.

--Andy

Re: [PATCH v2 3/3] dell-wmi: Improve unknown hotkey handling

[Darren Hart]

On Fri, Dec 04, 2015 at 08:15:04AM -0800, Andy Lutomirski wrote:
> On Fri, Dec 4, 2015 at 12:39 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Thursday 03 December 2015 15:38:56 Darren Hart wrote:
> >> Pali, this appears to have the one change you asked for (0x%x instead of %d).
> >> I've added the Reviewed-by: Pali Rohár <pali.rohar@gmail.com> you provided
> >> previously pending this change.
> >
> > Ok.
> >
> >> > +           /* Uninitialized entries are 0 aka KEY_RESERVED. */
> >> > +           u16 keycode = (bios_entry->keycode <
> >> > +                          ARRAY_SIZE(bios_to_linux_keycode)) ?
> >> > +                   bios_to_linux_keycode[bios_entry->keycode] :
> >> > +                   KEY_RESERVED;
> >> > +           BUILD_BUG_ON(KEY_RESERVED != 0);
> >
> > Anyway, Darren what do you think is that BUILD_BUG_ON check needed?
> >
> 
> Sorry, my bad.  IIRC Darren made that change, I made the other change,
> and then I resent and we lost this one.
> 
> Darren, want to fix it in your tree?  If not, I'll include the
> BUILD_BUG_ON deletion in v3.

Thanks for the catch Pali. I've removed this in my tree. No need to resend.

-- 
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html