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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


+
+    /* 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.

Thanks,
Armin Wolf





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux