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

[Werner Sembach]

Am 18.09.25 um 23:20 schrieb Armin Wolf:
> 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.
ack
> 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