From: Werner Sembach <wse@tuxedocomputers.com>
To: Armin Wolf <W_Armin@gmx.de>,
ilpo.jarvinen@linux.intel.com, hdegoede@redhat.com,
chumuzero@gmail.com, corbet@lwn.net, cs@tuxedo.de,
ggo@tuxedocomputers.com
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
platform-driver-x86@vger.kernel.org, rdunlap@infradead.org,
alok.a.tiwari@oracle.com, linux-leds@vger.kernel.org,
lee@kernel.org, pobrn@protonmail.com
Subject: Re: [PATCH v3 1/2] platform/x86: Add Uniwill laptop driver
Date: Wed, 3 Sep 2025 19:08:14 +0200 [thread overview]
Message-ID: <003d760c-0314-4ea2-b2b5-860021e0daf8@tuxedocomputers.com> (raw)
In-Reply-To: <20250831192708.9654-2-W_Armin@gmx.de>
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).
> +
> + /* 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
next prev parent reply other threads:[~2025-09-03 17:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-31 19:27 [PATCH v3 0/2] Add support for Uniwill laptop features Armin Wolf
2025-08-31 19:27 ` [PATCH v3 1/2] platform/x86: Add Uniwill laptop driver Armin Wolf
2025-09-03 17:08 ` Werner Sembach [this message]
2025-09-05 18:46 ` Armin Wolf
2025-09-09 8:49 ` Werner Sembach
2025-09-18 21:20 ` Armin Wolf
2025-09-22 15:57 ` Werner Sembach
2025-09-05 14:05 ` Werner Sembach
2025-09-08 16:29 ` Armin Wolf
2025-09-09 9:18 ` Werner Sembach
2025-09-09 19:13 ` Werner Sembach
2025-09-18 21:25 ` Armin Wolf
2025-09-22 16:03 ` Werner Sembach
2025-08-31 19:27 ` [PATCH v3 2/2] Documentation: laptops: Add documentation for uniwill laptops 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=003d760c-0314-4ea2-b2b5-860021e0daf8@tuxedocomputers.com \
--to=wse@tuxedocomputers.com \
--cc=W_Armin@gmx.de \
--cc=alok.a.tiwari@oracle.com \
--cc=chumuzero@gmail.com \
--cc=corbet@lwn.net \
--cc=cs@tuxedo.de \
--cc=ggo@tuxedocomputers.com \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=lee@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=pobrn@protonmail.com \
--cc=rdunlap@infradead.org \
/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
all inboxes | Powered by JetHome®