X86 platform drivers
 help / color / mirror / Atom feed
From: Armin Wolf <W_Armin@gmx.de>
To: Werner Sembach <wse@tuxedocomputers.com>,
	hansg@kernel.org, ilpo.jarvinen@linux.intel.com
Cc: platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/6] platform/x86/uniwill: Handle more WMI events required for TUXEDO devices
Date: Tue, 18 Nov 2025 15:41:12 +0100	[thread overview]
Message-ID: <2d5d88fe-cd54-4311-b5cd-b1c435ff973d@gmx.de> (raw)
In-Reply-To: <3c075220-79f3-4dff-a760-6fe065147793@tuxedocomputers.com>

Am 18.11.25 um 15:27 schrieb Werner Sembach:

>
> Am 18.11.25 um 14:48 schrieb Armin Wolf:
>> Am 18.11.25 um 14:29 schrieb Werner Sembach:
>>
>>>
>>> Am 18.11.25 um 14:12 schrieb Armin Wolf:
>>>> Am 18.11.25 um 13:45 schrieb Werner Sembach:
>>>>
>>>>>
>>>>> Am 18.11.25 um 12:08 schrieb Armin Wolf:
>>>>>> Am 17.11.25 um 14:23 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 29bb3709bfcc8..0cb86a701b2e1 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 }},
>>>>>>
>>>>>> I am currently working a patch adding platform profile support, 
>>>>>> so this event would
>>>>>> be handled inside the kernel on models with platform profile 
>>>>>> support.
>>>>>
>>>>> For tuxedo devices we have profiles managed in userspace that do 
>>>>> additional things. So we need a way to handle this in userspace.
>>>>>
>>>> Do these things have something to do with the uniwill EC? If so 
>>>> then we should implement those inside the driver
>>>> itself. The control center can then poll the platform profile sysfs 
>>>> file to get notified when platform_profile_cycle()
>>>> is executed to perform additional actions.
>>> Not exclusively, e.g. one thing is display brightness.
>>
>> And you cannot poll the sysfs interface?
> I can't follow you atm?

I meant to ask whether or not your application could poll the platform profile sysfs interface for changes instead of
listing for the F14 key.

Thanks,
Armin Wolf

>>
>>>>
>>>>> The 2 things I can spontaneously think of would be a sysfs toggle 
>>>>> or 2 different UNIWILL_FEATURE_* defines.
>>>>>
>>>> TPH i would love to have an ordinary keycode allocated for that if 
>>>> the above does not work for you. There already
>>>> exists KEY_PERFORMANCE, so adding something like 
>>>> KEY_PERFORMANCE_CYCLE should be possible.
>>>
>>> New keycodes won't work on X11, I don't know the reason, but X11 
>>> only supports a max of 248 keycodes
>>>
>>> That's why for example touchpad toggle is bound to F21 e.g. here 
>>> https://elixir.bootlin.com/linux/v6.17.8/source/drivers/platform/x86/lg-laptop.c#L106 
>>> .
>>>
>> Oh no. In this case using F14 is fine.
>>
>>
>> Thanks,
>> Armin Wolf
>>
>>>>
>>>>>>
>>>>>>>         /* 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 }},
>>>>>>
>>>>>> Why is this event being ignored?
>>>>> Because the UNIWILL_OSD_MUTE event is sent in addition to the mute 
>>>>> key event, so not ignoring it here would result in a double trigger.
>>>>
>>>> I understand.
>>>>
>>>>>>
>>>>>>> +
>>>>>>>       /* 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 }},
>>>>>>
>>>>>> Same as above.
>>>>>
>>>>> Same as above ;)
>>>>>
>>>>> At least iirc, would have to double check
>>>>>
>>>> Ok.
>>>>
>>>> Thanks,
>>>> Armin Wolf
>>>>
>>>>>>
>>>>>>> +
>>>>>>>       { 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
>>>>>>
>>>>>> Wrong comment style, please use /* */.
>>>>> ack
>>>>>>
>>>>>> Thanks,
>>>>>> Armin Wolf
>>>>>>
>>>>>>> +
>>>>>>>           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;
>>>>>
>

  reply	other threads:[~2025-11-18 14:41 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-17 13:23 [PATCH 0/6] Start of Upstream Support for TUXEDO NB02 devices Werner Sembach
2025-11-17 13:23 ` [PATCH 1/6] platform/x86/uniwill: Add TUXEDO devices Werner Sembach
2025-11-18 11:03   ` Armin Wolf
2025-11-17 13:23 ` [PATCH 2/6] platform/x86/uniwill: Handle more WMI events required for " Werner Sembach
2025-11-18 11:08   ` Armin Wolf
2025-11-18 12:45     ` Werner Sembach
2025-11-18 13:12       ` Armin Wolf
2025-11-18 13:29         ` Werner Sembach
2025-11-18 13:48           ` Armin Wolf
2025-11-18 14:27             ` Werner Sembach
2025-11-18 14:41               ` Armin Wolf [this message]
2025-11-18 15:05                 ` Werner Sembach
2025-11-20  0:53                   ` Armin Wolf
2025-11-20 10:42                     ` Werner Sembach
2025-11-20 13:40                       ` Armin Wolf
2025-11-20 22:06                         ` Werner Sembach
2025-11-22 23:54                           ` Armin Wolf
2025-11-24 17:43                             ` Werner Sembach
2025-11-24 18:40                     ` Werner Sembach
2025-11-25  0:50                       ` Armin Wolf
2025-11-25 14:05                         ` Werner Sembach
2025-11-17 13:24 ` [PATCH 3/6] platform/x86/uniwill: Implement cTGP setting Werner Sembach
2025-11-18 11:12   ` Armin Wolf
2025-11-18 12:58     ` Werner Sembach
2025-11-18 13:29       ` Armin Wolf
2025-11-19 15:34         ` Werner Sembach
2025-11-20  1:16           ` Armin Wolf
2025-11-20 10:47             ` Werner Sembach
2025-11-17 13:24 ` [PATCH 4/6] platform/x86/uniwill: Make uniwill_dmi_table accessible in probe Werner Sembach
2025-11-18 11:16   ` Armin Wolf
2025-11-18 13:01     ` Werner Sembach
2025-11-18 13:35       ` Armin Wolf
2025-11-18 13:40         ` Werner Sembach
2025-11-17 13:24 ` [PATCH 5/6] platform/x86/uniwill: Run callbacks of uniwill_dmi_table Werner Sembach
2025-11-17 13:24 ` [PATCH 6/6] platform/x86/uniwill: Set cTGP support based on EC for TUXEDO IBP Gen7 MK1 Werner Sembach
2025-11-18 10:43   ` Ilpo Järvinen
2025-11-18 13:05     ` Werner Sembach
2025-11-18 11:31 ` [PATCH 0/6] Start of Upstream Support for TUXEDO NB02 devices Armin Wolf
2025-11-18 13:17   ` Werner Sembach
2025-11-18 13:42     ` Armin Wolf
2025-11-18 14:24       ` Werner Sembach
2025-11-18 13:42   ` Werner Sembach
2025-11-18 13:43     ` Armin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2d5d88fe-cd54-4311-b5cd-b1c435ff973d@gmx.de \
    --to=w_armin@gmx.de \
    --cc=hansg@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=wse@tuxedocomputers.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox