diff mbox series

[RFC] input: Add "AI Assistant" key

Message ID 20241118231014.GA2011625@quokka
State New
Headers show
Series [RFC] input: Add "AI Assistant" key | expand

Commit Message

Peter Hutterer Nov. 18, 2024, 11:10 p.m. UTC
Not to be confused with KEY_ASSISTANT which is for Siri/Cortana/...,
this one is the Copilot key.

Unfortunately Microsoft requires that the Copilot key sends
Win+Shift+F23 so this is merely a placeholder for now. Eventually we
may see hardware that actually sends a custom key code for this.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
---
Note: this is really just an RFC, happy to change the name (which is not
great given we have KEY_ASSISTANT already), the value, anything. The
purpose of this patch is simply to scope if this is something worth
pursuing.

As above, because of the MS specs I don't see any (MS-compatible) HW
sending that particular key in the immediate future. But since userspace
is expected to implement the functionality via the Win+Shift+F23 we'll
need a new keysym for this in XKB anyway.

If the kernel plans to add a keysym for this we can happily re-use that,
otherwise we'll need to define our own but that means some manual
attention if we do get a kernel keycode later.

Thoughts?

 include/uapi/linux/input-event-codes.h | 2 ++
 1 file changed, 2 insertions(+)

Comments

Dmitry Torokhov Nov. 19, 2024, 2:36 a.m. UTC | #1
Hi Peter,

On Tue, Nov 19, 2024 at 09:10:14AM +1000, Peter Hutterer wrote:
> Not to be confused with KEY_ASSISTANT which is for Siri/Cortana/...,
> this one is the Copilot key.

So my understanding is that Copilot is a successor of Cortrana. Why do
we need another assistant key? Do we expect to have multiple
assistants being available on device, each with its own key?

> 
> Unfortunately Microsoft requires that the Copilot key sends
> Win+Shift+F23 so this is merely a placeholder for now. Eventually we
> may see hardware that actually sends a custom key code for this.
> 
> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
> ---
> Note: this is really just an RFC, happy to change the name (which is not
> great given we have KEY_ASSISTANT already), the value, anything. The
> purpose of this patch is simply to scope if this is something worth
> pursuing.
> 
> As above, because of the MS specs I don't see any (MS-compatible) HW
> sending that particular key in the immediate future. But since userspace
> is expected to implement the functionality via the Win+Shift+F23 we'll
> need a new keysym for this in XKB anyway.
> 
> If the kernel plans to add a keysym for this we can happily re-use that,
> otherwise we'll need to define our own but that means some manual
> attention if we do get a kernel keycode later.

There's nothing in the HID spec yet, is there?

Thanks.
diff mbox series

Patch

diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
index a4206723f503..99c5e866e627 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -806,6 +806,8 @@ 
 #define BTN_TRIGGER_HAPPY39		0x2e6
 #define BTN_TRIGGER_HAPPY40		0x2e7
 
+#define KEY_AI_ASSISTANT                0x2f0
+
 /* We avoid low common keys in module aliases so they don't get huge. */
 #define KEY_MIN_INTERESTING	KEY_MUTE
 #define KEY_MAX			0x2ff