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
446
This bug affects 81 people
Affects Status Importance Assigned to Milestone
X.Org X server
In Progress
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
128 comments hidden view all 208 comments

I don't know what they have done in Ubuntu but 12.04 understands both press and release. Layout switching happens on release. If you press Alt you see the global menu and after release HUD uppears. Looks like everything has been fixed. But if you use Ctrl or Alt for layout switching you still can't use this key for anything more, it's "exclusived" :( So ridiculous.

(In reply to comment #108)
> I don't know what they have done in Ubuntu but 12.04 understands both press
> and release. Layout switching happens on release.

Ubuntu have simply applied Ilya's patch (one of the revisions attached here) to fix the layout switching problem.

> If you press Alt you see
> the global menu and after release HUD uppears.

This is a different behavior and one that works with the pristine X.org server - the ALT key, when used without any other shift keys, fires "down" when pressed and "up" when released. The Ubuntu HUD listens for this sequence and triggers when ALT is used like that without any other shift key.

The problematic behavior (as documented in this lengthy bug report - kitates, please read the discussion), is that when you press down on the second shift key, X.org fires the keyboard layout change (problem 1) and also immediately fires the "up" event for the second shift key, even though the user is still holding the key down (problem 1).

Problem 1 means that when the user wants to use <shift1>+<shift2>+<key> as a keyboard shortcut (when "shift1" and "shift2" are the shift keys used for layout switching, for example ALT+SHIFT or CTRL+ALT), then the user will inadvertently also trigger a layout switching that wasn't supposed to happen.

Problem 2 means that the actual keyboard shortcut will never actually trigger because when the user holds down <key>, even though all keys are physically held down X.org only acknowledges that <shift1> and <key> are held down.

> Looks like everything has
> been fixed. But if you use Ctrl or Alt for layout switching you still can't
> use this key for anything more, it's "exclusived" :( So ridiculous.

It shouldn't work like that - I've tested the Ubuntu built X.org (with Ilya's patch) and it worked properly when using CTRL+ALT as the keyboard switching. It was immediately after the patch got accepted (at 11.04) but as ALT+SHIFT still works fine, I don't see a reason everything shouldn't continue to work (though I don't have access to an Ubuntu machine ATM to test).

(In reply to comment #107)

> A Windows-only compose key program uses the "ctrl" key as the compose key.
> This is apparently impossible to do in X input methods because you can only
> bind actions to the press of "ctrl".

Of course this is possible. Compose is unrelated to actions in the XKB meaning of the term. It is not only possible, it is even implemented in the XIM compose code. You can put

  <Control_L><a><e> : ae

and similar stuff in your .XCompose, and your left control key acts as a Compose key. But you need the latest libX11 for this.

I'm really disappointed this change didn't make it to 1.13.
I'm sick and tired of applying this patch after each xorg update.

How many users (and years) do you need to finally accept this change?

I believe the most serious objection with this request is that it violates the XKB specification (see the description of SA_LockGroup in section 6.3 of "The X Keyboard Extension: Protocol Specification").

In the same specification, in section 4.0 of appendix D ("Protocol Encoding"), we see in the description of SA_LockGroup that there are still 5 unused bits in the flags field. My proposal in to use one of these bits decide whether to lock groups on press or release. By default (bit is zero), lock groups on press as the protocol specification demands. If the flag is one, lock groups on release. So by default, we would conform to the specification, and add the alternative behaviour as a new possibility beyond the specification.

There are some usage implications. One must use 'Private' do create actions with the new flag set (until xkbcomp is updated as well), and one needs support in xkeyboard-config to make the new feature usable for non-XKB-hackers.

(In reply to comment #112)
> I believe the most serious objection with this request is that it violates
> the XKB specification (see the description of SA_LockGroup in section 6.3 of
> "The X Keyboard Extension: Protocol Specification").
>
> In the same specification, in section 4.0 of appendix D ("Protocol
> Encoding"), we see in the description of SA_LockGroup that there are still 5
> unused bits in the flags field. My proposal in to use one of these bits
> decide whether to lock groups on press or release. By default (bit is
> zero), lock groups on press as the protocol specification demands. If the
> flag is one, lock groups on release. So by default, we would conform to the
> specification, and add the alternative behaviour as a new possibility beyond
> the specification.
>
> There are some usage implications. One must use 'Private' do create actions
> with the new flag set (until xkbcomp is updated as well), and one needs
> support in xkeyboard-config to make the new feature usable for
> non-XKB-hackers.

Thanks Andreas, your answer pretty much clarifies everything for me!

Your proposal is very correct, no doubt. Does it mean that once your proposal is implemented all 3rd-party keyboard switchers (like those in Gnome and KDE) would have to be updated to make use of this new possibility?

Anyway, as i see it, there are two ways to go:
1) The long way - making things right and according to specification. This would take from very long to forever (this is the way we've been going for the last 8 years with this bug report).
2) Take a short way - let the common sense win over specification and make everybody happy.

> Your proposal is very correct, no doubt. Does it mean that once your
> proposal is implemented all 3rd-party keyboard switchers (like those in
> Gnome and KDE) would have to be updated to make use of this new possibility?

As far as I understand, KDE and Gnome all use xkeyboard-config, and just provide their own GUI. If this is understanding is correct, the changes to xkeyboard-config would be sufficient.

> Anyway, as i see it, there are two ways to go:
> 1) The long way - making things right and according to specification. This
> would take from very long to forever (this is the way we've been going for
> the last 8 years with this bug report).

Assuming the existing patch is correct, adding the additional check for the flag is just a few lines. The changes to xkeyboard-config would be fairly simple. Assuming we grab bit 3 for the new flag, in xkeyboard-config/compat/iso9995, change the current definition:

  interpret ISO_Next_Group {
      useModMapMods= level1;
      virtualModifier= AltGr;
      action= LockGroup(group=+1);
  }

to

  interpret ISO_Next_Group {
      useModMapMods= level1;
      virtualModifier= AltGr;
      action= Private(type=6, data[0]=16, data[1]=1);
  }

(untested, of course), and similarly for ISO_Prev_Group, ISO_First_Group, and ISO_Last_Group. I do not know wether the action bound to keysyms is standardised; even if it is not, it might be a good idea to make the above redefinition conditional.

> 2) Take a short way - let the common sense win over specification and make
> everybody happy.

Believe it or not, I would be unhappy when the specification would be broken. Also remember that the attitudes in this discussion are not necessarily representative of all X users, as the users satisfied with the current behaviour do not have any reason to even know about this discussion.

(In reply to comment #109)
> (In reply to comment #108)
> > Looks like everything has
> > been fixed. But if you use Ctrl or Alt for layout switching you still can't
> > use this key for anything more, it's "exclusived" :( So ridiculous.
>
> It shouldn't work like that - I've tested the Ubuntu built X.org (with
> Ilya's patch) and it worked properly when using CTRL+ALT as the keyboard
> switching. It was immediately after the patch got accepted (at 11.04) but as
> ALT+SHIFT still works fine, I don't see a reason everything shouldn't
> continue to work (though I don't have access to an Ubuntu machine ATM to
> test).

Oded Arbel, I repeat: Ctrl OR Alt. OR, not AND. I use right Alt for layout switching so I can't use it for any other purpose.

(In reply to comment #115)
> > It shouldn't work like that - I've tested the Ubuntu built X.org (with
> > Ilya's patch) and it worked properly when using CTRL+ALT as the keyboard
> > switching. It was immediately after the patch got accepted (at 11.04) but as
> > ALT+SHIFT still works fine, I don't see a reason everything shouldn't
> > continue to work (though I don't have access to an Ubuntu machine ATM to
> > test).
>
> Oded Arbel, I repeat: Ctrl OR Alt. OR, not AND. I use right Alt for layout
> switching so I can't use it for any other purpose.

Hi,
Actually, the patch works for key shortcuts with two or more buttons (like ALT+SHIFT, but not Alt or Ctrl alone). It is not done intentionally.

Despite the fact that there is a possibility to improve current patch behaviour for needs like yours I don't think it should be improved for all possible cases -
there are many other things to be done to make the world a better place.

Created attachment 69198
LockMods can lock another group

This patch follows a different route: It extends modifier locking, rather than changing how group lock works. Extending has the advantage that the previous behaviour is maintained, and the patch does not violate the X Keyboard Protocol Specification. Extending modifier locking rather than group locking has the advantage that we do not need the "Kludge" of the other patch, as we can pass the modifiers that we want to set, rather then relying on heuristics.

The disadvantage over the existing patch is that we must change the keymap.

Here are three examples. The left alt key is to switch to the next layout when it is pressed and released before any other key is pressed.

    key <LALT> {
        repeat= No,
        type= "TWO_LEVEL",
        symbols[Group1]= [ Alt_L, Meta_L ],
 actions[Group1]= [ Private(type=3,data[0]=1,data[1]=8,data[2]=8,data[3]=0,data[4]=0,data[5]=0,data[6]=1),
                    Private(type=3,data[0]=1,data[1]=8,data[2]=8,data[3]=0,data[4]=0,data[5]=0,data[6]=1) ]
    };

Similarly, shifting group with Shift+Right Alt (where Shift is pressed first):

Similarly, shifting group with Shift+Right Alt (where Shift is pressed first):

  key <RALT> {
        repeat= No,
        type= "TWO_LEVEL",
        symbols[Group1]= [ Alt_R, Meta_R ],
 actions[Group1]= [ SetMods(modifiers=Mod1),
                    Private(type=3,data[0]=1,data[1]=8,data[2]=8,data[3]=0,data[4]=0,data[5]=0,data[6]=1) ]
    };

Shifting group with Shift+Left Control:

    key <LCTL> {
        repeat= No,
        type= "TWO_LEVEL",
        symbols[Group1]= [ Control_L, Control_L ],
 actions[Group1]= [ SetMods(modifiers=Control),
                    Private(type=3,data[0]=1,data[1]=4,data[2]=4,data[3]=0,data[4]=0,data[5]=0,data[6]=1) ]
    };

(In reply to comment #117)
> Similarly, shifting group with Shift+Right Alt (where Shift is pressed first):

Is this mean your patch won't work when Alt (or Ctrl) is pressed before Shift?
AFAIK most people press Ctrl, then Shift, then either release them (to switch layout) or press A-Z when they need Ctrl-Shift-something hotkey.

> Is this mean your patch won't work when Alt (or Ctrl) is pressed before
> Shift?

It does not mean that. I just restricted to three examples. There is no problem to rewrite all options that xkeyboard-config offers to switch groups to take advantage of the patch.

> AFAIK most people press Ctrl, then Shift, then either release them (to
> switch layout) or press A-Z when they need Ctrl-Shift-something hotkey.

In this case, one needs to remap the shift key. For the left shift key:

    key <LFSH> {
        repeat= No,
        type[Group1]="PC_CONTROL_LEVEL2",
        symbols[Group1]= [ Shift_L, Shift_L ],
 actions[Group1]= [ SetMods(modifiers=Shift),
                    Private(type=3,data[0]=1,data[1]=1,data[2]=1,data[3]=0,data[4]=0,data[5]=0,data[6]=1) ]
    };

For the right shift key it works similarly. If combined with the third example above, it will make the order of Shift and Control irrelevant.

Created attachment 69213
LockMods can lock another group

My previous patch does not properly account for absolute group specification. The revised patch corrects this.

Just to add something as a reply on comment #114:

Ubuntu has applied this patch already since 06 Jan 2011 all versions till nowadays, as you can see in the changelogs here:

http://packages.ubuntu.com/quantal/xserver-xorg-core
Select "Ubuntu Changellog" and then search for "208_switch_on_release.diff".

Even after almost two years, there has been noone to file a bug report that this change breaks anything. I believe this is quite a good indication that Ilya's patch is already safe enough.

I have to recompile xorg-server on ubuntu because of this patch. It may be useful for layout switching with only modifier keys, but key-on-release behavior is unreliable while typing.

Denis,
What do you mean that "key-on-release behavior is unreliable while typing"? Please describe.

Evgeny Kolesnikov (evgenyz) wrote :

Typing so fast that keys release events happen in different order than press events? Typing with chords?

For example, if I press a key (letter, backspace or other) and then layout switch combination without half second pause between, then layout wont be changed.
To switch between layouts I use "caps/shift+caps" combination. It's not a "modifier only" combination, but still affected by 208_switch_on_release.diff patch. In Windows even alt+shift combination work perfectly.

My English is bad. So can I e-mail you details in Russian?

Just my 0.02 cents. Why not to introduce "transaction" concept for key presses?

1. Transaction is finished when the last key is released
2. The returned result from the transaction is the sequence of keys pressed

This should solve all [Alt, Shift] problems.

Example:
  user presses Alt key
  user presses Shift key and releases it
  user presses Shift key
  user releases Alt key
  user releases Shift key

The returned sequence is [Alt, Shift, Shift]

Ilya Murav'jov (muravjov-il) wrote :

> My English is bad. So can I e-mail you details in Russian?
Ok, but I am far away from playing with Xorg now.

Ilya Murav'jov (muravjov-il) wrote :

> Just my 0.02 cents. Why not to introduce "transaction" concept for key presses?
You just go too far. Xorg developers don't apply the patch because _any_ such events should be sent on press, not on release. Because X specifications tell so and they will be broken down otherwise.

Ilya Murav'jov (muravjov-il) wrote :

And if X specifications are broken down then some applications may be potentionally broken down.

It is xorg-server 1.14, year 2013, and the bug still exists.

Do something with it already...

I wonder, bearing in mind the fact that Ubuntu has the patch for the problem, will Mir be the first Linux display server which implemet this feature? :)

(In reply to comment #124)
> I wonder, bearing in mind the fact that Ubuntu has the patch for the
> problem, will Mir be the first Linux display server which implement this
> feature? :)

You've wandered far off.

Both Mir and Wayland have a completely different input architecture - they simply don't have this problem from the very beginning.

I've just installed OpenSuse 12.3 and met face to face with this bug. Very frustrating, because of it I can't open last closed tab in chromium with ctrl+shift+t.

Constantine (theaspect) wrote :

Appears again in Ubuntu 13.10

It stooped working again

Oded Arbel (oded-geek) wrote :

This issue is still solved for me - test if the fix still works by holding slowly ALT then SHIFT then some letter key, then release all one by one - if the keyboard layout has not changed, then the issue is still resolved.

Volodya (volodya) wrote :

Ubuntu 13.10 does not work. Willing to help by providing any requested information

Lisio (lisio) wrote :

Ubuntu 13.10 has exactly the same bug.

Igor Gnatenko, I partly solve my problem via KSuperKey app http://kde-apps.org/content/show.php?content=154569
so maybe it solve your needs too.

But I also waiting fix for this issue in xkb.

Download full text (3.4 KiB)

As far as I can tell, it is already clear that XKB specifications needs to be extended for this to be cleanly solved. While Ilya's hack works for many people, and as much as I would like to see this fixed, I understand why it is unacceptable to the developers. So, trying to delve into XKB specs now; this page seems to be a good starting point to me:

https://wiki.archlinux.org/index.php/X_KeyBoard_extension

Also (as suggested by the author), copying info here from https://bugzilla.redhat.com/show_bug.cgi?id=660254

Peter Hutterer 2011-01-05 22:07:57 EST

there is two problems with the "tiny" patch you mentioned. one, it's an _explicit_ violation of the XKB specification (see section 4.4). two, implementing this behaviour requires guesswork that I'm not sure is safe in a number of setups.

Peter Hutterer 2011-01-06 17:12:05 EST

(In reply to comment #4)
> But: doesn't fixing of a huge problem have a priority over preservation of a
> "holy spec"?

it's a matter of figuring out the side-effects. a specification is a behaviour promise, in this case in place for 15 years or so. a lot of users and apps rely on the promised behaviour (in general, not necessarily this specific issue) and breaking it is a dangerous thing because you may not know what else you break.
this is why we're hesitant to break the behaviour on purpose.

note that i'm not claiming that there is no problem, i'm just saying it's the balance between a known problem and introducing new bugs that potentially break current applications.

> > two,
> > implementing this behaviour requires guesswork that I'm not sure is safe in a
> > number of setups.
>
> What guesswork do you mean? Which setups can present problems?
> BTW, I'm 100% sure that Ilya Murav'jev (patch author) will be glad to
> cooperate.

afaict, the desired behaviour for a ctrl+shift groupchange is:
ctrl down → set Control modifier
shift down → set Shift modifier
if (other key pressed)
   send event Contrl+Shift+<other key>
else if (ctrl || shift released)
   change group

The XKB map for left control in this case is:
    key <LCTL> { [ Control_L, ISO_Next_Group ] };
So whenever ISO_Next_Group is pressed, you still need to know which modifier to set in case the group action isn't executed. The XkbSA_SetMod, XkbSA_LockMod, etc. actions provide the modifiers set for a given key, hence why it works currently. This information comes from the client when the xkb map is loaded and is used to trigger the modifier flags for a given key. The XkbSA_LockGroup behaviour (which is triggered at ISO_Next_Group) does not have this field (adding it would break ABI), so you need to guess which modifiers to set if you didn't trigger this action. This is the main stumbling point that I found and if you look at Ilya's patch that's where he needs the big hack that I'm not comfortable at all with it.

Now, I don't know if there are layouts where the modifier mask would be different on the second level as opposed to the first (and Ilya's hack or a similar attempt would fail completely) but there's so many layouts that it'll take a while to get through them all.

> And leaving the design bug because of purist reason looks rea...

Read more...

(In reply to comment #129)
> As far as I can tell, it is already clear that XKB specifications needs to
> be extended for this to be cleanly solved. While Ilya's hack works for many
> people, and as much as I would like to see this fixed, I understand why it
> is unacceptable to the developers.
...
> there's two-ish ppl working on input at them moment, both are badly
> overloaded because there's a lot of bugs and plenty new features that ppl
> cry out for. so this bug has less to do with purist reasons, it's more along
> the lines of "i've got so many things to do that don't break the spec, they
> get priority".

So I understand that this issue is currently not worked on by Xorg developers.

Priorities are a good thing, and I'm currently comfortable with the pragmatic approach of the downstream distributions applying Ilya's patch in their packages (which works fine for a lot of happy users who have reported as such - I have yet to hear a report where Ilya's patch is not improving behavior for multi-language users).

Still:

1) Its a good idea to have the pragmatic patch set maintained in this bug report - even if it will never be applied to upstream Xorg, simply as a central point for downstream distributors to get access to a reasonable workaround until a "correct" solution is available.

2) It will be a real shame if this issue, that is actively discussed by the community for 10 years now and is hurting a lot of users, will be ignored for another 10 years. In the mean time XKB2 - that was supposed to be the solution to all our problems - was relegated from "being worked on" to "being thought on" to "being dreamed of" (around 2010) and now appears to have fallen to the status of "it will never be important enough".

xkb should be extended to be able to recognize a sequence of key presses and key releases and fire action upon it. Again, this would be an extension, not a violation of current standard.

Currently, the group switching is defined in /usr/share/X11/xkb/symbols/group with parts like

partial modifier_keys
xkb_symbols "lalt_lshift_toggle" {
    virtual_modifiers Alt;
    key <LALT> {
        symbols[Group1] = [ NoSymbol, ISO_Next_Group ],
        virtualMods= Alt
    };
    key <LFSH> {
        type[Group1]="PC_ALT_LEVEL2",
        symbols[Group1] = [ Shift_L, ISO_Next_Group ]
    };
};

The following is what this part of the file would look like after appropiate changes in xkb code:

xkb_sequences "lalt_lshift_toggle" {
    sequence { keydown <LALT>, keydown <LFSH>, keyup <LFSH> } = ISO_Next_Group;
    sequence { keydown <LFSH>, keydown <LALT>, keyup <LALT> } = ISO_Next_Group;
}

For this to work
1) http://www.x.org/docs/XKB/XKBproto.pdf need to be extended with a small chapter
2) http://cgit.freedesktop.org/xorg/xserver/tree/xkb - code the run time check for sequences; changes to xkm format required
3) http://cgit.freedesktop.org/xorg/app/xkbcomp/tree/ - code the parsing of "xkb_sequences", "keydown", and "keyup" keywords

At least this is my impression after a day of investigation. I know this seems like unnecessarily big change compared to Ilya's patch. But, basically, that is what I mean by "clean solution". Unfortunatelly, it is more of a "dream solution", since I feel I will hardly be able to code this..

Allowing arbitrary sequences to decide which action to take would certainly be powerful, but quite some effort, also for specification (think about multiple matching sequences).

In comment #117 I suggested an extension to the specification that is restricted to the enhancement request at hand. But even this change would need a protocol bump. This is where this proposal is stuck.

Found partial workaround today.

It _is_ possible to setup xkb so that the group (i.e. layout) switch occurs on <Shift>+<Alt> (which means press and hold Shift, then press Alt - order matters) - and still <Alt>+<Shift>+<something> (first alt, then shift, then something) shortcuts work. All this without the need to recompile xserver.

Here's what I did:

$ setxkbmap us,cz
(just load the layouts I want to the server, switching not working yet)
$ xkbcomp $DISPLAY xkbdesc
(list the xkb description from server to a file named "xkbdesc")

Now two little changes to xkbdesc:

change1:

     key <LALT> { [ Alt_L, Meta_L ] };
to
     key <LALT> { [ Alt_L, ISO_Next_Group ] };

change2:

      key <RALT> {
          type[group1]= "TWO_LEVEL",
         type[group2]= "ONE_LEVEL",
         symbols[Group1]= [ Alt_R, Meta_R ],
         symbols[Group2]= [ ISO_Level3_Shift ]
      };
to
      key <RALT> {
          type[group1]= "TWO_LEVEL",
         type[group2]= "TWO_LEVEL",
         symbols[Group1]= [ Alt_R, ISO_Next_Group ],
         symbols[Group2]= [ ISO_Level3_Shift, ISO_Next_Group ]
      };

then
$ xkbcomp xkbdesc $DISPLAY
(load kbdesc to the server; ignore the warnings)

and voila! Shift+Alt (in that order) switches us<->cz keyboard and Alt+Shift+Tab works like it should.

I was actually quite surprised when I found this.

PS: Next time you start X, you can do just the last step, supposed you keep the xkbdesc file.

Perhaps easier variant of the above workaround pertaining Alt+Shift is to comment out the following (eight) lines in /usr/share/X11/xkb/symbols/group

first change (search for "lalt_lshift"):

partial modifier_keys
xkb_symbols "lalt_lshift_toggle" {
    virtual_modifiers Alt;
    key <LALT> {
        symbols[Group1] = [ NoSymbol, ISO_Next_Group ],
        virtualMods= Alt
    };
// key <LFSH> {
// type[Group1]="PC_ALT_LEVEL2",
// symbols[Group1] = [ Shift_L, ISO_Next_Group ]
// };
};

second change (~15 lines below):

partial modifier_keys
xkb_symbols "ralt_rshift_toggle" {
    virtual_modifiers Alt;
    key <RALT> {
        symbols[Group1] = [ NoSymbol, ISO_Next_Group ],
        virtualMods= Alt
    };
// key <RTSH> {
// type[Group1]="PC_ALT_LEVEL2",
// symbols[Group1] = [ Shift_R, ISO_Next_Group ]
// };
};

then load the keymap, in my case

$ setxkbmap us,cz -option grp:alt_shift_toggle

or set it through gui (Change layout option=Alt+Shift in XFCE), or just restart X server if you've already done so

Now <shift>+<left alt> (*in that order*, i.e. first press and hold any shift, then press left alt) switches keyboard layout

<alt>+<shift> (first alt, then shift) works as a modifier (i.e. shortcuts work), and does nothing in itself

<alt>+<shift>+<tab> works as it should

It would be nice to actually have a separate "rule" for this - titled "Shift+LAlt", available with -grp:shift_lalt_toggle, but unfortunatelly I don't know how to modify the rules files..

affects: control-center (Ubuntu) → gnome-control-center (Ubuntu)
Displaying first 40 and last 40 comments. View all 208 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.