Tastaturnutzung in VMware VM → keine Tastenkombinationen und rechte Shift Taste auf Host #464

New Issue

tzone · 2016-01-03T00:10:47+01:00

tzone commented

2016-01-03 00:10:47 +01:00

Nach einmaliger Nutzung der Tastatur in einer VMware VM (Windows 8 mit qwertz) unter einem Host Linux (aktualisiertes Gentoo) funktionieren sämtliche bisher getesteten Tastenkombinationen (Strg+F,Strg+Shift+T) nicht mehr. Der Workaround aus #438 wird wirkungslos (und damit fast alle anderen auch). Die rechte Shift Taste aktiviert nur noch den Caps Lock Modus (in links-rechts-Kombi).

Der Workaround ist das erneute Ausfüheren von ‘setxkbmap de; setxkbmap de neo’. Leider triggert dieser weitere Fehler wie den aus der Wiki: Die anhaltend gedrückte rechte Shift-Taste Wechselt nun repetitiv den Caps Lock Modus. Die Led blinkt also nicht einfach nur sondern zeigt tatsächlich den aktuellen Modus an (nicht wie mit Windows AHK).

Schritte zum Anlocken:

Nutze Tastatur in VMware VM.
Löse eingefangene Tastatur mit Strg+Alt.

Probleme nach Erfolg:

Tastenkombinationen funktionieren nicht mehr.
Plasma Workaround aus #438 wird wirkungslos.
Rechte Shift-Taste funktioniert nur noch für Rechts-Links-Shift-Kombination zum Caps Lock Moduswechsel.

Schritt zum Totschlagen:

• Führe ‘setxkbmap de; setxkbmap de neo’ aus.

Nebenwirkungen vom Totschlagen:

Die klebenden Eier sorgen für Ungezieferausbreitung.
Dank Nachkommen verursacht die anhaltend gedrückte rechte Shift-Taste einen repetitiven Caps Lock Moduswechsel.

Utopie:

Man hat ein Insektennetz.
Man hat mehrere Kammerjäger (vorzugsweise hungrige Spinnen)

PS: Sollte man im Tracker eigentlich auf Englisch posten oder interessieren sich die Entwickler der involvierten Projekte (xkb,qt,plasma,gnome,gtk) so wenig für Layout-Probleme, dass es eigentlich egal ist?

Nach einmaliger Nutzung der Tastatur in einer VMware VM (Windows 8 mit qwertz) unter einem Host Linux (aktualisiertes Gentoo) funktionieren sämtliche bisher getesteten Tastenkombinationen (Strg+F,Strg+Shift+T) nicht mehr. Der Workaround aus #438 wird wirkungslos (und damit fast alle anderen auch). Die rechte Shift Taste aktiviert nur noch den Caps Lock Modus (in links-rechts-Kombi). Der Workaround ist das erneute Ausfüheren von ‘setxkbmap de; setxkbmap de neo’. Leider triggert dieser weitere Fehler wie den aus der Wiki: Die anhaltend gedrückte rechte Shift-Taste Wechselt nun repetitiv den Caps Lock Modus. Die Led blinkt also nicht einfach nur sondern zeigt tatsächlich den aktuellen Modus an (nicht wie mit Windows AHK). Schritte zum Anlocken: 1. Nutze Tastatur in VMware VM. 2. Löse eingefangene Tastatur mit Strg+Alt. Probleme nach Erfolg: 1. Tastenkombinationen funktionieren nicht mehr. 2. Plasma Workaround aus #438 wird wirkungslos. 3. Rechte Shift-Taste funktioniert nur noch für Rechts-Links-Shift-Kombination zum Caps Lock Moduswechsel. Schritt zum Totschlagen: • Führe ‘setxkbmap de; setxkbmap de neo’ aus. Nebenwirkungen vom Totschlagen: 1. Die klebenden Eier sorgen für Ungezieferausbreitung. 2. Dank Nachkommen verursacht die anhaltend gedrückte rechte Shift-Taste einen repetitiven Caps Lock Moduswechsel. Utopie: 1. Man hat ein Insektennetz. 2. Man hat mehrere Kammerjäger (vorzugsweise hungrige Spinnen) PS: Sollte man im Tracker eigentlich auf Englisch posten oder interessieren sich die Entwickler der involvierten Projekte (xkb,qt,plasma,gnome,gtk) so wenig für Layout-Probleme, dass es eigentlich egal ist?

tzone added the

Bug

Treiber/Linux/xkbmap

labels 2016-01-03 00:10:47 +01:00

Stephan commented

2016-01-03 12:36:25 +01:00

