* Re: [PATCH v2] platform/x86: Add WMI driver for Redmibook keyboard.
From: Gladyshev Ilya @ 2025-07-30 17:37 UTC (permalink / raw)
To: Armin Wolf
Cc: linux-input, nikita.nikita.krasnov, Hans de Goede,
Ilpo Järvinen, linux-kernel, platform-driver-x86
In-Reply-To: <8e7f2cde-f068-4696-8298-f83619dfaf76@gmx.de>
Thx for review
On 7/30/25 19:33, Armin Wolf wrote:
>> +
>> + if (obj->type != ACPI_TYPE_BUFFER) {
>> + dev_err(&wdev->dev, "Bad response type %u\n", obj->type);
>> + return;
>> + }
>> +
>> + if (obj->buffer.length != 32) {
>
> Please also accept oversized buffers.
>
Sorry if this is a stupid question, but isn't any size other than 32 a
sign of a firmware bug?
>> +
>> + /* AI key quirk */
>> + if (entry->keycode == KEY_ASSISTANT) {
>> + value = !(payload & AI_KEY_VALUE_MASK);
>
> I would rather check the payload for 0x00011901 here.
Personally I prefer to think about it as "some value encoded in payload"
rather than "is it AI button release payload?", because in the latter
case alternatives are more unclear. It's just a preference, btw, would
fix if you insist.
--
Gladyshev Ilya
^ permalink raw reply
* Re: [PATCH 1/1] Add WMI driver for Redmibook keyboard.
From: Armin Wolf @ 2025-07-30 16:35 UTC (permalink / raw)
To: Gladyshev Ilya
Cc: Hans de Goede, Ilpo Järvinen, linux-kernel,
platform-driver-x86, Nikita Krasnov, Dmitry Torokhov,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...
In-Reply-To: <b9a06c17-c18d-4ff1-b020-9eea505a6f41@foxido.dev>
Am 29.07.25 um 10:37 schrieb Gladyshev Ilya:
> On 7/29/25 00:47, Armin Wolf wrote:
>> Am 28.07.25 um 00:34 schrieb Gladyshev Ilya:
>>
>>> This driver implements support for various Fn keys (like Cut) and
>>> Xiaomi
>>> specific AI button.
>>
>> Interesting, i was just talking with another person about
>> implementing a WMI event
>> driver for the exact same WMI event device. I CCed the person
>> involved in the discussion
>> so that he can test this driver on his device as well.
>> All in all the driver looks promising, but there are still things
>> that need to be improved
>> before we can include this driver in the mainline kernel. For details
>> see below.
> Thanks for your feedback, will fix in v2. However, I have small
> question: do I still need a mutex for linearizability if I implement
> driver via sparse-keymap? I've copied mutex from xiaomi-wmi, but as I
> looked up not all WMI keyboard drivers use it (fujitsu-laptop, acer-wmi).
>
Yes, the mutex is still necessary unless the event handler itself is already protected by some sort of locking. Many older WMI driver are not using a mutex for legacy reasons, but new drivers should.
Thanks,
Armin Wolf
> --
> Gladyshev Ilya
>
^ permalink raw reply
* Re: [PATCH v2] platform/x86: Add WMI driver for Redmibook keyboard.
From: Armin Wolf @ 2025-07-30 16:33 UTC (permalink / raw)
To: Gladyshev Ilya
Cc: linux-input, nikita.nikita.krasnov, Hans de Goede,
Ilpo Järvinen, linux-kernel, platform-driver-x86
In-Reply-To: <20250729190528.8446-1-foxido@foxido.dev>
Am 29.07.25 um 21:05 schrieb Gladyshev Ilya:
> This driver implements support for various Fn keys (like Cut) and Xiaomi
> specific AI button.
>
> Signed-off-by: Gladyshev Ilya <foxido@foxido.dev>
> ---
>
> Changes from v1:
> - Use sparse-keymap instead of manual matching
> - Fix GUID case so it actually autoloads
> - Other fixes from v1 review
>
> Link to v1: https://lore.kernel.org/platform-driver-x86/20250727223516.29244-1-foxido@foxido.dev/
>
> ---
> MAINTAINERS | 6 ++
> drivers/platform/x86/Kconfig | 11 +++
> drivers/platform/x86/Makefile | 1 +
> drivers/platform/x86/redmi-wmi.c | 129 +++++++++++++++++++++++++++++++
> 4 files changed, 147 insertions(+)
> create mode 100644 drivers/platform/x86/redmi-wmi.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c0b444e5fd5a..eb25fb10e751 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20965,6 +20965,12 @@ S: Maintained
> T: git https://github.com/pkshih/rtw.git
> F: drivers/net/wireless/realtek/rtw89/
>
> +REDMIBOOK WMI DRIVERS
> +M: Gladyshev Ilya <foxido@foxido.dev>
> +L: platform-driver-x86@vger.kernel.org
> +S: Maintained
> +F: drivers/platform/x86/redmi-wmi.c
> +
> REDPINE WIRELESS DRIVER
> L: linux-wireless@vger.kernel.org
> S: Orphan
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index e5cbd58a99f3..3c570cb398d3 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -109,6 +109,17 @@ config XIAOMI_WMI
> To compile this driver as a module, choose M here: the module will
> be called xiaomi-wmi.
>
> +config REDMI_WMI
> + tristate "Redmibook WMI key driver"
> + depends on ACPI_WMI
> + depends on INPUT
Please also select INPUT_SPARSEKMAP.
> + help
> + Say Y here if you want support for WMI-based hotkey events on
> + Xiaomi Redmibook devices.
> +
> + To compile this driver as a module, choose M here: the module will
> + be called redmi-wmi.
> +
> config GIGABYTE_WMI
> tristate "Gigabyte WMI temperature driver"
> depends on ACPI_WMI
> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> index bea87a85ae75..406dd0807ba7 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_HUAWEI_WMI) += huawei-wmi.o
> obj-$(CONFIG_MXM_WMI) += mxm-wmi.o
> obj-$(CONFIG_NVIDIA_WMI_EC_BACKLIGHT) += nvidia-wmi-ec-backlight.o
> obj-$(CONFIG_XIAOMI_WMI) += xiaomi-wmi.o
> +obj-$(CONFIG_REDMI_WMI) += redmi-wmi.o
> obj-$(CONFIG_GIGABYTE_WMI) += gigabyte-wmi.o
>
> # Acer
> diff --git a/drivers/platform/x86/redmi-wmi.c b/drivers/platform/x86/redmi-wmi.c
> new file mode 100644
> index 000000000000..732688fb94e0
> --- /dev/null
> +++ b/drivers/platform/x86/redmi-wmi.c
> @@ -0,0 +1,129 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* WMI driver for Xiaomi Redmibooks */
> +
> +#include <linux/acpi.h>
> +#include <linux/device.h>
> +#include <linux/input.h>
> +#include <linux/input/sparse-keymap.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/unaligned.h>
> +#include <linux/wmi.h>
> +
> +#include <uapi/linux/input-event-codes.h>
> +
> +#define WMI_REDMIBOOK_KEYBOARD_EVENT_GUID "46C93E13-EE9B-4262-8488-563BCA757FEF"
> +
> +#define AI_KEY_VALUE_MASK 0x00000100
> +
> +static const struct key_entry redmi_wmi_keymap[] = {
> + {KE_KEY, 0x00000201, {KEY_SELECTIVE_SCREENSHOT}},
> + {KE_KEY, 0x00000301, {KEY_ALL_APPLICATIONS}},
> + {KE_KEY, 0x00001b01, {KEY_SETUP}},
> +
> + /* AI button has code for each position */
> + {KE_KEY, 0x00011801, {KEY_ASSISTANT}},
> + {KE_KEY, 0x00011901, {KEY_ASSISTANT}},
> +
> + /* Keyboard backlight */
> + {KE_IGNORE, 0x00000501, {}},
> + {KE_IGNORE, 0x00800501, {}},
> + {KE_IGNORE, 0x00050501, {}},
> + {KE_IGNORE, 0x000a0501, {}},
> +
> + {KE_END}
> +};
> +
> +struct redmi_wmi {
> + struct input_dev *input_dev;
> + /* Protects the key event sequence */
> + struct mutex key_lock;
> +};
> +
> +static int redmi_wmi_probe(struct wmi_device *wdev, const void *context)
> +{
> + struct redmi_wmi *data;
> + int err;
> +
> + /* Init dev */
> + data = devm_kzalloc(&wdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + dev_set_drvdata(&wdev->dev, data);
> +
> + err = devm_mutex_init(&wdev->dev, &data->key_lock);
> + if (err)
> + return err;
> +
> + /* Setup input device */
> + data->input_dev = devm_input_allocate_device(&wdev->dev);
> + if (!data->input_dev)
> + return -ENOMEM;
> + data->input_dev->name = "Redmibook WMI keys";
> + data->input_dev->phys = "wmi/input0";
> +
> + err = sparse_keymap_setup(data->input_dev, redmi_wmi_keymap, NULL);
> + if (err)
> + return err;
> +
> + return input_register_device(data->input_dev);
> +}
> +
> +static void redmi_wmi_notify(struct wmi_device *wdev, union acpi_object *obj)
> +{
> + struct redmi_wmi *data = dev_get_drvdata(&wdev->dev);
> + int value = 1;
> + bool autorelease = true;
Please order the variable declarations using reverse xmas tree order.
> +
> + if (obj->type != ACPI_TYPE_BUFFER) {
> + dev_err(&wdev->dev, "Bad response type %u\n", obj->type);
> + return;
> + }
> +
> + if (obj->buffer.length != 32) {
Please also accept oversized buffers.
> + dev_err(&wdev->dev, "Invalid buffer length %u\n", obj->buffer.length);
> + return;
> + }
> +
> + /* For linearizability */
> + guard(mutex)(&data->key_lock);
> +
> + u32 payload = get_unaligned_le32(obj->buffer.pointer);
> + struct key_entry *entry = sparse_keymap_entry_from_scancode(data->input_dev, payload);
> +
> + if (!entry) {
> + dev_dbg(&wdev->dev, "Unknown WMI event with payload %u", payload);
> + return;
> + }
> +
> + /* AI key quirk */
> + if (entry->keycode == KEY_ASSISTANT) {
> + value = !(payload & AI_KEY_VALUE_MASK);
I would rather check the payload for 0x00011901 here.
Thanks,
Armin Wolf
> + autorelease = false;
> + }
> +
> + sparse_keymap_report_entry(data->input_dev, entry, value, autorelease);
> +}
> +
> +static const struct wmi_device_id redmi_wmi_id_table[] = {
> + { .guid_string = WMI_REDMIBOOK_KEYBOARD_EVENT_GUID },
> + { }
> +};
> +
> +static struct wmi_driver redmi_wmi_driver = {
> + .driver = {
> + .name = "redmi-wmi",
> + .probe_type = PROBE_PREFER_ASYNCHRONOUS
> + },
> + .id_table = redmi_wmi_id_table,
> + .probe = redmi_wmi_probe,
> + .notify = redmi_wmi_notify,
> + .no_singleton = true,
> +};
> +module_wmi_driver(redmi_wmi_driver);
> +
> +MODULE_DEVICE_TABLE(wmi, redmi_wmi_id_table);
> +MODULE_AUTHOR("Gladyshev Ilya <foxido@foxido.dev>");
> +MODULE_DESCRIPTION("Redmibook WMI driver");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: mfd: Add power-button option for TI TPS6594 PMIC
From: Markus Schneider-Pargmann @ 2025-07-30 13:52 UTC (permalink / raw)
To: Michael Walle, Jon Cormier, Jerome Neanne
Cc: Job Sava, Krzysztof Kozlowski, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Julien Panis, Dmitry Torokhov,
devicetree, linux-kernel, linux-input
In-Reply-To: <DBHJ1S8MTSA2.35ZZDZFQGFNB1@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2176 bytes --]
Hi,
I think my mail wasn't sent properly, so here we go again:
On Mon Jul 21, 2025 at 8:42 AM CEST, Michael Walle wrote:
> [+ Jerome and Markus ]
>
> Hi,
>
>> > > > Someone knowing the device should come with arguments whether
>> > > > other states for this are useful at all. Or not useful and then argument
>> > > > that in commit msg for example.
>> > > The other states are not useful for the kernel. Only the push button
>> > > has a need for an interrupt handler. The other states the PMIC handles
>> > > on its own.
>> > >
>> > > What exactly do you want me to change?
>> >
>> > Because the driver isn't setting the configuration anyway, wouldn't
>> > it be possible to read the config bits (Register 0x3c, bits 7-6) to
>> > figure out whether the pin is configured as power-button instead of
>> > having this property?
>> >
>> > I mean, the correct config is likely stored in the NVM anyway, and
>> > reconfiguring it to another value seems unlikely.
>> Currently, the TPS MFD driver only loads the power button driver if
>> the flag is set. We could put that discovery code in the MFD driver,
>> but what if the system designer doesn't want the power button driver?
>
> The device tree is not for configuration. The designer can just
> ignore the input event in that case.
>
>> I'm not sure auto detecting it makes sense.
>
> Why?
>
>> We are basing this on the other TI PMIC drivers and how they are
>> configured. I'm not sure I want to reinvent the wheel, so to speak.
>
> That was never a good reason. Maybe there was a reason for the
> TPS65219. Markus? Jerome? I haven't found anything in the commit
> messages or cover letters. Only that it is "optional". Not sure what
> that means. According to the TPS65219 datasheet, that pin if not
> used shall be configured as EN and be connected to VSYS.
I don't think the TPS65219 has a config register to detect if the pin is
a power-button that's why a devicetree description was necessary.
Looking at it now, it should probably have been an enum for TPS65219. It
is not relevant to any software but it is not describing the
configuration fully.
Best
Markus
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [PATCH] x86/Mouse: thinkpad_acpi/Trackpoint: Trackpoint Doubletap handling
From: Pavel Machek @ 2025-07-30 10:55 UTC (permalink / raw)
To: Vishnu Sankar
Cc: pali, dmitry.torokhov, hmh, hansg, ilpo.jarvinen, tglx, mingo,
jon_xie, jay_lee, zhoubinbin, linux-input, linux-kernel,
ibm-acpi-devel, platform-driver-x86, vsankar, Mark Pearson
In-Reply-To: <20250620004209.28250-1-vishnuocv@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 665 bytes --]
On Fri 2025-06-20 09:42:08, Vishnu Sankar wrote:
> Newer ThinkPads have a doubletap feature that needs to be turned
> ON/OFF via the trackpoint registers.
> Systems released from 2023 have doubletap disabled by default and
> need the feature enabling to be useful.
>
> This patch introduces support for exposing and controlling the
> trackpoint doubletap feature via a sysfs attribute.
> /sys/devices/platform/thinkpad_acpi/tp_doubletap
> This can be toggled by an "enable" or a "disable".
sysfs attributes need documentation.
Pavel
--
I don't work for Nazis and criminals, and neither should you.
Boycott Putin, Trump, and Musk!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH] Input: max77693 - Convert to atomic pwm operation
From: Uwe Kleine-König @ 2025-07-29 20:04 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Dzmitry Sankouski, Marek Szyprowski, Krzysztof Kozlowski,
linux-input, linux-pwm
In-Reply-To: <sl3jqe36dfxfzblposdtkvlgalc4ydixpqkfmn7gc6hcjfwmqn@7bex3mxwjqyy>
[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]
Hello Dmitry,
On Wed, Jul 02, 2025 at 08:02:33AM +0200, Uwe Kleine-König wrote:
> On Tue, Jul 01, 2025 at 11:06:50AM -0700, Dmitry Torokhov wrote:
> > On Tue, Jul 01, 2025 at 07:49:22AM +0200, Uwe Kleine-König wrote:
> > >
> > > I had something like that at first, but didn't like it. With that
> > > approach you have two places that have to know how to set the PWM's
> > > duty_cycle. Also I think the control flow is more complicated.
> > >
> > > I considered renaming max77693_haptic_enable() to something that better
> > > matches what it does in my variant, but max77693_haptic_configure() was
> > > already taken.
> > >
> > > But that might all be subjective? If you like your version better,
> > > that's fine, it still gets rid of pwm_config(), pwm_enable() and
> > > pwm_apply_args() which is my main objective.
> >
> > Yes, I agree that it is subjective. I know that you do not quite like
> > the version I posted, still will you be OK if it is attributed to you?
>
> Yes, feel free to apply it as you suggested.
As of today's next that didn't happen. Do you have this patch still on
your radar?
This is the last driver making use of pwm_config(), it would be great to
get rid of that.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v2] platform/x86: Add WMI driver for Redmibook keyboard.
From: Gladyshev Ilya @ 2025-07-29 19:05 UTC (permalink / raw)
To: foxido
Cc: w_armin, linux-input, nikita.nikita.krasnov, Hans de Goede,
Ilpo Järvinen, linux-kernel, platform-driver-x86
This driver implements support for various Fn keys (like Cut) and Xiaomi
specific AI button.
Signed-off-by: Gladyshev Ilya <foxido@foxido.dev>
---
Changes from v1:
- Use sparse-keymap instead of manual matching
- Fix GUID case so it actually autoloads
- Other fixes from v1 review
Link to v1: https://lore.kernel.org/platform-driver-x86/20250727223516.29244-1-foxido@foxido.dev/
---
MAINTAINERS | 6 ++
drivers/platform/x86/Kconfig | 11 +++
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/redmi-wmi.c | 129 +++++++++++++++++++++++++++++++
4 files changed, 147 insertions(+)
create mode 100644 drivers/platform/x86/redmi-wmi.c
diff --git a/MAINTAINERS b/MAINTAINERS
index c0b444e5fd5a..eb25fb10e751 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20965,6 +20965,12 @@ S: Maintained
T: git https://github.com/pkshih/rtw.git
F: drivers/net/wireless/realtek/rtw89/
+REDMIBOOK WMI DRIVERS
+M: Gladyshev Ilya <foxido@foxido.dev>
+L: platform-driver-x86@vger.kernel.org
+S: Maintained
+F: drivers/platform/x86/redmi-wmi.c
+
REDPINE WIRELESS DRIVER
L: linux-wireless@vger.kernel.org
S: Orphan
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index e5cbd58a99f3..3c570cb398d3 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -109,6 +109,17 @@ config XIAOMI_WMI
To compile this driver as a module, choose M here: the module will
be called xiaomi-wmi.
+config REDMI_WMI
+ tristate "Redmibook WMI key driver"
+ depends on ACPI_WMI
+ depends on INPUT
+ help
+ Say Y here if you want support for WMI-based hotkey events on
+ Xiaomi Redmibook devices.
+
+ To compile this driver as a module, choose M here: the module will
+ be called redmi-wmi.
+
config GIGABYTE_WMI
tristate "Gigabyte WMI temperature driver"
depends on ACPI_WMI
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index bea87a85ae75..406dd0807ba7 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_HUAWEI_WMI) += huawei-wmi.o
obj-$(CONFIG_MXM_WMI) += mxm-wmi.o
obj-$(CONFIG_NVIDIA_WMI_EC_BACKLIGHT) += nvidia-wmi-ec-backlight.o
obj-$(CONFIG_XIAOMI_WMI) += xiaomi-wmi.o
+obj-$(CONFIG_REDMI_WMI) += redmi-wmi.o
obj-$(CONFIG_GIGABYTE_WMI) += gigabyte-wmi.o
# Acer
diff --git a/drivers/platform/x86/redmi-wmi.c b/drivers/platform/x86/redmi-wmi.c
new file mode 100644
index 000000000000..732688fb94e0
--- /dev/null
+++ b/drivers/platform/x86/redmi-wmi.c
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: GPL-2.0
+/* WMI driver for Xiaomi Redmibooks */
+
+#include <linux/acpi.h>
+#include <linux/device.h>
+#include <linux/input.h>
+#include <linux/input/sparse-keymap.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/unaligned.h>
+#include <linux/wmi.h>
+
+#include <uapi/linux/input-event-codes.h>
+
+#define WMI_REDMIBOOK_KEYBOARD_EVENT_GUID "46C93E13-EE9B-4262-8488-563BCA757FEF"
+
+#define AI_KEY_VALUE_MASK 0x00000100
+
+static const struct key_entry redmi_wmi_keymap[] = {
+ {KE_KEY, 0x00000201, {KEY_SELECTIVE_SCREENSHOT}},
+ {KE_KEY, 0x00000301, {KEY_ALL_APPLICATIONS}},
+ {KE_KEY, 0x00001b01, {KEY_SETUP}},
+
+ /* AI button has code for each position */
+ {KE_KEY, 0x00011801, {KEY_ASSISTANT}},
+ {KE_KEY, 0x00011901, {KEY_ASSISTANT}},
+
+ /* Keyboard backlight */
+ {KE_IGNORE, 0x00000501, {}},
+ {KE_IGNORE, 0x00800501, {}},
+ {KE_IGNORE, 0x00050501, {}},
+ {KE_IGNORE, 0x000a0501, {}},
+
+ {KE_END}
+};
+
+struct redmi_wmi {
+ struct input_dev *input_dev;
+ /* Protects the key event sequence */
+ struct mutex key_lock;
+};
+
+static int redmi_wmi_probe(struct wmi_device *wdev, const void *context)
+{
+ struct redmi_wmi *data;
+ int err;
+
+ /* Init dev */
+ data = devm_kzalloc(&wdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ dev_set_drvdata(&wdev->dev, data);
+
+ err = devm_mutex_init(&wdev->dev, &data->key_lock);
+ if (err)
+ return err;
+
+ /* Setup input device */
+ data->input_dev = devm_input_allocate_device(&wdev->dev);
+ if (!data->input_dev)
+ return -ENOMEM;
+ data->input_dev->name = "Redmibook WMI keys";
+ data->input_dev->phys = "wmi/input0";
+
+ err = sparse_keymap_setup(data->input_dev, redmi_wmi_keymap, NULL);
+ if (err)
+ return err;
+
+ return input_register_device(data->input_dev);
+}
+
+static void redmi_wmi_notify(struct wmi_device *wdev, union acpi_object *obj)
+{
+ struct redmi_wmi *data = dev_get_drvdata(&wdev->dev);
+ int value = 1;
+ bool autorelease = true;
+
+ if (obj->type != ACPI_TYPE_BUFFER) {
+ dev_err(&wdev->dev, "Bad response type %u\n", obj->type);
+ return;
+ }
+
+ if (obj->buffer.length != 32) {
+ dev_err(&wdev->dev, "Invalid buffer length %u\n", obj->buffer.length);
+ return;
+ }
+
+ /* For linearizability */
+ guard(mutex)(&data->key_lock);
+
+ u32 payload = get_unaligned_le32(obj->buffer.pointer);
+ struct key_entry *entry = sparse_keymap_entry_from_scancode(data->input_dev, payload);
+
+ if (!entry) {
+ dev_dbg(&wdev->dev, "Unknown WMI event with payload %u", payload);
+ return;
+ }
+
+ /* AI key quirk */
+ if (entry->keycode == KEY_ASSISTANT) {
+ value = !(payload & AI_KEY_VALUE_MASK);
+ autorelease = false;
+ }
+
+ sparse_keymap_report_entry(data->input_dev, entry, value, autorelease);
+}
+
+static const struct wmi_device_id redmi_wmi_id_table[] = {
+ { .guid_string = WMI_REDMIBOOK_KEYBOARD_EVENT_GUID },
+ { }
+};
+
+static struct wmi_driver redmi_wmi_driver = {
+ .driver = {
+ .name = "redmi-wmi",
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS
+ },
+ .id_table = redmi_wmi_id_table,
+ .probe = redmi_wmi_probe,
+ .notify = redmi_wmi_notify,
+ .no_singleton = true,
+};
+module_wmi_driver(redmi_wmi_driver);
+
+MODULE_DEVICE_TABLE(wmi, redmi_wmi_id_table);
+MODULE_AUTHOR("Gladyshev Ilya <foxido@foxido.dev>");
+MODULE_DESCRIPTION("Redmibook WMI driver");
+MODULE_LICENSE("GPL");
--
2.50.0
^ permalink raw reply related
* Re: Re [PATCH v11 0/4] Firmware Support for USB-HID Devices and CP2112
From: Danny Kaehn @ 2025-07-29 17:49 UTC (permalink / raw)
To: Willie Thai
Cc: andriy.shevchenko, bartosz.golaszewski, bentiss, devicetree,
dmitry.torokhov, ethan.twardy, jikos, krzk+dt, linux-input, robh,
tingkaic, rastekar, dkodihalli, mhn, arundp
In-Reply-To: <20250729145350.3538324-1-wthai@nvidia.com>
On Tue, Jul 29, 2025 at 02:53:50PM +0000, Willie Thai wrote:
> Hi Danny,
>
> I hope this message finds you well.
> Thank you for the patch set — it’s exactly what we need for the I2C-over-USB feature in our new products.
> Could you please let us know when we can expect the next version of the patch set?
> If you've paused work on it, we're happy to take over and continue from where you left off.
>
> Thanks!
Thanks for reaching out!
Apologies, I haven't been working on this in a while, and have only been able
to intermittently return to attempt to bring it forward.
Feel free to take over and move this forward! I'm not sure what the protocol
is for that, as far as changelogs and versions and whatnot. If your product's
timeline for needing this mainlined is not urgent; however, I can prioritize
coming back to this and having a v12 submitted, likely by the end of next
week, to remove the overhead needed for you to assume ownership of the
patchset.
The last several versions of this patchset have all revolved around trying
to get this change working for ACPI as well as DeviceTree in such a way which
make the ACPI and DeviceTree interface/binding acceptable to their respective
maintainers. With this latest version, it seemed that there was not going to
be any consensus between the two firmware languages, so it seemed an entirely
different binding/interface and corresponding logic in the device driver
would be needed. This seems unfortunate, as it seemed the whole purpose of
the fwnode / device_*() functions was to unify the driver interface to the
firmware language used... but this is presumably a special case, being almost
exclusively a device composed of different generic device functions...
Let me know if you plan to take this over and if there's any
documentation/context/test procedures you would need from me; else I would be
happy to start moving this forward again now that there is someone waiting
on it.
Thanks
Danny Kaehn
^ permalink raw reply
* Re [PATCH v11 0/4] Firmware Support for USB-HID Devices and CP2112
From: Willie Thai @ 2025-07-29 14:53 UTC (permalink / raw)
To: danny.kaehn
Cc: andriy.shevchenko, bartosz.golaszewski, bentiss, devicetree,
dmitry.torokhov, ethan.twardy, jikos, krzk+dt, linux-input, robh,
tingkaic, rastekar, dkodihalli, mhn, arundp
In-Reply-To: <20240605-cp2112-dt-v11-0-d55f0f945a62@plexus.com>
Hi Danny,
I hope this message finds you well.
Thank you for the patch set — it’s exactly what we need for the I2C-over-USB feature in our new products.
Could you please let us know when we can expect the next version of the patch set?
If you've paused work on it, we're happy to take over and continue from where you left off.
Thanks!
^ permalink raw reply
* Re: [PATCH 1/1] Add WMI driver for Redmibook keyboard.
From: Nikita Krasnov @ 2025-07-29 13:10 UTC (permalink / raw)
To: Armin Wolf, Gladyshev Ilya
Cc: Hans de Goede, Ilpo Järvinen, linux-kernel,
platform-driver-x86, Dmitry Torokhov,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...
In-Reply-To: <2aa477f3-526e-4b06-826a-83f95633c040@gmx.de>
[-- Attachment #1.1: Type: text/plain, Size: 449 bytes --]
On Tue, Jul 29, 2025 at 12:47:57AM +0300 Armin Wolf wrote:
> "Say Y here if you want support for WMI-based hotkey events on Xiaomi Redmi devices."
I think it should be "Xiaomi Redmibook" instead. "Xiaomi Redmi" is
associated with mobiles devices. See Google Images for example of this:
[1] and [2].
[1]: https://www.google.com/search?q=xiaomi+redmi&udm=2
[2]: https://www.google.com/search?q=xiaomi+redmibook&udm=2
--
Nikita Krasnov
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* [PATCH][next] Input: lm8323: Remove space before newline
From: Colin Ian King @ 2025-07-29 11:31 UTC (permalink / raw)
To: Dmitry Torokhov, Krzysztof Kozlowski, linux-input
Cc: kernel-janitors, linux-kernel
There is an extraneous space before a newline in a dev_err message.
Remove it
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
---
drivers/input/keyboard/lm8323.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/lm8323.c b/drivers/input/keyboard/lm8323.c
index e19442c6f80f..d9df10484755 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -259,7 +259,7 @@ static void process_keys(struct lm8323_chip *lm)
ret = lm8323_read(lm, LM8323_CMD_READ_FIFO, key_fifo, LM8323_FIFO_LEN);
if (ret < 0) {
- dev_err(&lm->client->dev, "Failed reading fifo \n");
+ dev_err(&lm->client->dev, "Failed reading fifo\n");
return;
}
key_fifo[ret] = 0;
--
2.50.0
^ permalink raw reply related
* Re: [PATCH 1/1] Add WMI driver for Redmibook keyboard.
From: Gladyshev Ilya @ 2025-07-29 8:37 UTC (permalink / raw)
To: Armin Wolf
Cc: Hans de Goede, Ilpo Järvinen, linux-kernel,
platform-driver-x86, Nikita Krasnov, Dmitry Torokhov,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...
In-Reply-To: <2aa477f3-526e-4b06-826a-83f95633c040@gmx.de>
On 7/29/25 00:47, Armin Wolf wrote:
> Am 28.07.25 um 00:34 schrieb Gladyshev Ilya:
>
>> This driver implements support for various Fn keys (like Cut) and Xiaomi
>> specific AI button.
>
> Interesting, i was just talking with another person about implementing a
> WMI event
> driver for the exact same WMI event device. I CCed the person involved
> in the discussion
> so that he can test this driver on his device as well.
> All in all the driver looks promising, but there are still things that
> need to be improved
> before we can include this driver in the mainline kernel. For details
> see below.
Thanks for your feedback, will fix in v2. However, I have small
question: do I still need a mutex for linearizability if I implement
driver via sparse-keymap? I've copied mutex from xiaomi-wmi, but as I
looked up not all WMI keyboard drivers use it (fujitsu-laptop, acer-wmi).
--
Gladyshev Ilya
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: Add virtual GPIO input for VNC keyboard
From: Krzysztof Kozlowski @ 2025-07-29 7:52 UTC (permalink / raw)
To: marlonwu, robh, dmitry.torokhov, krzk+dt
Cc: linux-input, devicetree, MenglongWoo
In-Reply-To: <20250729064346.22834-3-marlonwu@126.com>
On 29/07/2025 08:43, marlonwu@126.com wrote:
> From: Menglong Wu <marlonwu@126.com>
>
> Implements a complete ANSI keyboard solution for VNC remote input
> on ARM devices by:
>
> 1. Adding a device tree include file (vnc-virtual-input.dtsi) that:
> - Defines a gpio-mockup controller with 104 virtual GPIOs
> (startingfrom 400)
> - Maps all standard keyboard keys
> (F1-F12, alphanumeric, modifiers, etc.)
> - Follows Linux input event codes for key mappings
>
> 2. Updating MAINTAINERS to track the new dtsi file
>
> The virtual GPIO approach allows embedded systems without physical
> keyboards to receive full keyboard input via VNC while avoiding
> conflicts with realGPIO numbering.
>
> Signed-off-by: Menglong Wu <marlonwu@126.com>
> ---
> MAINTAINERS | 1 +
> arch/arm/boot/dts/vnc-virtual-input.dtsi | 569 +++++++++++++++++++++++
This is a dead, no-op, impossible to test code.
Also, does not follow any upstream coding style.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/2] Register virtual GPIO keys for VNC
From: Krzysztof Kozlowski @ 2025-07-29 7:39 UTC (permalink / raw)
To: marlonwu, robh, dmitry.torokhov, krzk+dt
Cc: linux-input, devicetree, MenglongWoo
In-Reply-To: <20250729064346.22834-1-marlonwu@126.com>
On 29/07/2025 08:43, marlonwu@126.com wrote:
> From: Menglong Wu <marlonwu@126.com>
>
> Test platform
> -------------
> Kernel: 4.14.98
Really? That's ancient kernel.
We cannot take any of this. You need to rebase and test on patches on
the latest kernel. Not some ancient, buggy thing.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings vnc virtual input
From: Krzysztof Kozlowski @ 2025-07-29 7:33 UTC (permalink / raw)
To: marlonwu, robh, dmitry.torokhov, krzk+dt
Cc: linux-input, devicetree, MenglongWoo
In-Reply-To: <20250729064346.22834-2-marlonwu@126.com>
On 29/07/2025 08:43, marlonwu@126.com wrote:
> From: Menglong Wu <marlonwu@126.com>
Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
>
> Add documentation for virtual GPIO keys to enable full ANSI keyboard
> emulation via VNC on embedded devices without physical keyboards.
>
> - vnc-virtual-input.txt: Usage scenario and implementation details
> - vnc-virtual-input.yaml: Formal DT binding specification
> - MAINTAINERS: Add entry for VNC virtual input support
>
> The solution registers virtual GPIOs (starting from 400) to avoid conflicts
> with physical GPIOs while supporting standard Linux input codes.
>
> Signed-off-by: Menglong Wu <marlonwu@126.com>
> ---
> .../bindings/input/vnc-virtual-input.txt | 153 ++++++++++++++++++
> .../bindings/input/vnc-virtual-input.yaml | 86 ++++++++++
> MAINTAINERS | 7 +
> 3 files changed, 246 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/vnc-virtual-input.txt
We do not take txt bindings anymore, sorry.
> create mode 100644 Documentation/devicetree/bindings/input/vnc-virtual-input.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/vnc-virtual-input.txt b/Documentation/devicetree/bindings/input/vnc-virtual-input.txt
> new file mode 100644
> index 000000000000..77d12308c553
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/vnc-virtual-input.txt
> @@ -0,0 +1,153 @@
> +Register virtual GPIO keys for VNC
> +==========================
> +
> +# Purpose
> +
> +To emulate a full ANSI keyboard on embedded devices without physical
> +keyboards.The server responds to key events via x11vnc.
> +This resolves the limitation where embedded systems only register a few
> +GPIO keys, making them unable to process full keyboard inputs.
> +
> +documented in Documentation/devicetree/bindings/input/vnc-virtual-input.yaml
I don't understand the placement of this file in bindings. What are you
writing bindings for here?
> diff --git a/Documentation/devicetree/bindings/input/vnc-virtual-input.yaml b/Documentation/devicetree/bindings/input/vnc-virtual-input.yaml
> new file mode 100644
> index 000000000000..8b5414cb2bea
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/vnc-virtual-input.yaml
> @@ -0,0 +1,86 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: VNC Virtual GPIO Keys
> +
> +maintainers:
> + - Menglong Wu <marlonwu@126.com>
> +
> +description: |
> + This binding describes a virtual GPIO key input node for VNC remote
> + input.
Describe the hardware, not the binding...
> + It is based on the standard gpio-keys binding.
> +
> +select: false
> +
> +allOf:
> + - $ref: gpio-keys.yaml#
> +
> +properties:
> + compatible:
> + const: gpio-keys
So this is all completely redundant and not needed. Drop the bindings.
> +
> + status:
> + enum:
> + - okay
> + - disabled
Do you see any bindings with this?
Srsly, it's second bindings today. I think you send some AI slops to us.
Please confirm:
Did you use any AI tool to generate this file?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/2] dt-bindings vnc virtual input
From: marlonwu @ 2025-07-29 6:43 UTC (permalink / raw)
To: robh, dmitry.torokhov, krzk+dt
Cc: linux-input, devicetree, marlonwu, MenglongWoo
In-Reply-To: <20250729064346.22834-1-marlonwu@126.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 7929 bytes --]
From: Menglong Wu <marlonwu@126.com>
Add documentation for virtual GPIO keys to enable full ANSI keyboard
emulation via VNC on embedded devices without physical keyboards.
- vnc-virtual-input.txt: Usage scenario and implementation details
- vnc-virtual-input.yaml: Formal DT binding specification
- MAINTAINERS: Add entry for VNC virtual input support
The solution registers virtual GPIOs (starting from 400) to avoid conflicts
with physical GPIOs while supporting standard Linux input codes.
Signed-off-by: Menglong Wu <marlonwu@126.com>
---
.../bindings/input/vnc-virtual-input.txt | 153 ++++++++++++++++++
.../bindings/input/vnc-virtual-input.yaml | 86 ++++++++++
MAINTAINERS | 7 +
3 files changed, 246 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/vnc-virtual-input.txt
create mode 100644 Documentation/devicetree/bindings/input/vnc-virtual-input.yaml
diff --git a/Documentation/devicetree/bindings/input/vnc-virtual-input.txt b/Documentation/devicetree/bindings/input/vnc-virtual-input.txt
new file mode 100644
index 000000000000..77d12308c553
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/vnc-virtual-input.txt
@@ -0,0 +1,153 @@
+Register virtual GPIO keys for VNC
+==========================
+
+# Purpose
+
+To emulate a full ANSI keyboard on embedded devices without physical
+keyboards.The server responds to key events via x11vnc.
+This resolves the limitation where embedded systems only register a few
+GPIO keys, making them unable to process full keyboard inputs.
+
+documented in Documentation/devicetree/bindings/input/vnc-virtual-input.yaml
+
+# Scenario
+
+- /dev/input/event1: Physical GPIO buttons
+
+- /dev/input/event2: Physical touchscreen
+
+Assume my-pcb.dts defines two GPIO-based hardware keys (‘A’ and ‘B’).
+When the VNC server x11vnc is started, a remote PC connects via a VNC
+client and attempts to send key inputs.
+Since the Linux kernel only recognizes two keys, the UI on the embedded
+device only responds to ‘A’ and ‘B’.
+
+Start x11vnc server:
+
+```
+ x11vnc -noipv6 -rawfb /dev/fb0 -forever -clip 640x480+0+0 \
+ -pipeinput UINPUT:touch,tslib_cal=/etc/pointercal,\
+ direct_key=/dev/input/event1,\
+ direct_abs=/dev/input/event2
+```
+
+Monitor key events:
+
+```
+ hexdump /dev/input/event1
+```
+
+Check registered virtual GPIOs:
+
+```
+ mount -t debugfs none /sys/kernel/debug/
+ cat /sys/kernel/debug/gpio
+
+ gpiochip5: GPIOs 400-503, parent: platform/gpio_mockup_hw, gpio-mockup-A:
+ gpio-400 ( |vk_key_0 ) in lo
+ gpio-401 ( |vk_key_1 ) in lo
+```
+
+Original my-pcb.dts:
+
+
+```
+ gpio_keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ key-a {
+ label = "btn-key-a";
+ gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_A>;
+ };
+ key-b {
+ label = "btn-key-b";
+ gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_A>;
+ };
+ };
+```
+
+
+# Solution
+
+Modify my-pcb.dts to support a virtual ANSI keyboard:
+
+```
+ #include "vnc-virtual-input.dtsi"
+
+ // Originally, the DTS relied on physical GPIO keys
+ gpio_keys {
+ // Disable the original physical key node
+ status = "disable";
+ };
+
+ // The virtual GPIO DTS node now integrates physical GPIO
+ vnc_key {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ key-a {
+ label = "btn-key-a";
+ gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_A>;
+ };
+ key-b {
+ label = "btn-key-b";
+ gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_A>;
+ };
+ }
+```
+
+# Explanation
+
+A virtual GPIO driver gpio_mockup_hw is registered, providing 104 GPIOs,
+starting from number 400.
+
+The starting number (400) avoids conflicts with physical GPIOs on
+commercialSoCs, which typically do not exceed 400. Most SoC vendors also
+start GPIO numbering from 0 in their drivers.
+
+The gpio_key_mockup node defines 100 ANSI standard keyboard keys.
+
+Key codes (KEY_xx) follow the definitions in
+include/uapi/linux/input-event-codes.h.
+
+
+
+ANSI Keyboard Layout (Symbolic Representation):
+
+```
+L FFFFFFFFFFFFFFF MMM
+L NNNNNNNNNNNN R CCC PPPP
+LL AAAAAAAAA RRR CCC PPPP
+LLL AAAAAAA RRRR PPPP
+LLL AAAAA RRRRR C PPPP
+LLLL LLLLL RRRRR CCC PPPP
+```
+
+
+Key Layout Categories
+
+L: Left-side keys (ESC, TAB, CAPS LOCK, etc.)
+F: Function keys (F1–F12)
+N: Number row (1–0)
+A: Alphabet keys (A–Z)
+R: Right-side keys (BACKSPACE, [, ], , ENTER, etc.)
+M: Miscellaneous (Print Screen, Scroll Lock, Pause/Break)
+C: Cursor controls (Insert, Home, Arrow keys, etc.)
+P: Numpad keys (0–9, -, +, etc.)
+
+
+Example from vnc-virtual-input.dtsi:
+
+```
+ /* Left of a-z */
+ vk_78 {
+ label = "vk_key_78";
+ gpios = <&gpio_mockup_hw 78 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_ESC>;
+ };
+```
diff --git a/Documentation/devicetree/bindings/input/vnc-virtual-input.yaml b/Documentation/devicetree/bindings/input/vnc-virtual-input.yaml
new file mode 100644
index 000000000000..8b5414cb2bea
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/vnc-virtual-input.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VNC Virtual GPIO Keys
+
+maintainers:
+ - Menglong Wu <marlonwu@126.com>
+
+description: |
+ This binding describes a virtual GPIO key input node for VNC remote
+ input.
+ It is based on the standard gpio-keys binding.
+
+select: false
+
+allOf:
+ - $ref: gpio-keys.yaml#
+
+properties:
+ compatible:
+ const: gpio-keys
+
+ status:
+ enum:
+ - okay
+ - disabled
+
+patternProperties:
+ "^key(-)?[0-9a-zA-Z_-]+$":
+ type: object
+ properties:
+ label:
+ description: Descriptive name of the button
+ $ref: /schemas/types.yaml#/definitions/string
+
+ gpios:
+ maxItems: 1
+
+ linux,code:
+ description: Linux input event code
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ debounce-interval:
+ description: Debounce time in milliseconds
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ gpio-key,wakeup:
+ description: Enables wakeup function from suspend
+ type: boolean
+
+ required:
+ - label
+ - gpios
+ - linux,code
+
+additionalProperties: false
+
+required:
+ - compatible
+
+examples:
+ - |
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ test {
+ vnc_key: vnc_key {
+ compatible = "gpio-keys";
+
+ key-a {
+ label = "btn-key-a";
+ gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_A>;
+ };
+ key-b {
+ label = "btn-key-b";
+ gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_A>;
+ };
+ };
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index c0b444e5fd5a..658ef6619542 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27476,6 +27476,13 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
F: sound/pci/hda/patch_senarytech.c
+VNC VIRTUAL INPUT SUPPORT
+M: Menglong Wu <marlonwu@126.com>
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/input/vnc-virtual-input.txt
+F: Documentation/devicetree/bindings/input/vnc-virtual-input.yaml
+
THE REST
M: Linus Torvalds <torvalds@linux-foundation.org>
L: linux-kernel@vger.kernel.org
--
2.39.5
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: Add virtual GPIO input for VNC keyboard
From: marlonwu @ 2025-07-29 6:43 UTC (permalink / raw)
To: robh, dmitry.torokhov, krzk+dt
Cc: linux-input, devicetree, marlonwu, MenglongWoo
In-Reply-To: <20250729064346.22834-1-marlonwu@126.com>
From: Menglong Wu <marlonwu@126.com>
Implements a complete ANSI keyboard solution for VNC remote input
on ARM devices by:
1. Adding a device tree include file (vnc-virtual-input.dtsi) that:
- Defines a gpio-mockup controller with 104 virtual GPIOs
(startingfrom 400)
- Maps all standard keyboard keys
(F1-F12, alphanumeric, modifiers, etc.)
- Follows Linux input event codes for key mappings
2. Updating MAINTAINERS to track the new dtsi file
The virtual GPIO approach allows embedded systems without physical
keyboards to receive full keyboard input via VNC while avoiding
conflicts with realGPIO numbering.
Signed-off-by: Menglong Wu <marlonwu@126.com>
---
MAINTAINERS | 1 +
arch/arm/boot/dts/vnc-virtual-input.dtsi | 569 +++++++++++++++++++++++
2 files changed, 570 insertions(+)
create mode 100644 arch/arm/boot/dts/vnc-virtual-input.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index 658ef6619542..da69f516388c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27482,6 +27482,7 @@ L: linux-kernel@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/input/vnc-virtual-input.txt
F: Documentation/devicetree/bindings/input/vnc-virtual-input.yaml
+F: arch/arm/boot/dts/vnc-virtual-input.da9052_tsi
THE REST
M: Linus Torvalds <torvalds@linux-foundation.org>
diff --git a/arch/arm/boot/dts/vnc-virtual-input.dtsi b/arch/arm/boot/dts/vnc-virtual-input.dtsi
new file mode 100644
index 000000000000..2937623d4099
--- /dev/null
+++ b/arch/arm/boot/dts/vnc-virtual-input.dtsi
@@ -0,0 +1,569 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/*
+ * vnc-virtual-input.dtsi - Device tree file for x11vnc
+ *
+ * KEY_xx references can be found in input-event-codes.h
+ * See vnc-virtual-input.txt Documentation file for details.
+ *
+ * Copyright (C) 2025 Menglong Wu <marlonwu@126.com>
+ *
+ */
+
+
+gpio_mockup_hw: gpio_mockup_hw {
+ compatible = "gpio-mockup";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-base = <400>;
+ nr-gpios = <104>;
+ status = "okay";
+};
+
+vnc_key {
+ compatible = "gpio-keys";
+
+ /* F1 - F12 */
+ vk_0 {
+ label = "vk_key_0";
+ gpios = <&gpio_mockup_hw 0 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_F1>;
+ };
+ vk_1 {
+ label = "vk_key_1";
+ gpios = <&gpio_mockup_hw 1 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_F2>;
+ };
+ vk_2 {
+ label = "vk_key_2";
+ gpios = <&gpio_mockup_hw 2 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_F3>;
+ };
+ vk_3 {
+ label = "vk_key_3";
+ gpios = <&gpio_mockup_hw 3 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_F4>;
+ };
+ vk_4 {
+ label = "vk_key_4";
+ gpios = <&gpio_mockup_hw 4 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_F5>;
+ };
+ vk_5 {
+ label = "vk_key_5";
+ gpios = <&gpio_mockup_hw 5 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_F6>;
+ };
+ vk_6 {
+ label = "vk_key_6";
+ gpios = <&gpio_mockup_hw 6 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_F7>;
+ };
+ vk_7 {
+ label = "vk_key_7";
+ gpios = <&gpio_mockup_hw 7 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_F8>;
+ };
+ vk_8 {
+ label = "vk_key_8";
+ gpios = <&gpio_mockup_hw 8 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_F9>;
+ };
+ vk_9 {
+ label = "vk_key_9";
+ gpios = <&gpio_mockup_hw 9 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_F10>;
+ };
+ vk_10 {
+ label = "vk_key_10";
+ gpios = <&gpio_mockup_hw 10 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_F11>;
+ };
+ vk_11 {
+ label = "vk_key_11";
+ gpios = <&gpio_mockup_hw 11 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_F12>;
+ };
+
+ /* Number */
+ vk_12 {
+ label = "vk_key_12";
+ gpios = <&gpio_mockup_hw 12 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_1>;
+ };
+ vk_13 {
+ label = "vk_key_13";
+ gpios = <&gpio_mockup_hw 13 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_2>;
+ };
+ vk_14 {
+ label = "vk_key_14";
+ gpios = <&gpio_mockup_hw 14 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_3>;
+ };
+ vk_15 {
+ label = "vk_key_15";
+ gpios = <&gpio_mockup_hw 15 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_4>;
+ };
+ vk_16 {
+ label = "vk_key_16";
+ gpios = <&gpio_mockup_hw 16 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_5>;
+ };
+ vk_17 {
+ label = "vk_key_17";
+ gpios = <&gpio_mockup_hw 17 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_6>;
+ };
+ vk_18 {
+ label = "vk_key_18";
+ gpios = <&gpio_mockup_hw 18 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_7>;
+ };
+ vk_19 {
+ label = "vk_key_19";
+ gpios = <&gpio_mockup_hw 19 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_8>;
+ };
+ vk_20 {
+ label = "vk_key_20";
+ gpios = <&gpio_mockup_hw 20 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_9>;
+ };
+ vk_21 {
+ label = "vk_key_21";
+ gpios = <&gpio_mockup_hw 21 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_0>;
+ };
+
+
+ /* a - z */
+ vk_22 {
+ label = "vk_key_22";
+ gpios = <&gpio_mockup_hw 22 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_A>;
+ };
+ vk_23 {
+ label = "vk_key_23";
+ gpios = <&gpio_mockup_hw 23 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_B>;
+ };
+ vk_24 {
+ label = "vk_key_24";
+ gpios = <&gpio_mockup_hw 24 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_C>;
+ };
+ vk_25 {
+ label = "vk_key_25";
+ gpios = <&gpio_mockup_hw 25 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_D>;
+ };
+ vk_26 {
+ label = "vk_key_26";
+ gpios = <&gpio_mockup_hw 26 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_E>;
+ };
+ vk_27 {
+ label = "vk_key_27";
+ gpios = <&gpio_mockup_hw 27 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_F>;
+ };
+ vk_28 {
+ label = "vk_key_28";
+ gpios = <&gpio_mockup_hw 28 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_G>;
+ };
+ vk_29 {
+ label = "vk_key_29";
+ gpios = <&gpio_mockup_hw 29 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_H>;
+ };
+ vk_30 {
+ label = "vk_key_30";
+ gpios = <&gpio_mockup_hw 30 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_I>;
+ };
+ vk_31 {
+ label = "vk_key_31";
+ gpios = <&gpio_mockup_hw 31 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_J>;
+ };
+ vk_32 {
+ label = "vk_key_32";
+ gpios = <&gpio_mockup_hw 32 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_K>;
+ };
+ vk_33 {
+ label = "vk_key_33";
+ gpios = <&gpio_mockup_hw 33 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_L>;
+ };
+ vk_34 {
+ label = "vk_key_34";
+ gpios = <&gpio_mockup_hw 34 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_M>;
+ };
+ vk_35 {
+ label = "vk_key_35";
+ gpios = <&gpio_mockup_hw 35 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_N>;
+ };
+ vk_36 {
+ label = "vk_key_36";
+ gpios = <&gpio_mockup_hw 36 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_O>;
+ };
+ vk_37 {
+ label = "vk_key_37";
+ gpios = <&gpio_mockup_hw 37 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_P>;
+ };
+ vk_38 {
+ label = "vk_key_38";
+ gpios = <&gpio_mockup_hw 38 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_Q>;
+ };
+ vk_39 {
+ label = "vk_key_39";
+ gpios = <&gpio_mockup_hw 39 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_R>;
+ };
+ vk_40 {
+ label = "vk_key_40";
+ gpios = <&gpio_mockup_hw 40 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_S>;
+ };
+ vk_41 {
+ label = "vk_key_41";
+ gpios = <&gpio_mockup_hw 41 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_T>;
+ };
+ vk_42 {
+ label = "vk_key_42";
+ gpios = <&gpio_mockup_hw 42 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_U>;
+ };
+ vk_43 {
+ label = "vk_key_43";
+ gpios = <&gpio_mockup_hw 43 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_V>;
+ };
+ vk_44 {
+ label = "vk_key_44";
+ gpios = <&gpio_mockup_hw 44 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_W>;
+ };
+ vk_45 {
+ label = "vk_key_45";
+ gpios = <&gpio_mockup_hw 45 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_X>;
+ };
+ vk_46 {
+ label = "vk_key_46";
+ gpios = <&gpio_mockup_hw 46 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_Y>;
+ };
+ vk_47 {
+ label = "vk_key_47";
+ gpios = <&gpio_mockup_hw 47 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_Z>;
+ };
+
+
+ /* Misc */
+ vk_48 {
+ label = "vk_key_48";
+ gpios = <&gpio_mockup_hw 48 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_SYSRQ>;
+ };
+ vk_49 {
+ label = "vk_key_49";
+ gpios = <&gpio_mockup_hw 49 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_SCROLLLOCK>;
+ };
+ vk_50 {
+ label = "vk_key_50";
+ gpios = <&gpio_mockup_hw 50 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_PAUSE>;
+ };
+
+ /* Cursor Position */
+ vk_51 {
+ label = "vk_key_51";
+ gpios = <&gpio_mockup_hw 51 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_INSERT>;
+ };
+ vk_52 {
+ label = "vk_key_52";
+ gpios = <&gpio_mockup_hw 52 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_HOME>;
+ };
+ vk_53 {
+ label = "vk_key_53";
+ gpios = <&gpio_mockup_hw 53 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_PAGEUP>;
+ };
+
+ vk_54 {
+ label = "vk_key_54";
+ gpios = <&gpio_mockup_hw 54 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_DELETE>;
+ };
+ vk_55 {
+ label = "vk_key_55";
+ gpios = <&gpio_mockup_hw 55 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_END>;
+ };
+ vk_56 {
+ label = "vk_key_56";
+ gpios = <&gpio_mockup_hw 56 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_PAGEDOWN>;
+ };
+
+ vk_57 {
+ label = "vk_key_57";
+ gpios = <&gpio_mockup_hw 57 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_UP>;
+ };
+ vk_58 {
+ label = "vk_key_58";
+ gpios = <&gpio_mockup_hw 58 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_LEFT>;
+ };
+ vk_59 {
+ label = "vk_key_59";
+ gpios = <&gpio_mockup_hw 59 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_DOWN>;
+ };
+ vk_60 {
+ label = "vk_key_60";
+ gpios = <&gpio_mockup_hw 60 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_RIGHT>;
+ };
+
+
+ /* Numpad */
+ vk_61 {
+ label = "vk_key_61";
+ gpios = <&gpio_mockup_hw 61 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_NUMLOCK>;
+ };
+ vk_62 {
+ label = "vk_key_62";
+ gpios = <&gpio_mockup_hw 62 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KPSLASH>;
+ };
+ vk_63 {
+ label = "vk_key_63";
+ gpios = <&gpio_mockup_hw 63 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KPASTERISK>;
+ };
+ vk_64 {
+ label = "vk_key_64";
+ gpios = <&gpio_mockup_hw 64 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_MINUS>;
+ };
+ vk_65 {
+ label = "vk_key_65";
+ gpios = <&gpio_mockup_hw 65 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KPPLUS>;
+ };
+ vk_66 {
+ label = "vk_key_66";
+ gpios = <&gpio_mockup_hw 66 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KPENTER>;
+ };
+ vk_67 {
+ label = "vk_key_67";
+ gpios = <&gpio_mockup_hw 67 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KPDOT>;
+ };
+
+ vk_68 {
+ label = "vk_key_68";
+ gpios = <&gpio_mockup_hw 68 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KP0>;
+ };
+ vk_69 {
+ label = "vk_key_69";
+ gpios = <&gpio_mockup_hw 69 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KP1>;
+ };
+ vk_70 {
+ label = "vk_key_70";
+ gpios = <&gpio_mockup_hw 70 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KP2>;
+ };
+ vk_71 {
+ label = "vk_key_71";
+ gpios = <&gpio_mockup_hw 71 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KP3>;
+ };
+ vk_72 {
+ label = "vk_key_72";
+ gpios = <&gpio_mockup_hw 72 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KP4>;
+ };
+ vk_73 {
+ label = "vk_key_73";
+ gpios = <&gpio_mockup_hw 73 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KP5>;
+ };
+ vk_74 {
+ label = "vk_key_74";
+ gpios = <&gpio_mockup_hw 74 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KP6>;
+ };
+ vk_75 {
+ label = "vk_key_75";
+ gpios = <&gpio_mockup_hw 75 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KP7>;
+ };
+ vk_76 {
+ label = "vk_key_76";
+ gpios = <&gpio_mockup_hw 76 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KP8>;
+ };
+ vk_77 {
+ label = "vk_key_77";
+ gpios = <&gpio_mockup_hw 77 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_KP9>;
+ };
+
+ /* Left of a - z */
+ vk_78 {
+ label = "vk_key_78";
+ gpios = <&gpio_mockup_hw 78 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_ESC>;
+ };
+ vk_79 {
+ label = "vk_key_79";
+ gpios = <&gpio_mockup_hw 79 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_GRAVE>;
+ };
+ vk_80 {
+ label = "vk_key_80";
+ gpios = <&gpio_mockup_hw 80 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_TAB>;
+ };
+ vk_81 {
+ label = "vk_key_81";
+ gpios = <&gpio_mockup_hw 81 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_CAPSLOCK>;
+ };
+ vk_82 {
+ label = "vk_key_82";
+ gpios = <&gpio_mockup_hw 82 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_LEFTSHIFT>;
+ };
+ vk_83 {
+ label = "vk_key_83";
+ gpios = <&gpio_mockup_hw 83 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_LEFTCTRL>;
+ };
+ vk_84 {
+ label = "vk_key_84";
+ gpios = <&gpio_mockup_hw 84 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_LEFTMETA>;
+ };
+ vk_85 {
+ label = "vk_key_85";
+ gpios = <&gpio_mockup_hw 85 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_LEFTALT>;
+ };
+ vk_86 {
+ label = "vk_key_86";
+ gpios = <&gpio_mockup_hw 86 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_SPACE>;
+ };
+
+ /* Right of a - z */
+ vk_87 {
+ label = "vk_key_87";
+ gpios = <&gpio_mockup_hw 87 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_MINUS>;
+ };
+ vk_88 {
+ label = "vk_key_88";
+ gpios = <&gpio_mockup_hw 88 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_EQUAL>;
+ };
+ vk_89 {
+ label = "vk_key_89";
+ gpios = <&gpio_mockup_hw 89 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_BACKSPACE>;
+ };
+ vk_90 {
+ label = "vk_key_90";
+ gpios = <&gpio_mockup_hw 90 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_LEFTBRACE>;
+ };
+ vk_91 {
+ label = "vk_key_91";
+ gpios = <&gpio_mockup_hw 91 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_RIGHTBRACE>;
+ };
+ vk_92 {
+ label = "vk_key_92";
+ gpios = <&gpio_mockup_hw 92 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_BACKSLASH>;
+ };
+
+ vk_93 {
+ label = "vk_key_93";
+ gpios = <&gpio_mockup_hw 93 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_SEMICOLON>;
+ };
+ vk_94 {
+ label = "vk_key_94";
+ gpios = <&gpio_mockup_hw 94 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_APOSTROPHE>;
+ };
+ vk_95 {
+ label = "vk_key_95";
+ gpios = <&gpio_mockup_hw 95 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_ENTER>;
+ };
+
+ vk_96 {
+ label = "vk_key_96";
+ gpios = <&gpio_mockup_hw 96 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_COMMA>;
+ };
+ vk_97 {
+ label = "vk_key_97";
+ gpios = <&gpio_mockup_hw 97 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_DOT>;
+ };
+ vk_98 {
+ label = "vk_key_98";
+ gpios = <&gpio_mockup_hw 98 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_SLASH>;
+ };
+ vk_99 {
+ label = "vk_key_99";
+ gpios = <&gpio_mockup_hw 99 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_RIGHTSHIFT>;
+ };
+
+ vk_100 {
+ label = "vk_key_100";
+ gpios = <&gpio_mockup_hw 100 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_RIGHTALT>;
+ };
+ vk_101 {
+ label = "vk_key_101";
+ gpios = <&gpio_mockup_hw 101 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_RIGHTMETA>;
+ };
+ vk_102 {
+ label = "vk_key_102";
+ gpios = <&gpio_mockup_hw 102 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_COMPOSE>;
+ };
+ vk_103 {
+ label = "vk_key_103";
+ gpios = <&gpio_mockup_hw 103 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_RIGHTCTRL>;
+ };
+};
--
2.39.5
^ permalink raw reply related
* [PATCH 0/2] Register virtual GPIO keys for VNC
From: marlonwu @ 2025-07-29 6:43 UTC (permalink / raw)
To: robh, dmitry.torokhov, krzk+dt
Cc: linux-input, devicetree, marlonwu, MenglongWoo
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 2964 bytes --]
From: Menglong Wu <marlonwu@126.com>
Test platform
-------------
Kernel: 4.14.98
Rootfs: BusyBox 1.29
QT: 4.7
x11vnc: 0.9.16
Purpose
-------------
To emulate a full ANSI keyboard on embedded devices without physical
keyboards.
The server responds to key events via x11vnc.
This resolves the limitation where embedded systems only register a few
GPIO keys, making them unable to process full keyboard inputs.
documented in Documentation/devicetree/bindings/input/vnc-virtual-input.yaml
Scenario
-------------
- /dev/input/event1: Physical GPIO buttons
- /dev/input/event2: Physical touchscreen
Assume my-pcb.dts defines two GPIO-based hardware keys (A and B).
When the VNC server x11vnc is started, a remote PC connects via a VNC
client and attempts to send key inputs.
Since the Linux kernel only recognizes two keys, the UI on the embedded
device only responds to ‘A’ and ‘B’.
Start x11vnc server:
```
x11vnc -noipv6 -rawfb /dev/fb0 -forever -clip 640x480+0+0 \
-pipeinput UINPUT:touch,tslib_cal=/etc/pointercal,\
direct_key=/dev/input/event1,\
direct_abs=/dev/input/event2
```
Monitor key events:
```
hexdump /dev/input/event1
```
Original my-pcb.dts:
```
gpio_keys {
compatible = "gpio-keys";
pinctrl-0 = <&pinctrl_gpio_keys>;
key-a {
label = "btn-key-a";
gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
linux,code = <KEY_A>;
};
key-b {
label = "btn-key-b";
gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
linux,code = <KEY_A>;
};
};
```
Solution
-------------
Modify my-pcb.dts to support a virtual ANSI keyboard:
```
#include "vnc-virtual-input.dtsi"
// Originally, the DTS relied on physical GPIO keys
gpio_keys {
// Disable the original physical key node
status = "disable";
};
// The virtual GPIO DTS node now integrates physical GPIO
vnc_key {
compatible = "gpio-keys";
pinctrl-0 = <&pinctrl_gpio_keys>;
key-a {
label = "btn-key-a";
gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
linux,code = <KEY_A>;
};
key-b {
label = "btn-key-b";
gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
linux,code = <KEY_A>;
};
}
```
Menglong Wu (2):
dt-bindings vnc virtual input
ARM: dts: Add virtual GPIO input for VNC keyboard
.../bindings/input/vnc-virtual-input.txt | 153 +++++
.../bindings/input/vnc-virtual-input.yaml | 86 +++
MAINTAINERS | 8 +
arch/arm/boot/dts/vnc-virtual-input.dtsi | 569 ++++++++++++++++++
4 files changed, 816 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/vnc-virtual-input.txt
create mode 100644 Documentation/devicetree/bindings/input/vnc-virtual-input.yaml
create mode 100644 arch/arm/boot/dts/vnc-virtual-input.dtsi
--
2.39.5
^ permalink raw reply
* Re: [PATCH 1/1] Add WMI driver for Redmibook keyboard.
From: Armin Wolf @ 2025-07-28 21:47 UTC (permalink / raw)
To: Gladyshev Ilya
Cc: Hans de Goede, Ilpo Järvinen, linux-kernel,
platform-driver-x86, Nikita Krasnov, Dmitry Torokhov,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...
In-Reply-To: <20250727223516.29244-1-foxido@foxido.dev>
Am 28.07.25 um 00:34 schrieb Gladyshev Ilya:
> This driver implements support for various Fn keys (like Cut) and Xiaomi
> specific AI button.
Interesting, i was just talking with another person about implementing a WMI event
driver for the exact same WMI event device. I CCed the person involved in the discussion
so that he can test this driver on his device as well.
All in all the driver looks promising, but there are still things that need to be improved
before we can include this driver in the mainline kernel. For details see below.
Also please CC the linux input mailing list in the future so that they can give feedback as well.
> Signed-off-by: Gladyshev Ilya <foxido@foxido.dev>
> ---
> MAINTAINERS | 6 ++
> drivers/platform/x86/Kconfig | 10 ++
> drivers/platform/x86/Makefile | 1 +
> drivers/platform/x86/redmi-wmi.c | 164 +++++++++++++++++++++++++++++++
> 4 files changed, 181 insertions(+)
> create mode 100644 drivers/platform/x86/redmi-wmi.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 10850512c118..b3956f3d2eb8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20965,6 +20965,12 @@ S: Maintained
> T: git https://github.com/pkshih/rtw.git
> F: drivers/net/wireless/realtek/rtw89/
>
> +REDMIBOOK WMI DRIVERS
> +M: Gladyshev Ilya <foxido@foxido.dev>
> +L: platform-driver-x86@vger.kernel.org
> +S: Maintained
> +F: drivers/platform/x86/redmi-wmi.c
> +
> REDPINE WIRELESS DRIVER
> L: linux-wireless@vger.kernel.org
> S: Orphan
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index e5cbd58a99f3..b8d426e6b5a3 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -109,6 +109,16 @@ config XIAOMI_WMI
> To compile this driver as a module, choose M here: the module will
> be called xiaomi-wmi.
>
> +config REDMI_WMI
> + tristate "Redmibook WMI key driver"
> + depends on ACPI_WMI
> + depends on INPUT
> + help
> + Say Y here if you want to support WMI-based keys on Redmibooks.
"Say Y here if you want support for WMI-based hotkey events on Xiaomi Redmi devices."
> +
> + To compile this driver as a module, choose M here: the module will
> + be called redmi-wmi.
> +
> config GIGABYTE_WMI
> tristate "Gigabyte WMI temperature driver"
> depends on ACPI_WMI
> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> index abbc2644ff6d..56903d7408cd 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_HUAWEI_WMI) += huawei-wmi.o
> obj-$(CONFIG_MXM_WMI) += mxm-wmi.o
> obj-$(CONFIG_NVIDIA_WMI_EC_BACKLIGHT) += nvidia-wmi-ec-backlight.o
> obj-$(CONFIG_XIAOMI_WMI) += xiaomi-wmi.o
> +obj-$(CONFIG_REDMI_WMI) += redmi-wmi.o
> obj-$(CONFIG_GIGABYTE_WMI) += gigabyte-wmi.o
>
> # Acer
> diff --git a/drivers/platform/x86/redmi-wmi.c b/drivers/platform/x86/redmi-wmi.c
> new file mode 100644
> index 000000000000..0bb6ea7b1081
> --- /dev/null
> +++ b/drivers/platform/x86/redmi-wmi.c
> @@ -0,0 +1,164 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* WMI driver for Xiaomi Redmibooks */
> +
> +#include <linux/acpi.h>
> +#include <linux/device.h>
> +#include <linux/input.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/wmi.h>
> +
> +#include <uapi/linux/input-event-codes.h>
> +
> +#define WMI_REDMIBOOK_KEYBOARD_EVENT_GUID "46c93e13-ee9b-4262-8488-563bca757fef"
> +
> +/* Supported WMI keys ... */
> +#define ACPI_CUT_PAYLOAD 0x00000201
> +#define ACPI_ALL_APPS_PAYLOAD 0x00000301
> +#define ACPI_SETUP_PAYLOAD 0x00001b01
> +#define ACPI_CST_KEY_PRESS_PAYLOAD 0x00011801
> +#define ACPI_CST_KEY_RELEASE_PAYLOAD 0x00011901
> +
> +/* ... and their mappings */
> +#define WMI_CUT_KEY KEY_PROG1
> +#define WMI_ALL_APPS_KEY KEY_ALL_APPLICATIONS
> +#define WMI_SETUP_KEY KEY_SETUP
> +#define WMI_CST_KEY KEY_ASSISTANT
> +
Why not using sparse-keymap for this?
> +/* Keyboard backlight key (not supported yet) */
> +#define BACKLIGHT_LEVEL_0_PAYLOAD 0x00000501
> +#define BACKLIGHT_LEVEL_1_PAYLOAD 0x00800501
> +#define BACKLIGHT_LEVEL_2_PAYLOAD 0x00050501
> +#define BACKLIGHT_LEVEL_3_PAYLOAD 0x000a0501
> +
> +struct redmi_wmi {
> + struct input_dev *input_dev;
> + /* Protects the key event sequence */
> + struct mutex key_lock;
> +};
> +
> +static void redmi_mutex_destroy(void *data)
> +{
> + struct mutex *lock = data;
> +
> + mutex_destroy(lock);
> +}
> +
> +static int redmi_wmi_probe(struct wmi_device *wdev, const void *context)
> +{
> + struct redmi_wmi *data;
> + int ret;
> +
> + /* Init dev */
> + data = devm_kzalloc(&wdev->dev, sizeof(struct redmi_wmi), GFP_KERNEL);
sizeof(struct redmi_wmi) -> sizeof(*data)
> + if (!data)
> + return -ENOMEM;
> +
> + dev_set_drvdata(&wdev->dev, data);
> +
> + /* Init mutex & setup destroy at exit */
> + mutex_init(&data->key_lock);
> + ret = devm_add_action_or_reset(&wdev->dev, redmi_mutex_destroy, &data->key_lock);
> + if (ret < 0)
> + return ret;
Please use devm_mutex_init() instead. You can also drop the comment then.
> +
> + /* Setup input device */
> + data->input_dev = devm_input_allocate_device(&wdev->dev);
> + if (!data->input_dev)
> + return -ENOMEM;
> + data->input_dev->name = "Redmibook WMI keys";
> + data->input_dev->phys = "wmi/input0";
> +
> + set_bit(EV_KEY, data->input_dev->evbit);
> +
> + /* "Cut" key*/
> + set_bit(WMI_CUT_KEY, data->input_dev->keybit);
> + /* "All apps" key*/
> + set_bit(WMI_ALL_APPS_KEY, data->input_dev->keybit);
> + /* "Settings" key */
> + set_bit(WMI_SETUP_KEY, data->input_dev->keybit);
> + /* Custom (AI?) key */
> + set_bit(WMI_CST_KEY, data->input_dev->keybit);
Please use sparse-keymap for setting up all of this.
> +
> + return input_register_device(data->input_dev);
> +}
> +
> +static void press_and_release_key(struct input_dev *dev, unsigned int code)
> +{
> + input_report_key(dev, code, 1);
> + input_sync(dev);
> + input_report_key(dev, code, 0);
> + input_sync(dev);
> +}
Using sparse-keymap would allow you to drop this function and instead rely on the autorelease
functionality of sparse-keymap instead.
> +
> +static void redmi_wmi_notify(struct wmi_device *wdev, union acpi_object *obj)
> +{
> + struct redmi_wmi *data = dev_get_drvdata(&wdev->dev);
> +
> + if (obj->type != ACPI_TYPE_BUFFER) {
> + dev_err(&wdev->dev, "Bad response type %u\n", obj->type);
> + return;
> + }
> +
> + if (obj->buffer.length < 4) {
> + dev_err(&wdev->dev, "Invalid buffer length %u\n", obj->buffer.length);
> + return;
> + }
The MOF description of the WMI event looks like this:
class WMIEvent : __ExtrinsicEvent {
};
[WMI, Dynamic, Provider("WmiProv"), Locale("MS\\0x40A"), Description("Root/WMI/HID_EVENT20"), guid("{46c93e13-ee9b-4262-8488-563bca757fef}")]
class HID_EVENT20 : WmiEvent {
[key, read] string InstanceName;
[read] boolean Active;
[WmiDataId(1), read, write, Description("Package Data")] uint8 EventDetail[32];
};
As you can see the buffer should contain at least 32 bytes. Please check this even when you are only using the
first 4 bytes as some WMI events might return fewer than 32 bytes of data in order to signal a firmware error.
> +
> + /* For linearizability */
> + guard(mutex)(&data->key_lock);
> +
> + u32 payload = ((u32 *)obj->buffer.pointer)[0];
Please use get_unaligned_le32() from linux/unaligned.h as the buffer might not
be properly aligned for 32 bit integers.
> +
> + switch (payload) {
> + case ACPI_CUT_PAYLOAD:
> + press_and_release_key(data->input_dev, WMI_CUT_KEY);
> + break;
> + case ACPI_ALL_APPS_PAYLOAD:
> + press_and_release_key(data->input_dev, WMI_ALL_APPS_KEY);
> + break;
> + case ACPI_SETUP_PAYLOAD:
> + press_and_release_key(data->input_dev, WMI_SETUP_KEY);
> + break;
> + case ACPI_CST_KEY_PRESS_PAYLOAD:
> + input_report_key(data->input_dev, WMI_CST_KEY, 1);
> + input_sync(data->input_dev);
> + break;
> + case ACPI_CST_KEY_RELEASE_PAYLOAD:
> + input_report_key(data->input_dev, WMI_CST_KEY, 0);
> + input_sync(data->input_dev);
> + break;
> + case BACKLIGHT_LEVEL_0_PAYLOAD:
> + case BACKLIGHT_LEVEL_1_PAYLOAD:
> + case BACKLIGHT_LEVEL_2_PAYLOAD:
> + case BACKLIGHT_LEVEL_3_PAYLOAD:
> + pr_debug("keyboard backlight WMI event, no action");
> + break;
> + default:
> + pr_debug("unsupported Redmibook WMI event with 4byte payload %u", payload);
Please use dev_dbg() here. Also using sparse-keymap would allow you to skip all of this and
instead let the input subsystem do the matching.
> + break;
> + }
> +}
> +
> +static const struct wmi_device_id redmi_wmi_id_table[] = {
> + { .guid_string = WMI_REDMIBOOK_KEYBOARD_EVENT_GUID },
> + /* Terminating entry */
Pointless commit, please remove.
Thanks,
Armin Wolf
> + { }
> +};
> +
> +static struct wmi_driver redmi_wmi_driver = {
> + .driver = {
> + .name = "redmi-wmi",
> + .probe_type = PROBE_PREFER_ASYNCHRONOUS
> + },
> + .id_table = redmi_wmi_id_table,
> + .probe = redmi_wmi_probe,
> + .notify = redmi_wmi_notify,
> + .no_singleton = true,
> +};
> +module_wmi_driver(redmi_wmi_driver);
> +
> +MODULE_DEVICE_TABLE(wmi, redmi_wmi_id_table);
> +MODULE_AUTHOR("Gladyshev Ilya <foxido@foxido.dev>");
> +MODULE_DESCRIPTION("Redmibook WMI driver");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: Missing ACPI driver for a keyboard button in Xiaomi RedmiBook Pro 16
From: Armin Wolf @ 2025-07-28 21:22 UTC (permalink / raw)
To: Nikita Krasnov, linux-acpi, linux-input, platform-driver-x86,
linux, fengwk94
In-Reply-To: <103ed888-ec6c-4b46-b03e-f2803850eec2@gmail.com>
Am 28.07.25 um 01:36 schrieb Nikita Krasnov:
>> No, it is because your device is using a different WMI interface for delivering events. Device manufacturers
>> are not exactly known for using the same WMI interfaces for a long time :(.
> By the way, how would we call this driver? xiaomi-2-wmi?
Another user just submitted a WMI driver for this WMI event device called "redmi-wmi". I think that
name sounds good enough.
>> Personally i have no problem with you writing a WMI driver in Rust, but currently we have
>> no suitable bindings for the WMI driver API. Additionally i am currently designing a new
>> WMI driver API that will make it easier to implement the necessary Rust bindings, so the
>> whole thing might take some time.
> Well, I am fine with having to implement the missing Rust bindings — no
> problem there. I was actually looking forward to it. But if the API's
> going to change... Oof.
>
> * Would the API change be _that_ drastic?
Not really. Basically all usages of acpi_object would be replaced with a struct wmi_buffer that
acts like a sized buffer containing binary data. The big changes happen inside the underlying
WMI subsystem itself.
> * Do you have any expectations on when would that API be released?
I plan to submit the patch series in a couple of weeks, but it might take some time before said
patch series is accepted upstream.
> * Would the new API deprecate the previous one?
Yes, but the old API would not be removed until all existing drivers have migrated to the new API.
> Maybe I could do this in Rust right now and then simply update the
> bindings to the new API? That way it would be possible to write the
> driver in Rust. If the API is going to change — the C code would have to
> be updated either way, right? Maybe updating C driver versus updating
> Rust bindings+driver is not that big of a difference. What do you think?
The old API uses a data structure called acpi_object that might be difficult to safely
use inside Rust, so only developing bindings for the new API would avoid this.
> I doubt there are going to be so many Rust WMI users that it would get
> really difficult to move anyone to the bindings with a new API..? How
> active is the WMI submodule (is it actually a submodule or just a
> component of ACPI) really is?
The WMI submodule itself is not that active, but the drivers using it are different in that regard.
>> Would it be possible for you to implement the WMI driver in C?
> Yea, absolutely! I'm totally fine with writing this in C. I just really
> don't want to miss the opportunity to use Rust here (is it's actually
> feasible)!
Since another user recently submitted a WMI driver for the WMI event device in question i suggest
that you instead focus on bringing this driver into the mainline kernel. You could for example test
this driver on your device and report back if everything works.
Thanks,
Armin Wolf
> --
> Nikita Krasnov
^ permalink raw reply
* Re: [PATCH 1/2] input: Add tracepoint support
From: Mathieu Desnoyers @ 2025-07-28 13:53 UTC (permalink / raw)
To: WangYuli, Steven Rostedt
Cc: dmitry.torokhov, guanwentao, linux-input, linux-kernel,
linux-trace-kernel, mhiramat, niecheng1, wangyuli, zhanjun,
Winston Wen
In-Reply-To: <921F8D487468018A+141227fc-070d-4ed9-8828-d446236eccd2@uniontech.com>
On 2025-07-28 03:07, WangYuli wrote:
> Hi Mathieu,
>
> On 2025/7/23 09:24, Mathieu Desnoyers wrote:
>> I've always been worried about adding tracepoint instrumentation of the
>> input subsystem that includes the actual keystrokes into the event
>> payload. What I'm trying to avoid here is people leaking their password
>> by mistake just because they happened to record a trace while
>> typing on their keyboard.
>>
> The evtest tool can also do this.
>
> However, it doesn't fully report all events from the input subsystem.
>
> From a debugging perspective, adding tracepoints to the input subsystem
> is still more convenient for debugging.
>
>> I don't mind if this gets enabled with a new kernel command line
>> options "tracing_leak_my_credentials=yes" or such, but I'd try to
>> avoid making it easy to enable by mistake unless this information
>> is specifically needed.
>>
> I'm not sure if this is over-engineering...
>
> I feel that adding too many command-line parameters will increase the
> user's cognitive load.
>
> However, the leakage of keyboard input records is indeed a very, very
> significant risk.
>
> As a compromise, would it be better if we added a separate Kconfig
> option specifically for the input subsystem's tracepoints to decide
> whether to enable them at compile time, and then documented the
> potential risks within that Kconfig's description?
In term of mechanism to select keylogger enabling/disabling, I can
think of the following options:
- Kconfig option,
- kernel command line parameter,
- sysctl
Here is a possibly incomplete list of desiderata for this:
- Keylogger should be disabled by default.
- System administrator should be able to enable keylogger at boot.
- Users should be able to query the state of keylogger
(enabled/disabled) during kernel execution, and this should be
invariant until reboot,
- Selecting whether this option is enabled or not should be decided
by the system administrator, not by the distribution vendors who
compile the distro kernels.
- Prevent use of a kernel tracer as a keylogger by mistake without
having the system administrator explicitly enable keylogging.
The most flexible approach would be a sysctl, because it would allow
a system administrator to enable this while the system runs. But it
is somewhat redundant with the fact that the tracers allow disabling
specific events dynamically. Also I don't think we would want to allow
changing this configuration after system boots, so users interacting
with a production system can check whether this is enabled or not to
learn whether they can trust that this keylogger feature is disabled.
This leaves Kconfig option and kernel command line. The downside of the
Kconfig option is that it requires to choose the configuration up
front for a distro kernel, not allowing the system admin to select
the behavior at boot time without recompiling a custom kernel.
This leaves the kernel command line option, which I think is a
good tradeoff. It allows sysadmins to enable keylogging at boot
from a distro kernel without recompiling their own kernel. It
also prevents enabling keylogging in a production system by
mistake after bootup. It allows users to inspect the status of
this knob by looking at the kernel command line to know whether
they are interacting with a system that has this keylogging
enabled.
Thoughts ?
Thanks,
Mathieu
>> But maybe I'm being too careful and people should really learn not
>> to share kernel traces with others.
>>
>> Thoughts ?
>>
> Thanks,
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply
* Re: [PATCH 1/2] input: Add tracepoint support
From: WangYuli @ 2025-07-28 7:07 UTC (permalink / raw)
To: Mathieu Desnoyers, Steven Rostedt
Cc: dmitry.torokhov, guanwentao, linux-input, linux-kernel,
linux-trace-kernel, mhiramat, niecheng1, wangyuli, zhanjun,
Winston Wen
In-Reply-To: <2b31b238-667e-47b9-b61f-76832a1f77a7@efficios.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 1490 bytes --]
Hi Mathieu,
On 2025/7/23 09:24, Mathieu Desnoyers wrote:
> I've always been worried about adding tracepoint instrumentation of the
> input subsystem that includes the actual keystrokes into the event
> payload. What I'm trying to avoid here is people leaking their password
> by mistake just because they happened to record a trace while
> typing on their keyboard.
>
The evtest tool can also do this.
However, it doesn't fully report all events from the input subsystem.
From a debugging perspective, adding tracepoints to the input subsystem
is still more convenient for debugging.
> I don't mind if this gets enabled with a new kernel command line
> options "tracing_leak_my_credentials=yes" or such, but I'd try to
> avoid making it easy to enable by mistake unless this information
> is specifically needed.
>
I'm not sure if this is over-engineering...
I feel that adding too many command-line parameters will increase the
user's cognitive load.
However, the leakage of keyboard input records is indeed a very, very
significant risk.
As a compromise, would it be better if we added a separate Kconfig
option specifically for the input subsystem's tracepoints to decide
whether to enable them at compile time, and then documented the
potential risks within that Kconfig's description?
> But maybe I'm being too careful and people should really learn not
> to share kernel traces with others.
>
> Thoughts ?
>
Thanks,
--
WangYuli
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 645 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] input: Add tracepoint support
From: WangYuli @ 2025-07-28 6:51 UTC (permalink / raw)
To: Steven Rostedt
Cc: dmitry.torokhov, guanwentao, linux-input, linux-kernel,
linux-trace-kernel, mathieu.desnoyers, mhiramat, niecheng1,
wangyuli, zhanjun, Winston Wen
In-Reply-To: <20250722202551.1614f59a@gandalf.local.home>
[-- Attachment #1.1.1: Type: text/plain, Size: 1308 bytes --]
Hi Steve,
On 2025/7/23 08:25, Steven Rostedt wrote:
>> + TP_STRUCT__entry(__string(name, dev->name ?: "unknown") __field(
>> + unsigned int, type) __field(unsigned int, code)
>> + __field(int, value) __field(u16, bustype)
>> + __field(u16, vendor)
>> + __field(u16, product)),
>> +
> The contents of the tracepoints in the subsystems are determined by the
> subsystem maintainers, but please follow the tracepoint formatting. The
> above is horrible. It should look like a structure layout. One wouldn't
> write:
>
> struct entry { char *name;
> unsigned int type; unsigned int code;
> int value; u16 bustype;
> u16 vendor;
> u16 product; };
>
> That's what the above looks like. It should be instead:
>
> TP_STRUCT__entry(
> __string( name, dev->name ?: "unknown" )
> __field( unsigned int, type )
> __field( unsigned int, code )
> __field( int, value )
> __field( u16, bustype )
> __field( u16, vendor )
> __field( u16, product )
> ),
>
> So the fields can be easily visible and easily reviewed.
My apologies.
Since this was a new file I added, I didn't carefully check it after
applying clang-format, which led to this issue.
I'll fix the code formatting and send a patch v2.
--
WangYuli*
*
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 645 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply
* Re: Missing ACPI driver for a keyboard button in Xiaomi RedmiBook Pro 16
From: Nikita Krasnov @ 2025-07-27 23:36 UTC (permalink / raw)
To: Armin Wolf, linux-acpi, linux-input, platform-driver-x86, linux,
fengwk94
In-Reply-To: <b4707664-6177-45ff-a284-36e921f316e7@gmx.de>
[-- Attachment #1.1: Type: text/plain, Size: 1756 bytes --]
> No, it is because your device is using a different WMI interface for delivering events. Device manufacturers
> are not exactly known for using the same WMI interfaces for a long time :(.
By the way, how would we call this driver? xiaomi-2-wmi?
> Personally i have no problem with you writing a WMI driver in Rust, but currently we have
> no suitable bindings for the WMI driver API. Additionally i am currently designing a new
> WMI driver API that will make it easier to implement the necessary Rust bindings, so the
> whole thing might take some time.
Well, I am fine with having to implement the missing Rust bindings — no
problem there. I was actually looking forward to it. But if the API's
going to change... Oof.
* Would the API change be _that_ drastic?
* Do you have any expectations on when would that API be released?
* Would the new API deprecate the previous one?
Maybe I could do this in Rust right now and then simply update the
bindings to the new API? That way it would be possible to write the
driver in Rust. If the API is going to change — the C code would have to
be updated either way, right? Maybe updating C driver versus updating
Rust bindings+driver is not that big of a difference. What do you think?
I doubt there are going to be so many Rust WMI users that it would get
really difficult to move anyone to the bindings with a new API..? How
active is the WMI submodule (is it actually a submodule or just a
component of ACPI) really is?
> Would it be possible for you to implement the WMI driver in C?
Yea, absolutely! I'm totally fine with writing this in C. I just really
don't want to miss the opportunity to use Rust here (is it's actually
feasible)!
--
Nikita Krasnov
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply
* Re: Missing ACPI driver for a keyboard button in Xiaomi RedmiBook Pro 16
From: Armin Wolf @ 2025-07-27 22:24 UTC (permalink / raw)
To: Nikita Krasnov, linux-acpi, linux-input, platform-driver-x86,
linux, fengwk94
In-Reply-To: <8f3d1015-3bef-4e7f-abea-c6665163af16@gmail.com>
Am 27.07.25 um 13:23 schrieb Nikita Krasnov:
> Hello again!
>
> Sorry for taking so long. Real life stuff gets in the way :(
>
> On Tue, Jul 22, 2025 at 07:09:37PM +0300 Armin Wolf wrote:
>> Take a look at https://docs.kernel.org/wmi/driver-development-guide.html.
> Thanks! Coupled with articles [1] and [2] this was a very good
> introduction to WMI and ACPI.
Please note that the LWN article regarding WMI drivers is quite outdated. Please follow the
WMI driver development guide from the kernel documentation instead.
>> Sure, but you have to develop a new WMI driver for your device because after looking at the
>> ACPI tables (SSDT20 in particular) i came to the conclusion that the xiaomi-wmi driver cannot
>> be used in this case.
> Why is that? Is it because xiaomi-wmi is using deprecated GUID-based WMI
> interface?
No, it is because your device is using a different WMI interface for delivering events. Device manufacturers
are not exactly known for using the same WMI interfaces for a long time :(.
> Btw, it's so weird for me that there are many laptop models, but only
> one *-wmi.c file per manufacturer (be it Xiaomi, ThinkPad, MSI or Asus).
> Is it because most of the time we write a driver for a specific piece of
> hardware that may be reused in different laptop models?
Usually a given WMI interface is used on a wide range of models so that the device manufacturers
do not have to develop a giant number of backends for their control center applications under Windows.
That is why many WMI driver work on a wide range of devices from a given manufacturer.
>> I suggest that you write a skeleton driver first that basically prints
>> the content of this buffer to the kernel log using print_hex_dump_bytes().
> About that... Would you be okay with me implementing this driver in
> Rust? I assume it's you, an ACPI WMI DRIVER maintainer, whose permission
> needs to be granted to green-light this?
Personally i have no problem with you writing a WMI driver in Rust, but currently we have
no suitable bindings for the WMI driver API. Additionally i am currently designing a new
WMI driver API that will make it easier to implement the necessary Rust bindings, so the
whole thing might take some time.
Would it be possible for you to implement the WMI driver in C?
Thanks,
Armin Wolf
> [1]: https://lwn.net/Articles/391230/
> [2]: https://lwn.net/Articles/367630/
>
> --
> Nikita Krasnov
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox