dokumentation/docs/Unsortiert/VM.md

6.9 KiB
Raw Blame History

Virtuelle Maschinen, Emulationen und RDP-Verbindungen

--8<-- "top/komplette Überarbeitung.md"

Soll Neo in Virtuellen Maschinen (z.B. VirtualBox, Qemu, VMware) oder für Remote-Desktop-Verbindungen verwendet werden, so kommt es oft zu Problemen, da zwei Tastaturbelegungen miteinander konkurrieren. Auf dieser Seite sollen einige Lösungsansätze vorgestellt werden.

Allgemein lässt sich sagen: Bei Problemen sollte für Windows lieber der kbdneo- anstatt des NeoVars-Treibers verwendet werden. Behebt dies die Probleme nicht, ist es oft nötig, eines der beiden Systeme auf qwertz einzustellen.

Virtualbox

Erst auf dem Wirt Qwertz aktivieren, auf dem Gast Neo. Danach kann man auf dem Wirt wieder auf Neo wechseln, das interessiert VBox dann nicht mehr. Siehe dafür auch das VBox-Ticket 2595.

  • Ist im Wirt Neo eingestellt, führt das sonst dazu, dass zwar die Buchstaben korrekt gesendet werden, jedoch weder Punkt, Komma, noch die Zahlen der Zahlenreihe korrekt funktionieren.

Version 2.1.0 macht zusätzliche Probleme, siehe VBox-Ticket 2793 und VBox-Ticket 2905, daher entweder eine ältere oder neuere Version von Virtualbox verwenden.

  • Fehler sind u.a., dass Mod3 die Funktion von Caps-Lock hat, die Mod-Funktion wird also nicht übernommen, und dass Mod4 immer noch <> sendet.

Wirt Linux, Gast Windows: Macht Probleme mit NeoVars, hier funktioniert Mod3 nicht richtig, das ist unabhängig vom eingestellten Layout auf dem Wirtssystem. Mit KbdNeo sollte Mod3 funktionieren. Erik sagt: „Kann ich nicht nachvollziehen, die Caps-Lock-LED leuchtet nur immer wieder mal nervig auf der Tastatur auf und geht wieder aus. Sonst keine Probleme. Bitte genauer beschreiben oder ein Ticket öffnen oder gibt es schon eins? Dann bitte hier nennen.“

Aktuelle Entwicklung

In VBox-Ticket 2302 wurde das Thema allgemeiner diskutiert und es gibt offenbar bereits einen Patch, der in der aktuellen Version (seit 3.1) eingepflegt wurde. Dieser erlaubt ein keycode-scancode-mapping manuell vorzunehmen. Der Befehl

#!sh
VBoxManage setextradata global GUI/RemapScancodes \
49=41,10=2,11=3,12=4,13=5,14=6,15=7,16=8, \
17=9,18=10,19=11,20=12,21=13,24=16,25=17, \
33=25,34=26,35=27,66=58,51=58,94=86,52=44, \
53=45,59=51,60=52,61=53,108=56,77=119

(einmalig) ausgeführt macht die Zahlenreihe verfügbar x,v,q,ß sowie Komma, Punkt und j.

Diese Lösung hat (noch) zwei Probleme: Erstens geht die rechte Mod4 (Alt Gr, wird im Gast-OS nur als Alt erkannt) nicht und zweitens, geht, wenn Neo im Gastsystem nicht verwendet wird, die #'-Taste nicht mehr (sie wird als Caps-Lock erkannt).

Technische Details zu dieser Lösung

**Es ist nicht notwendig diesen Abschnitt zu lesen! **

(Keine Garantie auf Richtigkeit, Blödsinn bitte ausbessern!)

Wenn man eine Taste drückt, emittiert die Tastatur einen Scancode. Da alle Tastaturen leicht unterschiedlich sind, werden diese Scancodes zu einheitlichen Keycodes umgewandelt und diese dann (von X11) an VirtualBox gesendet. VirtualBox nimmt dann den Keycode und wandelt ihn zurück in einen Scancode um, um diesen dann an das Gast-OS zu senden. (Das Gast-OS nimmt dann diesen Scancode und wandelt ihn wieder in einen Keycode um usw.) Dieser Mechanismus geht, wenn man im Host-OS Neo verwendet nicht mehr richtig.

