Binding ctrl+shift, alt+shift, etc for switching keyboard layout makes shortcuts with ctrl+shift, etc not working in any program

Bug #1245473 reported by kolen on 2013-10-28
362
This bug affects 77 people
Affects Status Importance Assigned to Milestone
GNOME Settings Daemon
Fix Released
Medium
GNOME Shell
Won't Fix
Medium
Unity
Confirmed
High
Unassigned
X.Org X server
Confirmed
High
firefox (Ubuntu)
Undecided
Unassigned
gnome-settings-daemon (ALT Linux)
Unknown
Unknown
gnome-settings-daemon (Debian)
New
Unknown
gnome-settings-daemon (Fedora)
In Progress
Undecided
gnome-settings-daemon (Ubuntu)
High
Unassigned
gnome-settings-daemon (openSUSE)
Confirmed
Medium
gnome-shell (Ubuntu)
Undecided
Unassigned
gnome-terminal (Ubuntu)
Undecided
Unassigned
kubuntu-meta (Ubuntu)
Undecided
Unassigned
unity (Ubuntu)
High
Unassigned

Bug Description

Tried only with ctrl+shift, maybe behaves the same for other modifier key combinations when used as shortcut for switching layouts.

- Set ctrl+shift as shortcut for switching keyboard layouts
- Try to use ctrl+shift+v, ctrl+shift+c in Terminal -- it doesn't work (actually Terminal window loses focus when ctrl+shift is pressed, and layout is switched)

