[Neo] Re: "Neo20.exe" geht nicht mit "normalen" Browsern in Win7
> On Tue, Feb 4, 2020 at 8:33 PM Manuel Ullmann wrote: >> >> In RDP funktioniert es, aber nur, wenn es auf dem zugreifenden >> Rechner deaktiviert ist. Sonst wertet die jeweils andere Instanz Shift >> als das Empfangen sehr vieler Zeichen und fragt, ob es sich beenden >> soll. > > Man kann auch bei den Settings der RDP-Verbindung unter "Local > Resources > Keyboard > Apply Window key combinations" (wie auch immer > auf Deutsch? "Lokale Ressourcen > Tastatur > > Windows-Tastenkombinationen anwenden"?) auf "Never"/"Nie" (oder wars > "nur lokal anwenden"?) einstellen. Dann kann man am lokalen System > neo20.exe am Laufen haben, muss am Remote-Host nichts > umstellen/installieren/starten und hat trotzdem vollen Zugriff auf Neo > inklusiver aller Ebenen. > > LG, > knittl Ah, gut zu wissen, danke. Viele Grüße, Manuel ___ Diskussion mailing list -- diskussion@neo-layout.org To unsubscribe send an email to diskussion-le...@neo-layout.org
[Neo] Re: "Neo20.exe" geht nicht mit "normalen" Browsern in Win7
> On 04.02.20 14:14, Annette Volz wrote: >> Letzte Woche nahm ich zum Testen einen anderen Win7-Rechner, 64Bit in >> Betrieb. > > Dir ist schon klar, daß das grob fahrlässig ist? > > Mit dem eigentlichen Problem kann ich leider nicht wirklich helfen. Die > einzigen Fälle, in denen bei mir AHK streikt („nur“ das Zusatzskript für > den „richtigen“ Treiber) sind Programme, die mit Adminrechten laufen. So > wie regedit halt. Windows 7 sollte man nicht mehr mit Internet betreiben, das stimmt. Was regedit betrifft: das funktioniert doch prima, wenn neo20.exe (NeoVars) mit Adminrechten läuft. In den meisten Virtualisierungslösungen funktioniert es natürlich nicht, es sei denn, man startet es in der VM. In RDP funktioniert es, aber nur, wenn es auf dem zugreifenden Rechner deaktiviert ist. Sonst wertet die jeweils andere Instanz Shift als das Empfangen sehr vieler Zeichen und fragt, ob es sich beenden soll. ___ Diskussion mailing list -- diskussion@neo-layout.org To unsubscribe send an email to diskussion-le...@neo-layout.org
[Neo] Re: QMK Erfahrungen, bzw. Iris 4 Layout
Hi, klar, in Bezug auf QMK weiß ich tatsächlich etwas mehr. Ich hatte schon überlegt, ob ich schreibe, als Du angefragt hast. QMK hat Makros, die den entsprechenden Tasten im jeweiligen Treiber entsprechen. NEO_X ist daher x im Neo Layout, DE_X, in qwertz, und KC_X in qwerty. Letztendlich kann der Controller nur die Tasten senden, die das USB HID Protokoll eben erlaubt. Was das System damit anfängt ist eine ganz andere Frage. Läuft ein Treiber, z.B. qwertz, und man verwendet KC_* Makros, dann modelt der qwertz Treiber des Betriebssystems die Eingabe um. Für Unicode braucht QMK daher Eingabemethoden auf dem System. Dann sendet es je nach eingestellter Eingabemethode einen Starteingabe, z.B. Ctrl+Shift+u und den im Layout eingespeicherten Unicode. Unter Linux empfiehlt QMK ibus. Das funktioniert aber halt erst ab X. Du wirst zumindest noch ein de-latin-1 als Map für die Kernelkonsolen brauchen, insbesondere, wenn Du Festplattenverschlüsselung mit LUKS betreibst. Bessere Alternativen gibt es aktuell nicht. Mein Plan ist bisher, uim zu patchen, damit es Unicodeeingabe direkt unterstützt (aktuell gibt es das nur über die nicht mehr gepflegte m17n-lib) und eine Möglichkeit einzubauen, das Unicode *nicht* anzuzeigen, weil das bei Passworteingaben kontraproduktiv wäre. Dazu müsste ich aber erst mal rudimentär Scheme lernen. uim läuft im Gegensatz zu ibus nicht als Service, sondern ist als Bibliothek konzipiert, die von verschiedenen bridges verwendet werden kann. Dazu zählt u.a. eine ncurses basierte shell, die in Kernelkonsolen läuft, was andere Eingabesysteme (scim, ibus) vermissen lassen. Unter Windows empfehlen sie WinCompose, das portabel läuft und XCompose Dateien einlesen kann und somit gar keine schlechte Alternative zum Treiber in Kombination mit Hardware wäre. Alternativ gibt es die Oktaleingabe übers Keypad, die aber nicht so gut funktionieren soll und ggf. Adminrechte zur Aktivierung über die Registry benötigt. Unter MacOS gibt es laut Doku einfach eine Option, die man anschalten muss. Grundsätzlich kann man zur Laufzeit zwischen den Eingabemethoden wechseln; als ich zuletzt in den QMK Code geschaut habe, habe ich allerdings eine Eingabe vermisst, die Unicodetasten ignoriert. Denn es ist klar, dass man während des Bootens nicht notwendigerweise schon Eingabemethoden zur Verfügung hat, insbesondere im Bios, Pre-Boot-Authentification (Veracrypt) oder auch grub boot-Partitionsentschlüsselung. So, das war’s zu Treiberproblemchen und Unicode. Das Treiberproblem hat man übrigens auch, wenn man eine Neolayout in Android hat und über kdeconnect Tasten an den Rechner sendet. Anysoftkeyboard sendet die umgemappten Tasten an den Rechner und der dortige Neo-Treiber mappt noch mal. Ja, ein Hardwarelayout hätte echt seine Vorzüge. Ein letzter Hinweis: verwendet man so was wie Oneshot Shift, hat das die Möglichkeit mit zwei mal Antippen Shift festzustellen (quasi Hardware Capslock). Verwendet man neo, funktioniert dann aber nicht mehr der Wechsel zu Ebene 3. *Sehr* nervig, wenn man einen Unterstrich tippen will. Viele Grüße, Manuel > Hi, > > mein erster Testlauf damit war mäßig erfolgreich. > Ja, die Tastatur gibt jetzt andere codes zurück, aber die werden vom > Betriebssystem (Arch / Manjaro) noch nicht richtig > interpretiert. > Das System nimmt die codes so auf, als wäre es ein qwerty layout und > verschiebt die tasten dann weiter. Wenn ich im > system auf qwerty stelle, funktioniert es fast wie es soll… wären da nicht > noch solche späßchen mit dem Unicode feature > von QMK. > Ich dachte, dann könnte ich die Umlaute etc. ja direkt als unicode zeichen > raus geben, aber das kommt dann etwa so an: > "00l4" > Also offensichtlich gibt es da noch Dinge, die ich noch nicht so richtig > verstanden habe, wie das gedacht ist bei QMK. > Weiß hier jemand mehr? > > Viele Grüße > Thomas > > > Am Dienstag, den 24.12.2019, 23:45 +0100 schrieb Thomas Kosel: >> Hi, >> >> ich habe vor kurzem ein Iris 4 Keyboard bekommen, und versuche jetzt ein >> Neo2-Layout dafür zu schreiben. >> Hat einer von euch schon etwas in die Richtung unternommen, woran ich mich >> orientieren könnte? >> >> Viele Grüße >> Thomas >> ___ >> Diskussion mailing list -- diskussion@neo-layout.org >> To unsubscribe send an email to diskussion-le...@neo-layout.org > > ___ > Diskussion mailing list -- diskussion@neo-layout.org > To unsubscribe send an email to diskussion-le...@neo-layout.org ___ Diskussion mailing list -- diskussion@neo-layout.org To unsubscribe send an email to diskussion-le...@neo-layout.org
[Neo] Re: Tastatur + Layout gesucht
Es gibt so was in der Art, z.B.: https://github.com/qmk/qmk_firmware/blob/master/layouts/community/ergodox/neo2_on_qwertz_hardware/keymap.c Hier fehlen natürlich Ebene 5/6 und nicht zu vergessen 2, weshalb der € auf Ebene 3 gewandert ist. Finde ich persönlich unschön, aber ich schätze, es würde es erst mal tun. Das coderkun_neo2 Layout war die Basis für mein erstes, rein treiberbasiertes Layout. Ich habe Ebene 4 übernommen. Es scheint auf Layouts von ka’imi zu basieren. Viele Grüße, Manuel > Also bitte noch mal für mich als Anfänger: > > Gibt es für das TEKB, die Ergodox, Redox oder andere eine fertige Firmware > mit der ich ein NEO/Adnw bassiertes Layout flashen kann? > > Gibt es ein modernes rechts lastiges Layout? > > Möchte zumindest zu beginn nicht gleich eine FW modden müßen, flashen ist > natürlich okay. > - > Von: ka’imi > Gesendet: Freitag, 31. Januar 2020 02:14:59 > An: diskussion@neo-layout.org > Betreff: [Neo] Re: Tastatur + Layout gesucht > > Erstes Mal, daß ich mir die Redox angucke, aber … > > On 30.01.20 23:18, Manuel Ullmann wrote: >> Dafür gibt es eine Daumentaste weniger und eine wurde zwischen die >> Daumen und die untere Tastenzeile gelegt. > > Nö. Da ist bei der Ergodox auch eine, aber halt eine Standardtaste und > keine breite. Und in der obersten Reihe fehlt auch eine je Seite :-/ ___ Diskussion mailing list -- diskussion@neo-layout.org To unsubscribe send an email to diskussion-le...@neo-layout.org
[Neo] Re: Tastatur + Layout gesucht
falba.tech liefert Ergodoxen und Redoxen, die man sich vom Holzgehäuse über die Switches etc. selbst zusammenstellen kann. Sie liefern inzwischen auch Cherry Red Silent Schalter. Die Redox hat nicht das Problem der Ergodox, dass die eine Daumentaste nicht erreichbar ist. Dafür gibt es eine Daumentaste weniger und eine wurde zwischen die Daumen und die untere Tastenzeile gelegt. Ähnlich wie bei der Infinity kann jede Hälfte auch unabhängig voneinander arbeiten. Sollte mein QMK Layout, an dem ich seit 2017 bastle, jemals fertig werden, würde ich es vermutlich auch auf die Redox portieren, die ich mir dann noch hole. Ich müsste mich mal wieder zur Code Review aufraffen. Beim Layout wechsle ich vermutlich zum matrixtastaturoptimierten Buteck (zu finden auf www.adnw.de), falls die Firmware fertig wird. Viele Grüße, Manuel > Also die Tastaturban sich sollte fertig zu kaufen sein. Zwecks der Garantie. > Aber da einen Controller tauschen oder Konverter dran basteln sollte > klappen. > > Achja Distro-hopping... wird wohl mal wieder Zeit. :) > - > Von: Thomas Kosel > Gesendet: Donnerstag, 30. Januar 2020 18:44:41 > An: Neo-Layout > Betreff: [Neo] Re: Tastatur + Layout gesucht > > Hallo Paul, > > wenn es überall funktionieren soll, und du keine angst vor code und löten > hast (oder jemanden kennst, der das für dich macht), ist vielleicht auch das > KeebIO board was https://docs.keeb.io/iris-rev3-build-guide/ > Ich bin gerade dabei dafür ein neo-layout zu schreiben, müsste es langsam mal > ausprobieren, was ich bisher so gemacht hab. > > Da man bei den programmierbaren boards das layout der Tastatur beibringen > kann, müsste es unabhängig vom angeschlossenen System funktionieren. > Ich benutze neo2 und bin damit sehr zufrieden, besonders weil da viele Dinge > einfach gut zusammen passen (die dritte ebene ist zum programmieren > bestens ausgelegt). > Es spricht aber natürlich nichts dagegen, auch andere layouts auszuprobieren. > Ist wie distro-hopping, so lange weiter machen, bis dir eins gefällt ;) > > Viele Grüße > Thomas > > Am Donnerstag, den 30.01.2020, 06:45 + schrieb newsgrep .: > > Liebe Gemeinde, > > ich bin auf der Suche nach einem neuen Layout + Tastatur, da schmerzen an > ver. Stellen in den Händen. > Arbeite grade mit QWERTZ. > Trage Handschuhe Größe S oder M. > Nutze im Moment die Thinkpad T400+420 übliche Tastatur mit TrackPoint. > > Welche Tastaturen unterstützen z.B. über FW oder Converter NEO2 bzw. ein > weiter entwickeltes Layout umfangreich in Hardware? > So das ich mich bei RDP und Virtualbox nicht mit Tastaturlayouts / Treibern > rumschlagen muss? > Welche Tastatur ist "ergonomisch" und leise? > > Welches Layout trägt man den in der aktuellen Saison? KOY, CRY, Bone3, ADNW? > Tut mir leid ich habe mir auch mit Mühe leider keine Überblick verschaffen > können. > > Präferenzen: > Die Last sollte ehr auf der Rechten als auf der Linken Hand sein. > Ehr Programmierer als Fremdsprachen / Sonderzeichen Experte. > Schreibe DE/EN und nur selten Matheformeln. > Schonen des Körpers ist wichtiger als schnell tippen. > > Vielen Dank für eure Ideen! > > Grüße > Paul Schink > > ___ > Diskussion mailing list -- > diskussion@neo-layout.org > > To unsubscribe send an email to > diskussion-le...@neo-layout.org > > ___ > Diskussion mailing list -- diskussion@neo-layout.org > To unsubscribe send an email to diskussion-le...@neo-layout.org ___ Diskussion mailing list -- diskussion@neo-layout.org To unsubscribe send an email to diskussion-le...@neo-layout.org
[Neo] Re: bone → neo2-llkh-Treiber (war: Wie Neo sicher installieren (als "Zivilist" (!Coder))
> Auf den Ebenen 3-6 sieht bone genauso aus wie Neo. Meines Wissens sind die Ebenen 5/6 an die Ebene 1 gekoppelt. Beim Learning Mode (qwertz-Basis mit Ebenen 3/4) befindet sich dann ∀ immer noch überm A. Viele Grüße, Manuel ___ Diskussion mailing list -- diskussion@neo-layout.org To unsubscribe send an email to diskussion-le...@neo-layout.org
Re: [Neo] TMK Hardware converter
Am December 21, 2018 11:06:59 PM UTC schrieb "ka’imi" : >On 21.12.18 23:44, Manuel Ullmann wrote: >> Problematisch für Festplattenentschlüsselung, da hier us das >> Standardlayout ist, welchem deutsche Zeichen fehlen. > >Also mein Fedora hat da Neo (Ebene 1–3) :) Ist mir klar. Es geht um die Unterstützung auf fremden Geräten ohne Anpassung. Den Kernelkonsolentreiber gibt es und der funktioniert natürlich auch und wird von mir auf meinen Geräten verwendet. Er wird aber im Gegensatz zum Xkb-Layout nicht standardmäßig mitgeliefert. Ohne Stick und root-Rechten ist man dann auf Fremdrechnern aufgeschmissen, weil loadkeys die benötigt. Der TMK-Converter zielt ja eben darauf ab, ohne Systemrechten eine Art Plug ’n Play Erlebnis zu haben, wobei man dort zugegebenermaßen selten auf Kernel-Konsolen agiert. Die UEFI/Bios und Bootloader Ebenen werden von den Treibern nun mal nicht abgedeckt (und können es partiell auch nicht; mit core-/libreboot theoretisch vielleicht). Grub hab ich nie im Neo-Layout zum Laufen gebracht. xkbcomp wird nicht mehr entwickelt und der resultierenden keymap fehlen die Pfeiltasten und Enter.
Re: [Neo] TMK Hardware converter
Hallo, ich hatte mal begonnen, die Neo-Spezifikation vollständig in der TMK basierten qmk_firmware für meine Ergodox zu implementieren, habe es aber mittlerweile fast ein Jahr nicht mehr angerührt. Ich hatte keine Lust die Speicherverwaltung zu implementieren und es könnte sein, dass es bei der Nutzung der globalen Variablen zu race conditions kommt, je nach dem, ob die Firmware Parallelität zulässt. Vielleicht komme ich die Tage mal dazu, es in Richtung flashbar zu bewegen. Unicode ist nicht ganz trivial und vor allem nicht standardmäßig aktiviert. Insofern macht es dafür keinen Unterschied, ob ich den Treiber starte oder den Converter zwischenschalte, weil es schlicht kein Plug ’n Play ist. Siehe auch: https://docs.qmk.fm/#/feature_unicode Windows hat die Oktaleingabe übers Keypad, die man im Controller simulieren kann, für die aber ein Registry Eintrag gesetzt werden muss. Die soll aber laut qmk docs nicht so gut funktionieren. Alternativ gäbe es WinCompose, das Unicode und XCompose Dateien versteht. Die Veracrypt Entschlüsselung ist außen vor. Die qmk Eingabe ist unter Linux auf ibus ausgelegt, das aber erst in X verfügbar ist. grub ist vollständig außen vor. Kernel Konsolen bekommt man nur über uim zum Laufen und dort auch nur in einer eigenen shell. Problematisch für Festplattenentschlüsselung, da hier us das Standardlayout ist, welchem deutsche Zeichen fehlen. Außerdem ist die Unicodeeingabe in uim kein Kernfeature und wird nur über die nicht mehr entwickelte m17n-lib bereitgestellt. In MacOS kann man es wiederum einfach aktivieren. Viele Grüße, Manuel > Hallo neo-Werkler, > > ich habe mir mal den TMK USB-USB > aus Japan schicken lassen > und näher angeschaut. > Das ging recht flott (2-3 Wochen). > > Im Prinzip ist darauf ein ATMEGA32U4, > der hat intern eine integrierte USB Schnittstelle, > der die Daten von einer Tastatur empfängt. > Außerdem kontrolliert der ATMEGA32U4 > über SPI einen MAX3421E, > der dann als USB Host funktioniert, > vom PC als Tastatur erkannt wird > und die Tastendrücke an den PC weiterleitet. > > Mit dem TMK oder einem geforktem TMK-neo > Atmel Code sollte man alle Tasten, > die mit einer herkömmlichen Tastatur > erzeugbar sind, umleiten können. > Das wäre schon mal eine großer Gewinn. > > Wie es mit "nicht-keyboard" Zeichen, > z.B. griechische aussieht, > weiß ich nicht. Hat da jemand eine Idee, > wie man das benutzerfreundlich > implementieren könnte (Xorg / Windows)? > Vielleicht über eine Unicode Routine? > https://en.wikipedia.org/wiki/Unicode_input > > Ich werde mal über die Feiertage > schauen, wie weit ich mit > der nativen TMK Umgebung komme, > > lg Florian > > >> Date: Mon, 19 Nov 2018 22:58:38 +0100 >> From: Manuel >> To: Neo-Layout >> Subject: [Neo] TMK Hardware converter >> Message-ID: <7d490965-9a67-a8bd-64bd-effe19fa7...@gmx.de> >> Content-Type: text/plain; charset="utf-8" >> >> Hallo Neouser, >> >> ich würde gerne einen Hardwarelayoutswitcher realisieren. Wurde schonmal >> TMK (USB to USB converter, https://geekhack.org/index.php?topic=69169.0) >> zusammen mit dem NeoLayout probiert? Weiß da jemand was? >> >> Es gibt dort einen Keymap Editor Editor >> (https://geekhack.org/index.php?topic=72052.0), bei dem mir das >> Realisieren von den ersten 4 Ebenen recht leicht zu sein scheint ? die >> ersten 4 kommen ja sogar ohne Metatastenkombinationen aus. Bis dahin ist >> Neo noch ganz normal, was die /alternativen Layouts/ angeht:-D >> >> Viele Grüße, >> Manuel >> > > >> >> Message: 2 >> Date: Tue, 20 Nov 2018 01:20:44 +0100 >> From: Thilo Fischer >> To: diskussion@neo-layout.org >> Subject: Re: [Neo] TMK Hardware converter >> Message-ID: <1542673244.3614.1.ca...@gmx.de> >> Content-Type: text/plain; charset="UTF-8" >> >> Hallo, >> >> ich plane, so etwas ähnliches zu basteln als Open-Source-Projekt auf >> Basis eines Raspberry Pi und eines Arduino. Bin damit schon angefangen, >> aber leider ist in den letzten Monaten keine Zeit da gewesen, weiter an >> dem Projekt zu arbeiten. Hoffe aber, in den kommenden Wochen rund um >> den Jahreswechsel mal wieder etwas Zeit dafür zu finden. Wenn ich was >> Brauchbares hinbekomme, werd ich das dann natürlich auch über diese >> Liste mit Euch teilen. >> >> Zur gelegentlich auf dieser Mailing-Liste diskutierten Frage, ob man >> Neo2 in Hardware abbilden kann: Man kann. Ich bin seit langem >> (inzwischen "seit Jahren") sehr zufrieden mit meiner "Simulation" des >> Neo2-Layouts in Hardware (auf einer selbstgebauten Neo2-optimierten >> ergonomischen Tastatur https://youtu.be/_H30DtSoXkY). Ebene 1-4 kann >> man recht gut auf einem Computer mit QWERTZ-Layouts simulieren; mit der >> Einschränkung, dass man auf Ebene 3 und 4 auf die Ziffernreihe und auf >> die ? auf Ebene 3 X (bzw. Q) verzichtet. >> >> @Manuel: Was meinst Du, wenn Du davon sprichst, einen >> Hardwarelayoutswitcher zu "realisieren"? Eine TMK-Konfiguration >> erstellen oder ggf. auch etwas TMK-ähnliches selber zu entwickeln, >> falls es mit TMK nicht klappen sollte?
Re: [Neo] neo auf programmierbarer tastatur etablieren
Hallo, ist halt die Frage inwieweit so ein Konfigurator limitiert. Ist die Tastatur frei programmierbar und Open Hardware? Ich fand die Idee auch interessant und habe mal versucht, sie für die Ergodox zu implementieren. Das hat so ca. 4 Monate gedauert bis ich an die Speichergrenze gestoßen bin. Ich habe früh daran gedacht mit cpp-Bedingungen die meisten Features abschaltbar zu machen und alle erstellten Varianten kompilieren momentan (soweit ich mich erinnere). Tatsächlich war es am schwersten, mein Ebenenwechselsystem für Neo zu implementieren. Da ich Ebenenwechsel zumindest partiell (ab L5/Keypad) Oneshot-fähig haben wollte, durfte ich im Grunde alle qmk-Funktionen für Ebenenwechsel reimplementieren und ändere in meinen Ebenenlogikhilfsfunktionen die Funktionspointer, falls die Tastatur den Neo-Treiber erwartet. Unicode unterstützt qmk grundsätzlich, die Alt Variante unter Windows soll aber schlecht funktionieren. Ich setze daher WinCompose voraus, von dem es eine portable Fassung gibt, Mac soll auch gehen; testen kann ich es nicht; Linux ist schwierig. Die Methode hängt nicht vom wm ab, sondern davon was davon gestartet wird. Da gibt es ibus, scim und uim. Uim ist trotz seiner spärlichen Docs der einzige der auf Kernel-Konsolen funktioniert und dort brauche ich ihn für die Festplattenentschlüsselung, wenn ich von der Us-Bioskeymap nicht umschalten will. Dafür müsste man ihn aber umschreiben, weil er sonst den Codepoint der eingegebenen Unicode-Zeichen anzeigt (und Scheme müsste ich erst lernen). Unicode-Eingabe funktioniert in uim außerdem nur über ein Modul der ungewarteten m17n-lib. Schöner wäre also eine native Implementierung. Zu guter Letzt war das Eintragen der 240+ Unicodepoints von Neo in Headerdateien ziemlich nervig und letztendlich automatisierbar. Aus Platz- und Arbeitsersparnisgründen wollte ich also mittels yacc einen Compiler generieren, der XKB Symboldateien ausliest und sie mittels keysymdef.h auf Unicodepoints ummappt. Dann könnte man diese mit entsprechender semantischer Ausgabe in mappende C-Arrays umwandeln und letztendlich das ganze so erweitern, dass man eine Treiberkeymap als Basis und eine als Ziel angibt, und die Ebenen automatisch generiert, wobei alle auf der Basis nichtexistenten Zeichen durch Unicodeeingabetasten ersetzt werden. Die XKB-Dokumentation ist aber quasi nicht vorhanden und ohne Grammatik hatte ich keinen Bock mehr, daran weiterzuarbeiten. Könnte den Code in seiner unfertigen und ungetesteten Fassung vielleicht mal auf Github laden. Viele Grüße, Manuel --
Re: [Neo] neo auf programmierbarer tastatur etablieren
Hallo, ist halt die Frage inwieweit so ein Konfigurator limitiert. Ist die Tastatur frei programmierbar oder Open Hardware? Ich fand die Idee auch interessant und habe mal versucht, sie für die Ergodox zu implementieren. Das hat so ca. 4 Monate gedauert bis ich an die Speichergrenze gestoßen bin. Ich habe früh daran gedacht mit cpp-Bedingungen die meisten Features abschaltbar zu machen und alle erstellten Varianten kompilieren momentan (soweit ich mich erinnere). Tatsächlich war es am schwersten, mein Ebenenwechselsystem für Neo zu implementieren. Da ich Ebenenwechsel zumindest partiell (ab L5/Keypad) Oneshot-fähig haben wollte, durfte ich im Grunde alle qmk-Funktionen für Ebenenwechsel reimplementieren und ändere in meinen Ebenenlogikhilfsfunktionen die Funktionspointer, falls die Tastatur den Neo-Treiber erwartet. Unicode unterstützt qmk grundsätzlich, die Alt Variante unter Windows soll aber schlecht funktionieren. Ich setze daher WinCompose voraus, von dem es eine portable Fassung gibt, Mac soll auch gehen; testen kann ich es nicht; Linux ist schwierig. Die Methode hängt nicht vom wm ab, sondern davon was davon gestartet wird. Da gibt es ibus, scim und uim. Uim ist trotz seiner spärlichen Docs der einzige der auf Kernel-Konsolen funktioniert und dort brauche ich ihn für die Festplattenentschlüsselung, wenn ich von der Us-Bioskeymap nicht umschalten will. Dafür müsste man ihn aber umschreiben, weil er sonst den Codepoint der eingegebenen Unicode-Zeichen anzeigt (und Scheme müsste ich erst lernen). Unicode-Eingabe funktioniert in uim außerdem nur über ein Modul der ungewarteten m17n-lib. Schöner wäre also eine native Implementierung. Zu guter Letzt war das Eintragen der 240+ Unicodepoints von Neo in Headerdateien ziemlich nervig und ist eigentlich automatisierbar. Aus Platz- und Arbeitsersparnisgründen wollte ich also mittels yacc einen Compiler generieren, der XKB Symboldateien ausliest und sie mittels keysymdef.h auf Unicodepoints ummappt. Dann könnte man diese mit entsprechender semantischer Ausgabe in mappende C-Arrays umwandeln und letztendlich das ganze so erweitern, dass man eine Treiberkeymap als Basis und eine als Ziel angibt, und die Ebenen automatisch generiert, wobei alle auf der Basis nichtexistenten Zeichen durch Unicodeeingabetasten ersetzt werden. Die XKB-Dokumentation ist aber quasi nicht vorhanden und ohne Grammatik hatte ich keinen Bock mehr, daran weiterzuarbeiten. Könnte den Code in seiner unfertigen und ungetesteten Fassung vielleicht mal auf Github laden, falls der Rebase halbwegs durchläuft. Viele Grüße, Manuel
Re: [Neo] [ticket] #497: Kann in keine Ebene wechseln
> Entsprechend habe ich nun auch schon einiges geübt, doch als der
> Tipptrainer dann bei der Lektion war, bei der man Shift+[Zahl] hätte
> tippen müssen, ging alles schief.
Das ist ein Feature. Man verwendet Caps Lock üblicherweise bei der
Eingabe von Enum Konstanten oder C Preprocessor Macros/Konstanten. Wie
soll man bitte sonst NEO2_LAYER6 eingeben? Warum sollte man Unmengen
von °§ℓ»«$€„“”—`'^ eingeben wollen? Typischerweise will man genau eines
dieser Zeichen auf einmal eingeben.
Es wird dir in Zukunft das Leben mit Open Source Projekten sehr viel
einfacher machen, wenn Du solche Fehlerberichte nicht mit Priorität
„hoch“ versiehst. Ich kann im Ebenenfeststellen einen legitimen
Änderungsvorschlag erkennen, aber da Neo2 final ist, werden
Verbesserungsvorschläge abgewiesen. Wenn Du das nicht willst, überzeuge
genug Leute auf der Mailingliste, Neo3 zu entwickeln. Bedenke, dass Neo
auf Windows, MacOS, Linux, Solaris, Android und teilweise BSD, C64 und
grub2 portiert sind, was eine Menge Portierungsarbeit ist.
Falls Du mit XKB nur für ein Zeichen auf Ebene 2,3 und 4 wechseln willst
UND Ebene 5 und 6 nicht brauchst, kannst Du in den Dateien in
/usr/share/xkb/symbols/{shift,level3,level5} die Modifiersymbole Shift_L
und Shift_R jeweils durch ISO_Level2_Latch, ISO_Level3_Shift durch
ISO_Level3_Latch und ISO_Level5_Shift durch ISO_Level5_Latch ersetzen.
Das dauerhafte Wechseln in Ebene 2 und 4 dürfte danach nicht mehr
funktionieren und ich habe das nicht getestet. Ein Backup ist also ein
Muss.
Falls Du vielleicht doch noch mit dem finalen Treiber warm werden
willst, hilfst es dir eventuell, alle Ebenenübergänge zu kennen. Neben
Ebene 2 ist auch Ebene 4 auf dieselbe Weise zu festzustellen (entspricht
intern Num Lock). Sie kann auch mit einem Tab von Ebene 5 festgestellt
werden. Von Ebene 4 kommt man mit Mod3 auf Ebene 6. Mit dem
Feststellen, kann man also Mod4 einsparen. Für Ebene 5 gibt es leider
nichts vergleichbares.
Abschließend sei festgehalten, dass Du mit einer nicht ganz billigen
Ergodox das von dir beschriebenen Ebenenfeststellen hardwareseitig
umsetzen kannst. Die keymaps, die ich gesehen habe, verwenden allerdings
meistens nur eine Hardware-Ebene 4, was das lästige Ebene4 Pfeiltasten
Problem in xterm und urxt umgeht. Allein das Wechseln zu Oneshot_Shift
bringt 50 Anschläge mehr pro Sekunde. Im Gegensatz zu XKB kann
qmk_firmware allerdings zwischen einem kurzen und langen Tastendruck
unterscheiden, weswegen hier (fast) keine Konflikte mit dem Neo-Treiber
entstehen. Ebene 3 ist vom hardwareseitigen OSM Lock nicht erreichbar.
XKB dagegen entscheidet nur zwischen Tastendruck und Tastenlösen,
weswegen zumindest mir bisher keine Möglichkeit eingefallen ist, Neo in
seiner jetzigen Form zu unterstützen. Für Doppel und Dreifachbelegungen
braucht man eben einen programmierbaren Tastaturcontroller.
Komme nicht auf die Idee, dass Du mit der Ergodox das Neo Layout
treiberunabhängig verwenden kannst. Es ist zwar möglich, aber nicht ganz
trivial zu implementieren und wird auch in der Endfassung eine
Eingabemethode zur Hex Unicode Eingabe für alle Zeichen, die nicht vom
Treiber unterstützt werden, benötigen.
https://wiki.neo-layout.org/wiki/Xorg
https://wiki.neo-layout.org/wiki/Ergodox
Grüße,
Manuel
PS: An jemanden auf der Liste, der das Spamschutzsystem von Trac
versteht: Erwartet das Captcha arabische Zahlen oder die Textform?
Ich bin mir nämlich ziemlich sicher, dass Zwei mal Fünf mal Fünf gleich
50 ist.
Re: [Neo] Nio auf Windows 10
> Benutzt das hier überhaupt wer (freiwillig)? Wie sind die Erfahrungen? > Geht alles? Kann ich weiterhin nativ installieren + AHK? Muss ich rein > AHK benutzen (suboptimal zum Spielen)? Gibt es gerade richtig dick Probleme? Ich hab es bis vor kurzem in einer VM mit IGD passthrough (vfio) verwendet¹. Das erzwungene 1703 Creator’s Update hat die native Neo Installation etwas erschwert, aber es gibt einen Workaround, siehe [2]. Das Update hat immerhin auch ein paar Optionen für Updates eingeführt. Man kann sie jetzt einen Monat herauszögern. Idealerweise verzögert man also zur Monatsmitte, sodass Kleinweich die neuen Fehler wieder flicken konnte. Man konnte auch vorher große Build Updates (wie 1703) um ein paar Monate herauszögern. Ansonsten darf man nach jedem großen Update die Datenschutzeinstellungen wieder abgrasen. Es gibt dafür aber auch Helferlein ala 10AntiSpy. Ich bin im Grunde nur wegen Ausschließen von Fehlerquellen zurück auf W8.1. Hatte einen Ressourcenkonflikt zwischen der emulierten Soundkarte und der durchgereichten Intel Grafik. Bin zur emulierten USB Soundkarte gewechselt und jetzt geht alles. Der Intelsoundtreiber funktioniert mit qemu in Windowsgästen äußerst schlecht. 1: Bin jetzt bei W8.1. Ist auch scheiße, aber wenigstens funktioniert Neo noch nativ per UI Einstellung. [2]: https://wiki.neo-layout.org/ticket/490#comment:2
Re: [Neo] [ticket] #490: [Windows 10] Neo2 funktioniert nicht
Ja, man kann Neo nicht mehr über das GUI aktivieren, obwohl es installiert ist. Zum Glück sind Windowsnutzer ja das Frickeln an der unübersichtlichen Registry gewohnt. Man setzt den Wert HKEY_CURRENT_USER\Keyboard Layout\Preload\1 von wahrscheinlich 0407 (qwertz) auf b407 (neo) und schwupps ist es wieder für den aktuellen Nutzer Standard¹. Will man es für alle Nutzer festlegen, verwendet man wohl HKEY_USERS\.DEFAULT\Keyboard Layout\Preload (letzteres habe ich nicht getestet). Siehe auch [2]. Zur möglichen Ursache: Es ist etwas auffällig, dass bei der Layoutauswahl kein Land angegeben wird (DEU, aber kein DE). Wahrscheinlich hat sich das entsprechende Format in der Registry geändert und seit dem Creators Update werden solche Layouts nicht mehr anständig behandelt. Evtl. stört es sich auch an der fehlenden Vorschau (nur vollständige Layoutdefinitionen sind gute). 1: Bis zum nächsten Update. 2: http://windowsitpro.com/systems-management/how-do-i-configure-default-keyboard-layout-during-login
Re: [Neo] Truly Ergonomic Ebene 3 in UEFI/Grub?
> eventuell ist eine Ergodox für deine Ansprüche besser geeignet. Dort > hast du die Firmware komplett in der Hand und es gibt einige > (mindenstens 2), die dafür schon eine "Hardware-Neo2"-Firmware > geschrieben haben (Ebenen 1 bis 4). Hallo Tom, hätte ich mal besser vorher ins Archiv geschaut. ;) Bin inzwischen auch darauf gekommen, dass die Ergodox Firmware meine Anforderungen erfüllt und werde bei nächster Gelegenheit eine bestellen. Danke für den Hinweis. Beste Grüße, Manuel
[Neo] Truly Ergonomic Ebene 3 in UEFI/Grub?
Hallo, ich überlege zur Zeit, mir eine Truly Ergonomic [1,2] anzuschaffen. Hauptgrund dafür ist nach der Ergonomie aber eigentlich die Passworteingabe zur Bootzeit fürs UEFI Bootpasswort und Grub Bootpartitionsentschlüsselung. Meine Frage wäre daher, ob es theoretisch möglich ist, die Firmware so zu konfigurieren, dass die ersten drei Ebenen zur Bootzeit funktionieren bzw. ob sich das anschließend mit dem Neo-Treiber beißen würde, was auf Dauer dann doch etwas nervig wäre, selbst wenn man per Hardware-Switch auf ein treiberkompatibles Layout wechseln könnte. Ich habe den Support von Truly mal kontaktiert und gefragt, ob sie die Firmware zur Unterstützung von 6 Ebenen erweitern würden, die insbesondere auch durch mehrere Modifier umgeschaltet werden können, aber bislang wenig überraschend keine Antwort erhalten. Wäre die Unterstützung vorhanden, müsste man natürlich immer noch das Scancode–Keycode Mapping in einem separaten Treiber abändern, weil die Scancodes für Pre-Boot Unterstützung anders sein müssten, wozu hier wahrscheinlich niemand Lust hat. Oder doch? Beste Grüße, Manuel PS: Die Grub-Unterstützung habe ich nie zum Laufen bekommen, weil sie mit dem usb_keyboard Modul nicht funktioniert. Würde sie gehen, bräuchte ich eh noch einen modifizierten grub-core für die Entschlüsselung. Mit dvorak wurde so was schon mal erfolgreich gemacht. [3] [1]: https://www.trulyergonomic.com/ [2]: https://wiki.neo-layout.org/wiki/Hardwareentwicklung/Truly [3]: https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Manual_configuration_of_core_image_for_early_boot
