gnome-terminal ignores current keyboard layout for ctrl+key shortcuts

Bug #204202 reported by Adam Lindberg on 2008-03-20
This bug affects 29 people
Affects Status Importance Assigned to Milestone
GNOME Terminal
Gnome Virtual Terminal Emulator
Fix Released
gnome-terminal (Ubuntu)
Ubuntu Desktop Bugs
Nominated for Hardy by Alex
Declined for Intrepid by Jean-Baptiste Lallement
Nominated for Karmic by Kai Webber
Nominated for Maverick by Ha-Duong Nguyen

Bug Description

Binary package hint: gnome-terminal

In Ubuntu 7.10 (Gutsy Gibbon), Gnome Terminal (2.18.2-0ubuntu1) doesn't respect the Dvorak keyboard layout correctly. When pressing Ctrl+Z to suspend a process the text size is instead decreased. Ctrl+Z on Dvorak is on top of the '-' key on Qwerty so I assume that it is somehow interpreted on the key code level.

Operation: Pressing Ctrl+Z in the terminal window
Expected behavior: The currently running program is suspended
Current behaviour: Text size is decreased

Note that the text size can be decreased by Pressing Ctrl+- on the Dvorak layout (the correct behavior for this command).
Note also that the same is valid for Ctrl+'+', i.e. pressing the physical key of Qwerty plus is interpreted as plus but it should use the Dvorak layout equivalent key.

== Regression details ==
Discovered in version: 2.29.6-0ubuntu1
Last known good version:

Pedro Villavicencio (pedro) wrote :

To be tested and confirmed by someone with a similar setup, thanks.

Changed in gnome-terminal:
importance: Undecided → Low
winstanr (robert-winstanley) wrote :

Ubuntu 7.10

I have also had an identical problem. Here are some details on how to reproduce it.

Run System/Preferences/Keyboard
On the layouts tab set the keyboard model to "Generic 105-key (Intl) PC"
Add the layout "U.S English Dvorak"
Add the layout "Germany"
Remove all other layouts
Set the default to "U.S English Dvorak"
Run Applications/Accessories/Terminal
Type the commands
cd /
ls -R

Typing Ctrl-Z during the listing should stop the output, but instead changes the character size as described by Pedro

Additional info

If the layout "Germany" is removed then Ctrl-Z works as expected
I have tried other layouts at random, some have the same effect some not.
(UK English has no effect, Switzerland causes the problem)

winstanr (robert-winstanley) wrote :

Testing with 8.04 Beta and the problem still exists

Joachim R. (jro) wrote :

With gutsy and fr oss keyboard, the problem exist !
If you use a classic xterm, ctrl+Z send current process to the background, and fg recall it "on front".
If you use ctrl+Z with gnome-terminal, it doesn't work. You may use ctrl+W as workaround, as if gnome-terminal was using us QWERTY layout !
"fr oss" is AZERTY, so A and Q are inverted compoaring to us QWERTY, W and Z are inverted too.

I imagine gnome-terminal is using key codes instead of corresponding characters... So if the layout is not like us QWERTY, you get some side effects.
 - crtl+Z doesn' work
 - when using GNU nano, hitting ctrl+W to search with a regexp has the effect of crtl+Z, sending nano to the background. You must use Ctrl+Z to use the "search" function.

James Hall (james-hall-01) wrote :

Confirmed with 8.04 full and gnome terminal 2.22.1-0ubuntu2. This problem also occurs with the Ctrl-c shortcut and the dvorak layout.

James Hall (james-hall-01) wrote :

Correction. On further investigation pressing Ctrl-z using the dvorak uk layout doesn't suspend a process but it doesn't change the text size either.

Pedro Fragoso (ember) wrote :
Changed in gnome-terminal:
status: New → Confirmed
Changed in gnome-terminal:
status: Unknown → Confirmed
Changed in gnome-terminal:
assignee: nobody → desktop-bugs
status: Confirmed → Triaged
André Pirard (a.pirard) wrote :

