Modify

Erstellt vor 10 Jahren

Geschlossen vor 10 Jahren

#135 closed Fehler/Defekt (fixed)

Mit der neuen Version der xkbmap funktioniert ein Großteil der linken Hälfte der vierten Ebene nicht mehr

Erstellt von: martin_r Verantwortlicher: erik
Priorität: normal Meilenstein: Neo Version 2.0
Komponente: Treiber: Linux – Xkbmap Version: 2.0 BETA
Stichworte: Beobachter: muflax@…

Beschreibung (zuletzt geändert von martin_r)

Außer Backspace, Tab und Enter funktioniert bei mir keine Taste der linken vierten Ebene mehr. Betriebssystem: Arch Linux, KDE

Anhänge (0)

Änderungshistorie (36)

comment:1 Geändert vor 10 Jahren durch erik

Gleicher Fehler wie #33 Kommentar 57?

Bei mir funktioniert noch alles. Unter Window Maker und Gnome.

Versionen des X-Servers? KDE?

comment:2 Geändert vor 10 Jahren durch muflax@…

  • Beobachter muflax@… hinzugefügt

Ich nutze auch Arch Linux und das sieht nach dem selben Fehler aus. Jetzt wo ich's sehe, scheint es wirklich nur die linke Hälfte zu betreffen. Hatte das nicht gemerkt, da ich die rechte fast nicht nutze.
Ich nutze als WM awesome und wmii, aber das Problem ist davon höchstwahrscheinlich unabhängig. Es betrifft wie gesagt nur QT-Apps, also wohl auch KDE. Meine Programmversionen hatte ich in #33 gepostet. X.org ist 1.6.1.

comment:3 Geändert vor 10 Jahren durch stephan

Was sagt denn 'xev' oder ein ähnliches Tool bei den nicht funktionierenden Tasten?

Kann das Problem unter Ubuntu mit X.org 1.6.0 nicht nachvollziehen.

comment:4 Geändert vor 10 Jahren durch muflax@…

xev-Output für "a", "A" und "mod4-a (down)", nacheinander: http://pastebin.com/m4ed6f812

Ich hab grade was probiert und das Problem für mich behoben. Ich hatte eine (unwirksame) policy unter /etc/hal/fdi/policy/10-keymap.fdi. Da martin_r auch Arch-User ist, wird er die vermutlich auch angelegt haben. Nachdem ich sie entfernt habe, also insbesondere nicht mehr

<merge key="input.xkb.layout" type="string">neo2</merge>
<merge key="input.xkb.variant" type="string">neo</merge>

definiere (ich benenne X/de in neo2 um), geht es korrekt in QT, warum auch immer. Das war sowieso verbuggt und ich nutze stattdessen setxkbmap in meiner .xinitrc.

comment:5 Geändert vor 10 Jahren durch muflax@…

Args, sorry, hab Mist gebaut. Grade gemerkt, dass ich ja die falsche Version des Layouts zum Testen genommen habe. Die Änderung bringt also nichts.

Ich wüsste also nicht mehr, wo Ubuntu sich jetzt in der Config unterscheiden könnte, außer in eventl. älteren Paketen.

comment:6 Geändert vor 10 Jahren durch erik

  • Verantwortlicher auf erik gesetzt

Gibt es eine Besserung mit r1824?

comment:7 Geändert vor 10 Jahren durch erik

Oh, auch bei mir gibt es mit KDE-Applikationen die gleichen Fehler. Ich nutze Fedora 10 und Window Maker. Bei GTK-Apps (und selbst bei xterm) gibt es die obigen Fehler der Ebene 4 nicht, daher ist mit das bisher nicht aufgefallen.

Allerdings funktioniert bei mir nur Tab und die Zahlen (Ziffernblock) auf Ebene 4. Bild↑ oder Bild↓, Ende, Pos1, Cursor ←↓→↑, Rück und Entf funktionieren nicht. Enter auch nicht.

comment:8 Geändert vor 10 Jahren durch stephan

