Beiträge von Seddi

    Zitat


    In file included from devices.cc:1:
    ../include/devices.hh:14:32: linux/dvb/frontend.h: No such file or directory


    Der vermisst eine Header Datei. Da diese Header Datei zur DVB API3 gehört und die Dream noch die alte API hat/nutzt, ist das klar.


    Daher nehm ich mal an, dass bei dir der Boxtyp nicht richtig gesetzt ist. Wie hast du das CDK denn aufgesetzt ?

    So dann hake ich mal den ersten Punkt ab, nachdem die lock() Funktionen nun ausgelagert sind :smiling_face:


    Den 2. Punkt (Schnittstelle Tuxtxt) hat sich auch fast erledigt, hab ich ja nun über Python direkt lösen können. Fehlt nur noch die Belegung der TEXT Taste.

    Das Zauberwort heisst eAppContainer ... wie das mit der Rückgabe funktioniert, kannst du im ipkg Plugin sehen, wie Reichi schon geschrieben hat. Wie du das Verzeichnis einliest, kannst du dir aus dem tuxboxplugins Plugin klauen.

    Hi @All ...


    so, dann will ich mal ein paar Wünsche loswerden, was mir im Moment auf der Box fehlt um ein paar Dinge zu realisieren. Bitte nicht falsch verstehen, das soll hier weder ne Forderung sein noch erwarte ich, dass das schnellstmöglichst umgesetzt wird. Wills nur anregen und mal festhalten, damit es nicht in Vergessenheit gerät. Alles zu seiner Zeit, also lasst euch nicht stressen :winking_face:


    [erledigt] -lock() Funktionen für Framebuffer und Fernbedienung in Python auslagern
    Die Funktionen existieren ja im C++ Code und funktionieren auch. Da ich aber gerne über Python einen Starter für standalone Binary Plugins basteln möchte, sollte ich die Funktionen in Python zur Verfügung haben. Das starten von binaries klappt via eAppContainer ganz gut und E2 läuft dabei auch weiter, nur regaiert dann halt sowohl E2 als auch meine binary auf die Fernbedienung, etc. Die lock() Funktion für das LCD-Display ist ja bereits in Python ausgelagert, scheint aber nicht zu funktionieren.
    Hab das ganze ja im IRC schon mit Ghost besprochen, wollte das nur nochmal festhalten.


    [fast erledigt] -Schnittstelle für tuxtxt
    tmbinc .. du denkst noch dran ? :smiling_face:
    Wenn ich die lock() Funktionen in Python bekomme, kann ich den Starter inkl. Tpid übergabe ja selbst basteln, sollte dann nur noch die TEXT Taste irgendwie belegt werden. Ich werde nächste Woche irgendwann den Source des tuxtxt soweit sauber haben und ihn dann auch rausgeben, dann kann man das vielleicht auch gleich richtig ins OE mit reinnehmen, so dass man diesen bei nem normalen CVS-Image gleich mitkompiliert und ins Image schiebt.


    -Video4Linux devices und dsp Device
    Es wäre schön, wenn man irgendwann die v4l Devices zur Verfügung hätte (sofern das die ATI Treiber hergeben) und ein dsp Device um auch Soundausgaben zu realisieren. Das C64 spielen macht ohne Ton keinen Spass :winking_face:


    -/dev/dvb/adapter0/video? bzw. DVB-Api 3
    Auch dieses Device scheint noch nicht voll verfügbar zu sein von den Treibern her, oder bin ich nur zu blöd dazu ? :winking_face:
    Siehe: /dev/dvb/adapter0/video0
    Wie weit wird denn die API3 Unterstützung irgendwann überhaupt mal gehen ? Gibt es Hoffnung auf die in der API spezifizierten SPU-Funktionen , etc. oder wird das nicht möglich sein ?



    So, das wars von meiner Seite erstmal, ansonsten bin ich mehr als zufrieden. Und wie gesagt, eins nach dem anderen und keinen Stress :winking_face:



    Grüsse
    Seddi

    Mal kurz ne Frage zu den dvb Treibern. Kann es sein, das die (noch) nicht voll ansprechbar sind ?


    Wenn ich Versuche auf ein video-Device ein VIDEO_SELECT_SOURCE (VIDEO_SOURCE_MEMORY) oder ein VIDEO_SET_BLANK abzusetzen, bekomm ich nur ein wunderschönes "is nich mein Jung" vom Treiber zurück :frowning_face:


    Grüsse
    Seddi

    You get as many epg-datas as the service is transmitting. The most tv-stations only transmit epg data 2 days in future. This has nothing to do with your memory, if you switch to a tv channel, E2 will collect as many datas as will be send. So you nor dmm can change anything about that.

    Ooops ... dann bin ich wohl einer der wenigen, der die neue Belegung "logischer" findet ... bin zwar auch die alte von den ganzen anderen Boxen gewöhnt und man muss sich erst mal dran gewöhnen. Aber meiner subjektiven Meinung nach ist die Belegung logischer.


    Geht mal von den Anwendern aus, die die alte Belegung nicht kennen. Für die ist die neue m.E. einfacher und sinnvoller. Das wir uns erstmal dran gewöhnen müssen ist klar ... :smiling_face:

    How do you start your "gSUB" ? I think you start this as a daemon with the help from a small Enigma-plugin as a Shellstarter ? If no, this would be a good idea, because. This "starter"-plugin (quick, small, easy) will be linked against enigma, so you can access the params you need and write the status-file by yourself.

    Mein Schachtel steht noch hier im Büro, hab gerade geschaut .. das steht nix :winking_face:


    Nee, ich finde PiP sehr interessant und das wird bestimmt auch noch kommen. Aber das ist ein nettes Zusatzfeature, das gut ist, wenn es geht aber auch nicht tragisch, wenn es im Moment nicht geht.


    Ich denke mal, da gibts erst mal noch ein paar grundlegendere Dinge zu machen :smiling_face:


    [IRONIE]
    Man könnte doch auch ne Steckdosenleiste mit Ethernetanschluss verwenden. Die sind alle über ein Webinterface steuerbar, dann könntest du anstatt dem halt via "wget" direkt den Strom zur Dreambox abschalten :smiling_face:
    [/IRONIE]


    Aber TV Bild per ASCII hätte doch was .. quasi Fernsehn schauen per Telnet :winking_face:


    Nee, ernsthaft. Das sollte schon in Enigma über die Eventhandler geregelt werden. Da ist der crond absolut fehl am Platze ...

    HI @all


    So, dann schreib ich mal kurz was dazu. Das tuxtxt auf dei 7025 zu portieren war eine riessen-Arbeit und ich war zwischendrin mehrmals an dem Punkt: Es geht nicht!
    Nun ja, es mussten die kompletten Grafikroutinen auf 32Bit umgeschrieben werden, etc. Wer ein bisschen was von Framebuffer versteht und sich den tuxtxt Quelltext mal anschaut, der weiss bestimmt was ich meine :winking_face:


    OK, zur Sache selbst. Der Tuxtxt ist nun komplett vom alten CVS gelöst worden und es wird einen eigenen Source für die 7025 geben. Im Moment haben wir erst mal das Problem, dass es in E2 noch keine Schnittstelle zum aufrufen gibt, aber ich denke mal da wird DMM in den nächsten Tagen reagieren.
    Das ganze ist nun eine Standalone Anwendung, die ausser der libfreetxpe, libm und zlib keine weiteren libs, etc. benötigt. Die libtuxtxt wurde komplett integriert. Wer basteln möchte, kann gerne die fertige Binary bekommen. Das ganze kann von der Konsole aus gestartet werden. Allerdings hat man da dann das Problem, dass E2 und Tuxtxt sich um die Fernbedienung und den Framebuffer streiten. Sobald eine Schnittstelle zum starten vorhanden ist, sollte das aber der vergangenheit angehören (wir haben ja auch extra eine Schnittstelle basteln müssen fürs Gemini).


    Den Quelltext werde ich selbstverstädnlich wieder unter der GPL freigeben (der unterliegt ja schon der GPL), allerdings bitte ich da euch noch um etwas Geduld, da nich nicht alles implementiert ist und es auch noch ein paar Fehler gibt. Weiterhin muss der Code noch gesäubert werden. ich halte es im Moment nicht für sinnvoll, wenn mehrere an dem Code rumschrauben. Daher will ich hier erst einen ordentlichen Stand erreichen. Wo und wie dann der Code gepflegt wird (CVS?) weiss ich noch nicht. Aber sobald ich den Code auf einem ordentlichen sauberen Stand habe, dass er problemlos kompiliert werden kann, werde ich ihn freigeben. Ich könnte mir dann auch vorstellen, das er gleich ins OE für die 7025 einfliesst, das muss aber DMM entscheiden/machen. Bis dahin seit bitte ein bisschen Geduldig. Kann euch bis dahin aber wie schon erwähtn zu jederzeit eine aktuelle, Imageunabhängige Binary anbieten.


    Grüsse
    @All
    Seddi

    Zitat

    Original von dcdead
    It will be a hard thing to run existing enigma1 plugins on enigma2 i guess... Another case are the plugins which use the fb directly, as for example tuxcom - these shouled be *easier* to port


    easier ? Not really, because the 7025 only has a 16 and 32Bit framebuffer and all the tuxbox plugins are based on 8Bit framebuffer. This means the complete grafics and text rendering routines must be completly rewritten and so on ...

    Zitat

    Original von tmbinc
    Der Framebuffer auf dem Xilleon kann leider kein 8bit auf dem Framebuffer. Find ich auch schade.


    OK, dann wird das mit dem Videotext, etc. auch ein bisschen aufwendiger ... wenn man überlegt, was für vorhandene Plugins alle auf einem 8Bit Framebuffer aufbauen, wäre es schon fast ne Überlegung wär eine lib zu schreiben, die einem beim konvertieren der Anwendungen hilft. Oder eben gleich auf sdl oder DirectFB gehen ..



    ---EDIT---
    Dazu ne Frage ... wie habt ihr das mit dem Videotext vor ? Wollt ihr tuxtxt direkt auf 16/32Bit (32Bit ist eigentlich sinnvoller und einfacher) portieren oder auch eine fertige lib wie directfb verwenden ? Oder wollt ihr ne komplett neue Anwendung schreiben ?


    Wenn ihr da auf ne lib setzen würdet, dann wäre es sinnvoll, wenn die restlichen Plugin-Progger (wie ich z.B.) vielleicht die gleiche einsetzen würden, bevor der Flash nachher mit unzähligen libs und zeugs zugeknallt wird :smiling_face:

    I although noticed, that no updates took place in the last 2 days. But I dont think this has to do with Gemini :winking_face:


    Maybe Ghost and tmbinc need a break after coding a lot of weeks day by day and they are only 2 days off use a long weekend and take the time for their private life. :smiling_face:

    Hi ...


    es gehört zwar nicht unbedingt in die Kategorie "Enigma2" aber ich wusste nicht wo sonst hinschieben, da es ja eigentlich auch nicht in die 7025er Hardware Ecke gehört sondern eher ne Entwicklungsfrage ...


    Naja, sei es drum. Ich versuche gerade den Framebuffer auf der 7025 in den 8Bit Modus zu schalten. Wenn ich das aus C heraus mache bekomme ich ein "Invalid". Wenn ich mit "fbset -depth 8" versuche den fb zu setzen, dann sieht es erst so aus, als macht fbset das ohne Probleme, wenn man danach jedoch gleich nochmal fbset ausführt um zu kontrollieren, meldet es wieder 32Bit Farbtiefe.


    War ich da gestern einfach nur zu "blöd" :winking_face: oder macht der Treiber keinen 8Bit Modus mit ?


    Grüsse


    Seddi


    P.S.: Enigma2 und Co. war natürlich fein säuberlich aus dem Speicher entfernt ...


    --EDIT--


    So .. hab noch ein bisschen getestet. Es funktioniert der 16Bit und der 32Bit Modus. Leider kein 8Bit Modus.
    @DMM
    Ist das eine Treibergeschichte die sich mal ändern wird, so dass man in naher Zukunft auch den Framebuffer im 8Bit Modus nutzen kann oder macht das die Hardware bzw. der Treiber niemals mit und ich darf anfangen alles auf 16Bit Framebuffer umzuprogrammieren ?