Handle some more WMI events that are triggered on TUXEDO devices.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
---
drivers/platform/x86/uniwill/uniwill-acpi.c | 19 ++++++++++++++++++-
drivers/platform/x86/uniwill/uniwill-wmi.h | 2 ++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c b/drivers/platform/x86/uniwill/uniwill-acpi.c
index 014960d16211b..4efb5a909f717 100644
--- a/drivers/platform/x86/uniwill/uniwill-acpi.c
+++ b/drivers/platform/x86/uniwill/uniwill-acpi.c
@@ -371,9 +371,11 @@ static const struct key_entry uniwill_keymap[] = {
/* Reported in manual mode when toggling the airplane mode status */
{ KE_KEY, UNIWILL_OSD_RFKILL, { KEY_RFKILL }},
+ { KE_IGNORE, UNIWILL_OSD_RADIOON, { KEY_UNKNOWN }},
+ { KE_IGNORE, UNIWILL_OSD_RADIOOFF, { KEY_UNKNOWN }},
/* Reported when user wants to cycle the platform profile */
- { KE_IGNORE, UNIWILL_OSD_PERFORMANCE_MODE_TOGGLE, { KEY_UNKNOWN }},
+ { KE_KEY, UNIWILL_OSD_PERFORMANCE_MODE_TOGGLE, { KEY_F14 }},
/* Reported when the user wants to adjust the brightness of the keyboard */
{ KE_KEY, UNIWILL_OSD_KBDILLUMDOWN, { KEY_KBDILLUMDOWN }},
@@ -382,11 +384,19 @@ static const struct key_entry uniwill_keymap[] = {
/* Reported when the user wants to toggle the microphone mute status */
{ KE_KEY, UNIWILL_OSD_MIC_MUTE, { KEY_MICMUTE }},
+ /* Reported when the user wants to toggle the mute status */
+ { KE_IGNORE, UNIWILL_OSD_MUTE, { KEY_MUTE }},
+
/* Reported when the user locks/unlocks the Fn key */
{ KE_IGNORE, UNIWILL_OSD_FN_LOCK, { KEY_FN_ESC }},
/* Reported when the user wants to toggle the brightness of the keyboard */
{ KE_KEY, UNIWILL_OSD_KBDILLUMTOGGLE, { KEY_KBDILLUMTOGGLE }},
+ { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL0, { KEY_KBDILLUMTOGGLE }},
+ { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL1, { KEY_KBDILLUMTOGGLE }},
+ { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL2, { KEY_KBDILLUMTOGGLE }},
+ { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL3, { KEY_KBDILLUMTOGGLE }},
+ { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL4, { KEY_KBDILLUMTOGGLE }},
/* FIXME: find out the exact meaning of those events */
{ KE_IGNORE, UNIWILL_OSD_BAT_CHARGE_FULL_24_H, { KEY_UNKNOWN }},
@@ -395,6 +405,9 @@ static const struct key_entry uniwill_keymap[] = {
/* Reported when the user wants to toggle the benchmark mode status */
{ KE_IGNORE, UNIWILL_OSD_BENCHMARK_MODE_TOGGLE, { KEY_UNKNOWN }},
+ /* Reported when the user wants to toggle the webcam */
+ { KE_IGNORE, UNIWILL_OSD_WEBCAM_TOGGLE, { KEY_UNKNOWN }},
+
{ KE_END }
};
@@ -1247,6 +1260,10 @@ static int uniwill_notifier_call(struct notifier_block *nb, unsigned long action
}
mutex_unlock(&data->battery_lock);
+ return NOTIFY_OK;
+ case UNIWILL_OSD_DC_ADAPTER_CHANGED:
+ // noop for the time being
+
return NOTIFY_OK;
default:
mutex_lock(&data->input_lock);
diff --git a/drivers/platform/x86/uniwill/uniwill-wmi.h b/drivers/platform/x86/uniwill/uniwill-wmi.h
index 2bf69f2d80381..48783b2e9ffb9 100644
--- a/drivers/platform/x86/uniwill/uniwill-wmi.h
+++ b/drivers/platform/x86/uniwill/uniwill-wmi.h
@@ -113,6 +113,8 @@
#define UNIWILL_OSD_BENCHMARK_MODE_TOGGLE 0xC0
+#define UNIWILL_OSD_WEBCAM_TOGGLE 0xCF
+
#define UNIWILL_OSD_KBD_BACKLIGHT_CHANGED 0xF0
struct device;
--
2.43.0
Am 18.11.25 um 16:02 schrieb Werner Sembach:
> Handle some more WMI events that are triggered on TUXEDO devices.
>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> ---
> drivers/platform/x86/uniwill/uniwill-acpi.c | 19 ++++++++++++++++++-
> drivers/platform/x86/uniwill/uniwill-wmi.h | 2 ++
> 2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c b/drivers/platform/x86/uniwill/uniwill-acpi.c
> index 014960d16211b..4efb5a909f717 100644
> --- a/drivers/platform/x86/uniwill/uniwill-acpi.c
> +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c
> @@ -371,9 +371,11 @@ static const struct key_entry uniwill_keymap[] = {
>
> /* Reported in manual mode when toggling the airplane mode status */
> { KE_KEY, UNIWILL_OSD_RFKILL, { KEY_RFKILL }},
> + { KE_IGNORE, UNIWILL_OSD_RADIOON, { KEY_UNKNOWN }},
> + { KE_IGNORE, UNIWILL_OSD_RADIOOFF, { KEY_UNKNOWN }},
>
> /* Reported when user wants to cycle the platform profile */
> - { KE_IGNORE, UNIWILL_OSD_PERFORMANCE_MODE_TOGGLE, { KEY_UNKNOWN }},
> + { KE_KEY, UNIWILL_OSD_PERFORMANCE_MODE_TOGGLE, { KEY_F14 }},
>
> /* Reported when the user wants to adjust the brightness of the keyboard */
> { KE_KEY, UNIWILL_OSD_KBDILLUMDOWN, { KEY_KBDILLUMDOWN }},
> @@ -382,11 +384,19 @@ static const struct key_entry uniwill_keymap[] = {
> /* Reported when the user wants to toggle the microphone mute status */
> { KE_KEY, UNIWILL_OSD_MIC_MUTE, { KEY_MICMUTE }},
>
> + /* Reported when the user wants to toggle the mute status */
> + { KE_IGNORE, UNIWILL_OSD_MUTE, { KEY_MUTE }},
> +
> /* Reported when the user locks/unlocks the Fn key */
> { KE_IGNORE, UNIWILL_OSD_FN_LOCK, { KEY_FN_ESC }},
>
> /* Reported when the user wants to toggle the brightness of the keyboard */
> { KE_KEY, UNIWILL_OSD_KBDILLUMTOGGLE, { KEY_KBDILLUMTOGGLE }},
> + { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL0, { KEY_KBDILLUMTOGGLE }},
> + { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL1, { KEY_KBDILLUMTOGGLE }},
> + { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL2, { KEY_KBDILLUMTOGGLE }},
> + { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL3, { KEY_KBDILLUMTOGGLE }},
> + { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL4, { KEY_KBDILLUMTOGGLE }},
>
> /* FIXME: find out the exact meaning of those events */
> { KE_IGNORE, UNIWILL_OSD_BAT_CHARGE_FULL_24_H, { KEY_UNKNOWN }},
> @@ -395,6 +405,9 @@ static const struct key_entry uniwill_keymap[] = {
> /* Reported when the user wants to toggle the benchmark mode status */
> { KE_IGNORE, UNIWILL_OSD_BENCHMARK_MODE_TOGGLE, { KEY_UNKNOWN }},
>
> + /* Reported when the user wants to toggle the webcam */
> + { KE_IGNORE, UNIWILL_OSD_WEBCAM_TOGGLE, { KEY_UNKNOWN }},
> +
> { KE_END }
> };
>
> @@ -1247,6 +1260,10 @@ static int uniwill_notifier_call(struct notifier_block *nb, unsigned long action
> }
> mutex_unlock(&data->battery_lock);
>
> + return NOTIFY_OK;
> + case UNIWILL_OSD_DC_ADAPTER_CHANGED:
> + // noop for the time being
Sorry forgot to edit comment style here, will do for v3 but first waiting for
ack of the rest.
> +
> return NOTIFY_OK;
> default:
> mutex_lock(&data->input_lock);
> diff --git a/drivers/platform/x86/uniwill/uniwill-wmi.h b/drivers/platform/x86/uniwill/uniwill-wmi.h
> index 2bf69f2d80381..48783b2e9ffb9 100644
> --- a/drivers/platform/x86/uniwill/uniwill-wmi.h
> +++ b/drivers/platform/x86/uniwill/uniwill-wmi.h
> @@ -113,6 +113,8 @@
>
> #define UNIWILL_OSD_BENCHMARK_MODE_TOGGLE 0xC0
>
> +#define UNIWILL_OSD_WEBCAM_TOGGLE 0xCF
> +
> #define UNIWILL_OSD_KBD_BACKLIGHT_CHANGED 0xF0
>
> struct device;
On Wed, 19 Nov 2025, Werner Sembach wrote:
>
> Am 18.11.25 um 16:02 schrieb Werner Sembach:
> > Handle some more WMI events that are triggered on TUXEDO devices.
To avoid another round-trip and a version, please write a bit more what
this is about than extremely vague "some".
--
i.
> >
> > Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> > ---
> > drivers/platform/x86/uniwill/uniwill-acpi.c | 19 ++++++++++++++++++-
> > drivers/platform/x86/uniwill/uniwill-wmi.h | 2 ++
> > 2 files changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/platform/x86/uniwill/uniwill-acpi.c
> > b/drivers/platform/x86/uniwill/uniwill-acpi.c
> > index 014960d16211b..4efb5a909f717 100644
> > --- a/drivers/platform/x86/uniwill/uniwill-acpi.c
> > +++ b/drivers/platform/x86/uniwill/uniwill-acpi.c
> > @@ -371,9 +371,11 @@ static const struct key_entry uniwill_keymap[] = {
> > /* Reported in manual mode when toggling the airplane mode status */
> > { KE_KEY, UNIWILL_OSD_RFKILL, { KEY_RFKILL
> > }},
> > + { KE_IGNORE, UNIWILL_OSD_RADIOON, { KEY_UNKNOWN
> > }},
> > + { KE_IGNORE, UNIWILL_OSD_RADIOOFF, { KEY_UNKNOWN
> > }},
> > /* Reported when user wants to cycle the platform profile */
> > - { KE_IGNORE, UNIWILL_OSD_PERFORMANCE_MODE_TOGGLE, { KEY_UNKNOWN
> > }},
> > + { KE_KEY, UNIWILL_OSD_PERFORMANCE_MODE_TOGGLE, { KEY_F14 }},
> > /* Reported when the user wants to adjust the brightness of the
> > keyboard */
> > { KE_KEY, UNIWILL_OSD_KBDILLUMDOWN, {
> > KEY_KBDILLUMDOWN }},
> > @@ -382,11 +384,19 @@ static const struct key_entry uniwill_keymap[] = {
> > /* Reported when the user wants to toggle the microphone mute status
> > */
> > { KE_KEY, UNIWILL_OSD_MIC_MUTE, { KEY_MICMUTE
> > }},
> > + /* Reported when the user wants to toggle the mute status */
> > + { KE_IGNORE, UNIWILL_OSD_MUTE, { KEY_MUTE }},
> > +
> > /* Reported when the user locks/unlocks the Fn key */
> > { KE_IGNORE, UNIWILL_OSD_FN_LOCK, { KEY_FN_ESC
> > }},
> > /* Reported when the user wants to toggle the brightness of the
> > keyboard */
> > { KE_KEY, UNIWILL_OSD_KBDILLUMTOGGLE, {
> > KEY_KBDILLUMTOGGLE }},
> > + { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL0, {
> > KEY_KBDILLUMTOGGLE }},
> > + { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL1, {
> > KEY_KBDILLUMTOGGLE }},
> > + { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL2, {
> > KEY_KBDILLUMTOGGLE }},
> > + { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL3, {
> > KEY_KBDILLUMTOGGLE }},
> > + { KE_KEY, UNIWILL_OSD_KB_LED_LEVEL4, {
> > KEY_KBDILLUMTOGGLE }},
> > /* FIXME: find out the exact meaning of those events */
> > { KE_IGNORE, UNIWILL_OSD_BAT_CHARGE_FULL_24_H, { KEY_UNKNOWN
> > }},
> > @@ -395,6 +405,9 @@ static const struct key_entry uniwill_keymap[] = {
> > /* Reported when the user wants to toggle the benchmark mode status */
> > { KE_IGNORE, UNIWILL_OSD_BENCHMARK_MODE_TOGGLE, { KEY_UNKNOWN
> > }},
> > + /* Reported when the user wants to toggle the webcam */
> > + { KE_IGNORE, UNIWILL_OSD_WEBCAM_TOGGLE, { KEY_UNKNOWN
> > }},
> > +
> > { KE_END }
> > };
> > @@ -1247,6 +1260,10 @@ static int uniwill_notifier_call(struct
> > notifier_block *nb, unsigned long action
> > }
> > mutex_unlock(&data->battery_lock);
> > + return NOTIFY_OK;
> > + case UNIWILL_OSD_DC_ADAPTER_CHANGED:
> > + // noop for the time being
> Sorry forgot to edit comment style here, will do for v3 but first waiting for
> ack of the rest.
> > +
> > return NOTIFY_OK;
> > default:
> > mutex_lock(&data->input_lock);
> > diff --git a/drivers/platform/x86/uniwill/uniwill-wmi.h
> > b/drivers/platform/x86/uniwill/uniwill-wmi.h
> > index 2bf69f2d80381..48783b2e9ffb9 100644
> > --- a/drivers/platform/x86/uniwill/uniwill-wmi.h
> > +++ b/drivers/platform/x86/uniwill/uniwill-wmi.h
> > @@ -113,6 +113,8 @@
> > #define UNIWILL_OSD_BENCHMARK_MODE_TOGGLE 0xC0
> > +#define UNIWILL_OSD_WEBCAM_TOGGLE 0xCF
> > +
> > #define UNIWILL_OSD_KBD_BACKLIGHT_CHANGED 0xF0
> > struct device;
>
Hi Ilpo, Am 20.11.25 um 11:44 schrieb Ilpo Järvinen: > On Wed, 19 Nov 2025, Werner Sembach wrote: > >> Am 18.11.25 um 16:02 schrieb Werner Sembach: >>> Handle some more WMI events that are triggered on TUXEDO devices. > To avoid another round-trip and a version, please write a bit more what > this is about than extremely vague "some". > ofc: I tested 3 more devices (InfinityBook 15 Gen9 Intel, Stellaris 16 Gen5 AMD and Intel) and found that these send additional WMI events that the devices Armin tested didn't. These are: UNIWILL_OSD_MUTE, UNIWILL_OSD_WEBCAM_TOGGLE, and UNIWILL_OSD_DC_ADAPTER_CHANGED I also went through our out-of-tree driver where additional WMI events are bound: UNIWILL_OSD_RADIOON, UNIWILL_OSD_RADIOOFF, and UNIWILL_OSD_KB_LED_LEVEL* While I don't know which devices exactly use them, at least one device does, otherwise we wouldn't have them there. Also I don't see any harm in binding them, so I did. Best Regards, Werner
Am 20.11.25 um 11:59 schrieb Werner Sembach: > Hi Ilpo, > > Am 20.11.25 um 11:44 schrieb Ilpo Järvinen: >> On Wed, 19 Nov 2025, Werner Sembach wrote: >> >>> Am 18.11.25 um 16:02 schrieb Werner Sembach: >>>> Handle some more WMI events that are triggered on TUXEDO devices. >> To avoid another round-trip and a version, please write a bit more what >> this is about than extremely vague "some". >> > ofc: > > I tested 3 more devices (InfinityBook 15 Gen9 Intel, Stellaris 16 Gen5 AMD and > Intel) and found that these send additional WMI events that the devices Armin > tested didn't. > > These are: UNIWILL_OSD_MUTE, UNIWILL_OSD_WEBCAM_TOGGLE, and > UNIWILL_OSD_DC_ADAPTER_CHANGED > > I also went through our out-of-tree driver where additional WMI events are > bound: UNIWILL_OSD_RADIOON, UNIWILL_OSD_RADIOOFF, and UNIWILL_OSD_KB_LED_LEVEL* > > While I don't know which devices exactly use them, at least one device does, > otherwise we wouldn't have them there. Also I don't see any harm in binding > them, so I did. Forgot the most important part: Why i bound them even when some are just ignored: This avoids warning spam in dmesg about unbound events. > > Best Regards, > > Werner
On Thu, 20 Nov 2025, Werner Sembach wrote: > Am 20.11.25 um 11:59 schrieb Werner Sembach: > > Am 20.11.25 um 11:44 schrieb Ilpo Järvinen: > > > On Wed, 19 Nov 2025, Werner Sembach wrote: > > > > > > > Am 18.11.25 um 16:02 schrieb Werner Sembach: > > > > > Handle some more WMI events that are triggered on TUXEDO devices. > > > To avoid another round-trip and a version, please write a bit more what > > > this is about than extremely vague "some". > > > > > ofc: > > > > I tested 3 more devices (InfinityBook 15 Gen9 Intel, Stellaris 16 Gen5 AMD > > and Intel) and found that these send additional WMI events that the devices > > Armin tested didn't. > > > > These are: UNIWILL_OSD_MUTE, UNIWILL_OSD_WEBCAM_TOGGLE, and > > UNIWILL_OSD_DC_ADAPTER_CHANGED > > > > I also went through our out-of-tree driver where additional WMI events are > > bound: UNIWILL_OSD_RADIOON, UNIWILL_OSD_RADIOOFF, and > > UNIWILL_OSD_KB_LED_LEVEL* > > > > While I don't know which devices exactly use them, at least one device does, > > otherwise we wouldn't have them there. Also I don't see any harm in binding > > them, so I did. > > Forgot the most important part: Why i bound them even when some are just > ignored: This avoids warning spam in dmesg about unbound events. Hi Werner, I've actually no problem with the diff itself :-) but what I want is us to explain what we're doing in the changelog text. E.g., if you add code ignore something to avoid warning spam, please state that in the changelog (not just "handle" which is actually quite different than "ignore" if we start to really go into language details, yeah, "ignoring" is kind of "handling" too but must less precise, I think you get the point). Some things can be read from the patch itself, but it usually means more work and we rarely can infer motivations behind any non-trivial change so it's always useful to record such otherwise hidden details to the changelog. Nobody is perfect in this, I don't expect that, but please try to avoid vague expressions when writing the description. Stating why they're ignored (beyond just warning spam itself) is even better when e.g. you know something else handles the same event already. But it's understandable if you don't always know such details which itself might be useful knowledge for somebody wanting to change the code later (was something done on purpose or just because we did not know better at that time? is often what I'm left to ponder after reading a change from history, if changelog doesn't give that detail, I'll haveto guess and hope for the best). In general, if somebody asks about some detail from a submitter, it's worth to stop to consider if it's something should be added to the changelog (when no change to the diff itself is asked). It could point out something in the change that is not obvious enough. We're not writing these changelogs just for the people around now but also for the people that come after us (and might only see the change from the commit history as there's no guarantee any of us will be there then and/or doesn't remember anyway). That also means if I don't seem to be directly asking a question, I usually don't expect email reply (other than in a form of a new version of the patch that addresses the feedback :-)). -- i.
Am 20.11.25 um 17:31 schrieb Ilpo Järvinen: > On Thu, 20 Nov 2025, Werner Sembach wrote: >> Am 20.11.25 um 11:59 schrieb Werner Sembach: >>> Am 20.11.25 um 11:44 schrieb Ilpo Järvinen: >>>> On Wed, 19 Nov 2025, Werner Sembach wrote: >>>> >>>>> Am 18.11.25 um 16:02 schrieb Werner Sembach: >>>>>> Handle some more WMI events that are triggered on TUXEDO devices. >>>> To avoid another round-trip and a version, please write a bit more what >>>> this is about than extremely vague "some". >>>> >>> ofc: >>> >>> I tested 3 more devices (InfinityBook 15 Gen9 Intel, Stellaris 16 Gen5 AMD >>> and Intel) and found that these send additional WMI events that the devices >>> Armin tested didn't. >>> >>> These are: UNIWILL_OSD_MUTE, UNIWILL_OSD_WEBCAM_TOGGLE, and >>> UNIWILL_OSD_DC_ADAPTER_CHANGED >>> >>> I also went through our out-of-tree driver where additional WMI events are >>> bound: UNIWILL_OSD_RADIOON, UNIWILL_OSD_RADIOOFF, and >>> UNIWILL_OSD_KB_LED_LEVEL* >>> >>> While I don't know which devices exactly use them, at least one device does, >>> otherwise we wouldn't have them there. Also I don't see any harm in binding >>> them, so I did. >> Forgot the most important part: Why i bound them even when some are just >> ignored: This avoids warning spam in dmesg about unbound events. > Hi Werner, > > I've actually no problem with the diff itself :-) but what I want is us > to explain what we're doing in the changelog text. E.g., if you add code > ignore something to avoid warning spam, please state that in the > changelog (not just "handle" which is actually quite different than > "ignore" if we start to really go into language details, yeah, > "ignoring" is kind of "handling" too but must less precise, I think you > get the point). > > Some things can be read from the patch itself, but it usually means more > work and we rarely can infer motivations behind any non-trivial change so > it's always useful to record such otherwise hidden details to the > changelog. Nobody is perfect in this, I don't expect that, but please try > to avoid vague expressions when writing the description. > > Stating why they're ignored (beyond just warning spam itself) is even > better when e.g. you know something else handles the same > event already. But it's understandable if you don't always know such > details which itself might be useful knowledge for somebody wanting to > change the code later (was something done on purpose or just because > we did not know better at that time? is often what I'm left to ponder > after reading a change from history, if changelog doesn't give that > detail, I'll haveto guess and hope for the best). > > In general, if somebody asks about some detail from a submitter, it's > worth to stop to consider if it's something should be added to the > changelog (when no change to the diff itself is asked). It could point out > something in the change that is not obvious enough. We're not writing > these changelogs just for the people around now but also for the people > that come after us (and might only see the change from the commit history > as there's no guarantee any of us will be there then and/or doesn't > remember anyway). > > That also means if I don't seem to be directly asking a question, I > usually don't expect email reply (other than in a form of a new version of > the patch that addresses the feedback :-)). Ah sorry i misunderstood your "To avoid another round-trip and a version, please write a bit more what this is about than extremely vague "some"." Ok will give more details in the patch description, v3 incoming. Best regards and thanks for being patient with my mistakes, Werner >
© 2016 - 2025 Red Hat, Inc.