Ich kann das Problem nun auch bei mir nachvollziehen. Scheinbar weigert sich KDE bestimmte Tasten zu interpretieren, wenn der vMod 'LevelThree' gesetzt ist.

Wenn Ebene4 (nach leichter Modifikation an den Types) durch den vMod 'LevelFive' aufgerufen wird, klappt es.
Der Fehler ist aufgetaucht, als wir xkb-intern die Levels vertauscht haben (r1803), um #33 zu "umgehen".

Wenn es nach mir ginge, würde ich diesen Tausch wieder rückgängig machen, da #33 (eigentlich ein Gnome-Bug) weniger schwerwiegend ist, da es sich einfach durch die systemweite Installation beheben lässt.

(Obwohl dies hier wohl auch nur ein Qt/KDE-Bug ist ...)

comment:9 Geändert vor 10 Jahren durch Christian P.

In dem Programm „Konsole“ lässt sich das Problem zumindest umgehen und zwar wiefolgt:
unter „Einstellungen/Profile“ verwalten das benutzte Profil auswählen und Profil bearbeiten … anklicken, dort unter der Registerkarte „Eingabe“ statt „Standard (XFree 4)“ „Linux-Konsole“ auswählen und mit „OK“ übernehmen.

comment:10 Geändert vor 10 Jahren durch muflax@…

Die neue Version (r1829) hat es noch schlimmer gemacht. Jetzt geht gar nichts außer Mod1 und Mod2 mehr. Da ich keine xmodmap nutze und mir Gnome egal ist, bin ich dafür Stephan's Änderung rückgängig zu machen. (Oder wenigstens einen der beiden Bugs zu fixen, je nachdem, was leichter ist. ;))

comment:11 Geändert vor 10 Jahren durch stephan

Das hört sich sehr danach an, als hättest du die zweite Datei 'types/level5' vergessen.
Bitte nochmal überprüfen.

comment:12 Geändert vor 10 Jahren durch muflax@…

Ah, hab die in r1824 beschriebenen Änderungen mal komplett gemacht. Dann geht zwar Mod3 & Co. wieder, aber es behebt den QT-Bug nicht. (Sorry, ich sollte echt mehr probieren, bevor ich hier schreibe... )

comment:13 Antwort: Geändert vor 10 Jahren durch erik

noch ein anderer fehler:
Wie Ihr seht kann ich nur mit der rechten Umschalt-taste groß schreiben. die rechte bewirkt kein umschalten auf großschreibung. Auch Capslock geht nicht mehr.

Wie habe ich das geschafft?
de/basic als standardbelegung, de/neo als zweitbelegung. das kann man entweder in gnome bei den tastatureinstellungen einstellen (siehe beispiele) oder ganz wie früher üblich per xorg.conf oder hal (siehe Anleitung für die xkbmap).

damit ist wieder fehler 46#X.org5 aktiv, nur in anderer form. :-(

comment:14 als Antwort auf: ↑ 13 ; Antwort: Geändert vor 10 Jahren durch stephan

Replying to erik:

damit ist wieder fehler 46#X.org5 aktiv, nur in anderer form. :-(

Hmm, das Layout wird wohl nicht ganz vollständig gewechselt. Wird das Layout mit "setxkbmap" gewechselt, klappt es einwandfrei.

Ich wüsst aber wirklich nicht, wie man sich daran anpassen könnte, ohne wiederrum andere Bugs wiederzubeleben.

comment:15 als Antwort auf: ↑ 14 Geändert vor 10 Jahren durch anonym

Replying to stephan:

Replying to erik:

damit ist wieder fehler 46#X.org5 aktiv, nur in anderer form. :-(

Hmm, das Layout wird wohl nicht ganz vollständig gewechselt. Wird das Layout mit "setxkbmap" gewechselt, klappt es einwandfrei.

Ja, aber viel komfortabler ist es eben über ’ne Tastenkombination oder per klick. Und es ist ja so vorgesehen.

Ich wüsst aber wirklich nicht, wie man sich daran anpassen könnte, ohne wiederrum andere Bugs wiederzubeleben.

