Tuxbox-Forum

Wie im vorigen Posting geschrieben, hab ich einen kleinen daemon geschrieben, der unter anderem das macht, was Barf mit seinem
"Keyboard-as-bulky-remote" Patch für Neutrion macht.

Der Unterschied: Der Patch macht die Umsetzung von Tastendrücken auf der Tastatur nur für Neutrino, die Plugins sowie Enigma werden nicht unterstützt.

Der daemon "hört" laufend mit und generiert bei einem Tastendruck auf der Tastatur das oder die entsprechenden Codes der Fernbedienung, alle anderen Processe, ob Enigma, Neutrino oder Plugins empfangen jetzt (auch) diese Codes. Es können Tastaturfolgen zugewiesen werden.

Der Nachteil daran: Jedes Programm das die Tastatur selbst auswertet bekommt trotzdem auch die umgewandelten Codes. Um dies zu verhindern muss man die Datei /tmp/keyboard.lck erzeugen, solange diese existiert ist der daemon "stillgelegt". Alternativ kann man dem daemon auch ein Signal schicken.


Die Frage ist jetzt, was ihr von dieser Lösung (bzgl. Tastatur als Fernbedienungsersatz) haltet?
d.h. soll oder kann das ins CVS?

ps:
Das config-file für die Umwandlung sieht z.B. so aus

Also ich finde diese Lösung sehr gut.

Ich denke das man die Plugins dann entsprechend anpassen kann.

Also ab damit ins CVS und lass uns die Funktionen am besten gleich
in Wiki sauber dokumentieren.


Gruß
____Paule

PS: Wie sieht es mit der "Mouse" aus??

Wie willst den die Mouse haben?

Prinzipiell ist die Maus kein Problem, d.h. bis auf das, das die "Tastendrücke" sehr schnell hintereinander kommen, da muss ich halt ein bischen was reduzieren. Die Zuordnung einfach auf die Cursor-Tasten?

Also ich würde sagen (auf/ab/links/rechts). Wir sollten es hinbekommen,
dass man mittels Mouse und Buttons Neutrino und die Scripts bedienen
kann.
Bedeutet der Button uter der Mouse ruft das menü auf (Dbox-Taste).


Gruß
____Paule

PS: Wenn ich was in Wiki dokumentieren soll schick mir ne PN.

@PauleFoul

Version 0.5 mit Maus-Unterstützung steht bereit.

Ich hab den Wert für einen Tastendruck mal auf 80 gesetzt.

Zur Erklärung: Die "Maus" liefert relative Werte in schneller Abfolge. Diese Werte addiere ich. Sobald ich einen gewissen Grenzwert erreiche erzeuge ich einen Tastendruck. Bei mir hat der Wert 80 ansprechende Ergebnisse geliefert. Eventuell sollte ich diesen Wert aber auch in die Config geben.

Ich glaub fürs Wiki ist es noch zu früh, aber wenns im CVS ist wäre ich dir sehr dankbar wenn du das schreibst.

Hallo,

kann mir mal jemand erklären, was ich ins Neutrino/[EDIT]illegales Schwarzglotz[/EDIT] Image hinzufügen muss, um die Unterstützung zu bekommen?

Danke

giovanne

http://www.jackthegrabber.de/viewtopic. ... 16&start=0

Greetz von DrStoned

robspr1s kb2rcd ist ohne Zweifel ein intressantes Approach. Es holt sich events, wandeln sie um (nicht notwendigerweise 1-1, sondern evtl 1-0 (z.B. "Script"), oder 1-n (makros)) und schaufelt sie in das Device zurück. Vorteil ist die Modularität, Funktionalität mit "alles" inklusive Plugins und Enigma, sowie die Nachinstallierbarkeit, sogar in cramfs/squashfs-Images. Nachteil ist dass es arbeitet auf Event-ebene, und deswegen muss alles wie Timing, up/down-Events etc nochmals gelöst werden. Als ich das Ding probierte, wollte es erstmals überhaupt nicht funktionieren, nur bei sehr lange Tastendrucke. Ich habe herausgefunden, dass meine Anfangsverzögerung (200ms) dafür gesenkt werden muss.

