Message-ID: <d9e3953bac9a4b4f8bf5b67add075368@AUSX13MPC105.AMER.DELL.COM>
Date:   Tue, 9 Jun 2020 19:41:20 +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

> Right, that is what I was thinking, although for the power adapter case
> I was thinking there are not so much variants so we can just do
> a couple of fixed strings for the combos, or maybe just sat that
> the adapter does not delivers enough power and that at minimum X watts
> is necessary" then we only have 1 variable and we can probably easily
> do fixed strings for the few cases of X.

I would rather have a generic fixed string or fixed strings with a single
than an array.  But the problem then is that the numbers are not discoverable
from anywhere and would need to be hardcoded.  So in that regard I think generic
fixed strings is the only way this can work.

> 
> Or we could get fancy and do some generic notification mechanism outside
> of printk/dmesg where we push a format string + parameters to the format
> string to userspace. So that the translation can be done on the format
> string rather then on the end result. I'm not sure we need to make things
> that complicated though.
> 
> >> 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.
> 
> Right, that was my idea behind having a generic notification mechanism.
> 
> Regards,
> 
> Hans

Powered by blists - more mailing lists