Wahrscheinlich ist der Fehler sogar in Xorg. Also sollten wir den melden. Am Besten wäre dazu ein Minimalbeispiel, wo der Fehler auch schon auftritt. Reicht es, die Shift-Tasten neu zu belegen? Oder woran liegt es?

Dann wäre nur noch heraus zu finden, ob der KDE-Fehler ein KDE-Problem ist, oder QT generell schuld ist oder doch X.org oder sogar Neo? Jedenfalls haben wir dafür bis morgen Zeit. :-) Dann wird der Stand für X.org 1.6 eingefroren. Siehe Roadmap.

comment:16 Antwort: Geändert vor 10 Jahren durch anonym

Intern bekommt man mit einer Kombination Nicht-Neo/Neo folgendes:

    key <LFSH> {
        type[group2]= "TWO_LEVEL",
        symbols[Group1]= [         Shift_L ],
        actions[Group1]= [ NoAction() ],
        symbols[Group2]= [         Shift_L,       Caps_Lock ],
        actions[Group2]= [ SetMods(modifiers=Shift), LockMods(modifiers=Lock) ]
    };

Das NoAction() führt dazu, dass das Shift wirkungslos bleibt.

Abhilfe könnte es bringen, die Umschalttasten aus xkb_symbols "neo" herauszunehmen und
in einer gesonderten Tabelle (vielleicht in symbols/shift) zu implementieren. Dann kann man die Umschalttasten im Neo-Stil als Option für alle Belegungen verfügbar machen. Ich bezweifle aber, dass es dazu bis morgen reicht.

comment:17 Geändert vor 10 Jahren durch knittl

r1831 macht bei mir mehr probleme, als sie löst.

ebene 4 geht in gar keinen programmen mehr, stattdessen erscheint ebene 1

aber sonst: gute arbeit soweit!

comment:18 Antwort: Geändert vor 10 Jahren durch wettstein509@…

In Zeile 284 von de «NumLock» durch «LevelFive» ersetzen sollte Ebene 4 wieder erreichbar machen.

comment:19 als Antwort auf: ↑ 18 ; Antwort: Geändert vor 10 Jahren durch muflax@…

Replying to wettstein509@solnet.ch:

In Zeile 284 von de «NumLock» durch «LevelFive» ersetzen sollte Ebene 4 wieder erreichbar machen.

Tut es. QT scheint jetzt auch korrekt zu funktionieren.

comment:20 als Antwort auf: ↑ 19 Geändert vor 10 Jahren durch Christian P.

Replying to muflax@gmail.com:

Replying to wettstein509@solnet.ch:

In Zeile 284 von de «NumLock» durch «LevelFive» ersetzen sollte Ebene 4 wieder erreichbar machen.

Tut es. QT scheint jetzt auch korrekt zu funktionieren.

Dem kann ich nur zustimmen.

comment:21 als Antwort auf: ↑ 16 Geändert vor 10 Jahren durch erik

Replying to anonymous:

Abhilfe könnte es bringen, die Umschalttasten aus xkb_symbols "neo" herauszunehmen und
in einer gesonderten Tabelle (vielleicht in symbols/shift) zu implementieren. Dann kann man die Umschalttasten im Neo-Stil als Option für alle Belegungen verfügbar machen. Ich bezweifle aber, dass es dazu bis morgen reicht.

Wäre es möglich dies mal testweise zu implementieren, denn so wie jetzt ist Neo mit keiner anderen Belegung kompatibel, wenn man eine andere Belegung als Erstbelegung wählt und Neo als die zweite.

comment:22 Geändert vor 10 Jahren durch wettstein509@…

Die Methode mit Auslagern von Shift funktioniert.

  • In xkb/symbols/shift ergänze:
    partial modifier_keys
    xkb_symbols "lshift_both_capslock" {
      key <LFSH> {
        type[Group1]="TWO_LEVEL",
        symbols[Group1] = [ Shift_L,                       Caps_Lock                ],
        actions[Group1] = [ SetMods(modifiers=Shift),      LockMods(modifiers=Lock) ]
      };
    };
    
    partial modifier_keys
    xkb_symbols "rshift_both_capslock" {
      key <RTSH> {
        type[Group1]="TWO_LEVEL",
        symbols[Group1] = [ Shift_R,                       Caps_Lock                ],
        actions[Group1] = [ SetMods(modifiers=Shift),      LockMods(modifiers=Lock) ]
      };
    };
    partial modifier_keys
    xkb_symbols "both_capslock" {
      include "shift(lshift_both_capslock)"
      include "shift(rshift_both_capslock)"
    };
    
  • Nimm die entsprechenden Belegungen aus de heraus
  • In rules/xorg ergänze eine Zeile unter
    ! option        =       symbols
    

nämlich:

  shift:both_capslock   =       +shift(both_capslock) 
  • Benutze XkbOption shift:both_capslock. In xorg.conf habe ich z.B. ausprobiert:
            Option      "XkbLayout"  "us,de"
            Option      "XkbVariant" "intl,neo"
            Option      "XkbOptions" "shift:both_capslock,grp:ctrls_toggle"
    

Damit funktioniert Shift auch im US-Layout, inklusive dem allseits
beliebten Neo-CapsLock.

comment:23 Antwort: Geändert vor 10 Jahren durch erik

Nur um nochmal den aktuellen Stand festzuhalten:

  • Bei Version r1803 gibt es zwar nur Shift-Lock (statt Caps-Lock) und dieses lässt sich auch nur durch Drücken einer Shift-Taste deaktivieren, aber dafür funktioniert das Umschalten zwischen zwei Belegungen (zum Beispiel QWERTZ und Neo) ohne Probleme:
    setxkbmap -layout "de,de" -variant "basic,neo" -option "grp:alt_shift_toggle,grp_led:scroll" -model pc105
    
    (Alt + Umschalt zum Wechseln zwischen QWERTZ (= basic) und Neo, leuchtende Rollen-LED zeigt Neo an)
  • Mit der aktuellen Version r1834 lässt sich zwar in KDE-Programmen auch auf Ebene 4 alles verwenden, aber Caps-Lock funktioniert gar nicht mehr. Mod4-Lock schon. Und Umschalten (wie oben angegeben) kann man auch nicht mehr: Es passiert einfach nichts, wenn man Alt+Umschalt drückt.
  • Die in 135#comment:22 genannten Änderungen bewirken mit
    setxkbmap -layout "de,de" -variant "basic,neo" -option "shift:both_capslock,grp:alt_shift_toggle,grp_led:scroll" -model pc105
    
    leider nur, dass die 3. Ebene (deshalb auch die 6.) nicht mehr funktioniert. Und bei KDE-Programmen auch wieder die Bewegungstasten der 4. Ebene nicht (sonst schon!). Vielleicht muss ich X erst neu starten bzw. ein zweites X starten um es dort zu probieren? Also mit Strg+Alt+F3 auf eine Textkonsole gewechselt und dort angemeldet. Dann mit
    startx -- :1
    
    einen zweiten X-Server gestartet. Oh! Dabei fällt mir auf, dass es Fehler mit der symbols/de zu geben scheint (mir wird dort unter Gnome ein Fehler angezeigt, dass symbols/de nicht geladen werden kann). Daher kann ich dort nicht weiter testen.

Was mir auch noch aufgefallen ist: Mit r1834 kann ich auch nicht mehr mit Strg+Alt+F3 auf eine Textkonsole wechseln. Die de-Datei scheint also wirklich defekt zu sein. Werde gleich mal wieder auf eine etwas ältere Version wechseln.


Auch mit r1830 ist es nicht besser.
Komisch. Na jedenfalls geht das Umschalten auf ’ne Textkonsole (tty) mit Strg+Alt+F3 mit r1803 noch.

Oder liegt das alles jetzt nur an meinem System?

comment:24 als Antwort auf: ↑ 23 Geändert vor 10 Jahren durch martin_r

  • Beschreibung geändert (Diff)

Replying to erik:

Mit der aktuellen Version r1834 lässt sich zwar in KDE-Programmen auch auf Ebene 4 alles verwenden, aber Caps-Lock funktioniert gar nicht mehr.

