Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I just installed VirtualBox (from Oracle) in Windows 7, and created a virtual machine with latest Ubuntu.

Here in Firefox I can use the left Ctrl key, while the right one doesn't have any effect. However, I can't use the AltGr key (also known as Right Alt) to produce e.g. curly braces like {} (I pasted that via Ctrl V).

In a terminal window I can switch the "Input method" to "Multipress", and then I can use AltGr to type e.g. {}, which is how I produced those characters for this posting. However, with "Multipress" the Ctrl keys seem to have no effect whatsoever. So in order to e.g. type Ctrl D I have to right click and switch the "Input method" to "System (IBus (Intelligent Input Bus))". Then AltGr does not work.

I tried specifying the compose key in the system settings keyboard layout.

With that, neither Ctrl nor AltGr worked.

Here's what xmodmap reports:

[~]
$ xmodmap -pke | grep -i control
keycode  37 = Control_L NoSymbol Control_L
keycode 105 = Control_R NoSymbol Control_R
[~]
$ xmodmap -pke | grep -i alt
keycode  64 = Alt_L Meta_L Alt_L Meta_L
keycode 204 = NoSymbol Alt_L NoSymbol Alt_L
[~]
$ _

How can I fix this?

Additional info: the keyboard is a standard PC keyboard, a Logitech K120, with Norwegian layout.

Also, I first tried asking this question over at the Superuser site but no response after 2 days...

share|improve this question
    
I got the AltGr key working in Ubuntu. I just had to know that I should create a file called ".Xmodmap" and add this line: "keycode 113 = Mode_switch Multi_key". Which I found in a bug report about a similar issue, at bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/349487/… –  Alf P. Steinbach Nov 12 '11 at 11:36

1 Answer 1

up vote 4 down vote accepted

Run the command xev. In the xev window, press the AltGr key. You'll see something like

KeyPress event, serial 29, synthetic NO, window 0x6400001,
    root 0x105, subw 0x0, time 966635535, (243,-207), root:(1891,26),
    state 0x0, keycode 66 (keysym 0xff7e, Mode_switch), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

Note the keycode; since the key isn't doing what you want, you'll see something else (possibly Alt_R) instead of Mode_switch. You want to assign this keycode to Mode_switch, which is X11's name for AltGr. Put the following command in a file called .Xmodmap (note capital X) in your home directory:

keycode 66 = Mode_switch

Additionally, you may need to assign a modifier to Mode_switch, but if all that's happening is a keycode discrepancy there'll already be one. See Set the key for spanish eñe letter for more information.

Run xmodmap ~/.Xmodmap to test your file. On many systems, including Ubuntu 10.04, this file is loaded automatically in the default Gnome environment. On other distributions or environments, you may need to indicate explicitly that you want to run xmodmap ~/.Xmodmap when you log in.

share|improve this answer
    
It is an interesting answer, using keycode 66. In my comment before you posted this answer, I noted that keycode 113, which I just copied and pasted from the net, works for that line. Now when I run xevas you suggest, it reports keycode 108. Yet the line I copied from the net works. So it apparently has nothing to do with the keycode. I changed it to 66, just for fun, and rebooted: it still works. So I conclude it's not something technically accurate at all, but evidently a Heisenbug in Ubuntu. –  Alf P. Steinbach Nov 12 '11 at 23:31
    
@AlfP.Steinbach The keycode is determined by your hardware (or hardware emulator, in a VM) and by your kernel and X server version. On PC keyboards, the right Alt key has keycode 113 on older Linux distributions and 108 on newer ones (my example with 66 is because I have AltGr on the Caps Lock key). I asked a while ago how to automatically determine whether I have an “old” or “new” system regarding keycode assignments. –  Gilles Nov 12 '11 at 23:34
    
Well, it still works after renaming that file and rebooting. And the terminal still remembers old command history after reboot. With silly persistent dynamic states like that, I think it must be rather difficult to hunt down bugs: they can't be reliably reproduced in such an interfering environment. I think further evidence of that is how the bug about AltGr has gone yoyo: closed as resolved, re-opened, closed as resolved, re-opened, so on and on. So I think it would be a Good Idea(TM) to severely punish the person who introduced that persistence of settings & state. :-) –  Alf P. Steinbach Nov 12 '11 at 23:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.