From: <Mario.Limonciello@dell.com>
To: <hdegoede@redhat.com>, <y.linux@paritcher.com>
Cc: <linux-kernel@vger.kernel.org>,
<platform-driver-x86@vger.kernel.org>, <mjg59@srcf.ucam.org>,
<pali@kernel.org>, <linux-input@vger.kernel.org>
Subject: RE: [PATCH 2/3] platform/x86: dell-wmi: add new keymap type 0x0012
Date: Tue, 9 Jun 2020 15:36:54 +0000 [thread overview]
Message-ID: <ae45da27126d470888ef0d839665b9ed@AUSX13MPC105.AMER.DELL.COM> (raw)
In-Reply-To: <137d8e69-a83f-6129-19e0-316ef0a51076@redhat.com>
Loop linux-input mailing list and trim to the relevant conversation.
> > Can you please comment here how you would like to see events like this
> should come
> > through to userspace?
> >
> > * Wrong power adapter (you have X and should have Y)
> > * You have plugged a dock into the wrong port
> > * Fn-lock mode
>
> Note just thinking out loud here.
>
> I'm thinking we just need a mechanism to show a "user notification". This
> would
> be just a plain text string passed from the kernel to userspace. I guess we
> may also want some mechanism to build (on the kernel side) a small file
> with all possible messages for translation from US English to other
> languages.
The part that falls apart here is that some strings have dynamic data added to
them. For example in the case I said wrong power adapter there will be some numbers
put into the string based on what comes into the buffer. So how will you translate
these?
I guess you can draw a line in the sand and say all strings that can be emitted must
be "static and generic".
>
> So the idea would be that e.g. gnome-shell can listen for these in some way
> and then show a notification in its notification mechanism with the
> message,
> like how it does for when software updates are available for example.
>
> I think we can make this as simple as using the normal printk buffer for
> this
> and prefixing the messages with "USER NOTIFY", we already have some
> messages
> in the kernel which would qualify for this, e.g. in the USB core we have:
>
> dev_info(&udev->dev, "not running at top speed; "
> "connect to a high speed hub\n");
>
> This one is about USB1 vs USB2 ports, but we have a similar one somewhere
> for USB2 vs USB3 ports (I think) which would also be an interesting message
> to actually show to the user inside the desktop environment.
>
> So sticking with the above example, we could change that to
>
> #define USER_NOTIFY "USER NOTIFY: "
>
> dev_info(&udev->dev, USER_NOTIFY "not running at top speed; connect to a
> high speed hub\n");
>
> And then userspace would trigger on the "USER NOTIFY: " part, keep the
> bit before it (which describes the device) as is, try to translate
> the text after it and then combine the text before it + the possibly
> translated text after it and show that as a notification.
>
> The reason for (ab)using the printk ring-buffer for this is that
> we will still want to have these messages in dmesg too anyways,
> so why add a new mechanism and send the same message twice if
> we can just tag the messages inside the printk ring-buffer ?
>
> Note the dev_info above would likely be replaced with some new
> helper which also does some magic to help with gathering a
> list of strings to translate.
>
> Again just thinking out loud here. If anyone has any initial
> reaction to this please let me know...
>
As a general comment, I think it captures very well the possibility
that the kernel has more information than userspace about the circumstances
of something that a user should be notified. Definitely that's the
case for these WMI/ACPI events, and I would think similar circumstances
can apply to other subsystem too.
> Regards,
>
> Hans
>
>
>
>
>
>
>
>
>
>
> >
> >>>>
> >>>> Signed-off-by: Y Paritcher <y.linux@paritcher.com>
> >>>> ---
> >>>> drivers/platform/x86/dell-wmi.c | 17 +++++++++++++++++
> >>>> 1 file changed, 17 insertions(+)
> >>>>
> >>>> diff --git a/drivers/platform/x86/dell-wmi.c
> >> b/drivers/platform/x86/dell-
> >>>> wmi.c
> >>>> index 0b4f72f923cd..f37e7e9093c2 100644
> >>>> --- a/drivers/platform/x86/dell-wmi.c
> >>>> +++ b/drivers/platform/x86/dell-wmi.c
> >>>> @@ -334,6 +334,14 @@ static const struct key_entry
> >>>> dell_wmi_keymap_type_0011[] = {
> >>>> { KE_IGNORE, KBD_LED_AUTO_100_TOKEN, { KEY_RESERVED } },
> >>>> };
> >>>>
> >>>> +/*
> >>>> + * Keymap for WMI events of type 0x0012
> >>>> + */
> >>>> +static const struct key_entry dell_wmi_keymap_type_0012[] = {
> >>>> + /* Fn-lock button pressed */
> >>>> + { KE_IGNORE, 0xe035, { KEY_RESERVED } },
> >>>> +};
> >>>> +
> >>>> static void dell_wmi_process_key(struct wmi_device *wdev, int type,
> int
> >>>> code)
> >>>> {
> >>>> struct dell_wmi_priv *priv = dev_get_drvdata(&wdev->dev);
> >>>> @@ -425,6 +433,7 @@ static void dell_wmi_notify(struct wmi_device
> *wdev,
> >>>> break;
> >>>> case 0x0010: /* Sequence of keys pressed */
> >>>> case 0x0011: /* Sequence of events occurred */
> >>>> + case 0x0012: /* Sequence of events occurred */
> >>>> for (i = 2; i < len; ++i)
> >>>> dell_wmi_process_key(wdev, buffer_entry[1],
> >>>> buffer_entry[i]);
> >>>> @@ -556,6 +565,7 @@ static int dell_wmi_input_setup(struct wmi_device
> >>>> *wdev)
> >>>> ARRAY_SIZE(dell_wmi_keymap_type_0000) +
> >>>> ARRAY_SIZE(dell_wmi_keymap_type_0010) +
> >>>> ARRAY_SIZE(dell_wmi_keymap_type_0011) +
> >>>> + ARRAY_SIZE(dell_wmi_keymap_type_0012) +
> >>>> 1,
> >>>> sizeof(struct key_entry), GFP_KERNEL);
> >>>> if (!keymap) {
> >>>> @@ -600,6 +610,13 @@ static int dell_wmi_input_setup(struct wmi_device
> >>>> *wdev)
> >>>> pos++;
> >>>> }
> >>>>
> >>>> + /* Append table with events of type 0x0012 */
> >>>> + for (i = 0; i < ARRAY_SIZE(dell_wmi_keymap_type_0012); i++) {
> >>>> + keymap[pos] = dell_wmi_keymap_type_0012[i];
> >>>> + keymap[pos].code |= (0x0012 << 16);
> >>>> + pos++;
> >>>> + }
> >>>> +
> >>>> /*
> >>>> * Now append also table with "legacy" events of type 0x0000.
> Some of
> >>>> * them are reported also on laptops which have scancodes in DMI.
> >>>> --
> >>>> 2.27.0
> >>>
next prev parent reply other threads:[~2020-06-09 15:37 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-08 4:22 [PATCH 0/3] platform/x86: dell-wmi: new keys Y Paritcher
2020-06-08 4:22 ` [PATCH 1/3] platform/x86: dell-wmi: add new backlight events Y Paritcher
2020-06-08 8:35 ` Pali Rohár
2020-06-08 15:30 ` Mario.Limonciello
2020-06-08 20:11 ` Y Paritcher
2020-06-08 20:14 ` Mario.Limonciello
2020-06-08 20:36 ` Pali Rohár
2020-06-08 20:38 ` Mario.Limonciello
2020-06-08 4:22 ` [PATCH 2/3] platform/x86: dell-wmi: add new keymap type 0x0012 Y Paritcher
2020-06-08 8:50 ` Pali Rohár
2020-06-08 20:12 ` Y Paritcher
2020-06-08 15:40 ` Mario.Limonciello
2020-06-08 20:12 ` Y Paritcher
2020-06-08 20:30 ` Pali Rohár
2020-06-08 20:36 ` Mario.Limonciello
2020-06-08 21:03 ` Y Paritcher
2020-06-08 22:00 ` Mario.Limonciello
2020-06-08 22:53 ` Y Paritcher
2020-06-09 10:44 ` Hans de Goede
2020-06-09 15:36 ` Mario.Limonciello [this message]
2020-06-09 16:14 ` Hans de Goede
2020-06-09 19:41 ` Mario.Limonciello
2020-06-09 15:49 ` Pali Rohár
2020-06-09 16:45 ` Sebastian Reichel
2020-06-09 16:59 ` Hans de Goede
2020-06-19 15:31 ` Sebastian Reichel
2020-06-19 17:26 ` Mario.Limonciello
2020-06-09 8:04 ` Pali Rohár
2020-06-08 4:22 ` [PATCH 3/3] platform/x86: dell-wmi: add keys to bios_to_linux_keycode Y Paritcher
2020-06-08 6:36 ` kernel test robot
2020-06-08 7:36 ` kernel test robot
2020-06-08 9:00 ` Pali Rohár
2020-06-08 15:46 ` Mario.Limonciello
2020-06-08 20:12 ` Y Paritcher
2020-06-08 20:48 ` Pali Rohár
2020-06-08 20:58 ` Mario.Limonciello
2020-06-09 8:27 ` Pali Rohár
2020-06-08 23:05 ` [PATCH v2 0/3] platform/x86: dell-wmi: new keys Y Paritcher
2020-06-08 23:05 ` [PATCH v2 1/3] platform/x86: dell-wmi: add new backlight events Y Paritcher
2020-06-08 23:24 ` Pali Rohár
2020-06-08 23:05 ` [PATCH v2 2/3] platform/x86: dell-wmi: add new keymap type 0x0012 Y Paritcher
2020-06-08 23:33 ` Pali Rohár
2020-06-09 0:26 ` Mario.Limonciello
2020-06-09 0:57 ` Y Paritcher
2020-06-09 8:40 ` Pali Rohár
2020-06-09 8:50 ` Pali Rohár
2020-06-08 23:05 ` [PATCH v2 3/3] platform/x86: dell-wmi: add new dmi keys to bios_to_linux_keycode Y Paritcher
2020-06-08 23:27 ` Randy Dunlap
2020-06-08 23:55 ` Pali Rohár
2020-06-09 0:43 ` Y Paritcher
2020-06-09 8:35 ` Pali Rohár
2020-06-09 19:49 ` Mario.Limonciello
2020-06-10 9:44 ` Pali Rohár
2020-06-10 12:35 ` Mario.Limonciello
2020-06-12 14:14 ` Pali Rohár
2020-06-12 14:59 ` Mario.Limonciello
2020-06-09 3:52 ` [PATCH v3 0/3] platform/x86: dell-wmi: new keys Y Paritcher
2020-06-09 3:52 ` [PATCH v3 1/3] platform/x86: dell-wmi: add new backlight events Y Paritcher
2020-06-09 16:02 ` Mario.Limonciello
2020-06-09 3:52 ` [PATCH v3 2/3] platform/x86: dell-wmi: add new keymap type 0x0012 Y Paritcher
2020-06-09 3:52 ` [PATCH v3 3/3] platform/x86: dell-wmi: add new dmi mapping for keycode 0xffff Y Paritcher
2020-06-09 9:19 ` Pali Rohár
2020-06-10 17:56 ` [PATCH v4 0/3] platform/x86: dell-wmi: new keys Y Paritcher
2020-06-10 17:56 ` [PATCH v4 1/3] platform/x86: dell-wmi: add new backlight events Y Paritcher
2020-06-10 17:56 ` [PATCH v4 2/3] platform/x86: dell-wmi: add new keymap type 0x0012 Y Paritcher
2020-06-10 17:56 ` [PATCH v4 3/3] platform/x86: dell-wmi: add new dmi mapping for keycode 0xffff Y Paritcher
2020-06-10 19:22 ` [PATCH v4 0/3] platform/x86: dell-wmi: new keys Mario.Limonciello
2020-07-09 19:29 ` Andy Shevchenko
2020-07-13 7:29 ` Pali Rohár
2020-08-14 8:10 ` Pali Rohár
2020-06-12 14:09 ` Pali Rohár
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=ae45da27126d470888ef0d839665b9ed@AUSX13MPC105.AMER.DELL.COM \
--to=mario.limonciello@dell.com \
--cc=hdegoede@redhat.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=pali@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=y.linux@paritcher.com \
/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;
as well as URLs for NNTP newsgroup(s).