[RFC PATCH] input: Add "AI Assistant" key

[RFC PATCH] input: Add "AI Assistant" key

[Peter Hutterer]

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(+)

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
-- 
2.47.0

Re: [RFC PATCH] input: Add "AI Assistant" key

[Dmitry Torokhov]

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.

-- 
Dmitry

Re: [RFC PATCH] input: Add "AI Assistant" key

[Peter Hutterer]

On Mon, Nov 18, 2024 at 06:36:33PM -0800, Dmitry Torokhov wrote:
> 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?

Ah, I didn't realise copilot replaces cortana, I thought they'd be
co-sharing since we can't possibly have too many AI features these days.
I did find an official-looking statement:
https://support.microsoft.com/en-au/topic/end-of-support-for-cortana-d025b39f-ee5b-4836-a954-0ab646ee1efa
Quick google says Siri gets Apple AI shoved onto/into/at instead of
being replaced, and there's only one Google Assistant^WBard^WGemini.

I doubt we'll see multiple assistants on the same device so I think
KEY_ASSISTANT should be fine then, thanks. Sorry about the noise.

> > 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?

Not that I'm aware of, I checked the current HUT RRs but it's not listed
there.

Cheers,
  Peter