Similar but different Ctrl key fight worth mentioning.
On 8.04.1, I configured kbd pair : RU Winkeys + UK International.
(added them and removed first (system's UK (plain)))
If you're asked why I do that in Belgium, reply Ubuntu.
Default is 0 = RU. Layout switcher set to Shift+Alt (like Windows).

Problem with Terminal only (other apps OK with Ctrl):
- When Shift+Alted to RU, Ctrl-anything does nothing.
- When Shift+Alted to UK, Ctrl-char types the sticker's RU character.
That is, Ctrl acts like a layout "push" switch, temporarily.
But that's only in UK mode.
And I have searched in vain for a description of such a feature.

I swapped the two layouts, making them UK,int + RU, Win.
Default is 1 = RU now.
And everything works as expected.

Надеясь, это поможет. Спасибо.


Changed in gnome-terminal:
status: Confirmed → Fix Released
Pedro Villavicencio (pedro) wrote :

fixed upstream ,thanks for reporting.

Changed in gnome-terminal:
status: Triaged → Fix Committed
Adam Lindberg (eproxus) wrote :

Does this mean Ubuntu 9.04 for a normal user?

Alexander Sack (asac) wrote :

should be fixed in jaunty.

Changed in gnome-terminal (Ubuntu):
status: Fix Committed → Fix Released
Gonzo (alex-satellite) wrote :

Strange, but Ctrl+C didn't work on a final Ubuntu 9.04 Live CD (to stop the process) and still doesn't work after install.
My layout is USA English default, no changes, no tweaks in xorg. Simply can't stop any process. Using Ctrl+Z instead.
What should I do?

Arno Teigseth (arno-teigseth) wrote :

Hope the server isn't tiref of hearing this since I posted it to other bug reports, too.
I too suddenly got this strange behaviour, but it used to work before.

Behaviour: In gnome-terminal, before I could start typing a command and then cancel it by pressing Ctrl+I on a qwerty keyboard. That is Ctrl+C on a dvorak.

Suddenly I could not. In fact all Ctrl+<whatever> did not work in gnome-terminal. But they did in openoffice, firefox etc.

After some head scratching and googling I found some hints saying it helped to delete the US layout. Made me think about that I recently had updated my keyboard configuration file (, and to make xkb take it into consideration I usually
0) Copy the xkb file into /usr/share/X11/xkb/symbols/
1) Open keyboard preferences and delete the dvorak layout
2) Open keyboard preferences and add the dvorak layout again
Now I can type my updated keyboard.

-But this time the "US Ctrl keys" are in effect no matter what I try, even when choosing the dvorak layout.

1) Open keyboard preferences and delete all but the dvorak layout
2) Add the layouts again.
3) Enjoy.

To me this is STILL A BUG, since now when I select US keyboard, I have to press Ctrl+I to get a Ctrl+C. In other words, dvorak rules the Ctrl-key. However since I never use anything but my custom layout I'm not very much affected...

When thinking about it, I probably never saw this bug before because I chose Norway dvorak during the install process. It is actually the system default layout, to my cow-orkers' despair. ;)

I'm writing this long story to remember it myself, maybe it will help you too.

MilkaJinka (milkajinka) wrote :

On Ubuntu 9.10 (Karmic Koala), the bug is still here, only in gnome-terminal (and not in any other gtk or gnome app).

My setup
A laptop with a Swiss French keyboard. At work, I connect a Dvorak keyboard to it. So I'm using a Swiss French layout at home and a Dvorak layout at work on the same machine.

Gnome-Terminal ignore the keyboard layout in use for its keyboard shortcuts. Keyboard shortcuts will always use the default layout.