Bei mir schon: ShiftL+ShiftR (Deaktivieren genauso :) )

comment:25 Geändert vor 10 Jahren durch erik

Hmm, bei mir hat’s wohl etwas im Verzeichnis /usr/share/X11/xkb/ zerhauen gehabt. Habe alles wieder mit dem entsprechenden Fedorapaket rückgängig gemacht.

1834

Nochmal: Also Caps-Lock funktioniert tatsächlich auch mit r1834. Allerdings nur ShiftL+ShiftR = CapsLock. Umgekehrt (ShiftR+ShiftL) passiert nichts. Auch Ebene 3 und 4 funktionieren (überall). Strg+Alt+F3 zum Wechseln auf eine Textkonsole (tty) funktioniert auch.

Aber wenn ich mehrere Belegungen lade (Neo nicht als erste!), dann funktioniert Caps-Lock nicht mehr. Außerdem auch die linke Shift-Taste nicht. Zusätzlich funktioniert gar keine Shift-Taste mehr bei der QWERTZ-Belegung (wenn ich QWERTZ und Neo als die zwei Varianten geladen habe).

1834 plus Änderungen von Kommentar 22

Mit dem Vorschlag von 135#comment:22 funktioniert Caps-Lock sowohl mit ShiftL+ShiftR als auch mit ShiftR+ShiftL. Auch Ebene 3 und 4 funktionieren (überall). Strg+Alt+F3 zum Wechseln auf eine Textkonsole (tty) funktioniert auch.

Aber wenn ich mehrere Belegungen lade (Neo nicht als erste!), dann funktioniert Caps-Lock nicht mehr. Außerdem auch die linke Shift-Taste nicht. Zusätzlich funktioniert gar keine Shift-Taste mehr bei der QWERTZ-Belegung (wenn ich QWERTZ und Neo als die zwei Belegungen geladen habe).

Einzige Verbesserung von 135#comment:22 ist also, dass Caps-Lock wieder mit beiden Shift-Kombinationen funktioniert.

Mein System:

[erik@supernegro ~]$ X -version

X.Org X Server 1.5.3
Release Date: 5 November 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.18-128.1.1.el5 x86_64 
Current Operating System: Linux supernegro 2.6.27.21-170.2.56.fc10.x86_64 #1 SMP Mon Mar 23 23:08:10 EDT 2009 x86_64
Build Date: 10 March 2009  07:20:43PM
Build ID: xorg-x11-server 1.5.3-15.fc10 
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.

[erik@supernegro ~]$ uname -a
Linux supernegro 2.6.27.21-170.2.56.fc10.x86_64 #1 SMP Mon Mar 23 23:08:10 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

comment:26 Geändert vor 10 Jahren durch erik

Zur Beruhigung aller: Mein System ist ja nicht auf dem neuesten Stand. Daher sollte vielleicht jemand mit aktuellem System (Fedora 11 oder Ubuntu 9.04 usw.) nochmal probieren und berichten.

comment:27 Antwort: Geändert vor 10 Jahren durch stephan

Das Problem mit der Shift-Taste liegt daran, dass du die Option "grp:alt_shift_toggle" verwendest, die allerdings mit der neuen Umsetzung nicht kompatibel ist, da dort die Shift-Taste neu definiert wird. Ich sehe auch keine Möglichkeit, Neo mit dieser Option kompatibel zu machen.

Die anderen Probleme mit dem Wechsel zwischen den Layouts sind wohl nur zu beheben, wenn alle Spezialfunktionen von Neo in externe Dateien ausgelagert werden und dann je nach Layout modular eingebunden werden (siehe Vorschlag von Andreas).

comment:28 als Antwort auf: ↑ 27 Geändert vor 10 Jahren durch erik

Replying to stephan:

Das Problem mit der Shift-Taste liegt daran, dass du die Option "grp:alt_shift_toggle" verwendest, die allerdings mit der neuen Umsetzung nicht kompatibel ist, da dort die Shift-Taste neu definiert wird. Ich sehe auch keine Möglichkeit, Neo mit dieser Option kompatibel zu machen.

