Re: [PATCH 2/3] platform/x86: dell-wmi: add new keymap type 0x0012
From: Hans de Goede
Date: Tue Jun 09 2020 - 12:14:27 EST
Hi,
On 6/9/20 5:36 PM, Mario.Limonciello@xxxxxxxx wrote:
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".
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.
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