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

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

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.

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

    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

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)

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?

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

another good article about XKB

http://pascal.tsu.ru/en/xkb/setup.html

(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

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

(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

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.

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

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/258.

Thanks for providing here attachments of Linux given and Assignee by Xorg Project Team.

Ida,
As an assignment writer, give assistance with psychology homework - http://www.assignmenthelpfolks.com/psychology/ at all university levels at Assignment Help Folks in Australia.

I like the helpful info you supply to your articles. I’ll bookmark your blog and take a look at once more here frequently. I am somewhat sure I will be told plenty of new stuff right right here! Good luck for the following!

https://www.writecdr.com/ipenz-ka02-new-zealand-skilled-migration/
https://www.writecdr.com/acs-rpl-report-samples/

An extensive yet tactical take on your Career Episodes can help represent everything that makes you an asset to the Engineers Australia. Career Episodes can open those closed doors comfortably. They demonstrate the key skills, the experience, and the expertise you bring along in your engineering domain. Every one of the three episodes is required to touch base on unique projects and experiences, and your role, and strategies. At CDRReport, we have that expertise to make your Career Episodes sound valid and convincing.
https://www.cdrreport.org/cpd-examples-samples/
https://www.cdrreport.org/how-to-create-a-perfect-resume-for-engineers-australia/

Hi! I have the same issue i would like to know the solution

Castro B,
gratisdatingsite.nl

It is not a bug, its a feature. To speed up the typing. Set the layout change on CapsLock. (In a case you need old caps behavior, you get it with shift + Caoslock)