| Message ID | 20241118231014.GA2011625@quokka (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] input: Add "AI Assistant" key | expand |
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.
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
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
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(+)