Keyboard layout change on hotkeys press instead of release and do not work well with shortcuts

Bug #36812 reported by Sergey Sinitsa on 2006-03-27
552
This bug affects 104 people
Affects Status Importance Assigned to Milestone
X.Org X server
Confirmed
High
Nominated for Trunk by ksn135
gnome-control-center
Unknown
Medium
gnome-control-center (Ubuntu)
Low
Unassigned
xorg-server (Ubuntu)
Wishlist
Unassigned

Bug Description

This is a bug about shortcuts mapped to combinations which include each other.

For example, if we have Ctrl+Shift (for keyboard layout) and Ctrl+Shift+N (to open a new terminal), then we are practically unable to use the second shortcut; this is what happens:
Ctrl press (nothing happens)
Shift press (keyboard layout change)
N (a simple N appears, since a shortcut has already fired)

The expected behavior is to fire shortcuts on the release (not on press) of the special keys (ctrl,shift,alt, etc) which is also how Windows behave. This is a serious problem for bilingual layouts, typically using Alt+Shift or Ctrl+Shift for keyboard layout change.

For users being affected by this problem, the easiest solution for now is to add this PPA in your repositories:
https://launchpad.net/~oded-geek/+archive/xorg-patches

Practical summary of this bug for ubuntu developers (since reading 120 comments is impractical for most):
This problem is a really old (since 2004) issue of the xkb part of xorg; the main discussion was made upstream in freedesktop-bugs #865. There has been a patch from Ilya Murav'jov for upstream (#55), and attached here (#61).
Upstream xorg has refused to apply the patch, mainly because it "explicitly contradicts the (xkb) spec" (#84, #91).
This patch has been reported to work for many people without any problems, and there is also a PPA by Oded Arbel (#95) where he maintains a patched version of the ubuntu xorg.
The proper resolution of this bug would be to apply this patch to the upstream xorg, or at minimum to the official ubuntu xorg package.

Related branches

*** Bug 731 has been marked as a duplicate of this bug. ***

Sergey Sinitsa (sin3) wrote :

I have Ctrl+Shift set to layout switch and press ctrl+shift+N (to open new Terminal or new tab in Opera) -- as a result I have my keyboard layout switched. This happens because Ubuntu (or XOrg?) change layout on key press instead of release and do not match layout hotkeys with application shortcuts. MS Windows do. If layout change hotkeys is pressed with another key this must be treated as application shortcut and layout must not be changed. Combined with shortcut bugs in some Linux applications [Bug 2561] this makes keyboard shortcuts nearly unusable in default bilingual configuration.

Are you able to reproduce this issue with a current version of xorg?

yep, it's still a current issue. reasonably non-trivial fix, though. we could
probably hijack PKE for this.

(In reply to comment #2)
> Are you able to reproduce this issue with a current version of xorg?

playing with current xorg 7.1 on SuSE 10.1, taken from SuSE repositories.
it still behaves the same.

Nick Andrik (andrikos) wrote :

I can also confirm this bug.
I use Alt+Shift for language change and Alt+Shift+Tab for backwards changing windows.
Thus, I cannot change the windows backwards

Daniel Holbach (dholbach) wrote :

Thanks for the bug report.

Somebody of the team could forward this upstream.

Changed in control-center:
assignee: nobody → desktop-bugs
importance: Medium → Low
status: Unconfirmed → Confirmed

Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.

*** Bug 10662 has been marked as a duplicate of this bug. ***

Sebastien Bacher (seb128) wrote :
Changed in control-center:
status: Unconfirmed → Unknown
Sergey Sinitsa (sin3) wrote :

http://bugzilla.gnome.org/show_bug.cgi?id=430637
Comment #1 from Sergey V. Udaltsov (developer, points: 14)
2007-04-17 12:44 UTC [reply]
NOTGNOME. That's the way X works.

Sebastien Bacher (seb128) wrote :

closing the Ubuntu task then

Changed in control-center:
status: Confirmed → Rejected
Changed in control-center:
status: Unknown → Rejected
Sergey Sinitsa (sin3) wrote :

This is three years old XOrg bug.
https://bugs.freedesktop.org/show_bug.cgi?id=865

Changed in xorg-server:
status: Unknown → In Progress

    Reproduced on Ubuntu 7.04.

    I would be happy to beta test patches were group change occurs at release, and
    only if no other key combination was pressed, i.e:
    in my configuration alt+shift chages group.
    alt+shift+tab should go back a window and NOT change a group.
    currently it changes a group and do goes a window forward!

    Thanx,
    nonZero

nonZero (udioron) wrote :

Personally this is a big problem for me - not allowing me to use alt-shift-tab while my change group key is alt-shift.
I belive this problem would be a major issue as more dual-language users are added to the gang.

nonZero

I have the same issue with Hebrew layout...
<Alt><Shift><Tab> changes language on <Alt><Shift> key-down and not go back window as expected.

Well... long time until I thought I should file a bug... :)

*** Bug 12085 has been marked as a duplicate of this bug. ***

I use

  Option "XkbOptions" "ctrl:nocaps"

and have related problems. When I want to type a keybinding like C-M-a (C = Control, M = Meta (Alt)) and type it by first pressing Control, then Alt and then "a" it's translated to C-a. The Alt is blocked when I hit Control first. xev shows this order of events:

  KP-C, KP-a, KR-a, KP-M, KR-M, KR-C

where KP stands for KeyPress and KR for KeyRelease. If I comment out the Option line from above in my xorg.conf, all works fine.

If I type C-M-a by first pressing Alt, then Control and then "a" it works, too.

This bug will touch all EX-WINDOWS users that use more then one language in their system. It was the major drawback when i found it.

Hello Xorg developers,

Can you please look at this issue?
It is very important to fix this for regular users to be able to use this environment.
It basically effects all multi-language users, and regular users are not able to accept the keydown/keyup explanations...

Thanks!

*** Bug 16041 has been marked as a duplicate of this bug. ***

Hmm, I am not that sure my report is a duplicate -- but if yes, differences:

* I don't do any layout switching, I have only single layout

* issue I described has nothing to do with pressing or releasing

* the problem is that you can assign shift key to keyboard shortcuts like shift+F1 but you cannot assign alt key (shift level3) to such combinations -- in other words, such key can generate only characters (specified in layout) but beside that it is a dead key

On Wed, May 21, 2008 at 01:43:08AM -0700, <email address hidden> wrote:
> Hmm, I am not that sure my report is a duplicate -- but if yes, differences:
>
> * I don't do any layout switching, I have only single layout
>
> * issue I described has nothing to do with pressing or releasing
>
> * the problem is that you can assign shift key to keyboard shortcuts like
> shift+F1 but you cannot assign alt key (shift level3) to such combinations --
> in other words, such key can generate only characters (specified in layout) but
> beside that it is a dead key

Yes, Fn keys acting differently is another bug, but one that's fixable
by changing the keyboard layout definition of Ctrl+Alt.

Daniel, thank you for the answer. Further clarification (just in case):

a) F1 was just an example -- alt+left, alt+enter, alt+<anything not defined as character> is not working.

b) I don't use ctrl+alt, I use only alt (for getting special characters, in fact since alt is a key I cannot use anymore (*) I cannot use alt+ctrl anywhere by definition)

c) alt also is an example, in general it is shift level 3 key, it could be meta key as well

(*) sorry for using term "dead key", it has special meaning in X (other than I meant)

In short my wish is:
alt+c --> ć (character)
alt+f --> alt+f (key combo; so I could use in KDE as a keyboard shortcut)

Igor Katson (descentspb) wrote :

I can add that this happens because of GNOME also, not jsut X.org. If i set "alt-shift" in xorg.conf for layout change, and for "ctrl-shift" in gnome, the "ctrl-shift-u" or "ctrl-shift-s" etc. shortcuts DO NOT work. It just changes the layout. So it's not X.org.

Hello,
Is there any news for this one?
It is very annoying issue.
Thanks!

*** Bug 18333 has been marked as a duplicate of this bug. ***

this is really annoying bug to me. I can't use Eclipse IDE for programming, because all hotkeys use either ctrl+shift+something or ant+shift. In other words instead of refactoring I get russian letters which replace my code.

I cant switch to different (like caps lock) swith mode, since I use both linux and windows too often, and it is very inconvenient to use different methods.

Is there a way I can help coding it? any narration from where I should start in sources?

xserver/xkb/xkbActions.c is where the action handling happens. There is little
documentation aside from the XKB protocol spec, so you need to dig through the
code to figure out what actually happens.

The entry point for xkb is ProcessKeyboardEvent, it's the first function
called when a keyboard event occurs. Anthing before doesn't matter to you.

Does someone work on this? It's a very annoying bug, a lot of Emacs shortcuts don't work because of it.

> --- Comment #21 from Alexander Kojevnikov <email address hidden> 2009-02-23 16:33:22 PST ---
> Does someone work on this?

Not that I know of. Any help would be much appreciated.

Can we solve this problem?
I've made some digg about key codes, may be this can be helpful?
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/292260/comments/6
Does anybody know: Russian distros like AltLinux or AspLinux have this poblem? Perhaps we can take some code from there?

Download full text (5.3 KiB)

--- Introduction

I'd like to discuss this problem in more detail and hopefully add some ideas. For the sake of concreteness, I'm mostly discussing the "Alt+Shift bound to layout switch and preventing other Alt+Shift keyboard shortcuts" case.

After some research, I have the feeling that the problem is in the XKB protocol itself and not in its implementation, which just correctly adheres to a deficient specification. It is the XKB protocol that needs to be extended to properly cover the requested behaviour. Seems to me that currently one can bind actions only to keypresses (please correct me if I'm wrong).

Admittedly, the fix is non-trivial. But it would be worth it; the current behaviour is clumsy and limiting and (as has been said before) e.g. disallows the use of "Alt+Shift+Tab" shortcut, commonly used to switch among open windows, when "Alt+Shift" is used to switch between layouts (that's actually how I found this bug - searching why Alt+Shift+Tab doesn't work).

--- Definition of "multi-key-press-release sequence"

Definition: A "multi-key-press-release sequence" (MKPR seq. for short) is a sequence of key presses and key releases occuring on a keyboard. It begins and ends with all keys on keyboard up. During the sequence, there must always be at least one key down.

--- The desired behaviour - the simple case with two layouts

Initial state: no key is pressed on the keyboard, two layouts are set in the X server (us,cz), layout "us" selected (locked)

The user's intention: to select (lock) the "cz" layout

Action taken - a four step MKPR sequence:
1) press (and hold) Alt 2) press Shift 3) release Shift 4) release Alt

