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@xxxxxxxxxxxxx>
> >>>> ---
> >>>> 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
> >>>