Die verwendete Einstellung greift in den Keycode zu Scancode Umwandlungsprozess ein und definiert für bestimmte Keycodes (links vom =) einen bestimmten Scancode (rechts vom =) der emittiert werden soll. Die Idee hinter dieser Einstellung ist es die falschen Scancodes zu den richtigen umzubiegen. Leider hab ich es nicht geschafft für die #'-Taste (Keycode 51) einen Scancode zu finden, mit dem sie richtig im Gast-OS als Mod3 funktioniert. Deshalb hat sie den Scancode 58 (Caps Lock) bekommen. Dies erklärt auch den Bug mit der jetzigen Lösung.

Weitere Informationen dazu http://www.virtualbox.org/ticket/2302 (vor allem der Kommentar von therp am 2010-05-13) und http://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html.

Qemu

Qemu verwendet immer die Tastaturbelegung, die im Gastsystem (der virtuellen Maschine) eingestellt ist. Also muss man im Gastsystem Neo aktivieren.

Linux mit Windows als Gastsystem in Qemu: keine Probleme, egal welche Belegung man unter Linux eingestellt hat.

Mit Qemu und Autohotkey gibt es jedoch auch das Problem: Linker Mod3 geht nicht. Aber sonst ziemlich alles.

andLinux

andLinux beruht auf colinux, einem Linuxkernel der auf Windows läuft, und Xming, einem XServer, der ebenso auf Windows läuft. Auch wenn das Prinzip ähnlich dem einer Virtuellen Maschine ist, so ist dieses System doch deutlich schneller.

andLinux arbeitet mit Neo ganz gut zusammen, die Tastaturlayouteinstellungen in Windows und andLinux sind voneinander unabhängig.

  1. einfache Möglichkeit Unter Windows NeoVars (den Autohotkey-Treiber) verwenden, und bei andLinux keine Änderungen vornehmen. Dann greift NeoVars auch für andLinux, allerdings funktionieren dann !^ ~ und die Ebenen 5+6 nicht.

  2. vollständige Möglichkeit Unter Windows den KbdNeo-Treiber (natives Windows Tastaturlayout) verwenden, und dann unter andLinux das Tastaturlayout gesondert einstellen. Dafür kann xmodmap oder die X/de-Datei verwendet werden (wie für ein alleinstehendes Linux). Es ist zu beachten, dass der verwendete X-Server Xming die Datei C:\Programme\andLinux\Xming\xkb\symbols\de verwendet, und NICHT /usr/share/X11/xkb/symbols/de. Bei der aktuellen Version von andLinux (Beta 2 final) ist hier noch Neo1 enthalten (kann aber natürlich geändert werden).

RDP-Verbindungen

Mit dem Remote Desktop Protocol kann man von Windows- oder Linuxrechnern (Client) aus auf einen Windowsrechner (Server) zugreifen.

Probleme entstehen, wenn auf dem Server der AHK-Treiber (NeoVars) verwendet wird. Für eine rdp-Verbindung von einem Linux-Client aus muss auf einem der beiden Rechner qwertz aktiviert sein. Und egal ob der Client Windows oder Linux ist, steuert CapsLock unter Windows nicht mehr die dritte Ebene an.

rdesktop

Unter Linux gibt es das Programm "rdesktop" für RDP-Verbindungen. Es funktioniert ganz gut, wenn man den Schalter "-k de" aktiviert. Jedoch tritt beim Aktivieren von Mod4 mit der "<>"-Taste das Problem auf, dass immer das Zeichen "<" mit ausgegeben wird und auf der Kommandozeile die Warnung "WARNING: No translation for (keysym 0xfe11, ISO_Level5_Shift)" erscheint.

Dies lässt sich beheben, indem man (etwa unter Ubuntu) /usr/share/rdesktop/keymaps/de-neo mit folgendem Inhalt anlegt und dann statt "-k de" den Schalter "-k de-neo" angibt.

de-neo:

include de
# Don't print <
ISO_Level5_Shift 0x0 inhibit