Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 660254 - When using multiple layout, XKB eats keyboard shortcuts that start with the layout switching shortcut
When using multiple layout, XKB eats keyboard shortcuts that start with the l...
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
29
All Linux
low Severity high
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: Reopened, Triaged
: 1339261 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-06 04:17 EST by Oded Arbel
Modified: 2018-08-14 07:11 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-08 07:39:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Oded Arbel 2010-12-06 04:17:16 EST
Description of problem:
Users with multiple keyboard layouts often setup a keyboard shortcut to switch between layouts. This is done on the X.org server level and often uses a combination of shift-keys, such as ALT+SHIFT or CTRL+SHIFT. When such a combination is used, any other keyboard shortcuts that are defined by the application and use a superset of shift-keys are no longer accessible because XKB acts on the layout switching combination on key-down and won't let the user complete the application shortcut.

For example - a common layout switching combination is ALT-SHIFT (used for MS-Windows compatibility) while ALT-SHIFT-TAB is the default "switch to previous window" shortcut in most window manager. With that setup a user can never use the "switch to previous window" action because as soon as the user holds down ALT and SHIFT together, XKB switches layout and effectively simulates the release of the shift-keys. When TAB is then clicked it does nothing.

The problem is even more serious if the user chooses CTRL-SHIFT as the layout switching shortcut (which is common on Europe) as a many applications use CTRL-SHIFT keyboard shortcuts, for example: Eclipse.

Version-Release number of selected component (if applicable):
xorg-x11-server-1.9.1-3

How reproducible:
Always

Steps to Reproduce:
1. Setup multiple keyboard layouts (for example - English and French)
2. Setup ALT-SHIFT as the keyboard layout switching sequence
3. Try to use ALT-SHIFT-TAB to switch to the previous window
  
Actual results:
The keyboard layout changes

Expected results:
The previous window should become active.

Additional info:
This bug has been discussed on the Freedesktop.org Bugzilla as bug #865 : http://bugs.freedesktop.org/show_bug.cgi?id=865 and a patch was offered by Ilya Murav'jov. The patch was tested by many users and was found useful and with no adverse effects. X11 developers have apparently decided not to apply this patch because the problematic behaviour is exactly according to the XKB 1 specs and they hope to solve it with XKB 2 (for which there currently is no viable roadmap for inclusion into an X.org release).

