linux-kernel - Re: [PATCH v3 1/2] platform/x86: Add Uniwill laptop driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c2f0b7ec-f409-41d5-9407-f5a2b43311f4@gmx.de>
Date: Thu, 18 Sep 2025 23:20:36 +0200
From: Armin Wolf <W_Armin@....de>
To: Werner Sembach <wse@...edocomputers.com>, ilpo.jarvinen@...ux.intel.com,
 hdegoede@...hat.com, chumuzero@...il.com, corbet@....net, cs@...edo.de,
 ggo@...edocomputers.com
Cc: linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 platform-driver-x86@...r.kernel.org, rdunlap@...radead.org,
 alok.a.tiwari@...cle.com, linux-leds@...r.kernel.org, lee@...nel.org,
 pobrn@...tonmail.com
Subject: Re: [PATCH v3 1/2] platform/x86: Add Uniwill laptop driver

Am 09.09.25 um 10:49 schrieb Werner Sembach:

>
> Am 05.09.25 um 20:46 schrieb Armin Wolf:
>> Am 03.09.25 um 19:08 schrieb Werner Sembach:
>>
>>> Hi,
>>>
>>> started to look into the driver regarding TUXEDO NB02 devices 
>>> support, starting with the FN-Keys:
>>>
>>> Am 31.08.25 um 21:27 schrieb Armin Wolf:
>>>> +static const struct key_entry uniwill_keymap[] = {
>>>> +    /* Reported via keyboard controller */
>>>> +    { KE_IGNORE,    UNIWILL_OSD_CAPSLOCK, { KEY_CAPSLOCK }},
>>>> +    { KE_IGNORE,    UNIWILL_OSD_NUMLOCK, { KEY_NUMLOCK }},
>>>> +
>>>> +    /* Reported when the user locks/unlocks the super key */
>>>> +    { KE_IGNORE,    UNIWILL_OSD_SUPER_KEY_LOCK_ENABLE, { 
>>>> KEY_UNKNOWN }},
>>>> +    { KE_IGNORE,    UNIWILL_OSD_SUPER_KEY_LOCK_DISABLE, { 
>>>> KEY_UNKNOWN }},
>>>
>>> Can you also add
>>>
>>> { KE_IGNORE,    UNIWILL_OSD_SUPER_KEY_LOCK_CHANGED,     { 
>>> KEY_UNKNOWN }},
>>>
>>> ?
>>>
>>> UNIWILL_OSD_SUPER_KEY_LOCK_ENABLE and 
>>> UNIWILL_OSD_SUPER_KEY_LOCK_DISABLE are always sent in pair 
>>> with UNIWILL_OSD_SUPER_KEY_LOCK_CHANGED (at least on my test device) 
>>> and without this line an unknown key event is generated (as that is 
>>> not explicitly marked as KE_IGNORE without the line).
>>
>> OK.
> I found more similar cases that probably don't happen on your devices, 
> but i will just create a patch once this got merged. I think that will 
> be easier.

Alright, but i will still include UNIWILL_OSD_SUPER_KEY_LOCK_CHANGED inside the next revision.

Thanks,
Armin Wolf

>>
>>>
>>>> +
>>>> +    /* Reported in manual mode when toggling the airplane mode 
>>>> status */
>>>> +    { KE_KEY,       UNIWILL_OSD_RFKILL, { KEY_RFKILL }},
>>>> +
>>>> +    /* Reported when user wants to cycle the platform profile */
>>>> +    { KE_IGNORE,    UNIWILL_OSD_PERFORMANCE_MODE_TOGGLE, { 
>>>> KEY_UNKNOWN }},
>>> This is a physical button on the gaming devices from Uniwill, my 
>>> suggestion would be to bind it to F14 (because another ODM has a 
>>> very similar key that already sends F14 by default) and then let 
>>> userspace handle it (KDE for example has energy profiles that could 
>>> be bound to it).
>>>> +
>>>> +    /* Reported when the user wants to adjust the brightness of 
>>>> the keyboard */
>>>> +    { KE_KEY,       UNIWILL_OSD_KBDILLUMDOWN, { KEY_KBDILLUMDOWN }},
>>>> +    { KE_KEY,       UNIWILL_OSD_KBDILLUMUP, { KEY_KBDILLUMUP }},
>>>> +
>>>> +    /* Reported when the user wants to toggle the microphone mute 
>>>> status */
>>>> +    { KE_KEY,       UNIWILL_OSD_MIC_MUTE, { KEY_MICMUTE }},
>>>> +
>>>> +    /* 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 }},
>>>> +
>>>> +    /* FIXME: find out the exact meaning of those events */
>>>> +    { KE_IGNORE,    UNIWILL_OSD_BAT_CHARGE_FULL_24_H, { 
>>>> KEY_UNKNOWN }},
>>>> +    { KE_IGNORE,    UNIWILL_OSD_BAT_ERM_UPDATE, { KEY_UNKNOWN }},
>>>> +
>>>> +    /* Reported when the user wants to toggle the benchmark mode 
>>>> status */
>>>> +    { KE_IGNORE,    UNIWILL_OSD_BENCHMARK_MODE_TOGGLE, { 
>>>> KEY_UNKNOWN }},
>>>> +
>>>> +    { KE_END }
>>>> +};
>>>
>>> Any reason for still having KEY_* defines even on the ignored 
>>> events? Looking at other drivers KE_IGNORE events usually don't have 
>>> it.
>>>
>>> Best regards,
>>>
>>> Werner
>>
>> I decided to ignore UNIWILL_OSD_FN_LOCK because i do not know if the 
>> Fn + Esc key presses are filtered by the EC or also received by the OS.
>
> Sorry for the misunderstanding.
>
> What i meant was: Why is it for example
>
> { KE_IGNORE,    UNIWILL_OSD_FN_LOCK,                    { KEY_FN_ESC }},
>
> and
>
> { KE_IGNORE,    UNIWILL_OSD_BENCHMARK_MODE_TOGGLE,      { KEY_UNKNOWN }},
>
> instead of just
>
> { KE_IGNORE,    UNIWILL_OSD_FN_LOCK},
>
> and
>
> { KE_IGNORE,    UNIWILL_OSD_BENCHMARK_MODE_TOGGLE},
>
> ?
>
The FN lock definition does map to a standard keycode, so i wanted to use KEY_FN_ESC
if this key definition is used in the future. The other usages of KEY_UNKNOWN exist
because i wanted to ensure that all field of the key definitions are properly initialized.

Thanks,
Armin Wolf

>>
>> Thanks,
>> Armin Wolf
>>
>