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

Closed
opened 2015-07-19 02:10:24 +02:00 by ullman.bugs · 8 comments

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.

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.
ullman.bugs added the
Bug
Treiber/Linux/xkbmap
labels 2015-07-19 02:10:24 +02:00
ullman.bugs added the
Invalid
label 2015-07-19 02:27:46 +02:00
Author

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.

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

X config für evdev und udev

X config für evdev und udev
ullman.bugs removed the
Invalid
label 2015-07-19 22:17:21 +02:00
Author

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.

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.
ullman.bugs added the
Wontfix
label 2015-07-20 02:09:57 +02:00
Author

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

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
tzone reopened this issue 2016-01-02 23:36:29 +01:00
tzone removed the
Wontfix
label 2016-01-02 23:36:29 +01:00

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.

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.

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

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

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.

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

Ich kann das Problem mit aktuellem sddm und Plasma nicht mehr reproduzieren.
Also wurde es eventuell in den letzten 5 Jahren doch gefixt.

Falls das Problem weiterhin besteht, bitte wieder öffnen.

Ich kann das Problem mit aktuellem sddm und Plasma nicht mehr reproduzieren. Also wurde es eventuell in den letzten 5 Jahren doch gefixt. Falls das Problem weiterhin besteht, bitte wieder öffnen.
hrnz closed this issue 2021-01-16 22:57:00 +01:00
Sign in to join this conversation.
No Milestone
No Assignees
3 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#438
No description provided.