Fixing this will offer a massive improvement in desktop behaviour for multi-lingual users. Also please see Launchpad bug 36812 ( https://bugs.launchpad.net/xorg-server/+bug/36812 ) for a longer discussion on the subject.

I've build a patched version of the Fedora 14 X.org server and it looks to be working fine for me on Fedora 14. The source RPM is available here: http://rpms.geek.co.il/fc14/SRPMS/xorg-x11-server-1.9.1-3.1.fc14.src.rpm and binaries for x86_64 can be downloaded from http://rpms.geek.co.il/fc14/x86_64/
Comment 1 Matěj Cepl 2010-12-07 06:30:12 EST
(In reply to comment #0)
> X11 developers have apparently decided not to apply this patch
> because the problematic behaviour is exactly according to the XKB 1 specs and
> they hope to solve it with XKB 2 (for which there currently is no viable
> roadmap for inclusion into an X.org release).

Passing this to our developers, but given that Peter is the main upstream developer of input stuff in X as well (IIRC), I don't expect much better chance of success here.
Comment 2 Dmitry Bolkhovityanov 2011-01-02 11:38:17 EST
(In reply to comment #1)
> Passing this to our developers, but given that Peter is the main upstream
> developer of input stuff in X as well (IIRC), I don't expect much better chance
> of success here.

That's really sad news.
Current behaviour makes input in native language EXTREMELY inconvenient. At least here, in Russia, the Ctrl+Shift and Alt+Shift are a de-facto standard, but setting those as layout switchers renders too many key combos unusable.
So, anybody using both Linux and Windows faces a sorrowful dilemma: either experience permanent cognitive dissonance, or just waive ability to use native language in Linux.

Current behaviour is here only because of historical reasons -- it has no benefits, only drawbacks.
If changing from "upon-press" to "upon-release" contradicts with XKB spces, then the SPECS should be changed.

C'mon, guys -- this is a really huge problem for multilingual people, and modifying the unreasonable specs is a negligible price for fixing it.
Or, if officially updating the specs is a long process -- let's just apply the aforementioned tiny patch.

Present situation is plainly weird...
Comment 3 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.
Comment 4 Dmitry Bolkhovityanov 2011-01-06 03:23:05 EST
(In reply to comment #3)
> there is two problems with the "tiny" patch you mentioned. one, it's an
> _explicit_ violation of the XKB specification (see section 4.4).

The XKB spec is lame here.  This reasonable requirement (to react upon release, not only upon press) was simply forgotten.

Yes, applying that patch without updating the XKB spec will be an explicit spec violation.

But: doesn't fixing of a huge problem have a priority over preservation of a "holy spec"?

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

Let me repeat: current switch-on-press is a TREMENDOUS problem.  Leaving it as is would be a plain discrimination of multilingual people.

And leaving the design bug because of purist reason looks really strange...
Comment 5 Dmitry Bolkhovityanov 2011-01-06 03:34:00 EST
P.S. Peter, I really understand your concerns.  Both the spec violation and potential side-effects don't sound good.

Unfortunately, leaving the current behaviour is even much worse. :-(
Comment 6 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 really strange...

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


also, I realise I should have written all this in the upstream bug. Feel free to copy my comment there, I'm CC'd on it anyway.
Comment 7 Oded Arbel 2011-01-08 08:43:12 EST
Regarding the spec behavior: the only comment from any Xorg developer on the freedesktop.org bug trackers seems to be that the spec should be updated anyway.

Regarding testing - there was some testing going on already with people who patch Xorg themselves or used pre-patched binaries and the launchpad bug linked above has a lot of positive feedback for this.

Additionally Ubuntu has now accepted the patch for their next release (11.04) so it will get a lot more testing.

Regarding the the technical issues - I don't understand much of what you said, but I'll copy that to the freedesktop.org tracker, and maybe the developer of the patch can figure out how to address these.
Comment 8 wayfarer 2011-02-11 17:53:26 EST
Here is info from patch author Ilya Murav'jov published in freedesktop bugzilla (https://bugs.freedesktop.org//show_bug.cgi?id=865#c81):

Ok, I try to answer here, but I should note that I don't remember full details
(because it was more than half a year ago).

> The following comments were made by Peter Hutterer (an X.org input developer)
> on the corresponding bug in RedHat bugzilla (
> https://bugzilla.redhat.com/show_bug.cgi?id=660254 ):
> (In reply to comment #6)
> > implementing this behaviour requires guesswork that I'm not sure is safe in a
> > number of setups.
> ...
> > 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.

I do not agree. You do not need to know/guess which modifiers to set - whenever
ISO_Next_Group is pressed I just don't execute it immediately but delay it till
a key release (by the means of _XkbNextFreeFilter()/_XkbApplyFilters() ). Btw,
that trick was suggested by Daniel Stone (somewhere on the mail list).

And I want to note that where I comment ":KLUDGE:" I mean a different thing: in
theory that branch of code should do the same thing as the switch in
XkbHandleActions() ; but, in practice I see (and want) only XkbSA_SetMods
action (so kludge here is copy-n-paste from XkbHandleActions() ). 

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

(do not understand properly the above, sorry) The only situation the patch
fails
(just behaves old way, and nothing more!) is when switching is set up as just
one key like "Right Alt". That is because of the line
   fake_state.mods = 0;
, mods here is 0 anyway => we can't block XkbSA_LockGroup .

Anyway, nobody wants more,- but only (de facto standard) Ctrl+Shift and
Alt+Shift on release. I think this is the situation where the practice begins
and the theory ends.
Comment 9 Oded Arbel 2011-10-29 09:52:38 EDT
I just wanted to ping about the status of this bug, sorry for the bug spam. 

Here's the summary of the status as I understand it:
1. There's a patch provided in the upstream tracker.
2. The patch has been tested in Fedora releases without adverse affects by interested parties.
3. Another major distribution - Ubuntu - has applied the bug and has made two releases already with this functionality enabled by default. People are happy with it and there were no regressions reported.
4. Work to apply this patch in Fedora is minimal - the patch applies cleanly against current Xorg and there is no additional work required.

Except for some theoretical discussions about whether the break from specification is important or not, is there anything preventing Fedora from applying this and advancing the accessibility for international users?
Comment 10 Peter Hutterer 2012-06-26 02:10:00 EDT
This bug was filed against Fedora 14 which is now EOL. Please re-open this bug if you still experience this issue with one of the currently suppported versions of Fedora. Don't forget to update the version field if you do so.
Comment 11 Oded Arbel 2012-06-27 13:42:27 EDT
This problem still exist in Fedora 18.
Comment 12 Jens Petersen 2012-09-13 06:07:26 EDT
I F18 I see that by default (meaning using @basic-x-windows) or
xinit if you like, that Alt+Shift maps to ISO_Next_Group which
sounds very similar to the symptoms described above.
(Alt-Shift works normally on kernel of course.)

This means that eg Alt-! does not work in Emacs and
Alt-Shift-Return does not work for xmonad, etc, etc.

But if it is a different issue I will file a new bug.
Comment 13 Jens Petersen 2012-11-05 23:34:25 EST
(In reply to comment #12)
> I F18 I see that by default (meaning using @basic-x-windows) or
> xinit if you like, that Alt+Shift maps to ISO_Next_Group which
> sounds very similar to the symptoms described above.
> (Alt-Shift works normally on kernel of course.)
> 
> This means that eg Alt-! does not work in Emacs and
> Alt-Shift-Return does not work for xmonad, etc, etc.
> 
> But if it is a different issue I will file a new bug.

My problem is/was probably something else: f18 anaconda has
been setting up Alt+Shift as a layout switcher, though
Gnome at least overrides this.
Comment 14 Fedora End Of Life 2013-04-03 16:12:03 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 15 Dmitry Bolkhovityanov 2013-06-22 05:10:07 EDT
Guys, what is the current status of this bug?
It will be a pity to have it sink as "WONTFIX" because of auto-bug-zapping.
Or should it also be reported against RHEL6?
Comment 16 Oded Arbel 2014-09-09 07:07:08 EDT
For any user migrating from Ubuntu or some other distro that packages the patches from the FreeDesktop.org bug report, and are annoyed that Fedora doesn't -

I've setup a copr repo with the patch for Fedora 21 and Rawhide:

$ sudo dnf copr enable guss77/xorg-patches
$ sudo dnf upgrade

If there is any interest I can build packages for other releases.
Comment 17 Fedora End Of Life 2015-01-09 16:46:37 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 18 Oded Arbel 2015-01-12 03:30:10 EST
This is still an issue with Fedora 21
Comment 19 Fedora End Of Life 2015-11-04 10:44:17 EST
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 20 Dmitry Bolkhovityanov 2015-11-04 23:31:14 EST
Still an issue with RHEL7.

Maybe change Product/Version from Fedora/21 to RHEL/7?


P.S. And regarding the "Priority": it is not "low", it is in fact EXTREMELY high!
It is definitely a non-issue for english-speakers (that's why this bug exists for so long), but is a TREMENDOUS problem for non-latin people.
Comment 21 Fedora End Of Life 2015-12-01 21:34:18 EST
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 22 Oded Arbel 2015-12-02 01:54:53 EST
Still experiencing this on Fedora 23. 

This is a bug for which there is a well tested patch that is integrated in Ubuntu and other distros. Its a shame Fedora chooses not to integrate it.
Comment 23 Jan Kurik 2016-02-24 10:53:11 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Comment 24 Yan Pas 2016-03-04 16:14:34 EST
Workaround - install gxneur + xneur and use shortcuts in this program. Also, is Red Hat going to fix this issue? Very annoying!
Comment 25 Peter Hutterer 2016-06-13 01:49:54 EDT
*** Bug 1339261 has been marked as a duplicate of this bug. ***
Comment 26 Romik Forest 2017-02-23 15:35:27 EST
Still an issue with Fedora 25.

International input is critical for me, and it is not working well on Fedora (not only xorg has problems)
Comment 27 Fedora End Of Life 2017-07-25 14:28:37 EDT
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 28 Dmitry Bolkhovityanov 2017-08-01 01:53:55 EDT
This bug is still an issue in RHEL7.

Please, please, please change the "Product" to RHEL version 7.
Comment 29 Fedora End Of Life 2017-08-08 07:39:19 EDT
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 30 Fedora End Of Life 2018-05-03 04:10:54 EDT
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 31 Jan Kurik 2018-08-14 07:11:38 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Note You need to log in before you can comment on or make changes to this bug.