Repository navigation
Some hotkeys work incorrectly: ctrl+shift, super+space, ctrl+a. #13787
Description
Distribution
Linux Mint 22.3 Cinnamon x64
Package version
Cinnamon 6.6.7
Graphics hardware in use
No response
Frequency
Always
Bug description
I'm considering different linux distors to choose to attempt to switch from windows. So I've tried to setup hotkeys ctrl+shift for switching languages, since I've got used to those the most. And what I've noticed is that whenever I would press them at the same time, they don't work properly. Like they might sometimes, but many times they don't. So while testing it I've noticed that if you press ctrl first and then shift - it always works. If you press shift first, then while holding it ctrl - then it never works. And, of course, if you try to press them at the same time, seems like it depends on which system detects pressed first.
This is a small detail, but very inconvenient. I tried how does super+space work and I've noticed that it's better: when pressed at the same time - works perfectly. But with a noticable delay if you press space first, hold it and then press super - it never works. Even if you do it very fast but in that order - never works.
So I suggest to fix those hotkeys in a way that it doesn't matter which key of the combination is pressed first, because current behavior is very misleading.
I've specified the version, but I think that I've been trying ctrl+shift before and the same behavior was already there like few years ago. Maybe 6-8 years ago.
Also switching languaguages closes start menu.
And Ctrl+A doesn't work in the start menu input field. Only shift+home works to select all the text.
On one hand, it sounds like 3 different bugs, but on the other hand, it all has to do with hotkeys. So I'm not sure if I should report them separately.
Steps to reproduce
- Setup 2 languages in your system for keyboard layout.
*Note: I have flags displayed for languages in the tray, but I don't think it matters. Just saying just in case. It seems to be more distinguishable for me that way. - Setup hotkeys
ctrl+left shiftto go to next language. - Setup hotkeys
ctrl+right shiftto go to previous language. - Open start menu by pressing a super key on your physical keyboard, or click the start menu button in the bottom left corner.
- Start typing some text so that you have some input in the start menu search bar.
- Change your mind on the language you're typing the text.
- ❗ Press ctrl+a to select all the wrong text you've just typed. Notice that ctrl+a doesn't work here.
- Delete the text in the start menu search input.
- Press super+space to change the language.
- ❗ Notice that the language have changed, but at the same time, because you've pressed the super button, the start menu has closed, even though it was not a single button pressed, but a part of hotkeys super+space. Seems like it's because start menu opens on super button release, but start menu closes on super button key down event.
- Try switching languages with hotkeys ctrl+shift, but press ctrl first, hold it, press shift, release shift, then release ctrl. Repeat few times. Notice that it works every time.
- ❗ Repeat the same, but this time press shift first, then ctrl. Repeat few times. Notice that it never works.
- Try pressing ctrl+shift at the same time multiple times. Notice that sometimes it works, sometimes it doesn't. Most likely because of the same reason: depending on which button is processed by OS first.
Expected behavior
- For hotkeys ctrl+shift order of pressing shouldn't matter. Like in math: the sum does not change when the variables order changes.
- When typing in the start menu search input, ctrl+a hotkeys should selec all the input text in the search field.
- When pressing super+space with open start menu, it shouldn't close. Instead it should close on super button release IF no other buttons are pressed.
Additional information
I'm pretty sure that this is an old bug. I'm sure that I've noticed ctrl+shift years ago. No, reboot doesn't help. I've been noticing it on a fresh install of a system. Including live usb usage.
Activity
Constantine-Ketskalo commentedon May 28, 2026
Update.
I've just realized, that there is an option to assign up to 3 hotkeys sets to switching keyboard layouts. So I've tried to assign both options: ctrl first and shift first for
ctrl+shiftas separate hotkeys and it fixed that issue.I'm not sure what is the best option to follow for this one. But it seems to me that this double assignment of
ctrl+shiftandshift+ctrlis rather a workaround, then a normal behavior.Other 2 issues with hotkeys (super+space, ctrl+a) are still relevant.
Constantine-Ketskalo commentedon Jun 6, 2026
Update:
I've just noticed that Ctrl+a in the start menu search input doesn't work only when using Ukrainian keyboard layout. It works normally with English (US).
In xed text editor Ctrl+a works normally in both Ukrainian and English keyboard layouts.
I don't know if it needs to switch binding from a character that goes to input to actual physical keyboard code or is it something else. But I just wanted to let you know just in case.
Constantine-Ketskalo commentedon Jun 19, 2026
Update:
I've also noticed 2 more hotkeys that might need fixing.
super+.
I've been trying to setup this hotkey to replace built-in win+. hotkey from windows for emojies. But for some reason it doesn't work in the hotkey assignment field. In this particular case, for some reason, it reads only super, when trying to press
super+.. So I had to use a different key instead of super for this particular case. But all the other combinations like super+v work perfectly.Also I've noticed that when I've assigned
ctrl+.hotkeys, then it works only when typing in English. When I switch languages, it doesn't work any more, unless I add another hotkeyctrl+ю, which is the cyrillic character, that is used in Ukrainian layout for the same button as dot in English.So seems like binding to a specific character instead of a physical key code is a global issue here.
I would guess that if it's possible to bind hotkeys to a physical keyboard code, it would work in the most reliable way. If not, then probably there could be automatic mapping from English keyboard layout, to other layouts of other languages, to match the same physical keys automatically. That could do the trick as well. I hope it wouldn't slow down the system though. Maybe switching to events of listening to certain keys only for the active keyboard layout could potentially help to optimise it in case if you would have to use characters binding instead of physical key code. Just a couple of ideas to share.
Constantine-Ketskalo commentedon Oct 23, 2026
I hope it's not going to be closed automatically due to inactivity... And also I hope I'm not the only person on planet Earth, who cares about these hotkeys... 😅