Copilot key will eventually be required in new PC keyboards, though not yet.

cross-posted from: https://programming.dev/post/8149733

Andrew Cunningham (arstechnica.com) - Jan 4, 2024 8:01 am UTC Writes:

Microsoft pushed throughout 2023 to add generative AI capabilities to its software, even extending its new Copilot AI assistant to Windows 10 late last year. Now, those efforts to transform PCs at a software level is extending to the hardware: Microsoft is adding a dedicated Copilot key to PC keyboards, adjusting the standard Windows keyboard layout for the first time since the Windows key first appeared on its Natural Keyboard in 1994.

The Copilot key will, predictably, open up the Copilot generative AI assistant within Windows 10 and Windows 11. On an up-to-date Windows PC with Copilot enabled, you can currently do the same thing by pressing Windows + C. For PCs without Copilot enabled, including those that aren’t signed into Microsoft accounts, the Copilot key will open Windows Search instead (though this is sort of redundant, since pressing the Windows key and then typing directly into the Start menu also activates the Search function).

A quick Microsoft demo video shows the Copilot key in between the cluster of arrow keys and the right Alt button, a place where many keyboards usually put a menu button, a right Ctrl key, another Windows key, or something similar. The exact positioning, and the key being replaced, may vary depending on the size and layout of the keyboard.

We asked Microsoft if a Copilot key would be required on OEM PCs going forward; the company told us that the key isn’t mandatory now, but that it expects Copilot keys to be required on Windows 11 keyboards “over time.” Microsoft often imposes some additional hardware requirements on major PC makers that sell Windows on their devices, beyond what is strictly necessary to run Windows itself.

Read Microsoft is adding a new key to PC keyboards for the first time since 1994

    • Troy
      4·
      1 year ago

      Tangent: Once upon a time (like… 2006 or 2007) when KDE was first creating KRunner, I did some work in porting features from KDesktop (from KDE 2&3) into KRunner.

      History: KDesktop had a bunch of session management code embedded in it, to handle things like the “log out” command – because KDE was window manager agnostic, you couldn’t put that code into KWin in case someone wanted to use something else. So it had to go into something that was always running in the background while a KDE session was up. The options were KDesktop and Kicker – but kicker wasn’t as stable, since it allowed plugins, so KDesktop got the job.

      With Plasma taking over the desktop “window”, and being so new and crash prone at the time, a bunch of the KDesktop session management code needed a place to land. KRunner was a much smaller in scope program that would be always on, so I ported all that code into KRunner. KRunner, that early in development, had the job of “being used to restart whatever crashed” so it has to be super stable. I was nervous as hell doing that work haha.

      I haven’t been involved in KDE development for over a decade now. I wonder if that code is still there. I’d wager it all got reworked during the Wayland related porting.