Ich habe anstatt mein Hack zu rcinput verbessert. Wird jetzt von einem Konfigurationsfile gesteuert. Ich habe hier versucht mit robspr1s Konfigurationsfile kompatibel zu sein. Der Patch arbeitet mit übersetzung von Keys,(nicht Events) deswegen keine 1->n (makros) möglich. Insbesonders kann anstatt Keys auch Neutrinomessages erzeugt werden, opional mit data. So kann mann direkt Plugins ausführen. Siehe beigefügte Konfigurationsfile. Die Konfigurationsfile soll übrigens /var/tuxbox/conf/rc.conf heissen (um die Kompatibilität im Grenzen zu halten ) Debug im Konfigurationsfile ein/ausschaltbar, neu einlesen des Konfigurationsfiel auf Knofpdruck (RELOAD_CONF). "Skriptfunktion" wie kb2rcd. (@robsp1: sollte wir es nicht "Command" anstatt "Script" nennen?) Keine PAUSE etc weil es hier kein nicht Sinn hätte. Alle Zeilen ohne = wird als Kommentar verworfen, sonst # als Kommentarzeichen.

Die vorliegende Patch soll als experimentell betrachtet werden. Ins besonderes kann mann mit den neutrinomessages das system crashen, oder Speicherlecks auslösen.

"Mouseunterstützung" ist z.Z. nicht drin, wäre evtl. möglich.

Leider ist z.Z CVS down so dass ich keine diffs herstellen kann. Deswegen hier rcinput.cpp und rcinput.h in extenso. Hier ein Konfigurationsfile. Mehr als test- und Demofile gedacht als "produktiv".

Der Patch von rcinput hat natürlich Vorteile, wie das direkte Ausführen von bestimmten Aktionen (z.B. wenn du SHUTDOWN sagst, dann ist das SHUTDOWN, auch wenn du in einem Menü bist).

Ein Nachtteil (derzeit ?) ist, das nur die Tasten direkt umgesetzt werden können, also kein Shift-F1 oder Alt-F4. Damit hast du aber deutlich weniger Tasten welchen du Funktionen zuweisen kannst. Ausserdem nimmst du "mir" damit auch die Möglichkeit der Shift- und Alt- Funktionalität (wenn du F2 verwendest belegst du auch "mein" Shift-F2 und Alt-F2). Ein Belegen der Buchstaben-Tasten ist IMHO ja nicht sinnvoll, da das Eingaben von Texten auch in Neutrino noch möglich sein soll

Ich sehe in der "Mischung" beider Methoden eine sinnvolle Lösung, denn für Plugins welche die Tastatur nicht unterstützen bringt das Patchen von rcinput.cpp nichts, ich sehe auch in der Handhabung bzw. Auswertung der Events (damit meine ich eben die Shift- und Alt- Funktionalität) Vorteile (aber das lässt sich auch in rcinput einbauen), die Möglichkeiten die direkt in Neutrino gegeben sind natürlich auch nicht zu verachten.


PS:
Das Ausführen von Plugins ist auch bei kb2rcd möglich mit z.B: wobei der Name Command wirklich sinnvoller ist. Ich werde das ändern (zwar weiterhin auch SCRIPT akzeptieren aber COMMAND schreiben).
Weiterhin kannst du in der aktuellen Version eine Funktion von einer "Mindest-Tastendruckdauer" abhängig machen, d.h. T2_KEY_F5=SCRIPT02 führt das script erst aus, wenn die Taste F5 mindestens 2 Sekunden durchgehend gedrückt worden ist.

Warum eigentlich immer mein Keycode und dein Keycode?
Irgendwie alles verwirrend

Warum wird da eigentlich nicht ein ganz normaler Tastaturtreiber ins Image gepackt und Neutrino empfängt den Tastencode ganz normal vom Betriebssystem? So wie das im normalen Linux/Windows Rechner auch funktioniert. (Die FB generiert ja auch nur Tastendrücke.)
Dann könnte z.B. der kb2rc Daemon sich an erster Stelle setzen gegebenenfalls Tastendrücke anfangen und durch andere ersetzen (Wenn das unter Linux geht. K.a. obs da sowas wie Tastatur hooks gibt.).

