Skip to content

Some hotkeys work incorrectly: ctrl+shift, super+space, ctrl+a. #13787

Open

Description

@Constantine-Ketskalo

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

  1. 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.
  2. Setup hotkeys ctrl+left shift to go to next language.
  3. Setup hotkeys ctrl+right shift to go to previous language.
  4. Open start menu by pressing a super key on your physical keyboard, or click the start menu button in the bottom left corner.
  5. Start typing some text so that you have some input in the start menu search bar.
  6. Change your mind on the language you're typing the text.
  7. ❗ Press ctrl+a to select all the wrong text you've just typed. Notice that ctrl+a doesn't work here.
  8. Delete the text in the start menu search input.
  9. Press super+space to change the language.
  10. ❗ 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.
  11. 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.
  12. ❗ Repeat the same, but this time press shift first, then ctrl. Repeat few times. Notice that it never works.
  13. 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

  1. For hotkeys ctrl+shift order of pressing shouldn't matter. Like in math: the sum does not change when the variables order changes.
  2. When typing in the start menu search input, ctrl+a hotkeys should selec all the input text in the search field.
  3. 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

  1. Constantine-Ketskalo commented on May 28, 2026

    @Constantine-Ketskalo
    Author

    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+shift as 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+shift and shift+ctrl is rather a workaround, then a normal behavior.

    Other 2 issues with hotkeys (super+space, ctrl+a) are still relevant.

  2. Constantine-Ketskalo commented on Jun 6, 2026

    @Constantine-Ketskalo
    Author

    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.

  3. Constantine-Ketskalo commented on Jun 19, 2026

    @Constantine-Ketskalo
    Author

    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 hotkey ctrl+ю, 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.

  4. Constantine-Ketskalo commented on Oct 23, 2026

    @Constantine-Ketskalo
    Author

    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... 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions