I have a problem with the keyboard mapping in virtualbox guests. 

A number of keys show no action at all or turn out wrong symbols and changing the keyboard layout settings in the guest does not fix it.
Both the host and the guest run in 64 Bit.
The problem occurrs both in windows and linux guests.
On the host I tried Debian 7 with XFCE, Trinity and LXDE and I checked both the virtualbox 4.1 that comes with the distro as well as the current 4.2 installed from the wheezy backports.
I started all new then, with centos 6.4, Gnome desktop. Same issue appeared with virtualbox 4.2 installed from the virtualbox.repo
This is on a remote server which I access through vnc (tightvnc on debian and tigervnc on centos, local client is KRDC)
 
I have a German keyboard layout but I prefer to have the box run in English.
 
On centos 
cat /etc/sysconfig/keyboard
 
KEYTABLE="de"
MODEL="pc105"
LAYOUT="de"
KEYBOARDTYPE="pc"
 
LANG=en_US.UTF-8
 
All is well accessing the machine via ssh, yz at the right places, umlauts and all the symbols at the right place and available. 
All is well still accessing the host through vnc. I open Gedit and doing the same tests as above there is no problem.
In the guest however testing with a linux mint live cd, while zy still have the correct place some keys show no activity, including the key right of the P (udiaeresis Udiaeresis) and the keys right of L that should give odiaeresis and adiaeresis. The key to the left of the 1 and the key to the right of the 0 show no action. 
Other keys including the shift values of 3,7,0 and the symbol-keys on the right side have wrong output.
 
On the linux mint guest I checked the key codes with xev and those keys that show no activity apparently do not evoke a key event when hit. I can type üöäß as long as I want in the guest and xev wont output a single line.
 
Going back to the linux host xev running there outputs:
 
KeyPress event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13158645, (431,15), root:(433,68),
state 0x2000, keycode 219 (keysym 0xfc, udiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 bc) "ü"
XmbLookupString gives 2 bytes: (c3 bc) "ü"
XFilterEvent returns: False
 
KeyRelease event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13158781, (431,15), root:(433,68),
state 0x2000, keycode 219 (keysym 0xfc, udiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 bc) "ü"
XFilterEvent returns: False
 
KeyPress event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13171357, (431,15), root:(433,68),
state 0x2000, keycode 255 (keysym 0xf6, odiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 b6) "ö"
XmbLookupString gives 2 bytes: (c3 b6) "ö"
XFilterEvent returns: False
 
KeyRelease event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13171481, (431,15), root:(433,68),
state 0x2000, keycode 255 (keysym 0xf6, odiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 b6) "ö"
XFilterEvent returns: False
 
KeyPress event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13174995, (431,15), root:(433,68),
state 0x2000, keycode 254 (keysym 0xe4, adiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 a4) "ä"
XmbLookupString gives 2 bytes: (c3 a4) "ä"
XFilterEvent returns: False
 
KeyRelease event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13175522, (431,15), root:(433,68),
state 0x2000, keycode 254 (keysym 0xe4, adiaeresis), same_screen YES,
XLookupString gives 2 bytes: (c3 a4) "ä"
XFilterEvent returns: False
 
KeyPress event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13179885, (431,15), root:(433,68),
state 0x2000, keycode 253 (keysym 0xdf, ssharp), same_screen YES,
XLookupString gives 2 bytes: (c3 9f) "ß"
XmbLookupString gives 2 bytes: (c3 9f) "ß"
XFilterEvent returns: False
 
KeyRelease event, serial 33, synthetic NO, window 0x3c00001,
root 0xfc, subw 0x0, time 13180045, (431,15), root:(433,68),
state 0x2000, keycode 253 (keysym 0xdf, ssharp), same_screen YES,
XLookupString gives 2 bytes: (c3 9f) "ß"
XFilterEvent returns: False
 
=================================
 
So I got it working in the end. There was a bug discussion on virtualbox with helpful info about the way virtualbox handles keyboard input:

I will quickly sumarise how we handle keyboard translation on X11 hosts. In fact we have two algorithms for doing this. The first one, which is the preferred one, is to try to determine whether one of the two standard X.Org PC mappings is in use (kbd or evdev). We do this by checking the keycodes of certain keys that are not likely to vary - like the left side modifier keys, tab, the first eight function keys - and seeing if they match one of the well-known mappings (and we do check for swapped ctrl and caps lock). If they do, we use that mapping, but certain custom keyboard layouts, like Neo and probably like your Dvorak layout, defeat this.

The second algorithm originally came from Wine, although a lot of work has gone into it since then. It works by reading the symbols attached to each keycode and comparing them to standard national layouts, and working back from there to the keyboard mapping. This is needed in particular for Sunray and I believe for X over ssh and VNC (although I should probably add Sunray to the standard layouts).

So this confirmed my suspicion that virtualbox performed some weird voodoo based on what it sees as the keyboard settings. And while all looked well judging from typing on the machine, both in a ssh shell or via vnc and X, I found rather strange tables with Xmodmap -pke . 
I created a valid xmodmap on my desktop box, shortened it to only contain those keys I actually need and use and put that into a file on the remote machine. 
I edited the ~/.vnc/xstartup script of the user who runs the vnc server to include the line 
xmodmap custom-modmap
at the top. And that made the difference.

I will not pretend to understand how things actually work together, my desktop, the remote machine, the xmodmap all use and are set to a German keyboard and still virtualBox now starts and presents an English keyboard to the guest machines. But this is something the guests are happy to remap to German and at least each keypress results in a key event now.

KRDC kann kein vnc

Sunday, August 18. 2013

 Ich hatte den Remote Desktop Client krdc mit pacman -S kdenetwork-krdc allein installiert, aber es ging und ging nicht. Den gewohnten Aufruf aus der konsole lehnte er mit Verweis auf nicht unterstützte URL ab und bei manuelle Auswahl bot er nur RDP aber kein VNC an. Google wusste gar keinen Rat. Die Antwort erriet ich aus der Beschreibung im KDE-Userbase Wiki: Krdc is one of a pair of KDE programs (Krfb is the other) 

Krdc funktioniert nur, wenn kdenetwork-krfb auch installiert ist.

Von Squeeze zu Wheezy

Sunday, May 12. 2013

Ein wenig nervös macht mich ein Dist-Upgrade schon, man hofft auf di Linderung einer lang ertragenen Druckstelle durch das viel aktuellere Paket so.und.so und ahnt doch, dass das durch manchen neuen Kummer erkauft wird. Auf den ersten Blick schien auf dem meist headless laufenden Rechner auch alles zu laufen, die Überraschungen kamen mit den grafischen Oberflächen.

Die Kiste lief vorher schon mit LXDE, aber nach dem Upgrade war plötzlich wieder Gnome der Standard. Gnome3 und was mich nun wirklich störte, war die Fluppe, die mir Gnome nun ständig zog, weil es in der thightvnc-Umgebung nicht alle Features ausspielen konnte sondern im Fallback-Modus lief. 

Gnome3 in der tightvnc-Umgebung eine Zumutung gefunden, versucht, es durch LXDE zu ersetzen.LXDE soweit unbenutzbar gefunden, ein Grossteil der Probleme mögen nicht wiedergefundene config-Dateien sein aber auch nach vielen Stunden Mühen blieb es dabei, dass der pcmanFM nur für root startete und sichtbar wurde (incl Desktop-Bild, Icons, Config-Dialog), für user aber zwar startete, aber nicht angezeigt wurde.Endlich aufgegeben und stattdessen XFCE installiert, dass nun tut was es soll. Bei der Gelegenheit habe ich mich des überwiegenden Teils der Gnome3-Pakete entledigt.

Noch etwas hefiger war die Entdeckung, dass mit dem neuen Kernel 3.2.0-4-amd64 nicht mehr die ganze Bildschirmfläche benutzt wurde, sondern nur noch die oberen 1280x768. Den Kernel hatte ich anfangs nicht in Verdacht sondern Grub, denn der zeigte anfangs das Grub-Menue noch auf der vollen Fläche, wechselte dann aber nach den ersten Bootmeldungen in den beschnittenen Modus. 
Wie schon beim LXDE-Fiasko fand mir Google nur ganz wenige vergleichbare Faelle und kein Beispiel mit einer besseren Lösung als der, einen neuen Kernel zu installieren. Ich probierte es mit dem alten und weg war das Problem.
Auf dem Desktop von Arch Linux und dessen problemlosen Aktualisierungen verwöhnt begann ich schon, nach Alternativen zu schielen, aber das hätte nun gewiss nicht mehr in dies Wochenende gepasst. Und als Router und Gateway zum Wan ist der Rechner doch ziemlich unverzichtbar.
Also bleibe ich vorerst bei dem uralt-Kernel 2.6.32-5-amd64.

tightvnc statt aufstehen

Friday, February 3. 2012

 Oft ist es ja nur der Rechner in der anderen Ecke des Lab, dessen desktop ich mal eben vor mir sehen möchte, und lieber nicht hinübergehen. Aber es funktioniert im wesentlichen ganz genau so mit einer Kiste, die hunderte Kilometer entfernt ist: eben mal vnc aufmachen.

Ich bin da, nach einigen Versuchen, mal auf tightvnc gestossen, der sich flink installieren und einrichten lässt und prima mit dem kdrc harmoniert. Und tightvnc laesst sich klaglos durch einnen ssh-Tunnel schicken, und das beruhigt schon. 

Ich gehe hier mal davon aus, dass zu dem entfernten Rechner ohnehin eine ssh-Verbindung besteht und Passworte dank authentification keys kein Thema sind.

Auf dem entfernten Rechner ist tightvnc schnell installiert, mit debian reicht ein

apt-get install tightvncserver  (als root)

und dann startet man den server zum initialisieren als der user, mit dem man auf dem entfernten Rechner aktiv sein will. 

vncserver

Man darf/muss ein Passwort festlegen, notieren! - man wird bei jeder Verbindung danach gefragt werden. Erstmal fertig.
Um jetzt konkret eine Session zu öffnen, gebe ich, als user, auf der console des entfernten Rechners

tightvncserver -nolisten tcp -localhost -geometry 1152x864 -nevershared :2
und kontrolliere den Erfolg mit
ps aux|grep vnc

Xtightvnc :2 -desktop X -auth /home/user/.Xauthority -geometry 1152x864 -depth 24 -rfbwait 120000 -rfbauth /home/user/.vnc/passwd -rfbport 5902 -fp /usr/share/fonts/X11/misc/,/usr/share/fonts/X11/Type1/,/usr/share/fonts/X11/75dpi/,/usr/share/fonts/X11/100dpi/ -co /etc/X11/rgb -nevershared -nolisten tcp -localhost :2

der rfbport (5902) und die Nummer des desktops (:2) sind die beiden Daten, die ich in dieser Ausgabe kontrolliere, dann bin ich mit dem Server soweit fertig und wechsele zu einer Shell des lokalen Rechners, auch hier als passender user.

krdc vnc:/127.0.0.1:2 & ssh user@host.domain.tld -N -C -L 5902:127.0.0.1:5902

und pling öffnet sich der kdrc mit der Passwortabfrage und dann baut sich der entfernte Desktop auf. Bei langameren Verbindungen (dsl rauf und schmales dsl runter) vereinfacht es die Maussteuerung, wenn man im krdc oben "Local Cursor" aktiviert. 

(Page 1 of 1, totaling 4 entries)