Im Moment scheinen alle Programme ja die Tastatur/FB direkt abzufragen. Wenn ich dann in der Konsole bin und "Curser hoch" drücke schaltet Neutrino im Hintergrund auch um. Und wenn es so ist das ein F2 im Patch das ALT+F2 im Daemon verhindert... Das sind doch eigentlich komplett andere Tastendrücke.

Irgendwie scheint es da also keinen Systemweiten Tastaturpuffer zu geben sondern ein großes Durcheinander.

Verstehe ich da irgendwas falsch oder ist da wirklich irgendwas Merkwürdig und es hat bloß keiner Lust daran was zu tun?

cu
usul

@usul1

Bei Windows werden Tastendrücke als Window-Messages (WM_KEYDOWN, WM_CHAR, WM_KEYUP) an das aktive Window geschickt. Wir haben bei der dBox keine Windows, und schon gar keine Window-Messages

Es geht auch nicht darum das hier der "Tastaturtreiber" direkt abgefragt wird (was auch nicht so ist), sondern hauptsächlich darum, das auf der Fernbedienung Tasten sind die auf der dBox Tastatur nicht sind und umgekehrt. Wenn du jetzt auf der Fernbedienung auf "ROT" drückst, dann wird der entsprechende Code erzeugt. Wenn Neutrino "das aktive Fenster " ist, dann wertet Neutrino diesen Code aus, wenn Neutrino die Kontrolle an ein Plugin abgegeben hat, dann wertet das Plugin diesen Code aus. Ein Sonderfall ist hier sicher die Art wie die Console integriert wurde, da werten dann die Console und Neutrino zugleich die Tasten aus.

Zurück zum Problem Tastatur - Fernbedienung: Man könnte jetzt auf Treiberebene die 10 Funktionstasten, eventuell auch mit ihren zweit und dritt-Funktionen, auf Fernbedienungscodes legen, d.h. F1 ergibt z.B. immer ROT, das einzige Plugin das damit Probleme hätte wäre VNC, da damit die Funktionstasten nicht mehr für den VNC Client funktionieren würden. Gelöst ist damit noch nicht das Problem, das wenn ich bei einer Texteingabe auf zweimal auf "2" drücke ich mit der Tastatur "22" haben möchte und mit der Fernbedienung "B". Dazu muss ich jedem Programm sagen wie er den "2"er jetzt auswerten soll.

Ein weiterer Vorteil der Tastatur ist natürlich, das durch die grosse Anzahl der Tasten wir auch eigene Funktionen definieren könnte, z.B. F10 öffnet den Teletext. Der Befehl "Teletext öffnen" ist jetzt aber kein Tastaturcode, ein Plugin könnte damit auch nichts anfangen, um das mit MS_Windows zu erreichen brauchst du auch ein eigenes Programm bzw. einen eigenen Treiber.

Und nochmals zum empfangen der "normalen" Tastendrücke: Vergleich einmal was bei einem Windows-Programm passieren kann wenn du auch SPACE drückst: Es kann ein Leerzeichen eingefügt werden oder es wird eine Taste gedrückt oder eine Checkbox selektiert oder wieder deselektiert ... Die Auswertung wie das SPACE zu interpretieren ist liegt immer bei den einzelnen Programmen, und genau das machen die Programmteile, seien es jetzt Enigma, Neutrino oder Plugins auch. Das, wenn ich auf "1" drücke meist eine 1 geschrieben wird, oder der Kanal 1 gewählt wird oder wie in Tuxmail auf das Konto 1 gewechselt wird ist also immer Sache der Programme selbst.


Wenn ich jetzt etwas falsches gesagt habe, korrigiert mich bitte.

Klar

