Volle Unterstützung der Dbox2 Tastatur

[robspr1]

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:

Code: Alles auswählen

SCRIPT01=Plugin:tuxtxt.cfg

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.

[usul1]

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

[robspr1]

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

[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

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.

sondern hauptsächlich darum, das auf der Fernbedienung Tasten sind die auf der dBox Tastatur nicht sind und umgekehrt.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

[Npq]

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.

[usul1]

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

[Npq]

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.

[usul1]

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.

Und KEY_Z ist? ;-)

Einfach ist etwas was mit einer Tastatur zusammenhängt nie ;-)

Der Aufwand ist aber in beiden Fällen gleich

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

[Barf]

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.

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

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.

[usul1]

Auch Tabellen für die qwertz-Layout ist drin. (Auch wenn nicht in YADD und JtG.)

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

Eine Tastatur ist eine Tastatur, eine Fernbedienung ist eine Fernbedienung, nicht verwechseln.

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

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!)

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?

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.

Super, besten Dank dafür.

cu
usul

[robspr1]

@Barf:

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.

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

Code: Alles auswählen

enum {
	KEY_RELEASED = 0,
	KEY_PRESSED,
	KEY_AUTOREPEAT.
	KEY_VIRTUAL
};

erweitert, dann könnte jedes Programm selbst entscheiden ob es einen solchen eingefügten "Tastendruck" verwenden will.

[Npq]

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?

[Barf]

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.

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

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.

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.

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.

[robspr1]

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.

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

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.

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

[mws]

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.

hmm, mcclean kann nur java *duq*

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

gruss
mws

[Barf]

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.

hmm, mcclean kann nur java *duq*

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

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

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

[mws]

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

[rasc]

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.

coool, so entstehen Gerüchte...

[Bimmel]

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.

coool, so entstehen Gerüchte...

Und was ist davon ein Gerücht ?

http://www.irclogs.ws/freenode/gentoo.d ... 005/9.html

[rasc]

jo, und wo steht das was von Python?

[Barf]

So, nach 3 Jahren zurück zum Thema!

Ich habe den oben beschriebenden Patch für sehr nützlig gefunden: mit einem Klick kann ich Aktionen auslösen, die sonst entweder unmöglich wäre, oder ein ganze Haufen mit Menüblättern erfordert hätte. Leider ist der Patch durch seifes rcinput-Basteleien kaputtgegangen. Hier eine aktualisierte Version, kann sogar repeat- und up-events binden. Dokumentation (englisch).

Auch wenn der Thread heisst "...Tastatur" ist der Patch durchaus von Intresse auch für Nichtbesitzer einer Tastatur!
(Natürlich ins besonderes falls man Tasten wie page-up, page-down ("Doppelpfeile" in Premiereterminologie) und/oder top-left, top-right, bottom-left, bottom-right zu verfügung hat.)

Ich möchte mittelfristig das Ding am liebstens in CVS sehen, um Unterhalt zu verenfachen. D.h., bitte testen, und eventuelle Einwände artikulieren.

Ich habe nur mit 2.4 getestet.

[rhabarber1848]

Kurze Rückmeldung: ohne rc.conf mit Kernel 2.4 funktioniert
Neutrino unverändert. Ich teste jetzt mit Kernel 2.6.

[rhabarber1848]

Ohne rc.conf mit Kernel 2.6 funktioniert Neutrino unverändert.

[rhabarber1848]

@Barf: Wenn Du keine neuen Einwände hast, denke
ich, dass der Patch eingecheckt werden kann.

[Barf]

So, jetzt ist es drin. Seit dem oben angegebenen Patch habe ich eine Initialisierung etwas sorgfälliger gemacht; könnte möglicherweise zu einem free-Fehler führen.