From: <Mario.Limonciello@dell.com>
To: <kai.heng.feng@canonical.com>, <alex.hung@canonical.com>
Cc: <dvhart@infradead.org>, <andy@infradead.org>,
<platform-driver-x86@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] platform/x86: intel-hid: Use hp-wireless for rfkill on HP platforms
Date: Wed, 10 Jun 2020 15:49:37 +0000 [thread overview]
Message-ID: <4d0714fe5e2548b6b638ea447ad19490@AUSX13MPC105.AMER.DELL.COM> (raw)
In-Reply-To: <20200610153747.27040-1-kai.heng.feng@canonical.com>
> -----Original Message-----
> From: platform-driver-x86-owner@vger.kernel.org <platform-driver-x86-
> owner@vger.kernel.org> On Behalf Of Kai-Heng Feng
> Sent: Wednesday, June 10, 2020 10:38 AM
> To: alex.hung@canonical.com
> Cc: Kai-Heng Feng; Darren Hart; Andy Shevchenko; open list:INTEL HID EVENT
> DRIVER; open list
> Subject: [PATCH] platform/x86: intel-hid: Use hp-wireless for rfkill on HP
> platforms
>
>
> [EXTERNAL EMAIL]
>
> Wireless hotkey on HP platforms can trigger two events, if both
> hp-wireless and intel-hid are supported. Two events at the same time
> renders wireless hotkey useless.
>
> HP confirmed that hp-wireless (HPQ6001) should always be the canonical
> source of wireless hotkey event, so skip registering rfkill hotkey if
> HPQ6001 is present.
>
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
> drivers/platform/x86/intel-hid.c | 31 ++++++++++++++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/intel-hid.c b/drivers/platform/x86/intel-
> hid.c
> index 9ee79b74311c..31091c8faf70 100644
> --- a/drivers/platform/x86/intel-hid.c
> +++ b/drivers/platform/x86/intel-hid.c
> @@ -25,6 +25,8 @@ static const struct acpi_device_id intel_hid_ids[] = {
> };
> MODULE_DEVICE_TABLE(acpi, intel_hid_ids);
>
> +static bool hp_wireless_present;
> +
> /* In theory, these are HID usages. */
> static const struct key_entry intel_hid_keymap[] = {
> /* 1: LSuper (Page 0x07, usage 0xE3) -- unclear what to do */
> @@ -49,6 +51,29 @@ static const struct key_entry intel_hid_keymap[] = {
> { KE_END },
> };
>
> +static const struct key_entry intel_hid_no_rfkill_keymap[] = {
> + /* 1: LSuper (Page 0x07, usage 0xE3) -- unclear what to do */
> + /* 2: Toggle SW_ROTATE_LOCK -- easy to implement if seen in wild */
> + { KE_KEY, 3, { KEY_NUMLOCK } },
> + { KE_KEY, 4, { KEY_HOME } },
> + { KE_KEY, 5, { KEY_END } },
> + { KE_KEY, 6, { KEY_PAGEUP } },
> + { KE_KEY, 7, { KEY_PAGEDOWN } },
> + /* 8: rfkill -- use hp-wireless instead */
> + { KE_KEY, 9, { KEY_POWER } },
> + { KE_KEY, 11, { KEY_SLEEP } },
> + /* 13 has two different meanings in the spec -- ignore it. */
> + { KE_KEY, 14, { KEY_STOPCD } },
> + { KE_KEY, 15, { KEY_PLAYPAUSE } },
> + { KE_KEY, 16, { KEY_MUTE } },
> + { KE_KEY, 17, { KEY_VOLUMEUP } },
> + { KE_KEY, 18, { KEY_VOLUMEDOWN } },
> + { KE_KEY, 19, { KEY_BRIGHTNESSUP } },
> + { KE_KEY, 20, { KEY_BRIGHTNESSDOWN } },
> + /* 27: wake -- needs special handling */
> + { KE_END },
> +};
> +
> /* 5 button array notification value. */
> static const struct key_entry intel_array_keymap[] = {
> { KE_KEY, 0xC2, { KEY_LEFTMETA } }, /* Press */
> @@ -317,7 +342,8 @@ static int intel_hid_input_setup(struct platform_device
> *device)
> if (!priv->input_dev)
> return -ENOMEM;
>
> - ret = sparse_keymap_setup(priv->input_dev, intel_hid_keymap, NULL);
> + ret = sparse_keymap_setup(priv->input_dev, hp_wireless_present ?
> + intel_hid_no_rfkill_keymap : intel_hid_keymap, NULL);
> if (ret)
> return ret;
>
> @@ -575,6 +601,9 @@ check_acpi_dev(acpi_handle handle, u32 lvl, void
> *context, void **rv)
> dev_info(&dev->dev,
> "intel-hid: created platform device\n");
>
> + if (!strcmp(acpi_device_hid(dev), "HPQ6001"))
> + hp_wireless_present = true;
Just having the ACPI device present doesn't actually mean that the user
has a kernel compiled with hp-wireless or that it has finished initializing.
I would think this needs a better handshake in case hp-wireless was unloaded
or not present so the event could still come through intel-hid in this
circumstance.
> +
> return AE_OK;
> }
>
> --
> 2.17.1
next prev parent reply other threads:[~2020-06-10 15:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-10 15:37 Kai-Heng Feng
2020-06-10 15:49 ` Mario.Limonciello [this message]
2020-06-10 17:41 ` Alex Hung
2020-06-11 7:24 ` Kai-Heng Feng
2020-06-11 15:53 ` Alex Hung
2020-06-11 7:16 ` Kai-Heng Feng
2020-06-11 13:14 ` Mario.Limonciello
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4d0714fe5e2548b6b638ea447ad19490@AUSX13MPC105.AMER.DELL.COM \
--to=mario.limonciello@dell.com \
--cc=alex.hung@canonical.com \
--cc=andy@infradead.org \
--cc=dvhart@infradead.org \
--cc=kai.heng.feng@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®