Tuxbox-Forum

neutrino-rework-rcinput-with-repeat.diff

Bisher wurde, wenn eine Taste länger gedrückt wurde, sie immer wieder in die Inputqueue eingespeist, je nach den repeat-Einstellungen. Allerdings war es nicht möglich festzustellen, ob ein Tastenevent schon wiederholt war oder nicht.
Ausserdem waren - hartkodiert - nur Hoch-, Runter-, Lauter-, Leiser- und Standby-Taste, sowie, auf Anforderung der einzelnen Routine auch die Links/Rechts-Tasten wiederholbar.

Mit diesem Patch, wird beim ersten tastendruck der RC_xxx code gesendet, bei längerem Druck wird RC_xxx|RC_Repeat gesendet.
Ausserdem können nun alle Tasten wiederholen, z.B. die Zifferntasten für die Texteingabe.

Die einzelnen Routinen können nun festlegen, ob sie auch auf repeated key-Events reagieren wollen (in dem sie RC_Repeat ausmaskieren) oder nicht.
Man könnte sogar bei einem kurzen Tastendruck eine ganz andere Aktion auslösen als bei einem langen - so wie es bei Enigma auch geht, oder wie es bisher schon beim Powerbutton gehandhabt wurde.

Als Beispiel habe ich die LCD-Helligkeitseinstellung so gemacht, dass bei kurzem Druck in 1er-Schritten eingestellt wird, sonst in 5er-Schritten. Ebenso die Lautstärkeregelung: kurz drücken => 1er Schritt, lang drücken => Eingestellte Schrittweite.

Ich habe es im grossen und ganzen so gemacht, dass die Tasten, die vorher wiederholt haben, das immer noch tun und andersherum.

Tests sind willkommen, auch ob Plugins etc. noch so funktionieren, wie sie sollen (tuxcom und tuxtxt funktionieren bei mir noch). Wenn die Tasten irgendwo nicht wiederholen, wo sie sollten, dann das auch melden.

ergebnisse unter http://dietmarw.trale.de unter div_tests

Ich habe mal die Lautstärke und LCD-Funktion getestet. Es wird trotz des langen Tastendrucks,
zu beginn, ein einzelner 1er-Schritt ausgeführt. Das solltest du noch ändern.
Ansonsten gehts schon mal. Gute Arbeit.

Das ist, prinzipbedingt, nur schwer zu lösen. Ich sehe darin aber auch erstmal kein Problem.

Wobei - wenn man Tasten wirklich doppelt belegen will, braucht man das natürlich.
Man müsste für den kurzen Tastendruck also nicht auf das Drücken, sondern auf das Loslassen der Taste triggern. Mal sehen, was sich da machen lässt...

Ich finde den Patch sehr Intressant, und werde in der nähe Zukunft untersuchen, falls ich mein "kabr-patch" anzupassen, um lange Tastendrücke zu binden.

Man könnte auch untersuchen, falls/wie rcsim und rcem lange Tasten emulieren könnte. Frage ist dann welche Syntax man benutzt um lange Tasten zu bezeichen; spontan fällt mir irgendwelche "modifier"-Syntax ein.

Weiter so!

nur mal als Beispiel, Enigma benutzt dafür flags in rcdbox_inputdev.xml (dbox2), es gibt 4 verschiede Tastendrücke in Enigma:
1. einfacher Tastendruck z.B. um Menü aufzurufen:
<action name="showMainMenu" key="d-box" flags="m" />

2. Tastendruck mit repeat (Wiederholung), Taste drücken und festhalten, sinvoll bei Volume und Navigationstasten, sonst müsste man bei Lautstärke ändern zig mal auf Volume -, + drücken:
<action name="volumeUp" key="+" flags="mr" />

3. kurzer Tastendruck, z.B. um Videotext auf der blauen Taste aufzurufen, flag "b", ich nehme an, b steht für "a little bit"
<action name="pluginVTXT" key="blue" flags="b" />

4. langer Tastendruck, z.B. um Plugins auf der blauen Taste aufzurufen, Taste drücken und festhalten, flag "r", ich nehme an, r steht für release, loslassen
<action name="pluginExt" key="blue" flags="r" />