Wenn du die erzeugte Datei von xkbcomp -xkb $DISPLAY -o test.xkb vor und nach deiner VM-Aktion vergleichst, siehst du möglicherweise, was VMWare an der Belegung verändert hat.

Vielleicht solltest du beim Testen auch sichergehen, dass du keine komischen options verwendest: nutze statt setxkbmap de neo lieber setxkbmap de neo -option.

Ich glaube kaum, dass Entwickler der anderen Projekte hier mitlesen. Wenn denen ein Bug zuzuschreiben ist, dann muss letztlich auch bei denen ein Bugreport geöffnet werden (dann aber in Englisch).

Wenn du die erzeugte Datei von `xkbcomp -xkb $DISPLAY -o test.xkb` vor und nach deiner VM-Aktion vergleichst, siehst du möglicherweise, was VMWare an der Belegung verändert hat. Vielleicht solltest du beim Testen auch sichergehen, dass du keine komischen options verwendest: nutze statt `setxkbmap de neo` lieber `setxkbmap de neo -option`. Ich glaube kaum, dass Entwickler der anderen Projekte hier mitlesen. Wenn denen ein Bug zuzuschreiben ist, dann muss letztlich auch bei denen ein Bugreport geöffnet werden (dann aber in Englisch).

tzone commented

2016-01-04 02:19:26 +01:00

xkbconfig vor und nach VM Zugriff

xkbDiff

870 B

tzone commented

2016-01-04 02:31:16 +01:00

Hab ein Diff von vor und nach VM-Zugriff erzeugt. Da in Xsetup jetzt setxkbmap de neo -option verwendet wurde, ist das Diff zwischen xkbconf nach einem auf den VM-Zugriff folgenden setxkbmap de neo erwartungsgemäß leer. Leider funktionieren die Tastenkürzel auch weiterhin wie angegeben durch den Workaround nur bedingt und das CapsLock nervt. Gibt es sonst was Konfigurationstechnisches, das ich beachten sollte? Ich verwende derzeit pc105 als Layoutmodell. Habe eine Cherry MX 3.0 mit blauen Schaltertypen. Keine Ahnung, ob eines der vordefinierten Cherrymodelle theoretisch passen würde.

Hab ein Diff von vor und nach VM-Zugriff erzeugt. Da in Xsetup jetzt ` setxkbmap de neo -option ` verwendet wurde, ist das Diff zwischen xkbconf nach einem auf den VM-Zugriff folgenden ` setxkbmap de neo ` erwartungsgemäß leer. Leider funktionieren die Tastenkürzel auch weiterhin wie angegeben durch den Workaround nur bedingt und das CapsLock nervt. Gibt es sonst was Konfigurationstechnisches, das ich beachten sollte? Ich verwende derzeit pc105 als Layoutmodell. Habe eine Cherry MX 3.0 mit blauen Schaltertypen. Keine Ahnung, ob eines der vordefinierten Cherrymodelle theoretisch passen würde.

Stephan commented

2016-01-04 19:29:01 +01:00

Naja, in der zweiten Datei fehlen die modifier_map Anweisungen, das erklärt, warum die Tastenkombinationen danach nicht mehr funktionieren. Bin mir nicht sicher, warum VMWare das bewirkt.

Zum eigenartigen Verhalten mit deinem Workaround:
Ich vermute, dass VMware auch am keyboard state rumpfuscht: mit xkbwatch kann man den aktuellen modifier status überwachen. Interessant wäre z.b zu beobachten, wie sich CapsLock innerhalb der VM auf das keyboard state des Hosts auswirkt.
Idealerweise sollte VMware wohl ein eigenes keyboard state haben und bei jedem focus/unfocus der VM mit dem keyboard state des hosts austauschen.

Mit ein bisschen Debugging kann man sich vielleicht zusammenreimen, was VMware anstellt. Ansonsten kann man sich mit einem reproduzierbaren Minimal-Beispiel an VMWare wenden, die können vielleicht auch was dazu sagen.

pc105 sollte schon in Ordnung sein.

PS: nimm lieber diff -u zum Vergleichen, ist schöner.

Naja, in der zweiten Datei fehlen die `modifier_map` Anweisungen, das erklärt, warum die Tastenkombinationen danach nicht mehr funktionieren. Bin mir nicht sicher, warum VMWare das bewirkt. Zum eigenartigen Verhalten mit deinem Workaround: Ich vermute, dass VMware auch am keyboard state rumpfuscht: mit `xkbwatch` kann man den aktuellen modifier status überwachen. Interessant wäre z.b zu beobachten, wie sich CapsLock innerhalb der VM auf das keyboard state des Hosts auswirkt. Idealerweise sollte VMware wohl ein eigenes keyboard state haben und bei jedem focus/unfocus der VM mit dem keyboard state des hosts austauschen. Mit ein bisschen Debugging kann man sich vielleicht zusammenreimen, was VMware anstellt. Ansonsten kann man sich mit einem reproduzierbaren Minimal-Beispiel an VMWare wenden, die können vielleicht auch was dazu sagen. pc105 sollte schon in Ordnung sein. PS: nimm lieber `diff -u` zum Vergleichen, ist schöner.

