neo
/
dokumentation
16
2
Fork 23
Code Issues 3 Pull Requests 2 Releases Activity
dokumentation/docs/Probleme/VM.md

7.7 KiB
Raw Blame History

Virtuelle Maschinen, Emulationen und RDP-Verbindungen

--8<-- "top/inhaltliche Ü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.

Es lässt sich kein allgemeingültiger Rat geben, da es unzählige Kombinationen aus sich unterschiedlich verhaltenen VMs, aus Host-Systemen, Gast-Systemen und Tastaturtreibern gibt. Bei Problemen unter Windows klappt es meist, im Host-Windows kbdneo einzusetzen und ggf. ReNeo während der Nutzung der VM bzw. des Remote Desktops zu deaktivieren. Behebt dies die Probleme nicht, ist es oft nötig, eines der beiden Systeme auf Qwertz einzustellen.

Ansonsten gilt: Ausprobieren, ausgehend von Qwertz auf Host- wie Gast-System und sich dann schrittweise vorantasten.

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 Capslock hat (die Mod-Funktion wird also nicht übernommen), und dass Mod4 immer noch ++ltgt++ 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.

!!! question "Erik sagt:" Kann ich nicht nachvollziehen, die Capslock-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.

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

#!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

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

??? info "Technische Details zu dieser Lösung" (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 ++raute++-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 unter <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 ++ltgt++-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

Remote Desktop Manager

Der Remote Desktop Manager scheint des lokale Tastaturlayout vom Client auch auf der Gegenstelle zu bewahren bzw. durchzuleiten. Ein tatsächliches Beispiel verwendet folgende Konfiguration:

  • lokal Windows 10 mit ReNeo (Standalone)
  • verbunden zu einem Windows 10 Server, dort Qwertz eingestellt

In dieser Konfiguration treten keine Probleme auf. Es kann sogar eine weitere RDP-Verbindung zu anderen Windows-Rechnern aufgebaut werden, auf denen Qwertz läuft, ohne dass das Layout auseinanderfällt.