Modify

Erstellt vor 21 Monaten

Zuletzt geändert vor 21 Monaten

#464 new Fehler/Defekt

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

Erstellt von: tzone@… Verantwortlicher:
Priorität: normal Meilenstein:
Komponente: Treiber: Linux – Xkbmap Version: 2.0 Final
Stichworte: Beobachter:

Beschreibung

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?

Anhänge (2)

xkbDiff (870 Byte) - hinzugefügt von tzone@… vor 21 Monaten.
xkbconfig vor und nach VM Zugriff
diffUmfeld.txt (786 Byte) - hinzugefügt von tzone@… vor 21 Monaten.
Das gleiche in allen Tests nicht veränderte Diff mit Umfeld

Alle Anhänge herunterladen als: .zip

Änderungshistorie (6)

comment:1 Geändert vor 21 Monaten durch stephan

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).

Geändert vor 21 Monaten durch tzone@…

xkbconfig vor und nach VM Zugriff

comment:2 Geändert vor 21 Monaten durch tzone@…

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.

comment:3 Geändert vor 21 Monaten durch stephan

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.

Geändert vor 21 Monaten durch tzone@…

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

comment:4 Geändert vor 21 Monaten durch tzone@…

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.

Kommentar hinzufügen

Ticket ändern

Eigenschaften ändern
<Autor-Feld>
Aktion
als new .
als Der Status der Lösung wird gesetzt. Der nächste Status wird 'closed' sein.
zu (none) wird von der Verantwortlichkeit für das Ticket befreit. Der nächste Status wird 'new' sein.
Die Verantwortlichkeit für das Ticket wird von (none) an anonymous übertragen. Der nächste Status wird 'assigned' sein.
Autor


E-Mail-Adresse und Benutzername können in den Einstellungen gespeichert werden.

 
Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.