tzone commented

2016-01-04 22:26:08 +01:00

Das gleiche in allen Tests nicht veränderte Diff mit Umfeld

diffUmfeld.txt

786 B

tzone commented

2016-01-04 22:57:47 +01:00

Nun auch dieser Hinweis war hilfreich, da ich es jetzt tatsächlich bis zu einem validen Workaround gebracht habe. Im Prinzip stand er allerdings in der Wiki. Und Erik hat vielleicht sogar recht, weil er sich auf Autohotkey im Gast bezog, und nicht kbd_neo.
Dewa – pardon – nun denn:
Damit die VM nicht das Host-Layout zur Strecke bringt, darf bei der Tastatursteuerungsübergabe kein Neo Layout gesetzt sein. Ist es qwertz, kann man munter die Tastatur lösen und sogar khotkeys spielt weiterhin mit. Ist es aber gesetzt gibt es die im Diff angegebenen Modifiermodifizierungen. xkbwatch verhält sich wie folgt: Caps Lock mit Host qwertz setzt Caps Lock auf Host. Ansonsten werden ebenfalls bis auf die rechte Shift-Taste alle Modifier ans Host-System übermittelt.
Mir ist sogar wieder eingefallen, warum ich setxkbmap zusätzlich in SDDM hatte: Die in khotkeys eingestellten Kürzel funktionieren zwar, orientieren sich aber am Qwertz-Layout. Das ändert sich erst durch ein zusätzlich ausgeführtes setxkbmap. Startet man die Sitzung danach neu, ändert sich dank SDDM’s nur im Fehlerfall durchgeführten X-Neustart daran nichts. Oh, und ich erstelle dann schon noch ein Diff werde es aber in #438 anhängen. Das wäre vielleicht tatsächlich ein Kandidat für einen separaten Projekt-Bug-Report, da Gentoo eher weniger zu den von VMware unterstützten Host-Linux-Systemen gehört. Hab beim KDE Bugzilla dagegen schon öfters welche geschrieben.

Nun, da ich bei VMware keine Unterstützung finden werde und das Problem nicht wirklich bei euch lag, würde ich dir den endgültigen Ticketzustand überlassen.

Nun auch dieser Hinweis war hilfreich, da ich es jetzt tatsächlich bis zu einem validen Workaround gebracht habe. Im Prinzip stand er allerdings in der Wiki. Und Erik hat vielleicht sogar recht, weil er sich auf Autohotkey im Gast bezog, und nicht kbd_neo. Dewa – pardon – nun denn: Damit die VM nicht das Host-Layout zur Strecke bringt, darf bei der Tastatursteuerungsübergabe kein Neo Layout gesetzt sein. Ist es qwertz, kann man munter die Tastatur lösen und sogar khotkeys spielt weiterhin mit. Ist es aber gesetzt gibt es die im Diff angegebenen Modifiermodifizierungen. xkbwatch verhält sich wie folgt: Caps Lock mit Host qwertz setzt Caps Lock auf Host. Ansonsten werden ebenfalls bis auf die rechte Shift-Taste alle Modifier ans Host-System übermittelt. Mir ist sogar wieder eingefallen, warum ich setxkbmap zusätzlich in SDDM hatte: Die in khotkeys eingestellten Kürzel funktionieren zwar, orientieren sich aber am Qwertz-Layout. Das ändert sich erst durch ein zusätzlich ausgeführtes setxkbmap. Startet man die Sitzung danach neu, ändert sich dank SDDM’s nur im Fehlerfall durchgeführten X-Neustart daran nichts. Oh, und ich erstelle dann schon noch ein Diff werde es aber in #438 anhängen. Das wäre vielleicht tatsächlich ein Kandidat für einen separaten Projekt-Bug-Report, da Gentoo eher weniger zu den von VMware unterstützten Host-Linux-Systemen gehört. Hab beim KDE Bugzilla dagegen schon öfters welche geschrieben. Nun, da ich bei VMware keine Unterstützung finden werde und das Problem nicht wirklich bei euch lag, würde ich dir den endgültigen Ticketzustand überlassen.

qwertfisch added the

Remote

label 2022-10-06 03:17:45 +02:00

Sign in to join this conversation.

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: neo/neo-layout#464