Date:   Tue, 9 Jun 2020 15:36:54 +0000
From:   <Mario.Limonciello@...l.com>
To:     <hdegoede@...hat.com>, <y.linux@...itcher.com>
CC:     <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <mjg59@...f.ucam.org>,
        <pali@...nel.org>, <linux-input@...r.kernel.org>
Subject: RE: [PATCH 2/3] platform/x86: dell-wmi: add new keymap type 0x0012

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@...itcher.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
> >>>

Powered by blists - more mailing lists