How to reproduce
- In Gnome keyboard preferences, add an "exotic" layout (like a Dvorak one) in addition to a classic one. We will imply that the "classic" layout is the default one.
- Open a gnome-terminal and type some text. Then hit Ctrl+c. It should work as expected (you should see a new command prompt line).
- Switch to the "exotic" layout and type some text. You can see that the new layout is active. Now try to hit Ctrl+c in your new layout. It won't work.
- Still using "exotic" layout, if you hit Ctrl+[key corresponding to the c key in the classic layout], it will work.
- Test it with other keyboard shortcuts. You encounter the same behavior.
- Now make your exotic layout the default one (see the solution in #15). All keyboard shortcuts will work using the exotic layout, and no longer using the classic layout.
- Open another GTK or Gnome app (like The GIMP). You will see that keyboard shortcuts will work as expected instead of ignoring the current keyboard layout.

Solution to implement
If one is currently using another keyboard layout than the default one, Gnome Terminal should use it for keyboard shortcuts too.

Kai Webber (kai11) wrote :

I'm using karmic and this bug isn't fixed.
Workaround by André Pirard (switching Russian and USA layouts, USA go first) works perfectly.

Yann Leprince (sciyann) on 2010-02-08
summary: - Ctrl+Z in Terminal doesn't work with dvorak layout
+ gnome-terminal ignores current keyboard layout for ctrl+key shortcuts
Kiri (kiri) wrote :

I was in Karmic and unaffected (perhaps something was different in the setup), now I am in Lucid and affected. If the fix was released, there has been a regression.

tags: added: lucid regression-potential
Changed in gnome-terminal (Ubuntu):
status: Fix Released → Confirmed
Kiri (kiri) wrote :

== Regression details ==
Discovered in version: 2.29.6-0ubuntu1

Maki Kato (mk2s) wrote :

This bug is still present in lucid 10.4 beta - gnome-terminal 2.29.6-0ubuntu5. The above mentioned workaround worked for me:
1) remove all layouts except for US Dvorak
2) add back whatever you want

For a dvorak user this is a pretty key bug, and I'm sure there are more than 6 of us.

Celal ERGÜN (celalergun) wrote :

I was going to report this as "ctrl+key works as if no alternate layout selected in gnome terminal". I'm switched to Turkish F but when I press a key with ctrl it behaves as I'm using Q layout.

I'm using Lucid by the way.

Celal ERGÜN (celalergun) wrote :

Here is how to reproduce it: I logon normally with Turkish F layout, gnome console works OK. Then I switch to Turkish F and console behaves as I am using Q layout when it comes to ctrl key. Rest of the keys are OK.

Celal ERGÜN (celalergun) wrote :

I made a mistake. Last sentence should read "Then I switch to Turkish Q and console behaves as I am still using F layout when it comes to ctrl key. Rest of the keys are OK."

MilkaJinka (milkajinka) wrote :

Still present in Lucid RC.

Just try it : add a non traditional keyboard layout (eg. Dvorak) but don't make it the default one (ie don't make it the first layout in the list), then launch gnome-terminal and try to hit Ctrl-C.

Doug Kelly (dougk-ff7) wrote :

Present in Lucid release as well.

I experienced the problem with a fresh install... but then I realized the issue was NOT present in an upgrade install. Went through things in gconf-editor, and I noticed /desktop/gnome/peripherals/keyboard/general/defaultGroup was 1 on the working configuration, and was set to -1 on the non-working configuration. I set the order in the Keyboard preferences to the same (USA followed by USA Dvorak), and set the defaultGroup to 1, and the issue went away. It appears there is no more default layout option in the Keyboard preferences.

I have a feeling that this isn't the same bug (but is the same symptom)--anyone else care to try?

Gonzo (alex-satellite) wrote :


This doesn't fix the problem. I already have USA (default) and Russian. Adding Dvorak doesn't do anything. The problem is still here, Ctrl+C doesn't quit any process like 'ping' or simply doesn't add a new line in gnome-terminal (with USA layout of course). By the way I have Ctrl+C assigned to copy any text in the terminal, but it was assigned in previous version of Ubuntu and it worked as expected.

Joe Liau (joe) wrote :

This seemed to not be a problem in Karmic, but it is in Lucid.

Doug Kelly: I tried your solution, but it does not seem to work for me on my fresh Lucid install.

Just tried something else: First layout indian, second Qwerty and then started a ping from the second layout. I could not figure out how to quit the ping (except 'killall ping'), since all my ctrl-c keystrokes printed indian characters. That cannot be useful under any circumstances it seems to me.

There are bug reports about this problem existing for other gtk apps as well, but I have not been able to reproduce the problem anywhere else besides gnome-terminal. Anyone knows another app?

E.g. similar, more general bug report:
And a later report that the fix for the above causes the symptons we see:
It is not clear to me whether this is indeed the same issue or just the same symptoms.

I cannot imagine that this is the intended behavior, for one because now it is different between gnome-terminal and xterm. But if it is, it should be more clearly documented. It is not intuitive that if you add a new layout that whether the ctrl- key mappings change depends on the order of the layouts.