vielleicht noch einer, ist aber nicht dokumentiert, von mir zufällig entdeckt, ohne flag, z.B.
<actionmap name="numbers">
<action name="1" key="1" /> normallerweise <action name="1" key="1" flags="m" />
es wird zu Kanal 1 umgeschaltet erst wenn man die Taste 1 loslässt, dabei kann man zick Minuten die Taste 1 gedrückt halten, bis dato tut sich nichts, in meiner rcdbox_inputdev.xml ich benutze das für Nummerntasten, weil Sagems und Philips zickig drauf reagieren

mrvica

Ich persönlich würde ja eher einen direkten socket anbieten, über den simulierte Tastendrücke ins neutrino geschleust werden können, anstelle die wir rcsim ins input-Device "hineinzukippen" (was auf der dream, die kein standard-inputdevice benutzt, zumindest nicht in neutrino, schon mal nicht funktioniert). Das aber später



Ja, ich kenne das von enigma. Ich denke aber die Buchstaben sind anders:

m - make, Taste wird gedrückt
b - break, Taste wird losgelassen
r - repeat

b macht einen kurzen Tastendruck, weil man ja erst beim loslassen der Taste entscheiden kann, ob er lang oder kurz war , ansonsten bekommt man immer erst einen "kurz"-Event, dann einen "lang"-Event.
Wenn die Taste losgelassen wird, bevor es für "Lang" reicht, dann war es kurz. Alles klar?

Dann schau ich halt doch mal in den Code.....
..... kein flag ist dasselbe wie "flag=b":

Eventuell könnte man bei diversen Reglern das Fortschreiten des Balkens
dynamisch machen, sprich: abhängig davon wie lange die Taste gedrückt
wird, die Schrittweite erhöhen auf 10...15 .

Obwohl, man kann es auch übertreiben ^^

So. Nächster, meiner Meinung nach finaler Versuch.
Dieses mal mit Key Release event, wird bisher noch nicht verwendet, könnte aber.

(Eigentlich wollte ich auch das repeat-Handling rauswerfen und dem Kernel den delay und repeat sagen, dann habe ich gemerkt, dass der dbox RC-Treiber das nicht kann).

Im rcinput.cpp sind die #ifdefs für OLD_RC nun etwas weniger verwirrend, wenn ich das irgendwann mal auf der dreambox ausprobiert habe, kann vermutlich der OLD_RC-Code komplett weg, sonst verwendet den ja keiner mehr.

Probiert's aus, es kommt bald ins CVS

neutrino-rework-rcinput-with-repeat-v2.diff

GetAway: Das hat mit diesem Patch nicht direkt zu tun, aber dieser Patch sorgt dafür, dass du die Infrastruktur hast, um sowas zu machen.

P.S.: das "Lautstärke in einser-Schritten bei kurzem Tastendruck" habe ich wieder rausgenommen, meine Betatesterin fand das nicht gut.

Na gut, v2 war nicht so toll (Volumebar "seltsam").
neutrino-rework-rcinput-with-repeat-v3.diff

Testen, zackzack!

So getestet, schädliche Nebenwirkungen habe ich bisher keine bemerkt. Auch bei den Plugins. Um's ausführlich zu testen isses aber etwas spät... da muss die Box im Wohnzimmer herhalten , das ist seit kurzem eine Sagem, da könnte das etwas interessanter sein.

Ich lasse es auch diese Woche mal durch meine Frau testen. Wenn die sich nicht beschwert, kommt's ins CVS

Habe kurz angetestet, Lautstärke und LCD-Helligkeit geprüft.
Fühlt sich gut an, die LCD-Helligkeit kann in 1- und 5-Schritten intuitiv geändert werden.

Für die Lautstärkeregelung würde ich eine Schrittweite von 3 als neuen Standard vorschlagen,
da ansonsten der Vorteil der genaueren Einstellung beim Tasten-Repeat, den dieser Patch bringt,
nicht richtig zum Tragen kommt.