Aber bei Windows braucht ein Programm ja auch kein "Fernster" um die Messages zu Empfangen. Es muß ja nur einmal nach dem Start bei Windows seine Prozeur anmelden die die Messages empfängt und abarbeitet.

Wie gesagt habe ich von Linux herzlich wenig ahnung. aber ich vermute jetzt einfach mal das es dort ähnliche Systeme gibt. Weil wie sollte es sonst anderst gehen.



Kommt das auf der Box nicht alles über die selbe Schnittstelle rein? Soll heißen: Die Tasten der FB (z.B. "Rot") sind ja auch nur Sondertasten der Tastatur.

Beim PC hat man ja auch Tastaturen mit haufenweise Multimediatasten.
Wenn ich jezt auch meiner PC Tastatur die Sondertaste "Lauter" drücke wird ein ganz normaler Tastendruck (aus dem Reserved) Bereich erzeugt und von Windows per Message an die Programme geschickt.
Der "Treiber" des Tastaturherstellers (wo man den Sondertasten Funktionen zuweist) fängt aber alle Tasten per hook ab um z.B. im Fall des Tastencodes für die "Lauter" Taste die Lautstärke des Mixers zu erhöhen und den Tastencode aus dem Buffer zu nehmen.
Startet man das Programm nicht geht dieser Tastendrück auch den ganz normalen Weg aller anderen Tastendrücke un jedes andere Programm könnte ihn auswerten wie jeden anderen Tastendruck.

AFAIK Funktioniert das ja unter Linux auch. Denn auch dort kann man die Sondertasten (z.B. die Standby Taste) nutzen.

Würde dein Daemon auf diese Weise arbeiten (wie die Sondertastenzuweisprogramme der Tastaturhersteller) gäbe ja div. Probleme nicht.



Ich vermute weil Neutrino garnicht weiß das die Console offen ist (wird ja vom System bereitgestellt) und so das Abfragen der Tastatur nicht unterbindet.

Das meinte ich mit Merkwürdig (irgendwie läuft die Sache bei Tuxbox anderst als normal).

Wenn ich unter meinem Linux am PC auf einer Console ein Programm offen habe und eine zweite öffne dann gehen alle Tastendrücke automatisch an das Programm in der zweiten Console ohne das das Programm in der ersten extra irgendwas abfragen (oh eine zweite Console aktiv. Da darf ich die Tastendrücke nicht annehmen) müsste.



Oder Neutrino Reagiert für die einzelnen Funktion auf meheren Tastendrücken. So das man einstellen kann das beim Tastencode "Rot" und beim Tastendruck "F1" die Funktion Rot ausgeführt wird.



Leider erzeugen die Ziffern der FB und der Tastatur wohl den selben Code. Da kann man dann wohl leider nichts tun.
IMHO das beste wäre man könnte bein Neutrino den SMS Eingabe Modus abschalten (oder umschalten. Z.b. "Gelb" wechselt zwischen normaler und SMS Eingabe).



Jup so sehe ich deinen Daemon eigentlich. Quasi als das Programm was unter Windows den Tastaturen beiliegt und dafür sorgt das beim druck auf die "E-Mail" Taste das E-Mail Programm startet. Nur das man bei der D-Box Tastur keine "E-Mail" Taste hat sondern statdessen "ALT+F1" verwendet wird.
Und sowas hatte bissher wirklich gefehlt.

Das wofür due das Programm eigentlich geschrieben hast (F1 = schick "Rot" an Neutrino) sollte lieber Neutrino selber übernehmen indem es "F1" als alternative zu "Rot" akzeptiert. Aber IIRC hattest du das ja auch schon mal so gesagt.



Natürlich. Wobei das ja einwenig komplexer ist.
Wenn ich die Leertaste drücke dann bekommt die ja als erstes Windows zu sehen. Ist dann eine Checkbox im aktieven Fenster selektiert dann schaltet Windows diese um und das Programm sieht dieses Tastendruck für die Leertaste garnicht (Bekommt aber statdessen die Checkbox Nummer X hat umgeschaltet Nachricht).
Ist das aktive Element des aktiven Fernsters ein Edit Control sieht das Programm die ganzen normalen Tastendrücke nicht denn sie landen im Edit control und das hat Windows selber unter Kontrolle.

Also geht jeder Tastendruck seinen ganz normalen Weg durch das System und jede Stelle lässt ihn passieren oder tut irgendetwas damit. Wie die einzelnen Programme dann Tatsächlich auf Tastendrücke Reagieren hängt selbstverständlich von den einzelnen Programmen ab.

Und irgendwie habe ich halt den Eindruck das das unter Tuxbox nicht so läuft sondern das das einiges durcheinander ist.
Halt das Neutrino Tastendrücke sieht auch wenn diese Console im hintergrund ist und eine andere läuft.

Aber evtl. liegt das auch daran das das ganze System für die FB entwickelt wurde und die Tastatur erst später reingebastelt wurde.

cu
usul

Neutrino empfängt die Tastatureingaben nicht über die Console, sondern über den Eventhandler (/dev/input/event0) des Input-Event Cores und bekommt daher vollkommen unabhängig von irgendwelchen Mappings des Kernels/Terminals immer die gleiche Information.

Eigentlich sollte die Anwendung dann das Mapping selber durchführen.

Sollte Neutrino dann nicht lieber die Tasten von der Console empfangen anstatt zu versuchen selber nochmal einen Tastaturtreiber einzubauen?

Ich meine Theoretisch bertachtet (was wäre am besten) als bessere Methode das zu handeln (das das was letztenlich real passiert immer davon abhängt ob sich jemand findert der das auch umsetzt mal außen vor gelassen).


Auch wenn man bedenkt das an die Box evtl. auch mal andere Tastaturen rankommen können (IIRC lase ich in irgendeinem IDE Interface Thread mal was von der Idee auch einen PS2 Anschluß mit einzubauen).

cu
usul

Neutrino empfängt die Tasten einfach 1:1. Bsp.: die "Power"-Taste auf der Fernbedienung ist KEY_POWER, die "rote" Taste einfach KEY_RED. Eindeutiger geht es nicht. Bei der Tastatur ist es genauso.

Man könnte die Tastatur natürlich auch auf ein anderes event-Device abbilden (ähnlich des Samsung-Tastaturtreibers) und dann in Neutrino auswählbar machen ob man die Eingaben von der Tastatur über stdin oder das /dev/input/event haben will.

Der Aufwand ist aber in beiden Fällen gleich, auch die Tasten, die über stdin empfangen werden müssen letztendlich abgebildet werden. Das ist ein einfaches Mapping innerhalb der Anwendung, kein echter Treiber.

Wenn es dir um ein selbstdefiniertes Mapping geht, dann nimm Enigma, das hat sowas von Anfang an vorgesehen.

Und KEY_Z ist?

Einfach ist etwas was mit einer Tastatur zusammenhängt nie



Nur der Nutzen ist bei der Methode über stdin größer da von vornherein Probleme vermieden werden (z.B. Neutrino reagiert auf Tastendrücke inerhalb der Console).

OK. Ich denke ich habe jetzt verstanden wo die Probleme liegen. Jetzt kann ich viel ruhiger darauf warten/hoffen das sich irgendein Dev mit viel langeweile mal eine Tastatur besorgt

cu
usul

Erstmals zum Threadtitel (habe vergessen dies zu sagen): die erste Generation Tuxboxentwickler hat schon nahezu vollständig "Unterstützung der Tastatur" implementiert. Auch Tabellen für die qwertz-Layout ist drin. (Auch wenn nicht in YADD und JtG.) Eine Tastatur ist eine Tastatur, eine Fernbedienung ist eine Fernbedienung, nicht verwechseln. Der Thead handelt (hauptsächlich) um die Zweckentfremdung der Tastatur: "Keyboard as a bulky remote". OK, wir möchten gerne die Hardware zum Limit pushen, und die Grenzen ausloten. Nur um dies endlich loszulassen.