Die anderen Probleme mit dem Wechsel zwischen den Layouts sind wohl nur zu beheben, wenn alle Spezialfunktionen von Neo in externe Dateien ausgelagert werden und dann je nach Layout modular eingebunden werden (siehe Vorschlag von Andreas).

Dann bin ich dafür alles auszulagern. So ist es von den xkeyboard-config-Entwicklern eh vorgesehen. Oder was spricht dagegen? Wäre das denn noch viel, was da ausgelagert werden müsste? Nur noch Compose, oder?

comment:29 Antwort: Geändert vor 10 Jahren durch wettstein509@…

Dann bin ich dafür alles auszulagern. So ist es von den xkeyboard-config-Entwicklern eh vorgesehen. Oder was spricht dagegen? Wäre das denn noch viel, was da ausgelagert werden müsste? Nur noch Compose, oder?

Neben Shift wären noch Mod3 und Mod4 auszulagern. Bei Mod3/Mod4 bin ich nicht sicher, ob sie auch in von Neo abweichenden Kombinationen funktionieren, und das sollten sie im Interesse der Modularität tun.

Auslagerung hat praktische Vorteile. Insbesondere könnte man den Benutzern neben Standard-Neo ein paar Varianten anbieten (ShiftLock statt oder zusätzlich zu CapsLock, Mod4 auf Windows-Tasten…). Zudem können andere Layouts mitprofitieren.

Der Nachteil wäre die Ausweitung von derzeit zwei auf sechs zu installierendeb Dateien.

comment:30 als Antwort auf: ↑ 29 Geändert vor 10 Jahren durch erik

Replying to wettstein509@solnet.ch:

Dann bin ich dafür alles auszulagern. So ist es von den xkeyboard-config-Entwicklern eh vorgesehen. Oder was spricht dagegen? Wäre das denn noch viel, was da ausgelagert werden müsste? Nur noch Compose, oder?

Neben Shift wären noch Mod3 und Mod4 auszulagern. Bei Mod3/Mod4 bin ich nicht sicher, ob sie auch in von Neo abweichenden Kombinationen funktionieren, und das sollten sie im Interesse der Modularität tun.

Was ist mit von Neo abweichenden Kombinationen gemeint? Wie, außer einzeln und zusammen könnte man sie denn noch kombinieren?

Auslagerung hat praktische Vorteile. Insbesondere könnte man den Benutzern neben Standard-Neo ein paar Varianten anbieten (ShiftLock statt oder zusätzlich zu CapsLock, Mod4 auf Windows-Tasten…). Zudem können andere Layouts mitprofitieren.

Sehr gut. Die Xkbmap wird also ähnlich flexibel wie die ahk-Variante.

Der Nachteil wäre die Ausweitung von derzeit zwei auf sechs zu installierendeb Dateien.

Das ist kein Nachteil. Nach kurzer Zeit ist eh alles schon bei den neuen Linuxen dabei, da kann es einem egal sein, aus wievielen Einzeldateien sich die Belegung zusammen setzt. Für die Übergangszeit muss man eben ein tar.gz runter laden und an die richtige Stelle entpacken. Das kann in die Anleitung.

comment:31 Antwort: Geändert vor 10 Jahren durch wettstein509@…

Was ist mit von Neo abweichenden Kombinationen gemeint? Wie, außer einzeln und zusammen könnte man sie denn noch kombinieren?

xkb-Layoutentwickler könnten die Modifikatoren für von Neo völlig verschiedene Layouts verwenden wollen. Ein interessanter Kandidat ist insbesondere Mod4.

comment:32 als Antwort auf: ↑ 31 ; Antwort: Geändert vor 10 Jahren durch erik

Replying to wettstein509@solnet.ch:

Was ist mit von Neo abweichenden Kombinationen gemeint? Wie, außer einzeln und zusammen könnte man sie denn noch kombinieren?

xkb-Layoutentwickler könnten die Modifikatoren für von Neo völlig verschiedene Layouts verwenden wollen. Ein interessanter Kandidat ist insbesondere Mod4.

