Volle Unterstützung der Dbox2 Tastatur
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
Ich würde diese beiden tauschen...
Finde ich besser, da man die dbox-Taste öfters nutzt.
Gruß
____Paule
Code: Alles auswählen
+ switch (ev.code)
+ {
+ case RC_btn_right:
+ ev.code = RC_setup;
+ break;
+ case RC_delete:
+ ev.code = RC_standby;
+ break;
+ }
Gruß
____Paule
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
-
- Erleuchteter
- Beiträge: 785
- Registriert: Samstag 6. August 2005, 03:39
HI,
habe eben den aktuellen Snap von Riker geflasht.
Aber irgendwie gehen die F Tasten für rot/blau usw. noch nicht.
Muss das jetzt noch aktiviert werden, oder ist e snochnicht drinnen, oder wird es auch nicht reinkommen ?
Ich habe gerade keinen Überblick wie und was jetzt der aktuelle Stand ist.
Kurz:
Welche Tasten gehen und welche gehen nicht...?
(Genauer: was geht im JTG aktuell und was nur im cvs rudimentär oder wenn man es selbst mit Schaltern compiliert ?)
Bye
PetB
habe eben den aktuellen Snap von Riker geflasht.
Aber irgendwie gehen die F Tasten für rot/blau usw. noch nicht.
Muss das jetzt noch aktiviert werden, oder ist e snochnicht drinnen, oder wird es auch nicht reinkommen ?
Ich habe gerade keinen Überblick wie und was jetzt der aktuelle Stand ist.
Kurz:
Welche Tasten gehen und welche gehen nicht...?
(Genauer: was geht im JTG aktuell und was nur im cvs rudimentär oder wenn man es selbst mit Schaltern compiliert ?)
Bye
PetB
1 x DBOX2 Phillips, 1 x DBOX2 Nokia, 1 x DBOX2 Sagem, 100er Gibertini (Astra / Hotbird), NFS Server
-
- Developer
- Beiträge: 587
- Registriert: Freitag 9. September 2005, 21:48
-
- Einsteiger
- Beiträge: 203
- Registriert: Mittwoch 27. April 2005, 09:37
bzgl. dem "Keyboard-as-bulky-remote" patch:
Es gibt derzeit IMHO 4 Plugins die die Tastatur unterstützen, wobei vnc die Tasten ja quasi weiterleitet, tuxcom, tuxmail und tuxcal die Tasten aber direkt verwenden.
Bei den 3 letztgenannten Plugins gibt es bereits eine Zuordnung der Funktionstasten zu gewissen Tasten der Fernbedienung. Diese Zuordnung unterscheidet sich aber von der Zuordnung im Patch. So sind z.B. die Farbtasten auf F1-F4 zu finden, im Patch auf F7-F10. Die unterschiedliche Zuordnung ist sicher nicht sehr sinnvoll.
Es gibt derzeit IMHO 4 Plugins die die Tastatur unterstützen, wobei vnc die Tasten ja quasi weiterleitet, tuxcom, tuxmail und tuxcal die Tasten aber direkt verwenden.
Bei den 3 letztgenannten Plugins gibt es bereits eine Zuordnung der Funktionstasten zu gewissen Tasten der Fernbedienung. Diese Zuordnung unterscheidet sich aber von der Zuordnung im Patch. So sind z.B. die Farbtasten auf F1-F4 zu finden, im Patch auf F7-F10. Die unterschiedliche Zuordnung ist sicher nicht sehr sinnvoll.
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
Wir sollten uns auf eine einheitliche Funktion / Belegung der Tasten
einigen. Sonst gibt es ein riesen Durcheinander finde ich.
Warum geht den die Mouse in Plugins und in Neutrino nicht?
Kann man die Treiber für die Tastatur nicht einmal in Neutrino implementieren?
Muss jeden Plugin seinen eigenen Treiber mitbringen?
Gibt es eine Schnittstelle für Plugins zu Neutrino??
Können wir in Wiki die Belegung dokumenteiren?
Welche Tasten sind von den Plugins wie belegt??
Gruß
____Paule
einigen. Sonst gibt es ein riesen Durcheinander finde ich.
Warum geht den die Mouse in Plugins und in Neutrino nicht?
Kann man die Treiber für die Tastatur nicht einmal in Neutrino implementieren?
Muss jeden Plugin seinen eigenen Treiber mitbringen?
Gibt es eine Schnittstelle für Plugins zu Neutrino??
Können wir in Wiki die Belegung dokumenteiren?
Welche Tasten sind von den Plugins wie belegt??
Gruß
____Paule
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
Hab hier mal einen Artikel unter Wiki angelegt.
http://wiki.tuxbox-cvs.sourceforge.net/IR-Tastatur
Wäre schön wenn man mal entsprechend die Funktionen dokumentieren
könnte.
Gruß
____Paule
http://wiki.tuxbox-cvs.sourceforge.net/IR-Tastatur
Wäre schön wenn man mal entsprechend die Funktionen dokumentieren
könnte.
Gruß
____Paule
-
- Tuxboxer
- Beiträge: 2067
- Registriert: Mittwoch 6. März 2002, 15:29
Und ich finde "OK" auf der "Enter"-Taste logischer.PauleFoul hat geschrieben:Ich würde diese beiden tauschen...
Code: Alles auswählen
+ case RC_enter:
+ ev.code = RC_ok;
+ break;
Code: Alles auswählen
+ case RC_btn_left:
+ ev.code = RC_ok;
+ break;
Die Zuordnung läßt sich doch nach belieben in rcinput.cpp ändern.
Zumal es so ausschaut, als ob auch dies nicht ins cvs wandert...
-
- Einsteiger
- Beiträge: 203
- Registriert: Mittwoch 27. April 2005, 09:37
Tastaturbelegung bei tuxmail/tuxcom/tuxcal:
F1 = rot
F2 = grün
F3 = gelb
F4 = blau
PAGE_UP = plus
PAGE_DOWN = minus
NUM = dBox
ESC = home
PAUSE = help
einige weitere Tasten sind noch "logisch" korrekt zugeordnet, da ich dies aber direkt in die Konvertierungstabellen im Source der Plugins eingetragen habe, weiss ich nicht mehr genau welche Taste wohin gehört
Die Enter Taste ist aber NICHT der OK Taste gleichgesetzt, da das bei der Eingabe von Texten in den Plugins sehr störend wäre, da Enter ja in die nächste Zeile wechseln soll und nicht die Eingabe beenden.
Ich habe zum Testen auch im tuxcald die Tastatur abgefragt und beim Erkennen von bestimmten Tasten den entsprechenden zugeordneten Fernbedienungscode erzeugt - das funktioniert auch ohne Probleme, d.h. ich kann die Tastatur als FB-Ersatz verwenden, nur werden diese Codes dann von Plugins die die Tastaturcodes selbst auswerden "doppelt" empfangen, d.h. dort müsste dann diese "Behandlung" deaktiviert werden oder das Umwandeln der Codes vom daemon während eines entsprechenden geöffneten Plugins gestoppt werden. Das ganze ist dann doch wohl ebenfalls "dirty"...
F1 = rot
F2 = grün
F3 = gelb
F4 = blau
PAGE_UP = plus
PAGE_DOWN = minus
NUM = dBox
ESC = home
PAUSE = help
einige weitere Tasten sind noch "logisch" korrekt zugeordnet, da ich dies aber direkt in die Konvertierungstabellen im Source der Plugins eingetragen habe, weiss ich nicht mehr genau welche Taste wohin gehört
Die Enter Taste ist aber NICHT der OK Taste gleichgesetzt, da das bei der Eingabe von Texten in den Plugins sehr störend wäre, da Enter ja in die nächste Zeile wechseln soll und nicht die Eingabe beenden.
Ich habe zum Testen auch im tuxcald die Tastatur abgefragt und beim Erkennen von bestimmten Tasten den entsprechenden zugeordneten Fernbedienungscode erzeugt - das funktioniert auch ohne Probleme, d.h. ich kann die Tastatur als FB-Ersatz verwenden, nur werden diese Codes dann von Plugins die die Tastaturcodes selbst auswerden "doppelt" empfangen, d.h. dort müsste dann diese "Behandlung" deaktiviert werden oder das Umwandeln der Codes vom daemon während eines entsprechenden geöffneten Plugins gestoppt werden. Das ganze ist dann doch wohl ebenfalls "dirty"...
-
- Developer
- Beiträge: 2183
- Registriert: Mittwoch 10. Dezember 2003, 07:59
-
- Einsteiger
- Beiträge: 203
- Registriert: Mittwoch 27. April 2005, 09:37
Wie wäre es mit einem eigenen daemon, quasi eine Kombination aus rcinfo und rcsim, welcher aus Tastendrücken der Tastatur die entsprechenden Fernbedienungskommandos erzeugt. Plugins die die Tastatur selbst abfragen könnten dann entscheiden, ob sie den daemon die Umwandlung weiter vornehmen lassen bzw. die Auswertung selbst machen.
Der Einbau in rcinput.cpp stellt ja nur die Tasten für Neutrino zur Verfügung, damit haben Plugins aber noch immer keine "rote Taste" von der Tastatur (oder sehe ich das falsch?)
Die Konfiguration mit einem Konfig-File wäre flexibel, eventuell könnte man auch Makros damit ermöglichen, so im Sinne von "F10 = BLAU-BLAU" um Teletext direkt aufzurufen.
Der Einbau in rcinput.cpp stellt ja nur die Tasten für Neutrino zur Verfügung, damit haben Plugins aber noch immer keine "rote Taste" von der Tastatur (oder sehe ich das falsch?)
Die Konfiguration mit einem Konfig-File wäre flexibel, eventuell könnte man auch Makros damit ermöglichen, so im Sinne von "F10 = BLAU-BLAU" um Teletext direkt aufzurufen.
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
Zustimm!robspr1 hat geschrieben:Wie wäre es mit einem eigenen daemon, quasi eine Kombination aus rcinfo und rcsim, welcher aus Tastendrücken der Tastatur die entsprechenden Fernbedienungskommandos erzeugt. Plugins die die Tastatur selbst abfragen könnten dann entscheiden, ob sie den daemon die Umwandlung weiter vornehmen lassen bzw. die Auswertung selbst machen.
Der Einbau in rcinput.cpp stellt ja nur die Tasten für Neutrino zur Verfügung, damit haben Plugins aber noch immer keine "rote Taste" von der Tastatur (oder sehe ich das falsch?)
Die Konfiguration mit einem Konfig-File wäre flexibel, eventuell könnte man auch Makros damit ermöglichen, so im Sinne von "F10 = BLAU-BLAU" um Teletext direkt aufzurufen.
Außerdem könnte man durchaus auch dopplet belegen.
Das Enter = OK ist finde ich super.
Aber der btn_left sollte auch OK bleiben. Ist besser
wenn man mit Mouse und Buttons navigieren möchte.
Gruß
____Paule
-
- Einsteiger
- Beiträge: 203
- Registriert: Mittwoch 27. April 2005, 09:37
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
"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
Code: Alles auswählen
KEY_HYPHEN=KEY_HELP;
KEY_ESC=KEY_HOME;
KEY_F1=KEY_RED;
KEY_F2=KEY_GREEN;
KEY_F3=KEY_YELLOW;
KEY_F4=KEY_BLUE;
KEY_BTNLEFT=KEY_POWER;
KEY_BTNRIGHT=KEY_OK;
KEY_102ND=KEY_VOLUMEDOWN;
KEY_GRAVE=KEY_VOLUMEUP;
KEY_PAUSE=KEY_MUTE;
KEY_DELETE=KEY_SETUP;
KEY_F10=KEY_BLUE;KEY_6;
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
-
- Einsteiger
- Beiträge: 203
- Registriert: Mittwoch 27. April 2005, 09:37
Wie willst den die Mouse haben?PauleFoul hat geschrieben:PS: Wie sieht es mit der "Mouse" aus??
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?
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
Also ich würde sagen (auf/ab/links/rechts). Wir sollten es hinbekommen,robspr1 hat geschrieben:Wie willst den die Mouse haben?PauleFoul hat geschrieben:PS: Wie sieht es mit der "Mouse" aus??
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?
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.
-
- Einsteiger
- Beiträge: 203
- Registriert: Mittwoch 27. April 2005, 09:37
@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.
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.
-
- Interessierter
- Beiträge: 21
- Registriert: Samstag 8. November 2003, 12:20
-
- Tuxboxer
- Beiträge: 2614
- Registriert: Montag 20. Mai 2002, 10:49
- Image: JTG-Image [IDE] Version 2.4.4
- Image: (7025SS) Merlin
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
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".
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".
Code: Alles auswählen
Comments that do not contain the equal character do not need the sharp sign.
# This is a comment with a = character
The following lines are for kb2rcd, and will be ignored here
MOUSECNT=0
MINMOUSE=1
MAXMOUSE=80
DELAY=0
SMARTDELY=1
INVERSE=0
WEBPORT=80
WEBUSER=
WEBPASS=
Turn on debugging
DEBUG=ON
"SCRIPT" is really a bad notation, e.g. "COMMAND" would be more correct.
SCRIPT01=date
SCRIPT20=df
SCRIPT08=tv_mode; TV is a 8805
SCRIPT05=projector_mode; Proki is a 500
Assigning a non-existing SCRIPT to a key is harmless
KEY_KP1=SCRIPT01;
KEY_KP2=SCRIPT02;
KEY_KP3=SCRIPT03;
KEY_KP4=SCRIPT04;
KEY_KP5=SCRIPT05;
KEY_KP6=SCRIPT06;
KEY_KP7=SCRIPT07;
KEY_KP8=SCRIPT08;
KEY_KP9=SCRIPT09;
KEY_KPASTERISK=SCRIPT20
KEY_HYPHEN=KEY_HELP;
KEY_ESC=KEY_HOME;
As opposed to kb2rcd,
there can be only one action to the right of the equal sign.
The rest are ignored.
KEY_F7=KEY_RED;KEY_DEEP_PURPLE;
KEY_F8 = KEY_GREEN;
KEY_F9=KEY_YELLOW ;
Spurious spaces are no problem
KEY_F10= KEY_BLUE;
Debug can be turned on and off
DEBUG=OFF
KEY_BTNLEFT =KEY_OK;
DEBUG=YES
KEY_BTNRIGHT=KEY_POWER;
KEY_102ND=KEY_VOLUMEDOWN;
KEY_GRAVE=KEY_VOLUMEUP;
KEY_PAUSE=KEY_MUTE;
KEY_DELETE=KEY_SETUP;
Nonexisting actions are simply ignored
KEY_M=no_such_thingy
Not only keys are recognised, but also neutrionMessages (see
neutrinoMessages.h). Some takes data, some not. Some makes sense in
this context, some not. Some crashes neutrino. Due to silliness in
neutrion.cpp, almost surely memory leaks will result in some cases.
TODO: disable the meaningless and/or crashing messages.
EVT_POPUP and EVT_EXTMSG works!
KEY_NUMLOCK=EVT_POPUP(Barf rulez!)
KEY_INSERT=EVT_EXTMSG(This is an EXTMSG)
Plugins can be started by EVT_START_PLUGIN
KEY_SCROLLLOCK=EVT_START_PLUGIN(tuxtxt.cfg)
Special function: RELOAD_CONF reloads this file
KEY_KPENTER=RELOAD_CONF
Some Neutrinomessages which work, and which MAY be useful
KEY_BOTTOMRIGHT=SHUTDOWN
KEY_BOTTOMLEFT=STANDBY_ON
KEY_Q=SHOW_EPG
KEY_W=SHOW_INFOBAR
KEY_E=VCR_ON
KEY_R=VCR_OFF
KEY_T=STANDBY_ON
The key saying `Z' (on the German layout) is KEY_Y
KEY_Y=STANDBY_OFF
KEY_U=LOCK_RC
KEY_I=CHANGEMODE # ??
KEY_O=EVT_VOLCHANGED # shows the volume bar
Works only partially
#KEY_A=STANDBY_TOGGLE # Problem with this
Works, but appears pretty useless (in this context)
KEY_A=ANNOUNCE_SHUTDOWN
KEY_S=ANNOUNCE_ZAPTO
KEY_D=ANNOUNCE_RECORD
KEY_F=RECORD_START
KEY_G=ANNOUNCE_SLEEPTIMER
KEY_H=SLEEPTIMER
KEY_J=UNLOCK_RC
KEY_K=EVT_VCRCHANGED
KEY_L=EVT_MODECHANGED
KEY_Z=EVT_BOUQUETSCHANGED
Do not work without data (crash), maybe with the correct data?
With some more work?
#KEY_A=ZAPTO
These crash the system, at least if used as here
#KEY_X=EVT_CURRENTEPG # crash
#KEY_C=EVT_NEXTEPG # crash
#KEY_A=RECORD_STOP
#KEY_F=REMIND
#KEY_K=EVT_MUTECHANGED
???
#// EVT_SERVICESCHANGED = CRCInput::RC_Events + 7,
#KEY_A=EVT_SCAN_COMPLETE
#KEY_A=EVT_SCAN_NUM_TRANSPONDERS
#KEY_A=EVT_SCAN_NUM_CHANNELS
#KEY_A=EVT_SHUTDOWN
#KEY_A=EVT_TIMER
#KEY_A=EVT_PROGRAMLOCKSTATUS
#KEY_A=EVT_RECORDMODE
#KEY_A=EVT_ZAP_CA_CLEAR
#KEY_A=EVT_ZAP_CA_LOCK
#KEY_A=EVT_ZAP_CA_FTA
#KEY_A=EVT_SCAN_FAILED
#KEY_A=EVT_SCAN_REPORT_NUM_SCANNED_TRANSPONDERS
#KEY_A=EVT_SCAN_REPORT_FREQUENCY
#KEY_A=EVT_SCAN_FOUND_RADIO_CHAN
#KEY_A=EVT_SCAN_FOUND_DATA_CHAN
#KEY_A=EVT_SCAN_FOUND_TV_CHAN
#KEY_A=EVT_SCAN_REPORT_FREQUENCYP
#KEY_A=EVT_ZAP_MOTOR
/* sectionsd */
#KEY_A=EVT_SERVICES_UPD
#KEY_A=EVT_START_PLUGIN
/* sectionsd */
#KEY_A=EVT_CURRENTNEXT_EPG # crash
#KEY_A=EVT_TIMESET # crash
/* "sectionsd" events triggered by neutrino */
#KEY_A=EVT_NOEPG_YET
/* "timerd" events triggered by neutrino */
#KEY_A=EVT_NEXTPROGRAM #crash