Modify

Erstellt vor 2 Jahren

Zuletzt geändert vor 23 Monaten

#438 reopened Fehler/Defekt

Alt+F# Tastenkombinationen funktionieren nicht in neo,basic xkb-Variante

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

Beschreibung

Setzt man
setxkbmap -layout de,de -variant basic,neo -option -option grp:sclk_toggle -option grp_led:scroll
wie in der Wiki beschrieben, funktioniert der Aufruf von Krunner in KDE 4 nicht mehr.
Konsole (der Terminal-Emulator) liefert den Grund: Alt+F[1–12] geben ‚PQRS;3~;3~;3~;3~;3~;3~;3~;3~‘ aus.

Die Variante anders herum hat das Problem nicht. Man kann also damit leben, auch wenn man bei jedem X-Start ‚Rollen‘ drücken darf. Oder man benutzt Neo exklusiv … Auch wenn ich damit jetzt eigentlich kein Problem hätte.

Reproduzierbar: Immer

Schritte zum Reproduzieren:

  1. setxkbmap -layout de,de -variant basic,neo -option -option grp:sclk_toggle -option grp_led:scroll
  2. Alt+F2 drücken

Endergebnis:
Alt+F2 startet nicht den Anwendungsstarter, sondern drückt ‚Q‘.

Erwartetes Ergebnis:
Alt+F2 sollte Anwendungsstarter starten (z. B. krunner).

Systeminformationen:
Gentoo – vollständig aktualisiert, stabiler Zweig (amd64)
KDE-Profil ohne Systemd
xkeyboard-config-2.14
xorg-server-1.16.4

Hardware:
HP Compaq 6735b
Cherry MX 3.0 mit blauen Schaltern

Ich hoffe, das reicht erst mal an Informationen.

Ich könnte höchstens noch ein emerge --info anhängen, aber damit können wohl eher nur Gentoo Entwickler was anfangen.

Anhänge (1)

10-keyboard.conf (258 Byte) - hinzugefügt von ullman.bugs@… vor 2 Jahren.
X config für evdev und udev

Alle Anhänge herunterladen als: .zip

Änderungshistorie (7)

comment:1 Geändert vor 2 Jahren durch ullman.bugs@…

  • Lösung auf invalid gesetzt
  • Status von new nach closed geändert

Enschuldigung, hat sich bereits erledigt. Ich hatte in meine X keyboard-config als Zweitlayout nodeadkeys. Seltsam ist aber, dass setxkbmap mit obigen Optionen nichts an dem Phänomen in laufender Sitzung ändern konnte. Ich hätte das irgendwie erwartet.

Nu ja, was soll’s. Entschuldigt die sinnfreien Mails.

Geändert vor 2 Jahren durch ullman.bugs@…

X config für evdev und udev

comment:2 Geändert vor 2 Jahren durch ullman.bugs@…

  • Lösung invalid gelöscht
  • Status von closed nach reopened geändert

Anscheinend war das temporär aktivierte Tastaturmanagement von KDE für die eigentliche Problemlösung verantwortlich. Kombiniert mit dem vergessenen X-Neustart (kdm startet ihn beim Abmelden nicht mehr neu) hatte es so den Anschein, dass der Fehler behoben wäre.

Das Problem sollte also weiterhin wie oben angegeben reproduzierbar sein – ob basic oder nodeadkeys das Zweitlayout ist, ist wohl egal. Weiterhin habe ich die erste Variante mit basic als Hauptlayout noch einmal getestet, um mögliche „Unschärfen“ bei der Erstmessung auszuschließen.

Man müsste prinzipiell nur die Standardeinstellungen von KDE mit der in der Wiki angegebenen Konfiguration nachschauen, um das Problem durch eine entsprechende Wikiseitenaktualisierung zu beheben, aber … nun ja, ich wüsste jetzt auch nicht, wo man die finden würde. Vermutlich im Quelltext.

Wenigstens gibt es einen vernünftigen Workaround.

comment:3 Geändert vor 2 Jahren durch ullman.bugs@…

  • Lösung auf wontfix gesetzt
  • Status von reopened nach closed geändert

Habe das Problem weiter eingegrenzt und die Ursache bei kdm’s auto login feature gefunden.
Meine ersten Reproduktionsschritte waren natürlich falsch, schon allein weil ich den falschen setxkbmap-Befehl angegeben habe.

Ich aktualisiere sie daher:

  1. kdm’s auto login Modus aktivieren.
  2. cp 10-keyboard.conf /etc/X11/xorg.conf.d/
  3. kdm neu starten.

Tatsächliches Ergebnis:
Alt+F# sowie Meta/Tux+<*> Kombinationen funktionieren nicht.

Der vernünftige Workaround ist damit, kdm normal (ohne auto login) zu starten.

Habe dazu einen bug report geschrieben:
https://bugs.kde.org/show_bug.cgi?id=350386

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

  • Lösung wontfix gelöscht
  • Status von closed nach reopened geändert

Mittlerweile ist relativ klar geworden, dass das Problem sowohl mit sddm, als auch kdm reproduzierbar ist. Bei beiden verwende ich im Xsetup Script ein einfaches ‘setxkbmap de neo’, um plasma zur Erkennung von Tastenkürzeln zu überreden. Das betrifft sowohl Plasma5 als auch KDE4. Die Ursache liegt nicht in Qt4|5. Beide Versionen zeigen in khotkeys (egal welches) korrekt erkannte Tastenkürzel, nur werden diese dann von der Plasmalaufzeit ignoriert.
Neo in der xorg.conf als alleiniges Layout zu setzen, löst das Problem jedenfalls nicht, sondern nur das eigentlich temporäre ‘setxkbmap’. Der Workaround ist folglich auch temporär. Mehr dazu im nächsten Kommentar.

Ich würde einen der Entwickler bitten, wenigstens mal eine beliebige KDE-Live-CD zu starten, um das zu reproduzieren und zu bestätigen. Reproduzieren kann ich das auf Uni-Rechnern mit OpenSUSE 13.2 sowie meinen beiden Gentoo Systemen mit ein mal KDE4 und ein mal Plasma5.
Anschließend kann man immer noch auslosen, bei wem der Fehler liegt.

comment:5 Geändert vor 23 Monaten durch tzone@…

#464 macht den Workaround mit setxkbmap bis zum Sitzungsneustart unwirksam.

comment:6 Geändert vor 23 Monaten durch tzone@…

Eine kleine Korrektur: Die Tastenkombinationen werden von khotkeys schon erkannt, aber auf Basis des basic Layouts. Wird vor Sitzungsstart setxkbmap de neo ausgeführt, werden sie dagegen erkannt. Die xkb-Einstellungen von vorher und nachher unterscheiden sich dabei nicht. Werde das vielleicht beim KDE Bugzilla melden.

Kommentar hinzufügen

Ticket ändern

Eigenschaften ändern
<Autor-Feld>
Aktion
als reopened .
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.
Autor


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

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