Alt+F# Tastenkombinationen funktionieren nicht in neo,basic xkb-Variante #438
Labels
Sans labels
(╯°□°）╯︵ ┻━┻
Bug
Diskussion
Dokumentation
Duplikat
Gitea
Hardware
Hilfe
Invalid
Java
Lernen
Qt
Remote
Subversion
Tablet
Tastaturbelegung
Test
Treiber/Android
Treiber/iOS
Treiber/Linux/Konsole
Treiber/Linux/xkbmap
Treiber/Linux/xmodmap
Treiber/MacOS
Treiber/Windows/AHK
Treiber/Windows/kbdneo
Treiber/Windows/ReNeo
Verbesserung
Website
Windows 11
Wontfix
Worksforme
Sans jalon
Sans assignation
3 participants
Notifications
Échéance
Aucune échéance n'a été définie.
Dépendances
Aucune dépendance définie.
Référence : neo/neo-layout#438
Chargement…
Référencer dans un nouveau ticket
Sans contenu.
Supprimer la branche "%!s(<nil>)"
La suppression d’une branche est permanente. Bien qu’une branche supprimée puisse temporairement subsister, elle NE PEUT PAS être facilement restaurée. Continuer ?
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:
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.
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.
X config für evdev und udev
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.
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:
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
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.
Eine kleine Korrektur: Die Tastenkombinationen werden von khotkeys schon erkannt, aber auf Basis des basic Layouts. Wird vor Sitzungsstart
setxkbmap de neoausgeführt, werden sie dagegen erkannt. Die xkb-Einstellungen von vorher und nachher unterscheiden sich dabei nicht. Werde das vielleicht beim KDE Bugzilla melden.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.