keys dead when remapped by xkb -> fixed in SVN

[Clemens Fruhwirth]

Xorg supports remapping keys via xkb. A typical way would be:

                Option            "CoreKeyboard"
                Option            "XkbRules"      "xorg"
                Option            "XkbModel"      "pc105"
                Option            "XkbLayout"    "us"
                Option            "XkbOptions"  "therp:desktop"

Additionally we put the following line into /etc/X11/xkb/rules/base (or xorg in the same dir):

therp:desktop         =       +therp(desktop)

This teaches Xorg to treat the option string "therp:desktop" namely by resolving it to +therp(desktop).

Further we need to add the line

--p----- -m------ therp(desktop)

to /etc/X11/xkb/symbols.dir

And finally add a file called therp to /etc/X11/xkb/symbols with the following content:

partial modifier_keys 
xkb_symbols "desktop" {
    key <AD11>  {  symbols[Group1]= [ parenleft, braceleft ] };
    key <AD12>  {  symbols[Group1]= [ parenright, braceright ] };
    key <AE09> { symbols[Group1]= [         9,    bracketleft       ]       };
    key <AE10> { symbols[Group1]= [         0,    bracketright      ]       };
};

The effect of these lines is that the keys () and [] are swapped on the keyboard. I personally like that as I type round brackets more often and I like them to be accessible without the Shift modifier key.

However, as soon as a key is touched by xkb, it goes dead for VirtualBox. Notice that 0 and 9 wasn't changed, however 0 and 9 don't work even unshifted.

To make it work I have to adjust the layouts manually in the vbox source code and supply vbox with a keymap that resembles my remappings precisely.

[Michael Thayer]

Can't get things working based on your description above. The command line

setxkbmap us -rules xorg -model pc105 -option therp:desktop -v

tells me

Warning! Multiple definitions of rules file
         Using command line, ignoring X server
Warning! Multiple definitions of keyboard model
         Using command line, ignoring X server
Warning! Multiple definitions of keyboard layout
         Using command line, ignoring X server
Trying to build keymap using the following components:
keycodes:   xfree86+aliases(qwerty)
types:      complete+therp(desktop)
compat:     complete
symbols:    pc+us
geometry:   pc(pc105)
Error loading new keyboard description

[Michael Thayer]

I changed /etc/X11/xkb/symbols/therp to the following:

partial alphanumeric_keys
xkb_symbols "desktop" {
    include "us(basic)"
//    key <AD11>  {  symbols[Group1]= [ parenleft, braceleft ] };
//    key <AD12>  {  symbols[Group1]= [ parenright, braceright ] };
//    key <AE09> { symbols[Group1]= [         9,    bracketleft       ]       };
//    key <AE10> { symbols[Group1]= [         0,    bracketright      ]       };
    key <AD11>  {  [ parenleft, braceleft ] };
    key <AD12>  {  [ parenright, braceright ] };
    key <AE09> { [         9,    bracketleft       ]       };
    key <AE10> { [         0,    bracketright      ]       };
};

Now I can select the keyboard map using "setxkbmap therp", and the brackets are indeed switched, but the keyboard works as it should inside the guest. Can you test to see if this is the case for you as well?

[Clemens Fruhwirth]

First of all, sorry for the incomplete bug report.

We have to add

therp:desktop = +therp(desktop)

under the section that starts with

! option = symbols

in rules/xorg, to map the option to the symbol modifier.

Second, I tested your suggestion and unfortunately it does not have any effect. VirtualBox keys are still dead. I have to patch a correct layout into VBoxKeyboard.so to make it work.

[Michael Thayer]

Could you take a look in the log file for your VM to see if there are any keyboard-related messages when you see the problem?

[Clemens Fruhwirth]

First, I found a much easier way to get xkb remappings into the X server without fiddling with config files. See switch-brackets.sh. This will switch the position of the () and [] brackets on keyboards with US layout.

Yes, VirtualBox does complain, but that's not surprising as, the code in keyboard-new.c X11DRV_InitKeyboardByLayout checks for overlaps in both the non-shifted and the shifted part of the KeyCode->KeySym mapping. X correctly returns

XKeycodeToKeysym(<dpy>,<keycode for AE09>,0)=9

XKeycodeToKeysym(<dpy>,<keycode for AE09>,1)=bracketleft

and as bracketleft isn't what VirtualBox is expecting in X11DRV_InitKeyboardByLayout it fails to initialize the respective keycode->scan code translation.

00:00:00.586 Failed to recognize the keyboard mapping or to guess it based on
00:00:00.586 the keyboard layout.  It is very likely that some keys will not
00:00:00.586 work correctly in the guest.  If you would like to help us improve
00:00:00.586 the product, please submit a bug report, giving us information
00:00:00.586 about your keyboard type, its layout and other relevant
00:00:00.586 information such as whether you are using a remote X server or
00:00:00.586 something similar.

I also do more remapping than the X11DRV_InitKeyboardByType allows for (see switch-brackets-and-ctrls.sh), so I'm pretty much stuck.

I would really like to supply a manual mapping keycode to scan code mapping.

Can someone give me a hint how to pipe configuration values to that particular code? I recognized that we have

keyboard-new.c <- XKeyboard-new.cpp <- VBoxConsoleView.cpp <- VBoxConsoleViewWnd.cpp

To me, it would make sense to have this customization attached to the configuration of the Frontend, so I'd stick it somewhere into .VirtualBox/VirtualBox.xml.

[Clemens Fruhwirth]

Switch () and [] brackets on US keyboards (evdev layout)

[Clemens Fruhwirth]

My real remapping configuration disturbing also the ByType mechanism

[Michael Thayer]

Sometime, when I have time, I will make the VirtualBox front-end read key position information straight from xkb, and this sort of issue will be solved for 99.9% of users. However, as it already works for 99.8% I'm afraid it will probably not happen very soon. Sorry about that.

[Clemens Fruhwirth]

I'm not sure how reading from xkb would help. With the ByType mapping, you do all the best you can. My problem can only be solved by manually specifying the key codes. I don't see any reason to be smarter than the user here with heuristics and guesses that fail in cases like this.

Are you ok with a patch that allows you to manually give/modify that map? Vmware runs into similar problems ​http://communities.vmware.com/message/508070

[Michael Thayer]

xbk allows you to query the keycodes for each key on the keyboard by position. I.e. you can query the keycode of (at random) the seventh key in the number row on the keyboard, or the third key in the second row of letters. Unfortunately I only discovered this relatively recently.

[Clemens Fruhwirth]

Remapper for the X11keycodes->scancodes table using GUI/RemapScancodes

[Clemens Fruhwirth]

Here is the promissed patch to enable the user to manually change the keycodes to keyboard-scancodes mapping used in the VirtualBox frontend. The user does that by setting the global property "GUI/RemapScancodes" via the VBoxManage command. The property is a string of comma-seperated keycode=scancode values, where scancode is emitted when keycode is pressed.

Please do not object because of a missing GUI. It is likewisely missing for setting GUI/MaxGuestResolution, and I had no trouble googling it when I pivoted my monitor. Also the "other product" (vmware) doesn't do better here -- justifiably, as someone who knows how get to keycodes and scancodes (xev) knows how to use the command line.

Previously we had two different X11keycode->scancode tables in keyboard-new.c: The first one was selected by builtin_table_number from the set of builtin tables, the second one was the mapping detected by ByLayout and stored in keyc2scan. The patch unifies this by always using keyc2scan, but updating it with the values (memcpy) found in the selected builtin table. The unification is necessary to have a common spot where to apply the remappings.

The remapping itself is straightforward. The property is parsed into tuples, and the tuples are parsed and inserted into an array of 2-element arrays. The mapping is handed to keyboard-new.cpp and applied after ByLayout/ByType detection. The rest of the patch is concerned with adding a new property to VBoxGlobal.

As QIHotKeyEdit and VBoxConsoleView needs to call initMappedKeyboard, I stuffed the initMappedKeyboard function into VBoxGlobal.cpp. This feels like a bad choice. Please feel free to move it.

The patch is licensed under the conditions of ​http://www.virtualbox.org/wiki/MIT%20license

[Michael Thayer]

Sorry that I didn't answer sooner, I had a large backlog of bugmail... I'm afraid that this won't make it into 3.0, as there is not enough time left to test it properly, but I will look at including it after that. Thanks!

[Clemens Fruhwirth]

Applies cleanly to 3.0.0 OSE tree (except for minor line offset differences). Patch works-for-me here. Thanks for the nice 3.0.0 release.

[Michael Thayer]

Applied your patch (I did move around a couple of things, but basically cosmetic changes). It should turn up in the public SVN tomorrow or so. I will close this ticket as fixed once you have confirmed. Thanks!

[Finswimmer]

Will it be in the next virtualbox-bin release? (3.0.3)

Thanks, Tobi

[Michael Thayer]

Unfortunately not, for a number of reasons I decided against backporting it to the 3.0 series. Sorry.

[Finswimmer]

Replying to michael:

Unfortunately not, for a number of reasons I decided against backporting it to the 3.0 series. Sorry.

Sorry. I just do not understand what you mean with "backporting to 3.0 series". Is "public SVN" 3.1? I just need this patch ASAP. It does not matter which series this will be.

Thank you Finswimmer

[Michael Thayer]

The public SVN always corresponds to the most recent development code. Major releases are branched off it, and then bugfixes are backported from the development code to the release branches - in general, we only backport things that are absolutely necessary in order not to accidentally introduce regressions into stable code.

[Clemens Fruhwirth]

Thanks, works for me in 3.1.0.

[Finswimmer]

Hello,

is there a howto or a can someone explain how I can use a custom Layout in Host and get all keys working on Guest(Windows7)?

Thanks Tobi

[Clemens Fruhwirth]

I would extend the documentation to answer tobi's question, but I haven't found the latex sources for it. Could anyone give me a pointer?

Reopening ticket, because of missing documentation.

[Michael Thayer]

Probably the easiest would be if you just wrote some text (a couple of lines should be enough, as this is advanced/rather specific stuff) that we could include, as the VBox manual is not part of the open source edition. Thanks!

[Clemens Fruhwirth]

Sorry for the delay. Here we go:

VirtualBox translates X11 keycodes into PC scancodes. If you want to emit a different scancode for an X11 keycode, you can use the global extra data "GUI/RemapScancodes". "GUI/RemapScancodes" is a comma separated list of value pairs of the form c=s. This overrides the default of VirtualBox to emit scancode s for key code c.

For instance,

$ VBoxManage getextradata global GUI/RemapScancodes
..
Value: 18=10,19=11,47=39,34=26,35=27

indicates to emit PC scancode 10 for X11 keycode 18. Further, emit scancode 11 for key code 19, and so on.

To find out, what the keycode of keys on your keyboard are, "xev" is a useful tool. To look up, the common PC scancodes ​http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html is a useful resource.

You can set the "GUI/RemapScancodes" variable using VBoxManage setextradata global GUI/RemapScancodes <value>.

[Dov Grobgeld]

This manual mapping looks exactly what I need, but I can't get this to work. Here is what I did:

1. Ran xev on Linux X11 host and found that LAlt generates keycode 64.
2. Looked up scan code for LAlt at ​http://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html and found it to be 0x38=56
3. Ran shell command:

     prompt> VBoxManage setextradata global GUI/RemapScancodes "64=56"
   

4. Started Linux guest and ran xev and found that LAlt generates the unexpected value 115 and not the expected 64 .

What went wrong?

Thanks!

[Frank Mehnert]

Note that this command works only if you use the Qt GUI to start the VM.

[Dov Grobgeld]

Sorry if I'm getting to far off from the original bug in this thread, but how do you start the Qt GUI? But in my previous complaint, I had simply run the shell command "VirtualBox" from the command line and started the VirtualMachine from within. What GUI does it run?

[Frank Mehnert]

That's exactly the Qt GUI I mean :) The command Michael posted would not work for VBoxSDL and not for VBoxHeadless.

[Dov Grobgeld]

My problem still isn't solved. Why didn't the steps above work for using GUI/RemapScancodes? Is there any way to debug it?

[Michael Thayer]

Dov: just checked this (and traced it in the debugger) and you are right - the patch in this ticket which is contained in current VirtualBox versions only remaps layout-dependent keys (mainly alphanumeric ones and punctuation) and silently ignores the rest. If the original author of the patch feels like fixing this we will of course include the fix in future versions, otherwise we will treat it as a known restriction of the feature. Regarding your unsupported keyboard layout though, you might feel like trying the updated libraries attached to ticket #2595 which should also solve your problem.

[Michael Thayer]

Update: I have fixed this locally in the process of fixing something else. I hope to add updated library binaries to ticket #2595 containing the fix in the next day or so.

[Frank Mehnert]

Should be fixed as of VBox 4.0.