Erstes "vorkauen" der Events passiert in ../driver/fp/dbox2_fp_keyboard.c. Ich habe entdeckt, dass drin hat mann "vergessen" die drei "tote" Tasten (Druck S-Abf, "Windowstasten") einzutragen. Ich habe dies gefixt (KEY_SYSREQ, KEYLEFTMETA, KEY_RIGHTMETA), und werde dies (zusammen mit enstprechende Änderungen in rcinput.[cpp,h]) einchecken sobald CVS wider i.O. ist. Auch das Handeln von der Fn-Taste passiert drin. (Ich muss mein Artikel updaten!)

Ich habe etwas aus mein oben genannten Patch weiterarbeitet, und die Konfigurationsoption NO_NEUTRINOEVENTS_WHEN_VC=[ON,OFF] eingefügt. Falls ON werden, solange ein virtuellen Console offen is, werden Tasten nicht an Neutrino weitergeleitet. (Es ist ärgerich, dass beim Drucken von z.B. numerische Tasten oder Cursortasten Neutrino zappt...) Eventuell ist diese Fix unabhängig von Interesse? Ich werde die neue Version bald zu Verfügung stellen.



Nicht richtig das gleiche: In Enigma kann mann z.B. konfigurieren dass KEY_BLUE unterschiedliche Sachen auslöst. Hier sagen wir z.B. dass F4 soll ins KEY_BLUE übersetzt werden. Vgl. keyboard-translate und keymaps in Emacs. ABER: Es wäre grundsätzlich besser, programmierbarkeit und Erweiterbarkeit ins Programm zu verschieben. Ich habe ein bisschen im Dreamboxforum rumgestöbert, und sofern ich verstehe arbetet McClean mit Neutrino2 (was wahrscheinlich alles anderes als GPL sein wird ), dass sich auf Python basiert.

@robsp1: Der unglüclich gewählte Name ist RC_minus (besser wäre RC_volumedown), so dass ich RC_hyphen eingeführt habe. Diese "Verwirrung" existiert aber nicht bei KEY_*-namen. Bitte überlege, falls du nicht das Wort KEY_HYPHEN durch den Standardname KEY_MINUS ersetzen soll.

Wo kann man den Antrag auf Aufnahme stellen?
Z und Y bekommt man ja noch hin, aber wo ist z.B. "_"?



Ab wieviel Tasten wird aus einer FB eine Tastatur?
(nicht ernstnehmen, die diskusion brauchen wir glaube ich nicht)



An der Stelle der Grund für mein Posting: Sehe nur ich das so das dort ein Bug ist?
Sollte nicht die "Num" Taste (die in Blau) den Ziffernblock (blaue) Zweitbedeutung aktivieren und nicht die "Fn" Taste?



Super, besten Dank dafür.

cu
usul

@Barf:



Ja, da hast du mich mit der Namesgebung verwirrt , werde ich ausbessern.

Ich hab noch ein Problem mit deinem Patch für rcinput: Wenn du ein Mapping für die Tastatur machst ist das zwar, für Neutrino, sinnvoll, stellt mich aber vor andere Probleme. Der daemon kb2rcd soll ja allen Programmen und Plugins die Möglichkeit geben die Tastatur als Ersatz für die Fernbedienung zu verwenden. Wenn Neutrino jetzt aber z.B. F1 in KEY_RED umsetzt, dann darf kb2rcd das nicht mehr machen (sonst hast du ja 2 mal Rot gedrückt). Es gibt aber auch Plugins die die Tastatur nicht unterstützen und die auch nicht im CVS sind (tuxwetter und das flexmenü z.B.), für diese Plugins müsstest du dann die Umsetzung durch kb2rcd wieder erlauben.

Eine Möglichkeit wäre auch, ich signalisiere dir wenn ein Tastendruck eingefügt wurde, z.B. im input_event.value. Dieser Wert wird ja meist nur auf != 0 abgefragt um zu erkennen ob eine Taste gedrückt wurde. Wenn man das auf erweitert, dann könnte jedes Programm selbst entscheiden ob es einen solchen eingefügten "Tastendruck" verwenden will.