Zum Thema multizap:
MIt dem aktuellen CVS habe ich auf meiner Sagem-Box hin und wieder das Problem, dass
das Weiterschalten eines Senders durch einmaligen Druck auf KEY_UP oder KEY_DOWN
nicht einen, sondern ungewollt zwei Sender weiterschaltet. Ich habe gesehen, dass Du
ein clearRCMsg() dagegen eingebaut hast, leider sorgt es in dem von mir beschriebenen
Fall nicht für Abhilfe.

Wer entscheidet eigentlich, ob eine Taste wiederholt oder nur einmal gedrückt wurde,
der Frontprozessor?

werds morgen Früh mal testen ^^

Für die Lautstärke würde ich es wieder rausnehmen (ich dachte, das hätte ich schon gemacht...)
Meine Testpersonen (Frau und Kinder) fanden das nicht so toll, die alte default-Schrittweite von 2 fanden sie besser - und tatsächlich hat man schnell genug laut und leise gemacht damit.


Ja, das gehört auch eigentlich nicht hier rein, das ist eher aus Versehen mit reingerutscht.
Wo das hilft ist, wenn du in der Kanalliste "unten raus" scrollst, oder in der EPG-Übersicht von einer Seite zur nächsten. Oder wenn du die Tasten lange gedrückt hast, so dass sie wiederholen, aber, weil das zappen relativ langsam geht, noch events in der input-Queue sind. Das könnte man allerdings später dadurch vermeiden, dass man fürs zappen nur nicht-repeated Tasten akzeptiert.

(Bei den Multizaps (das hatte ich auch manchmal) ist es meiner Meinung nach eher so, dass vom zapit irgendwann ein "verirrtes" "Zap complete"-Event kommt. Bei mir ist es manchmal so, dass ich, wenn ich der Reihe nach 1-2-3-4-5 durchzappe (mit KEY_UP), dass die box dann plötzlich nach 10 oder 11 wieder auf 5 springt (oder so ähnlich), was auch keine RC-Fehlerkennung ist (sonst wäre erst die Ziffer eingeblendet, vom NumZap). Das muss ich mal getrennt debuggen, ist aber extrem selten und hat mit diesem Patch nichts zu tun.)

Dieser Patch fixt erst mal gar nichts, (ausser die LCD-Einstellungen), aber er schafft Infrastruktur


Nein, der kernel in dbox2_fp_rc.c

Bis auf den Makel... Funktionierts gut, keine Auffälligkeiten.

Ist committed. Evtl. fallout (ich kann mir nicht vorstellen, dass ich damit garnichts kaputt gemacht habe) einfach melden.
Das mit den 1er-Schritten für die Lautstärke habe ich dann doch weggelassen, das fanden meine Betatester nicht nützlich, aber die LCD-Einstellungen sollten jetzt schön mit Grob- und Feineinstellung funktionieren (Das ist das einzige, was ein User an Unterschied bemerken sollte).

Inzwischen habe ich auch gelernt, wie man Kernel-Input-Treibern autorepeat inklusive Einstellung der Wiederholrate beibringt, das könnte das Ganze in naher Zukunft nochmals etwas vereinfachen (und dabei auch gleich die dreambox, so sie denn jetzt nicht mehr tut, wieder fixen).

Volle Zustimmung! Danke für den Patch!

@ Seife

Irgendwie kann ich die dbox am Powerschalter unter der Frontklappe jetzt nicht mehr durch langes drücken
ausschalten. Die geht nur noch in den StandBy-Modus...

Kann das an Deinem Patch liegen??


Gruß
____Paule

Das kann ich mit meiner Sagem-Box reproduzieren, mit der Fernbedienung
und langem Drückem des Ausschaltknopfes funktioniert der deep-standby.

Ja., definitiv
Moment.

fixed. http://cvs.tuxbox.org/cgi-bin/viewcvs.c ... 8&r2=1.909

Es scheint so, dass das unlocken des FSs kaputt gegangen ist. Möglicher Fix:

Korrekt. Ist (etwas anders, hoffentlich noch korrekter) gefixt.

Ich habe gestern abend mal neu ausgeckeckt und Neutrino gebaut:
Bei mir läßt sich die Box per Fernbedienung nicht mehr ausschalten.
Nur noch Standby geht.

gruß boardgeist