I hacked together my own keyboard layout indicator that just rearranges the layouts in gconf so the selected one is on top. It is kinda a kludge, but it works. (Ensure the gnome indicator is set to use the top one and don't touch it again.)

I do not intend to create a proper applet out of this, but it might be useful to others as well. And I think anyone with some python experience can create something nice out of it, maybe someone will.

Changed in gnome-terminal (Ubuntu):
status: Confirmed → Triaged
Changed in gnome-terminal:
status: Fix Released → Unknown
Pavel Grishkov (pgrishkov) wrote :

I must admit I've spent huge amount of time figuring out what had caused my Ctrl key to behave in such inconvenient way as described here :)
And eventually I see many people in Gnome bugzilla claiming it may be useful to keep it as is. It definitely have to be fixed and work as user expects it to work. No surprises should be allowed.
A perfect example of reproducing Ctrl-C failure (from Gnome Bug 599894):
setxkbmap us,ru -option grp:caps_toggle /* works nice */
setxkbmap ru,us -option grp:caps_toggle /* we get "яс" symbols instead of sending SIGINT and SIGSTOP */

Please work with GNOME developers to fix it.

MilkaJinka (milkajinka) wrote :

Bug #487604 says that the bug doesn't come from gnome-terminal but from GTK+2 and states that this bug entry is erroneous. Yet Ctrl+[key] mappings work as expected in most GTK+2 applications. This bug seems to come from VTE instead, as in bug #307888

I made some tests with several applications other than gnome-terminal :
 - uxterm: when switching keyboard layout, Ctrl+[key] mappings are correct, they follow the current layout. Is not using VTE
 - konsole: same as uxterm, correct behavior. Is not using VTE.
 - xfce4-terminal: incorrect behavior, same as gnome-terminal. Is using VTE.
 - lxterminal : incorrect behavior, same as gnome-terminal and xfce4-terminal. Is using VTE.

So we can see that the problem relates to libvte instead of gnome-terminal, as it is present in all applications using libvte.

Changed in vte:
status: Unknown → New
Changed in gnome-terminal:
importance: Unknown → Medium
status: Unknown → New
Changed in vte:
importance: Unknown → Medium
Jocelyn Delalande (jocelyn) wrote :

This bugs affects me (maverick) and imho, simply makes multiple keyboards layouts under gnome a total pain :
 - the « gnome way » of switching (via keyboard-preferences) will not work in gnome-terminal, as explained in this bug report ;
 - the « X way » using the setxkbmap command works well... But gets overwritten by gnome each time the screensaver runs or when you plug an USB keyboard.

So, there is simply no way to use multiple layouts efficiently under gnome. (this is an essential feature for all dvorak-likes users).

Ha-Duong Nguyen (cmpitg) wrote :

Actually I don't think it's really a problem but a behaviour of GNOME. To use the right keyboard shortcut in some applications (gnome-terminal, wine, ...) which are related to gnome-setting-daemon, just make sure that *that keyboard layout is the first one* in gnome-keyboard-properties. I'm a Programmer Dvorak user and this (trick) works well for me with both Programmer Dvorak and QWERTY since Karmic Koala and now Lucid Lynx (and probably Maverick Meerkat). I have to keep QWERTY layout for QWERTY users to use my keyboard as well.

Is it an issue in maverick too ?

tags: added: regression-release
removed: regression-potential
Changed in gnome-terminal (Ubuntu Lucid):
status: New → Confirmed
description: updated
Ha-Duong Nguyen (cmpitg) wrote :

@Jean-Baptiste Lallement: Yes, I can confirm that it happens in Maverick also.

Changed in vte:
status: New → Fix Released
Erik Wognsen (r4mses) wrote :

It's confusing to find out what the status is. It seems to say "Fix released" in several projects and threads related to this, but the bug is still there for me in both Ubuntu 10.10 and 11.04 whether the real problem is in gnome-terminal, gnome, gtk, vte or something else.

It would sure be nice to have it resolved :-)

Rolf Leggewie (r0lf) wrote :

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

Changed in gnome-terminal (Ubuntu Lucid):
status: Confirmed → Won't Fix
Changed in gnome-terminal:
status: New → Confirmed
Changed in gnome-terminal:
status: Confirmed → Incomplete
Changed in gnome-terminal:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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