Leider bringt die Manipulation von value das Statehandling im Kernel durcheinander (der Wert 3 würde dazu führen, daß kernelintern die Taste als "losgelassen" markiert wird).

Hmm, es besteht eigentlich auch die Möglichkeit das Mapping zwischen Scancode und Keycode im laufenden Betrieb zu verändern (mit dem EVIOCSKEYCODE-ioctl). Das unterstützt der dbox2-Treiber momentan aber nicht (der Kernel hat keinen Zugriff auf die Map).

Würde das reichen?

Ich habe die neueste Version des kabr ("Keyboard as bulky remote")-Patches abgelegt als kabr-2006-03-26.diff.gz.
Nicht wirklich "fertig", aber auch nicht geheim. Eigenschaften sind in frühere Postings beschrieben.

kb2rcd und der kabr-Patch können tatsächlich koexistieren. Falls beide KEY_F1 ins KEY_RED übersetzen seht rcinput nur KEY_RED beim drucken von F1.


Klar. Betrachte aber die "philosofische" Bemerkungen in meine vorige Posting zu thema "Unterstützen". Es ist (mir) nicht (a priori) klar dass diese "Unterstützung" sinnvoll ist. Ich habe mich selbst einfach nicht darüber gekümmert.

Unabhäng davon, eine andere mögliche Sache wäre (falls mann meint dass meine user_translate funktion des Patches wirklich das Gelbe des Eis darstellt, und für Plugins (und Enigma!) zu Verfügung stehen sollte) die Funktionalität zu einer shared library auszulagern. Just as food for thought. Vgl. die readline Bibliothek.

Die Änderungen für sysrq, leftmeta, rightmeta sind in CVS.

Das verstehe ich jetzt nicht wie das funktionieren soll: wie will dein Patch erkennen das jetzt ein zusätzlicher Tastendruck in den Event-Buffer gelegt worden ist



Wenn Plugins die Tastatur nicht unterstützen dann liegt es IMO daran, das der Source dieser Plugins nicht offen bzw. im CVS ist (sonst hätte ich das dort eingebaut ). Eine Bibliothek dafür zur Verfügung zu stellen ist also vergebene Mühe, denn zu einem case KEY_RED auch ein case KEY_F1 dazuzuschreiben ist ja nicht ein sonderlich grosser Aufwand . Wenn ich Npq richtig verstehe, dann wäre ein 1:1 Mapping das man während der Laufzeit ändern kann sehr praktisch: d.h. prinzipiell mapped man z.B. den Code der eigentlich KEY_F1 erzeugt auf KEY_RED, nur wenn ein Programm die Tastatur selbst behandeln will (weil man z.B. auf KEY_F1 eine Hilfe-Funktion haben will), dann wird das Mapping geändert.

d.h. ein umschaltbares 1:1 Mapping (damit z.B. statt KEY_F1 KEY_RED) im Event-Buffer landet und zusätzlich das Mapping im rcinput (damit man auch Funktionen einzelnen Tasten zuweisen kann) könnte eine gute Lösung sein. Dann kann man kb2rcd auch entsorgen

hmm, mcclean kann nur java *duq*

nee mal im ernst, haste dich mit neutrino und enigma vertan?

gruss
mws

Ich habe den kabr-Patch weiterentwickelt, und sogar dokumentiert, siehe die (aktualiserte) version meines Artikels.

Änderungen:

- jetzt wird es klein geschrieben in Konfigurationfile,
- (für uns) sinnlose Neutrinomessages rausgeworfen,
- div Bugfixes
- effizienter Kodierung
- jetzt sagt mann key_f10=system(date) um das "date" kommando auszufüren, statt SCRIPTnn=date und danach KEY_F10=SCRIPTnn,
- etc.


Wenn ich die C++-Kode in neutrino.cpp sehe, halte ich durchaus "kann nur <andere sprache als C++>" für plausibel

Ich halte die Quellcode für Neutrino für eine Katastrophe, falls dass klarheit bringt?

du hattest aber vom dreambox forum und neutrino 2 geschrieben

das hatte mich verwirrt

gruss
mws