Dabei kommt die Frage auf, ob es nicht eh schon einen weiteren Mod gibt. Haben nicht einige asiatische Sprachen mehr als zwei Mods? Vielleicht können wir einfach diesen für Neo verwenden.

comment:33 Antwort: Geändert vor 10 Jahren durch erik

Hier noch ein ärgerlicher Fehler:
Wenn ich mich mit einem Benutzer anmelde, der de/basic (QWERTZ) als Belegung hat, dann kann ich auch nicht mal mit

setxkbmap de neo

bewirken, dass auf der QWERTZ-Capslock-Taste Mod3 liegt. Diese Taste reagiert weiter so, als wäre dort eine Capslock-Taste. Ich habe als nur noch die rechte Mod3 zur Verfügung.

Wenn ich andererseits, wie oben schon beschrieben, QWERTZ und Neo als die zwei wechselbaren Belegungen einstelle (bei Gnome bei den Tastatureinstellungen), dann kann der QWERTZ-Benutzer nicht mehr groß schreiben (beide Shift-Tasten bewirken nichts). Das geht natürlich überhaupt nicht.

Ich rede hier von Version r1846 ohne die in Kommentar 22 genannten Änderungen. Falls es damit (auf aktuellen Systemen) besser sein sollte, sollten wir diese Änderungen bald ins SVN aufnehmen. Sprich die Datei rules/base und symbols/shift. Am Besten basierend auf den aktuellen Dateien aus dem GIT-Repo von X.org.

comment:34 als Antwort auf: ↑ 32 Geändert vor 10 Jahren durch erik

Replying to erik:

Replying to wettstein509@solnet.ch:

Was ist mit von Neo abweichenden Kombinationen gemeint? Wie, außer einzeln und zusammen könnte man sie denn noch kombinieren?

xkb-Layoutentwickler könnten die Modifikatoren für von Neo völlig verschiedene Layouts verwenden wollen. Ein interessanter Kandidat ist insbesondere Mod4.

Dabei kommt die Frage auf, ob es nicht eh schon einen weiteren Mod gibt. Haben nicht einige asiatische Sprachen mehr als zwei Mods? Vielleicht können wir einfach diesen für Neo verwenden.

Ich meine hier vor allem chinesisch (symbols/cn) und japanisch (symbols/jp). Vielleicht auch andere. Genauer angesehen habe ich mir die jetzt nicht. Ich weiß nur von Florian, der den kbdneo2-Windows-Treiber schreibt, dass er auch den japanischen Mod für Neo missbraucht hat.

Natürlich haben die dann trotzdem nicht das von Neo vorgeschriebene Lock-Verhalten. Aber das kann man ja optional einbauen.

comment:35 als Antwort auf: ↑ 33 Geändert vor 10 Jahren durch erik

Replying to erik:

Hier noch ein ärgerlicher Fehler:
Wenn ich mich mit einem Benutzer anmelde, der de/basic (QWERTZ) als Belegung hat, dann kann ich auch nicht mal mit

setxkbmap de neo

bewirken, dass auf der QWERTZ-Capslock-Taste Mod3 liegt. Diese Taste reagiert weiter so, als wäre dort eine Capslock-Taste. Ich habe als nur noch die rechte Mod3 zur Verfügung.

Die Lösung von Björn von der Mailingliste funktioniert tatsächlich. Man muss also

setxkbmap de neo -option

eingeben, damit alte Optionen (hier also Capslock auf der Feststelltaste) gelöscht werden.

comment:36 Geändert vor 10 Jahren durch stephan

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

Das ursprüngliche Problem wurde behoben. Andere Probleme (vorallem die, die durch die Verwendung der mehreren Dateien aufgetreten sind) bitte in einem anderen Ticket diskutieren (z.B. #141).

Kommentar hinzufügen

Ticket ändern

Eigenschaften ändern
<Autor-Feld>
Aktion
als closed .
Der Status der Lösung wird gelöscht. Der nächste Status wird 'reopened' sein.
Autor


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

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