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.
+
+ /* 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},
?
Thanks,
Armin Wolf