----------
For other layout switching problems introduced in Ubuntu 13.10 you can see bug 1218322.
----------

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: gnome-settings-daemon 3.8.5-0ubuntu11.1
ProcVersionSignature: Ubuntu 3.11.0-13.20-generic 3.11.6
Uname: Linux 3.11.0-13-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: amd64
Date: Mon Oct 28 16:40:02 2013
InstallationDate: Installed on 2013-10-23 (5 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
MarkForUpload: True
SourcePackage: gnome-settings-daemon
UpgradeStatus: No upgrade log present (probably fresh install)

kolen (incredible-angst) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-settings-daemon (Ubuntu):
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

Thank you for your bug report.

To fix that properly we need to key grabbing to happen in unity

Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → High
Changed in unity (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Norbert (nrbrtx) wrote :

Merged bug 1246656 here. It's description was:
"In 12.04.3 I was able to use Ctrl+Shift+C and Ctrl+Shift+V for copying and pasting text in gnome-terminal even if my keyboard layout change hotkey is set to Ctrl+Shift.
In Saucy I can't use these shortcuts in gnome-terminal."

Bug exists with the latest versions of packages (gnome-control-center 1:3.6.3-0ubuntu45.1, gnome-settings-daemon 3.8.5-0ubuntu11.1).

Lockal (lockal) wrote :

Highly important for blender. Blender uses all kind of keyboard shortcuts: ctrl+alt+key, ctrl+shift+key, ctrl+alt+key, ctrl+alt+shift+key, control+space, shift+space, alt+space, ctrl+alt+space... There is an alternative way to get access to these functions, but shortcuts are essential in blender (like in vim). List of keyboard shortcuts in blender (only for 2 modes, while blender has about 10 different modes): http://wiki.blender.org/index.php?title=User:Lockal/Keyboard&action=render

kolen (incredible-angst) wrote :

Possibly caused by bug 1244090: when keys to change layout are pressed, focus moves away from application to some system app, therefore app cannot receive keypress events.

1 comments hidden view all 280 comments
Andrey (abelt) wrote :

It's probably related to fix released for bug #1218322

Andrey (abelt) on 2013-11-12
tags: added: keyboard-layout-switching-related
tags: added: keyboard-layout-switching-hotkeys
removed: keyboard-layout-switching-related
Norbert (nrbrtx) wrote :

I reported to upstream about shortcuts started from Ctrl+Shift.

Changed in gnome-settings-daemon:
importance: Unknown → Medium
status: Unknown → Won't Fix

What about CTRL+SHIFT+t in browsers? It is very annoying now going to the
menu every time you want to restore a closed tab :(

On Tue, Nov 19, 2013 at 3:34 PM, Bug Watch Updater <
<email address hidden>> wrote:

> ** Changed in: gnome-settings-daemon
> Status: Unknown => Won't Fix
>
> ** Changed in: gnome-settings-daemon
> Importance: Unknown => Medium
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1245473
>
> Title:
> Binding ctrl+shift, alt+shift, etc for switching keyboard layout makes
> shortcuts with ctrl+shift, etc not working in any program
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/gnome-settings-daemon/+bug/1245473/+subscriptions
>

--
Regards,
Yuriy Padlyak

Roland Bertolom (bertolom-1) wrote :

Maybe that will help for someone as workaround or smth. If you bind for switching keyboard layout to [left-ctrl] + [left-shift] than only [left-ctrl] + [any-shift] would not work. While [any-shift] + [right-ctrl] still works _IF_ you press [shift] first. And if you press keys in such order it, in fact, doesn't switch keyboard.

Norbert (nrbrtx) wrote :

Unable to use Ctrl+Shift+key shortcuts (for example Ctrl+Shift+arrows for selecting text) on Ubuntu 14.04 with all updates installed if keyboard layout switching is set to Ctrl+Shift.

tags: added: trusty
removed: amd64
Norbert (nrbrtx) wrote :

Did a fresh install of latest (2013-03-16) Ubuntu 14.04 image, set Ctrl+Shift as layout switch.
I unable to copy test with Ctrl+Shift+arrows, copy and paste text in gnome-terminal with Ctrl+Shift+C/V.
Tested on GNOME FlashBack session (Metacity, Compiz). But I can do this way on Unity session.

Please fix this bug before Ubuntu 14.04 final release.

tags: added: trusty-desktop
Norbert (nrbrtx) wrote :

Ctrl+Shift+PrintScreen is broken too if layout switching is set to Ctrl+Shift.

Norbert (nrbrtx) wrote :

Made a clean install of Ubuntu 14.04 beta2 ( 4cf9e5ef2c1c362317c90312c76cfda0 *ubuntu-14.04-beta2-desktop-i386.iso).

There is a big problem with shortcuts, which start from Ctrl+Shift if layout switching key is set to Ctrl+Shift in GNOME sessions (Compiz and Metacity):
1. I can't copy and paste text in gnome-terminal with Ctrl+Shift+C/V
2. I can't make Screenshot of desired area to clipboard with Ctrl+Shift+PrintScreen
3. I can't select text with Ctrl+Shift+arrows in gedit
4. I can't select text with Ctrl+Shift+arrows in LibreOffice Writer

Please fix these bugs before Ubuntu 14.04 final release.

You can see all non-latin shortcut problems in my Google Docs table (https://docs.google.com/spreadsheet/ccc?key=0Ao5e713Ig9g_dEJrX2NRYlpLWWVzSWxsVXU4ck9HYVE&usp=sharing , Sheet "!!! Non-latin shortcuts (14.04)").

Norbert (nrbrtx) wrote :

Ubuntu 14.04 with all updates for today - bug exists. Please fix it as soon as possible.

Roland Bertolom (bertolom-1) wrote :

Gmm... I updated to 14.04 just yesterday and it looks that bug vanished. Tested shorcuts in terminal (ctrl+shift+c/ctrl+shift+v) in Brackets IDE and in Firefox (ctl+shift+arrows, ctrl+shift+s). It is also looks that applications do not loose focus when layout switching.
So, I can't confirm this bug in 14.04.
P.S. It looks that PrintScreen works only for windows (alt+print) at all. But that's a different story.

Norbert (nrbrtx) on 2014-04-21
description: updated
Norbert (nrbrtx) wrote :

@Roland Bertolom
on which session you got these positive results?

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0

Let's assume for clarity that keyboard layout shortcut is set to <Ctrl+Shift>.
In previous versions of GNOME this key combination did not interfere with other hotkey combinations. But nowadays it is broken.

- Set ctrl+shift as shortcut for switching keyboard layouts
- Try to use ctrl+shift+v, ctrl+shift+c in Terminal -- it doesn't work (actually Terminal window loses focus when ctrl+shift is pressed, and layout is switched)

Steps to Reproduce (S); Actual Results (AR); Expected Results (ER)

Test case No. 1:
(S): Open gnome-terminal, type some command, try to copy the command with <Ctrl+Shift+C> and to paste it with <Ctrl+Shift+V>.
(ER): Text is copied and pasted, keyboard layout is not changed.
(AR): Text is not copied and not pasted, but keyboard layout is changed.

Test case No. 2:
(S): Open Firefox web-browser, open new tab, go to some site, close this tab, try to recover tab with <Ctrl+Shift+T>
(ER): Recently closed tab is opened, keyboard layout is unchanged
(AR): Firefox opened new tab, keyboard layout is changed

Test case No. 3:
(S): Open any text editor (gedit libreoffice Writer), type some text with several words, try to select some of that words with <Ctrl+Shift+Left Arrow> or <Ctrl+Shift+Right Arrow>
(ER): Text is selected by words, keyboard layout is not changed
(AR): Text is not selected, keyboard layout is changed

Test case No. 4:
Open Blender (see https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1245473/comments/5 for details)

Test case No. 5:
(S): Try to make a screenshot of desired window region with <Ctrl+Shift+PrintScreen>
(ER): Cursor is changed to cross, desired area is selected by user, screenshot is copied to clipboard, keyboard layout is not changed
(AR): Whole screen screenshot is saved to clipboard, keyboard layout is changed

The aforementioned test-cases works as expected on previous versions of GNOME (for example 3.4.2 in Ubuntu 12.04).

Reproducible: Always

This bug exists at least in Ubuntu (see https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1245473), RedHat 7 (https://bugzilla.redhat.com/show_bug.cgi?id=1091631), the bug is reported to upstream (https://bugzilla.gnome.org/show_bug.cgi?id=712667) with no luck.

Changed in gnome-settings-daemon (openSUSE):
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in gnome-settings-daemon (Debian):
status: Unknown → New
ivan (funivan) wrote :

I use Ubuntu 14.04 and this bug still present. If you can, please fix it. I use Alt+shift and this combination does not work with other keys in programs.

affects: gnome-settings-daemon → gnome-shell
Changed in unity:
importance: Undecided → High
status: New → Confirmed
Norbert (nrbrtx) wrote :

Ubuntu 14.04.1 with all updates, Ctrl+Shift as layout switch (English and Russian).
I unable to use <Ctrl+Shift+arrows> for text selection and <Ctrl+Shift+T> in Firefox, <Ctrl+Shift+PrintScreen> in the following sessions:
* GNOME Session (Metacity)
* GNOME Session (Compiz)

All these shortcuts work as expected in Unity.

Norbert (nrbrtx) wrote :

It's great that Ubuntu 14.10 MATE beta is not affected by this bug.

Norbert (nrbrtx) wrote :

Ubuntu Utopic 14.10 final with all updates, Ctrl+Shift as layout switch (English and Russian).
I unable to use <Ctrl+Shift+arrows> for text selection and <Ctrl+Shift+T> in Firefox, <Ctrl+Shift+PrintScreen> in the following sessions:
* GNOME Session (Metacity)
* GNOME Session (Compiz)

All these shortcuts work as expected in Unity.

tags: added: amd64
removed: trusty-desktop
Norbert (nrbrtx) on 2015-01-17
tags: removed: amd64
Norbert (nrbrtx) wrote :

Bug exists in Ubuntu 15.04 alpha2., Ctrl+Shift as layout switch (English and Russian).
I unable to use <Ctrl+Shift+arrows> for text selection and <Ctrl+Shift+T> in Firefox, <Ctrl+Shift+PrintScreen> in the following sessions:
* GNOME Session (Metacity)
* GNOME Session (Compiz)

All these shortcuts work as expected in Unity.

tags: added: vivid
Norbert (nrbrtx) wrote :

Bug exists in Ubuntu 15.04 beta2., Ctrl+Shift as layout switch (English and Russian).
I unable to use <Ctrl+Shift+arrows> for text selection and <Ctrl+Shift+T> in Firefox, <Ctrl+Shift+PrintScreen> in the following sessions:
* GNOME Session (Metacity)
* GNOME Session (Compiz)

All these shortcuts work as expected in Unity.

Norbert (nrbrtx) wrote :

Bug exists in Ubuntu 15.04 final, Ctrl+Shift as layout switch (English and Russian).
I unable to use <Ctrl+Shift+arrows> for text selection and <Ctrl+Shift+T> in Firefox, <Ctrl+Shift+PrintScreen> in the following sessions:
* GNOME Session (Metacity)
* GNOME Session (Compiz)

All these shortcuts work as expected in Unity.

Norbert (nrbrtx) wrote :

Bug exists in Ubuntu 15.10 alpha (same behaviour as in comment 26).

tags: added: wily
Changed in gnome-settings-daemon (Ubuntu):
status: Confirmed → Triaged
Changed in unity (Ubuntu):
status: Confirmed → Triaged
affects: gnome-settings-daemon (Fedora) → ubuntu
Changed in ubuntu:
importance: Unknown → Undecided
status: Unknown → New
no longer affects: ubuntu
affects: gnome-settings-daemon (ALT Linux) → ubuntu
Changed in ubuntu:
importance: Unknown → Undecided
status: Unknown → New
no longer affects: ubuntu
Norbert (nrbrtx) wrote :

Bug exists in Ubuntu 15.10 beta2, Ctrl+Shift as layout switch (English and Russian).
I unable to use <Ctrl+Shift+arrows> for text selection and <Ctrl+Shift+T> in Firefox, <Ctrl+Shift+PrintScreen> in the following sessions:
* GNOME Flashback (Metacity)
* GNOME Flashback (Compiz)

All these shortcuts work as expected in Unity.

Norbert (nrbrtx) wrote :

Bug exists in Ubuntu 15.10 final, Ctrl+Shift as layout switch (English and Russian).
I unable to use <Ctrl+Shift+arrows> for text selection and <Ctrl+Shift+T> in Firefox, <Ctrl+Shift+PrintScreen> in the following sessions:
* GNOME Flashback (Metacity)
* GNOME Flashback (Compiz)

All these shortcuts work as expected in Unity.

Norbert (nrbrtx) wrote :

Bug exists in 16.04 as described in #29.

tags: added: xenial
Norbert (nrbrtx) wrote :

Bug exists in 16.10 as described in #29.

tags: added: yakkety
Eli (eliterdaboss) wrote :

Could the bug I reported ( Bug #1644959 ) be a duplicate of this bug?

Velkan (velkan-s) wrote :

17.04 with GNOME Shell: can't use the Alt+Shift+# key combination in the gnome-terminal because of that.

Anton (truthzp) wrote :

Ubuntu 17.04 + GNOME Shell 3.24.2 with all updates. Bug exists.
When set combination for switch keyboard layout - CTRL + Shift, then can't use any hotkeys with CTRL+Shift combination.

Any solutions?

Norbert (nrbrtx) wrote :

Bug exists in 17.10 too. So it's time to switch to Ubuntu with MATE Desktop Environment.

tags: added: artful zesty
Norbert (nrbrtx) wrote :

Ubuntu 17.10: unable to open new tab in gnome-terminal with <Ctrl+Shift+T> if layout switcher is <Ctrl+Shift>.

Norbert (nrbrtx) wrote :

Unable to use Ctrl+Shift+key shortcuts (for example Ctrl+Shift+arrows for selecting text) on Ubuntu 17.10 with all updates installed if keyboard layout switching is set to Ctrl+Shift. Both on Xorg and Wayland.

Norbert (nrbrtx) wrote :

Ubuntu 17.10 with MATE desktop is affected by this bug (see bug 1720364). I hoped that this would not happen.

I'll continue to use Ubuntu 16.04 LTS with MATE desktop. I hope they fix this bug before Ubuntu 20.04 LTS release.

202 comments hidden view all 280 comments

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

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

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

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

Who invite me this blog?

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

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

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

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

Created attachment 134843
KDE keyboard layout switcher screenshot

Sorry, I'm Hungarian.

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

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

High, Viktor!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

215 comments hidden view all 280 comments
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-terminal (Ubuntu):
status: New → Confirmed
Norbert (nrbrtx) wrote :

Unable to use Ctrl+Shift+key shortcuts (for example Ctrl+Shift+arrows for selecting text) on fresh clean Ubuntu 17.10 final with all updates installed if keyboard layout switching is set to Ctrl+Shift. Both on Xorg and Wayland.

Changed in gnome-settings-daemon:
importance: Unknown → Medium
status: Unknown → Fix Released
Changed in gnome-settings-daemon (Fedora):
importance: Unknown → Undecided
status: Unknown → In Progress
Norbert (nrbrtx) on 2017-10-30
tags: added: bionic
removed: saucy vivid wily yakkety
Changed in xorg-server:
importance: Unknown → High
status: Unknown → Confirmed
Changed in firefox (Ubuntu):
status: New → Confirmed
Changed in gnome-shell (Ubuntu):
status: New → Confirmed
215 comments hidden view all 280 comments

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14 years of doing nothing. My congratulations!

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

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

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

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

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

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

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

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

tags: added: patch
Changed in kubuntu-meta (Ubuntu):
status: New → Confirmed

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

sacredwow (mesquunclub) wrote :

Hi,

Is there any fix available for wayland?

Oded Arbel (oded-geek) wrote :

Norbert: any chance you update your PPA with support for Xorg 1.20 from Cosmic?

Norbert (nrbrtx) wrote :

@Oded Arbel (oded-geek)

Currently I do not plan to support non-LTS Ubuntu versions.

Norbert (nrbrtx) on 2018-10-18
tags: added: cosmic
removed: artful zesty
Snaker (snaker.me) wrote :

I have the same problem on Ubuntu 18.04.
After all these posts.. fix it, please.

nake89 (nake89) wrote :

Hello,

Putting CTRL+SHIFT as the keyboard layout change hotkey should not disable all CTRL+SHIFT+<Any key>

I can confirm this bug is real and is affecting more and more people.
CTRL-SHIFT used not to conflict with other keybindings. Now it does.

Witnessed here: https://askubuntu.com/questions/1009352/os-keyboard-shortcuts-conflict-with-apps-keyboard-shortcuts-in-gnome-3

I really wish this bug would be fixed. Please.

Displaying first 40 and last 40 comments. View all 280 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.