The expected behaviour/response: The release of all keys (i.e. step 4) would trigger the selection (and locking) of "cz" layout.

Current behaviour/response: The layout gets changed after step 2). Moreover, XKB then somehow forgets that Shift is still held down and acts as if only Alt was held down. This precludes even the reachability of any shortcut containing "Alt+Shift" combination.

Note on expected behaviour/response: If any key other than Alt or Shift is pressed during the time when Alt was held down, no layout change should occur. In other words, pressing any other key than "Shift" or "Alt" would completely disqualify the MKPR sequence being formed from being a candidate for layout switching.

--- Slight extension

Consider this MKPR seq.:
1) press and hold Alt 2) press Shift 3) release Alt 4) release Shift

That should switch the layout too, as well as this other two possibilities:

1) press and hold Shift 2) press Alt 3) release Alt 4) release Shift

1) press and hold Shift 2) press Alt 3) release Shift 4) release Alt

Unsure: What about the following MKPR seq?

1) press and hold Alt 2) press Shift 3) release Alt 4) press Alt 5) release Shift 6) release Alt

Should this do something special? (probably not, maybe it should not do anything at all)

--- What if there are more than two layouts (e.g. 4 layouts?)

It would be IMHO practical, if the switching among layouts with Alt+Shift could work similarly as Alt+Tab switching between windows in XFCE/GNOME/KDE etc., i.e. there would be some internal recency ...

Read more...

(In reply to comment #24)
> Action taken - a four step MKPR sequence:
> 1) press (and hold) Alt 2) press Shift 3) release Shift 4) release Alt
.
.
.
> It would be IMHO practical, if the switching among layouts with Alt+Shift could
> work similarly as Alt+Tab switching between windows in XFCE/GNOME/KDE etc.,
> i.e. there would be some internal recency list, enabling to quickly switch
> between two most recently used layouts. I.e. press and hold Alt and then

To make this happen, the event should be triggered following step 3.
So, basically what needed to be done is whenever a key is pressed, key combination should be matched against the current pressed keys, and if a combination is met exactly, we should only set a flag for this combination - and not actually fire the event.
Whenever a key is released, this flag is checked - if the flag was set, the event shoud be fired and the flag should be cleared.
Whenever a key is pressed, the flag should also be cleared, so:
Example A:
Step Action Flag
---- ----------------------------- ----
                                      0
1 Alt pressed 0
2 Shift Pressed - match! 1
3 Shift released - EVENT FIRED 0
4 Alt released 0

Example B:
Step Action Flag
---- ----------------------------- ----
                                      0
1 Alt pressed 0
2 Shift Pressed - match! 1
3 Tab Pressed 0
4 Tab released 0
5 Shift released 0
6 Alt released 0

Example C:
Step Action Flag
---- ----------------------------- ----
                                      0
1 Alt pressed 0
2 Shift Pressed - match! 1
3 Shift released - EVENT FIRED 0
4 Shift Pressed - match! 1
5 Shift released - EVENT FIRED 0
6 Alt released 0

Example D: (very strange case, unexpected, just for "fun")
Step Action Flag
---- ----------------------------- ----
                                      0
1 Alt pressed 0
2 Shift Pressed - match! 1
3 Tab Pressed 0
4 Tab released 0
5 Shift released 0
4 Shift Pressed - match! 1
5 Shift released - EVENT FIRED 0
6 Alt released 0

I think this is good enough for 99% of the cases.
I did not dive into the protocol, but I have a feeling that adding such a flag is not a big deal, and does not require a rewrite, but please, correct me if I am wrong.

Udi

Download full text (6.2 KiB)

> To make this happen, the event should be triggered following step 3.
>.
>.
> So, basically what needed to be done is whenever a key is pressed, key
> combination should be matched against the current pressed keys, and if a
> combination is met exactly, we should only set a flag for this combination -
> and not actually fire the event.
> Whenever a key is released, this flag is checked - if the flag was set, the
> event shoud be fired and the flag should be cleared.
>.
>.
> I think this is good enough for 99% of the cases.

Good idea with the flag, and you are probably right that your solution would solve 99% of the cases (since lot of people affected by this probably use just two layouts - US and their national one - at least that is my situation).

Anyway I would be definitely for incorporating the "recency-awareness" into the switching of keyboard layouts. It would be very handy in the case when there is need to switch among more than two layouts.

I know I'm straying quite a bit from the original problem now, since this is definitely a request for extension, but I think it's still in close relation, so let me explain the idea in more detail.

--- First introduce some shorthands

<key> down = press <key> and hold it down
<key> up = release <key>
<key> hit = press <key> and immediately release it

--- What do I mean by "recency-aware" switching and why is it a good idea

Basically it's the type of switching that is used for switching among windows in XFCE/GNOME/KDE, so let's first describe how that works. For example, let's open four applications in say XFCE - first app1, then app2, then app3 and finally app4. By that, subsequently app1 app2 app3 and app4 gets focused (i presume that when the app is opened, it gathers focus). So now app4 is focused. Suppose we want to switch to app2. What one can do is:

1) Alt down
2) Tab down - now a list of applications appears, showing the applications in this order: app4, app3(selected), app2, app1 - it's the order in which they had been lastly focused
3) Tab up
4) Tab down - now app2 gets selected in the applist
5) Tab up
6) Alt up - this release triggers the actual switch, so applist disappears and app2 gets focused; also, the applist gets reordered (internally) - the apps in it are now in this sequence: app2 (currently=most recently focused), app4, app3, app1 (focused longest time ago)

Now suppose we want to switch back from app2 to app4 (typical scenario: app2 is an editor in which one edits a webpage and app4 is a web browser used for testing that page). With recency-aware applist, this can be done easily, thanks to the clever rearrangement of apps in it:

1) Alt down
2) Tab down - list of application appears: app2, app4(selected), app3, app1
3) Tab up
4) Alt up - app4 gets focused

If the list didn't get rearranged (and was still app4,app3,app2,app1) one would need to hit tab twice to get back to app4 (assuming wrap arround). But with recency awareness, it's just "down Alt + hit Tab + up Alt" et voila.

Compare this to e.g. tab switching in Firefox which, by default, is just rudimentary; no recency awareness there. Ctrl+Tab is just "switch one tab to the right", Ctrl+Shift+Tab "switch one...

Read more...

(In reply to comment #27)
> So this is my proposal for keyboard layout switch. It requires changes in the
> XKB and also in the desktop environments (to display the layout selection
> window), but the result would be well worth the effort IMO.

+1 to Adam's idea. This is how it should work.

Five years the problem remains not solved.

Developers have no problems with switching of keyboard layouts and hotkeys?

(Sorry for my english)

(In reply to comment #29)
> Five years the problem remains not solved.
>
> Developers have no problems with switching of keyboard layouts and hotkeys?
>
> (Sorry for my english)
>

Looks like Russian and Slavic users are mainly affected. :(
What about Adam's idea? It looks very good.

Can anybody realize it? Unfortunately I'm not an Xorg developer :(
Is it possible to make it as a patch? or specific branch?

www.xneur.ru - switch layouts on key release!
No problem for hotkeys!

xneur - daemon
gxneur - gui for gnome
kxneur - gui on QT for KDE

Nick Andrik (andrikos) on 2010-02-08
tags: added: patch
Changed in xorg-server:
importance: Unknown → Medium
Changed in gnome-control-center:
importance: Unknown → Medium
status: Invalid → Unknown
affects: hundredpapercuts → null
Changed in null:
status: New → Invalid
Nick Andrik (andrikos) on 2010-11-27
description: updated
description: updated
description: updated
description: updated
description: updated
bugbot (bugbot) on 2010-11-28
affects: xorg (Ubuntu) → xserver-xorg-input-evdev (Ubuntu)
Changed in control-center (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
Changed in xserver-xorg-input-evdev (Ubuntu):
status: New → Confirmed
Bryce Harrington (bryce) on 2011-01-06
Changed in xserver-xorg-input-evdev (Ubuntu):
importance: Undecided → Wishlist
status: Confirmed → Fix Committed
Timo Aaltonen (tjaalton) on 2011-01-07
affects: xserver-xorg-input-evdev (Ubuntu) → xorg-server (Ubuntu)
Changed in xorg-server (Ubuntu):
status: Fix Committed → Fix Released
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium
Changed in xorg-server:
importance: Medium → Critical
Changed in xorg-server:
importance: Critical → High
Curtis Hovey (sinzui) on 2011-11-11
no longer affects: null
affects: control-center (Ubuntu) → gnome-control-center (Ubuntu)
201 comments hidden view all 281 comments

> - Can you describe a bit how you imagine the changes to xkeyboard-config
> would look with this approach?
We would need changes wherever we want the new behaviour. I would prefer to create new options for group switching, rather than modifying existing options. Comments #117 and #118 show examples. Basically, I imagine we use explicit action specifications. However, unless as shown in the examples, with changes to xkbcomp, one could write 'LockMods' with an 'group' option, rather than using the cryptic 'Private' actions.

> - Do you think this can be done in a backwards compatible way? As far as
> xkbcommon is concerned, I am only interested in this scenario: old library
> (unaware of the new LockMods options) & new keymap (in textual form,
> modified with the new flags).
Certainly, an old library or application would get parse errors when it encountered the new options in textual form.

If xkeyboard-config adds new options rather than modifying old ones, users could just keep using the old options until they upgraded the library/application. If the library/application parses only used stuff, that would circument transitional compatibility issues. For an old xkbcomp with a new xkeyboard-config, I believe that would work.

As I far as remember, xkbcommon intentionally does not support 'Private'; otherwise, using it could help during the transition.

> X has more compatibility concerns,
Yes. Peter's main concern was that some tools might create binary forms of a layout where the two bytes that now get a meaning are not zero, but set to some random values (zero is fine, as it will have no effect in the new interpretation). His idea was to bump the protocol version, but that is beyond my capabilities, so I gave up at this point. Anyway, current xkbcomp puts the bytes to zero, so the combination of an old xkbcomp with new X-server would be no problem, ever without the precaution of a protocol version bump.

> BTW: xkbcommon already supports noLock/noUnlock in LockMods (unlike xkbcomp),
> based on your work[1]. So I hope the approach does not rely on these not
> already working :)
With my proposal, xkbcomp should be touched anyway, and this is just one of three occasions where I unsuccessfully tried to get noLock/noUnlock supported in xkbcomp.

(In reply to Nikolay from comment #155)
> There is now once more spike of activity here - probably because Ubuntu
> 17.04 was released recently which dropped this patch because it was not
> compatible with newer xorg. kyak has provided an updated patch, but it would
> take a lot of time for distributions to pick it up and then circle would
> repeat with next xorg version.

On Ubuntu 16.04.03 LTS I just went from using Unity to Gnome. With some back and forth with lightdm vs. gdm and the screen lock issues I got things working more or less until I stumbled over what probably are the ripples of this old bug (and I couldn't agree more with Nikolay and his comment).

I had two keyboard layouts running with Unity, and as everybody seems to have, I used Alt-Shift to switch layouts, just like on my Windows laptop. And like almost everyone else, I of course have Alt-Shift-Tab set for cycling backwards through windows (after jumping through all sorts of hoops to tell the window manager not to group windows of the same app...).

I reported my issue at https://bugzilla.gnome.org/show_bug.cgi?id=786257 which obviously was the wrong place. And now I found this bug here.

I haven't taken the time to understand all the details, so I apologize for the outside perspective. Yet, I am of the opinion that it should be possible to define shortcuts such that they trigger their event only upon release, not upon press, because as noted by everyone else here it makes it impossible to define "release" shortcuts that are "prefixes" of other shortcuts, and this is a severe limitation that becomes highly practically relevant for the usual keyboard layout switching shortcut that just so happens to be a prefix of the usual window backwards switching shortcut.

There have been much worse backward incompatibilities in Linux. And while I hate seeing things break by such changes, here my very personal view is that should this really present a problem that cannot be solved in a backward-compatible way (e.g., by letting users distinguish between "release" and "press" shortcut definitions) then so be it. What is this compared to deprecating X11, then xorg and at some point also Wayland...?

After the next update of the package "xserver-xorg-input-evdev-hwe-16.04" (with dependencies) from the version "1: 2.10.2-1ubuntu1 ~ 16.04.1" to the version "1: 2.10.5-1ubuntu1 ~ 16.04.1 ", in the KDE shell, the language switch does not happen when the keys are released, but when pressed.

Distributions on which this problem was repeated:
neon-useredition-20171012-1018-amd64
kubuntu-16.04.3-desktop-amd64
kubuntu-17.04-desktop-amd64

Distributions in which there is no such problem:
ubuntu-16.04.3-desktop-amd64
ubuntu-17.04-desktop-amd64 (but there is no such package)

When setting the switch to Ctrl-Shift, you can not quickly select text with the "Ctrl-Shift-Arrows" keys. However, you do not want to have outdated xorg packages. Extremely uncomfortable, help!

Me too very upset about this bug: there is patch for several yers - no one cares. I suggest compromise: add autotools|meson option to enable this feature. At least every distro would be able to decide whether they want to provide nonstandard behavior.

I also see that this bug is assigned but nothing happens.

Why don't you change your layout switcher key-combination? You can set up another key-combinations for russian and different key-combination for english keyboard,too. That's KDE's problem, that allow choose frequently used key combinations.

Changed in xorg-server:
status: In Progress → Won't Fix

With all due respect, I hope this is not the usual response to X bugs. I do not think it is unreasonable to ask that shortcuts be made available from the set of control keys, since this is a very widespread feature across operating systems. I have used Kubuntu for the past several years, and made use of the alt-shift key combination to toggle between the English and Greek keyboard layouts. After the recent KDE change I find this bug affecting my workflow, interrupting various keyboard combinations involving the use of those modifiers. I think it is appropriate to call this a bug in xkb's behaviour.

I wholeheartedly understand that X developers are more thinly stretched than most, and that this bug—despite its labeled importance—does not have as extreme a disruptive impact as many other bugs. I have no desire to complain of the amount of time this bug has spent open and demand that it be fixed. I would however request that this bug not be closed, as it is indeed a bug and the responsibility of xkb.

The main keyword the KDE interface programming philosophy called Quick Time. Windows use message queue, and uses built togheter windows manager with the os hardly. Qt enables for programs override every reactions, "answered" the user actions. Under xcfe desktop manager main program override subprograms actions, for example, midnight commander is not closeable pressed f10 key, it override the main window. KDE close midnight commander pressing f10 key.
Xkb layouts can not to do anything with this problem.

This bug is not exclusive to KDE. I use XFCE on a different machine as well, and encounter the bug there. Various people in this thread have reported it in other WMs. Is there a reason why the solution should not be, as the title says, that XKB kick its hotkeys on release rather than press?

Who invite me this blog?

(In reply to Kovács Viktor from comment #165)
> Why don't you change your layout switcher key-combination? You can set up
> another key-combinations for russian and different key-combination for
> english keyboard,too. That's KDE's problem, that allow choose frequently
> used key combinations.

This has nothing to do with KDE, but lack of functionality of xkb.

There is universal key sequence to switch layout which is common to most operating systems, once this sequence is selected, functionality is lost.

Comment#161 summaries the options to actually solve the issue, until resolved people should be able to land here to apply the patch which I use for 10 years.

Changed in xorg-server:
status: Won't Fix → Confirmed

Created attachment 134843
KDE keyboard layout switcher screenshot

Sorry, I'm Hungarian.

Original problem was, that Shishakov uses ctrl+shift keyboard layout keycombination, and it not works, because it can be used in hotkeys.
Why do not change It? It is much easier thing, I think.

@Kovács Viktor, this report is not only about "original" problem, but all the problems affected by current implementation. I described other one with modifier for national characters, once you define such key you cannot use it as shortcut modifier.

High, Viktor!

I'm using Ctrl+Shift for twelve years since Win XP. I use this combintaion on my win machines. So it's definetely not an option for me. Since I use Cyrillic layout I switch layouts frequently (people using Latin layouts are less affected). Imagine saving action shortcut "Ctrl+S" combintaion would be replaced with something like "Alt+R" in your favourite text editor.

I'm also sure that no one will complain if the patch will be merged. And I do not understand why should we follow the standard if this standard makes living uncomfortable.

BTW according to previous comments wayland implentations suffer from this bug too despite they do not depend on Xorg-server. Do we need separate patch for libxcb and libxcbcommon?

I understand, that you must switch between Russian and English layout. The programs uses latin-based hotkeys, I did understand. In my opinion, in the future would be change, if the translator projects "translate" the hotkeys, for example to cyrillyc letters, too. (then won't need switches between layouts so frequently) We (Hungarians) will run into that problems on the future, when we will want to write old Hungarian texts. This is a runic-like right-to-left script. My question is, do you use Windows yet, or you uses already only Linux? You can choose switcher combination closely positioned with ctrl and shift. If you buy a new laptop, it could be happen, that the keyboard metrics not exactly same as on previous one.

I use both Windows and Linux. BTW Many people don't have a choise of the OS on their jobs.

I may provide a patch that would make it available to switch the behaviour in the runtime (I guess a line in xorg.conf would be fine). So we don't break the standard, people don't need to recompile xorg every time and patch developers don't need to adapt the patch.

(In reply to Yan Pas from comment #176)
> I use both Windows and Linux. BTW Many people don't have a choise of the OS
> on their jobs.
>
> I may provide a patch that would make it available to switch the behaviour
> in the runtime (I guess a line in xorg.conf would be fine). So we don't
> break the standard, people don't need to recompile xorg every time and patch
> developers don't need to adapt the patch.

You should get developers' feedback about this approach first. If they are not willing to merge the patch that works via xorg.conf, you will only waste your time.

From the other hand side, you will probably waste your time anyway.
Developers talk about the "standard", and explicitely suggest sending patches to standard instead of patching xorg (read previous comments). And when such patch for the standard gets attached to this bug report, what happens? Nothing.

(In reply to Vitaly Shishakov from comment #0)
> I used to use Ctrl-Shift combination to switch keyboard layouts (ru <--> us)
>
> but in this case i cant use any of the Ctrl-Shift-* hotkeys in any software
> i try.
>
> I noticed, that the keyboard layout becomes swithced as soon an both keys
> are DOWN --
> pressing any other key is not treated as Ctrl-Shift-<key> combination.
>
> For example -- in Windows i also use Ctrl-Shift to switch layouts, but
> there, the layout
> becomes switched only when both SHIFT and CTRL keys are UP, and no other key
> was
> pressed while they were down -- in that case the hole combination is treates
> as
> Ctrl-Shift-<key> combination, and the layout is not changed.
>
> see also: http://bugs.kde.org/show_bug.cgi?id=59303
>
>
>
> I use the following lines in XF86Config:
>
> Section "InputDevice"
> Driver "Keyboard"
> Identifier "Keyboard[0]"
> Option "Protocol" "Standard"
> Option "XkbLayout" "us,ru"
> Option "XkbModel" "pc104"
> Option "XkbOptions" "grp:ctrl_shift_toggle"
> Option "XkbRules" "xfree86"
> Option "XkbVariant" ",winkeys"
> EndSection

Kubuntu grants Control+Shift+K combination. Is it acceptable?

(In reply to Kovács Viktor from comment #178)
> Kubuntu grants Control+Shift+K combination. Is it acceptable?

The question is not, largely speaking, about whether there is any shortcut available. The question is largely specifically about shortcuts such as Ctrl+Shift or Alt+Shift, which due to this bug will interfere with other shortcuts and applications. Users such as myself are accustomed to using these shortcuts, and they should be expected to work.

(In reply to Zebediah Figura from comment #179)
> (In reply to Kovács Viktor from comment #178)
> > Kubuntu grants Control+Shift+K combination. Is it acceptable?
>
> The question is not, largely speaking, about whether there is any shortcut
> available. The question is largely specifically about shortcuts such as
> Ctrl+Shift or Alt+Shift, which due to this bug will interfere with other
> shortcuts and applications. Users such as myself are accustomed to using
> these shortcuts, and they should be expected to work.

Yes, I was thinking about it before you answered. I tested RCtrl+RShift combination, and it has no conflicts with hotkeys. There are possibility of XKeyboard-config, I used it before a keyboard layout: caps_switch_latch. It works when capslock pushed, but not released. I just thinking, I am in a black room. But it cannot do anything with hotkeys. I think, that problem is a miner-like. X-windows have messages keypress and release, but in my opinion, it should be adopt all windows manager. I will read the according X11 header files first, I promiss. After that I come back again, could we step to an easy way or not.

Sorry, on newer Linux you can set up hot key combination for that problem as graphical UI settings, older Linux versions will not be updated. May I close It?

(In reply to Kovács Viktor from comment #181)
> Sorry, on newer Linux you can set up hot key combination for that problem as
> graphical UI settings, older Linux versions will not be updated. May I close
> It?

With all respect to you... Why do you want to close well described bug moreover that it has good proposed solution? This issue affects multiple users using multiple keyboard layouts and merging available patch probably won't cause any problems to the rest of people that does not use layout switchig.

(In reply to Jan Pohanka from comment #182)
> (In reply to Kovács Viktor from comment #181)
> > Sorry, on newer Linux you can set up hot key combination for that problem as
> > graphical UI settings, older Linux versions will not be updated. May I close
> > It?
>
> With all respect to you... Why do you want to close well described bug
> moreover that it has good proposed solution? This issue affects multiple
> users using multiple keyboard layouts and merging available patch probably
> won't cause any problems to the rest of people that does not use layout
> switchig.

Sorry, but where do you see "good proposed solution"? Please, please show me that solution.

(In reply to Kovács Viktor from comment #181)
> Sorry, on newer Linux you can set up hot key combination for that problem as
> graphical UI settings, older Linux versions will not be updated.

What exactly "newer Linux" is supposed to mean? I'm using yesterday's updated Gentoo Linux with xorg-server-1.19.5 and Fluxbox - is it counts as "newer"? Or by "newer Linux" you mean something like "modern KDE only"?

(In reply to k0fe from comment #183)
> Sorry, but where do you see "good proposed solution"? Please, please show me
> that solution.

There is a patch, working good enough for years without creating any new (practical) issues. In comment #161 is was proposed to make it configurable option to make everyone happy and let users choose between using compliant protocol or working hotkeys.

(In reply to Alex Efros from comment #184)
> (In reply to Kovács Viktor from comment #181)
> > Sorry, on newer Linux you can set up hot key combination for that problem as
> > graphical UI settings, older Linux versions will not be updated.
>
> What exactly "newer Linux" is supposed to mean? I'm using yesterday's
> updated Gentoo Linux with xorg-server-1.19.5 and Fluxbox - is it counts as
> "newer"? Or by "newer Linux" you mean something like "modern KDE only"?
>
> (In reply to k0fe from comment #183)
> > Sorry, but where do you see "good proposed solution"? Please, please show me
> > that solution.
>
> There is a patch, working good enough for years without creating any new
> (practical) issues. In comment #161 is was proposed to make it configurable
> option to make everyone happy and let users choose between using compliant
> protocol or working hotkeys.

Where is the link to the patch? Where is the instruction like how to apply this patch? And how can this comment be used by an ordinary user (without knowledge of programming) to solve this problem?

(In reply to k0fe from comment #185)
> (In reply to Alex Efros from comment #184)
> > There is a patch, working good enough for years without creating any new
> > (practical) issues. In comment #161 is was proposed to make it configurable
> > option to make everyone happy and let users choose between using compliant
> > protocol or working hotkeys.
>
> Where is the link to the patch? Where is the instruction like how to apply
> this patch? And how can this comment be used by an ordinary user (without
> knowledge of programming) to solve this problem?

As an ordinary Gentoo Linux user, I:
- download patch attached to this issue named "The same patch, but based on 1.19.1 (fixed)" into directory /etc/portage/patches/x11-base/xorg-server/
- run `emerge xorg-server` to reinstall Xorg with this patch applied
- restart X to enjoy working hotkeys :)

If users of other Linux distributions have issues with this - probably they just didn't use "newer Linux". </sarcasm>

(In reply to Kovács Viktor from comment #181)
> Sorry, on newer Linux you can set up hot key combination for that problem as
> graphical UI settings, older Linux versions will not be updated. May I close
> It?

Please do not close this bug. If you do not want to receive any further updates on it, you can unsubscribe by removing yourself from the Cc list.

(In reply to Alex Efros from comment #186)
> (In reply to k0fe from comment #185)
> > (In reply to Alex Efros from comment #184)
> > > There is a patch, working good enough for years without creating any new
> > > (practical) issues. In comment #161 is was proposed to make it configurable
> > > option to make everyone happy and let users choose between using compliant
> > > protocol or working hotkeys.
> >
> > Where is the link to the patch? Where is the instruction like how to apply
> > this patch? And how can this comment be used by an ordinary user (without
> > knowledge of programming) to solve this problem?
>
> As an ordinary Gentoo Linux user, I:
> - download patch attached to this issue named "The same patch, but based on
> 1.19.1 (fixed)" into directory /etc/portage/patches/x11-base/xorg-server/
> - run `emerge xorg-server` to reinstall Xorg with this patch applied
> - restart X to enjoy working hotkeys :)
>
> If users of other Linux distributions have issues with this - probably they
> just didn't use "newer Linux". </sarcasm>
I'd like to thank you! And great thanks to kyak for the patch!
I confirm that it works for me on "older" Gentoo and xorg-server 1.9.5.

There seems to have been a proposed protocol extension (comment #159 etc.) Can anyone shed light, for the outside user, as to the current status of this proposal? Thanks.

(In reply to Zebediah Figura from comment #189)
> Can anyone shed light, for the outside user, as to the current status of
> this proposal? Thanks.
No news since. Apart from the formal proposal, there are some old patches for its implementation:
https://lists.x.org/archives/xorg-devel/2012-November/034427.html
https://lists.x.org/archives/xorg-devel/2012-November/034430.html
https://lists.x.org/archives/xorg-devel/2012-November/034429.html
https://lists.x.org/archives/xorg-devel/2012-November/034431.html
https://lists.x.org/archives/xorg-devel/2012-November/034428.html

(In reply to Andreas Wettstein from comment #190)
> No news since. Apart from the formal proposal, there are some old patches
> for its implementation:
> https://lists.x.org/archives/xorg-devel/2012-November/034427.html
> https://lists.x.org/archives/xorg-devel/2012-November/034430.html
> https://lists.x.org/archives/xorg-devel/2012-November/034429.html
> https://lists.x.org/archives/xorg-devel/2012-November/034431.html
> https://lists.x.org/archives/xorg-devel/2012-November/034428.html

Here's what I think we would need to do in order to not break old clients:
https://lists.freedesktop.org/archives/xorg-devel/2013-January/035049.html

Another, probably better, way to do it would be to define a new flag like XkbSA_HasGroupFlags inside the XkbModAction flags field when group_flags and group_XXX are valid rather than potentially garbage. That would avoid the whole version-negotiation nightmare, as nothing appears to be too picky about extra flags being defined.

Five years later, it would also be good to have support inside libxkbcommon (which has a pretty decent test suite) and xcb-proto for the flags.

(In reply to Alex Efros from comment #184)
> There is a patch, working good enough for years without creating any new
> (practical) issues. In comment #161 is was proposed to make it configurable
> option to make everyone happy and let users choose between using compliant
> protocol or working hotkeys.

(In reply to Aliaksei Urbanski from comment #188)
> I'd like to thank you! And great thanks to kyak for the patch!
> I confirm that it works for me on "older" Gentoo and xorg-server 1.9.5.

I could to say, that this patch does not work exactly as expected. See, please, my comment #146 for explanation. So I think, this thread could not be closed.

Another user here voting for this bug to get patched OFFICIALLY from upstream.

Did you changed your opinion after for years of not fixing this bug?

Users still need this functionality (see https://community.ubuntu.com/t/keyboard-layout-switching-problems-and-poll/2876 and https://askubuntu.com/q/1009352/66509 as examples).

All current Ubuntu versions are affected and RHEL too. And nobody cares.

14 years of doing nothing. My congratulations!

(In reply to Daniel Stone from comment #191)
> Another, probably better, way to do it would be to define a new flag like
> XkbSA_HasGroupFlags inside the XkbModAction flags field when group_flags and
> group_XXX are valid rather than potentially garbage. That would avoid the
> whole version-negotiation nightmare, as nothing appears to be too picky
> about extra flags being defined.
>
> Five years later, it would also be good to have support inside libxkbcommon
> (which has a pretty decent test suite) and xcb-proto for the flags.

This comment lays out the best way forward for anyone interested to fix this bug. It shouldn't be too difficult, but personally I haven't worked on X11 for quite some time.

Just tested simple idea on Ubuntu 16.04.4 LTS with MATE DE.
Out-the-box it has Xorg 1.18.4 which perfectly allow user to set for example <Ctrl+Shift> keyboard shortcut for keyboard layout switching.
But when I install HWE on 16.04 LTS I get newer Xorg 1.19.5.

Debian 8 (Xorg 1.16.4) and 9 (Xorg 1.19.2) have this problem too (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891915 ).

So versions 1.16.4, 1.19.2 and 1.19.5 should be patched to bring <Ctrl+Shift> keyboard shortcut functionality back.

Did somebody tested Russian rulemak keyboard layout? It is between the extra layouts. It is based on russian layout with latin letters. I' m not a russian man, but I think, just testing first is a good idea!

Viktor, could you please elaborate how exactly that may be useful here?

I would also like to ask you to make sure you contribute useful content to this discussion, or if you cannot, resist from posting. I don’t think it helps anyone to to support flamewars in this bug report, or even make the discussion longer than necessary.

Norbert (nrbrtx) on 2018-04-07
tags: added: artful bionic trusty xenial

FYI the bug may be temporarily fixed on Ubuntu 16.04 LTS (with HWE), Ubuntu 18.04 LTS (and Mint 19) using packages from my PPA ( https://launchpad.net/~nrbrtx/+archive/ubuntu/xorg-hotkeys or " ppa:nrbrtx/xorg-hotkeys " ). It contains patched Xorg (with patch from kyak - https://aur.archlinux.org/packages/xorg-server-bug865/ ). Thank you very much again, kyak!

And it is unbelievable that we need to patch core graphical system component by ourselves to use traditional keyboard shortcuts ...

Displaying first 40 and last 40 comments. View all 281 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.