Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren

  • Moin!


    fnu, dass was nst hier macht, ist genau das Thema des Threads. Das dddvb-Paket so umkrempeln, dass zumindest Teile daraus irgendwann nach linux-media geschoben werden können, damit die Leute mit DVB-C-Karten von DD endlich einen normalen Kernel benutzen und damit auch andere DVB-C-Karten, die noch so rumliegen.


    Anders als bei DVB-S ist es bei DVB-C ja problemlos möglich, ein Kabel auf dutzende Karten zu verteilen, d.h. die alten Satelcos usw. sind noch lange nicht überflüssig, vor allem, weil die richtig stabil laufen. Nur kann man die mit dem ddvb-dkms nicht nutzen, weil das dddvb-dkms den dvb-core austauscht und damit alle Kernel-Treiber nicht mehr funktionieren.


    Aber das habt ihr mittlerweile ja schon selbst geklärt. :)


    Ich, als Themenstarter, bin mit den Beiträgen von nst vollkommen einverstanden. Hätte ich auch nur annähernd seinen Masochismus (ich hab's mal versucht), dann würde ich genau das machen wollen, was er gerade tut. Mir tut es nur leid, dass ich ihm momentan nicht helfen kann, weil ich es noch nicht zeitlich geschafft habe, aus seinem git ein dkms zu bauen, so dass man zumindest DD und nicht-DD Karten mischen kann. Wenn dann später irgendwann noch die TT-6400 dazukommt, ist das ein netter Bonus, aber für mich nicht weiter relevant. Mir persönlich geht es nur um die DD-DVB-C-Karten.
    Ich bin halt nicht so fit im Treiber-programmieren, dafür kann ich eben mit vdr-Plugins und vdr-Patches ganz gut.


    Lars.

  • Es besteht nach wie vor dringender Bedarf. Meiner Meinung nach würde das Linux, zumindest wenn es um DVB geht, ganz deutlich voranbringen. Mein Respekt jedem der es schaffen sollte hier tatsächlich die Treiber, die so in verschiedensten Trees rumstehen, in den Kernel zu bekommen.


    DKMS ist vor allem ein ziemlicher Verhau der zumindest bei den DVB-Treibern ständig Nacharbeit braucht. Bei vdr4arch hatten wir mehrere Anläufe und regelmäßig Ärger weshalb wir die DVB-Treiber schon eine ganze Weile komplett rausgehauen haben. Kann man denn irgendwie unterstützen?


    Meine Meinung: Hau ruhig erstmal alles raus was "die große Masse" nicht braucht. Für den Anfang wäre es schon ein riesiger Gewinn wenn die "gängigen" DVB-Karten gehen.

  • Masochistisch? Vielleicht. Aber auch heroisch! Wenn das gelingt, wäre das von großem Nutzen für Viele.


    Wie weit bist du eigentlich? Hast du schon was zum Einreichen?


    Zusätzlich müssten dich auch Einige unterstützen, die genug Fachwissen haben. Sonst geht es dir so wie mir, klitzekleinen Patch eingereicht, nach 1 Jahr Kommentar von Mauro, der etwas verändert haben wollte, nach der Änderung noch 1 weiteres Jahr bis zur Akzeptanz.

  • Alsdann. dddvb-0.9.28 plus die zwei Commits ontop aus dem DD repository sind "drin".


    • mediatree/master-ddbridge-update: DVB-API-Clean (dddvb-Code bereinigt um Dinge, die die Linux DVB API modifizieren) - Alle Tuner-Boards abzgl. MaxS8 sollten (genauso gut oder schlecht wie mit dddvb) laufen (ich denke nicht, dass DVB-C2 bzw. irgendeine S2-Scrambling-Code-Unterstützung relevant sind - dies sind die einzigen Dinge, die API-Änderungen für die normalen Tuner-Boards erfordern)
    • mediatree/master-ddbridge-update-features: DVB-API "modified" (restliche Änderungen, die API-Modifikationen erfordern) - Max S8 Support, DVB-C2, S2-Scrambilngcode


    Die Neuerungen setzen auf den bereits erfolgten Aufräumarbeiten basierend auf dddvb-0.9.23 auf und müssen noch "squashed" und anständig sortiert werden. Das, und checkpatch-Säuberung, mache ich die nächsten Tage noch. Es können auch noch weitere Code-Teile wegoptimiert werden, die z.B. nur für die Modulator-Unterstützung oder die OctoNet-Büchsen von relevanz sind (ebenfalls Teil meiner TODO-List).


    Ich werde mir anschliessend mal die MaxS8-Unterstützung vornehmen: Der Grund, warum die Unterstützung nicht im "Clean"-Branch ist, ist eine neue API-Funktion "DTV_INPUT", die nur im Zusammenspiel mit den mxl5xx-Karten gebraucht wird. Auch wenn mir nicht wirklich 100% klar ist, wofür die API-Änderung gut ist bzw. was sich funktional dahinter verbirgt, sehe ich eine Möglichkeit, die durch die Funktion erfolgenden Aufrufe in das mxl5xx-Demodulator-Modul anders zu lösen. Der Frontend-Treiber könnte dann ebenfalls "Clean" funktionieren. Damit wäre die gesamte DD Tuner-Hardware funktionsfähig, ohne die API zu "beschmutzen" :) Das dürfte im Vorfeld für die DKMS-Paketierer interessant sein, um Kartenunterstützung "nachzurüsten" anstatt zu "ersetzen"!


    Ein weiterer Punkt ist das cxd2843-Frontend-Modul. Ich denke, dies kann durch das mittlerweile im Kernel vorhandene cxd2841er ersetzt werden, wenn man dort einige Chip-IDs "nachrüstet" (weniger Patch, weniger Duplikat, höhere Chance auf Mainline).


    Wichtig/Disclaimer: Der 0.9.28-er Code ist bisher nur Compile-Tested! Wenn dadurch Tunerkarten oder Rechner kaputtgehen oder das Haus abfackelt, ist das nicht mein Problem :)


    Wie weit bist du eigentlich? Hast du schon was zum Einreichen?

    Jein: Einige Seiten zurück sind "stabile" Branches verlinkt, die dddvb-0.9.23 "In-Kernel" enthalten (selbes Clean/Dirty-Prinzip wie oben beschrieben). Der Code ist aufgeräumt (checkpatch-Clean), die Commits in Bi-Sect-kompatibler Reihenfolge sortiert und enthält diverse Ergänzungen/Fixes, ausserdem ist das TDA18212DD-Tunermodul durch die In-Kernel-Variante ausgetauscht - Details in den Commit-Messages. Es würden aber mit Sicherheit noch Änderungen durch die linux-media-Maintainer gefordert werden, aber ein Versuch wäre es bestimmt wert :)


    Grüße,
    nst

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Servus,


    mehr oder weniger große Umsortierung in https://github.com/herrnst/dddvb-linux-kernel:

    • Alte/unfertige/nicht mehr gebrauchte Branches sind jetzt allesamt mit einem "attic/" prefixed (sozusagen archiviert) und werden nicht mehr weiter verwendet oder verändert (hauptsächlich alte Kernel-Versionen mit ersten Versuchen der dddvb-Zerlegung)
    • Bastel-Branches sind jetzt mit "dev/" prefixed, u.a. behalte ich hier die History der Einzelcommits für das 0.9.23-0.9.28 Update als Referenz vor
    • Übrig sind noch Kopien der jeweiligen Upstreams (Torvalds-Master und linux-media-master) und darauf basierend - weiterhin als "Moving Target" - die dddvb/ddbridge Integrationsarbeit, die im Fall "linux-media-master" zur Patcherzeugung für die Übermittlung an die Linux-Media-List dienen soll - wenn das tatsächlich irgendwann mal was wird...

    Die "master-*" und "mediatree/master-*" den aktuellen, zusammgefassten (git squash/fixup) und aufgeräumten Stand mit dddvb-0.9.28 (das schliesst das TODO-Item "Säuberung" ab).


    Es wäre an dieser Stelle extrem Klasse und hilfreich, zu diesem Stand Feedback zu unterschiedlichen Hardware-Kombos zu bekommen! Installation geht nach wie vor am Einfachsten gemäß https://github.com/herrnst/ddd…ile-using-media_build.git, Gentoo-User können in /etc/portage/patches/sys-kernel/gentoo-sources/ diesen Patch (oder alternativ diesen Patch) - vorausgesetzt, dass gentoo-sources verwendet werden - mit ".patch" als Dateiendung ablegen und per "emerge gentoo-sources" vorbereitete Sourcen bekommen. ddbridge-sources wird mit 4.10.0 den 0.9.28er Code erhalten.


    EDIT: Teste gerade selbst mit meiner CTv6+Flex CT2 mit "msi=1" und bin gespannt, ob die Änderungen am MSI-IRQ-Handling den Betrieb verbessern.


    Und:

    TL/DR: Feedback benötigt für DRXK- und STV0910-basierende Boards, Feedback für MaxS8-Karten mit Feature-Branch wünschenswert, MaxA8 (Octo-C/T) sollte mit dem Basis-Branch laufen, Feedback wäre aber auch nicht schlecht. Ausserdem wäre DuoFlex CI-Feedback (Vergleich Base-Branch zu Feature-Branch) hilfreich. LNBH25 benötigt wohl Fixing, STV0367DD muss wohl wie beschrieben umgebaut werden.


    Nach wie vor gültig.


    Schönen Restsonntag,
    nst

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • ... neue API-Funktion "DTV_INPUT" ...
    Auch wenn mir nicht wirklich 100% klar ist, wofür die API-Änderung gut ist bzw. was sich funktional dahinter verbirgt, sehe ich eine Möglichkeit, die durch die Funktion erfolgenden Aufrufe in das mxl5xx-Demodulator-Modul anders zu lösen.

    Vieleicht solltest du mit Ralph Metzler Kontakt aufnehmen (eMail kann ich dir zukommen lassen). Er macht den Linux Treiber für DD und kann dir vielleicht weiterhelfen warum das so gemacht wurde.


    Der Frontend-Treiber könnte dann ebenfalls "Clean" funktionieren. Damit wäre die gesamte DD Tuner-Hardware funktionsfähig, ohne die API zu "beschmutzen"

    Ich finde das super, aber diese Änderungen müssten von DD übernommen werden um den Aufwand zu reduzieren. Es gibt derzeit eben zwei Varianten, die inkompatibel sind.


    Ralph hat den Auftrag die Treiber für DD Karten zu machen und wird von DD dafür bezahlt. Er hat das, aus welchen Gründen auch immer, eben so gemacht wie es jetzt ist. Und es hat sich in der Zwischenzeit auch der Kernel weiter entwickelt. Aus meiner Sicht müsste DD den Auftrag geben die Treiber so zu schreiben, dass diese ohne Änderungen in generischen Teilen funktionieren. Wenn das nicht geht, dann muss man sich eben mit den Kernel Entwicklern herum schlagen und Argumente für API Erweiterungen diskutieren. Letzteres zu umgehen, indem man einfach ändert und somit ein mergen unmöglich macht ist einfach kontraproduktiv.
    Hier wäre DD gefordert klare Richtlinien für den Entwickler vorzugeben.
    Und ja, der Karren ist jetzt schon weit verfahren und nst hat jetzt einen Haufen Arbeit um das wieder gerade zu ziehen, aber wenn Ralph hier nicht mitspielt und die DD Sourcen entsprechend anpasst, dann verpuffen diese Anstrengungen wieder!


    Ich BITTE hier DD sich bewusst zu werden was für ein Aufwand getrieben werden muss um die neuste Version endlich in den Kernel zu bekommen und auch hier zu schreiben, ob DD das überhaupt will. Wenn nicht, dann können wir nämlich den Thread schließen und mit der Spezial Variante von DD weiter wursteln, oder einfach keine DD Karten mehr kaufen (obwohl die zu dem Besten gehören was am Markt ist).


    Es würden aber mit Sicherheit noch Änderungen durch die linux-media-Maintainer gefordert werden, aber ein Versuch wäre es bestimmt wert :)

    Siehst, schreibst es ja selbst!
    Ist DD willens das Thema jetzt ein für alle mal zu einem guten Ende zu bringen?
    Wenn ja, dann sollte DD Ralph Metzler den Auftrag erteilen hier mit zu arbeiten. Nachdem Ralph nicht mehr mit Mauro kann, wird sich sicher jemand finden, der die Kommunikation mit den Herrschaften übernimmt, aber diese Person muss dann im Hintergrund Unterstützung durch DD (Ralph M.) erhalten.


    LG
    Jasmin

  • Nachdem Ralph nicht mehr mit Mauro kann, wird sich sicher jemand finden, der die Kommunikation mit den Herrschaften übernimmt, aber diese Person muss dann im Hintergrund Unterstützung durch DD (Ralph M.) erhalten.

    Nur mal so, bzgl. "die Linux-Media-Maintainer sind alle unmöglich": Ich weiss nicht, ob und wenn was sich "hinter den Kulissen" noch abgespielt hat, aber das, was öffentlich in den ML-Archiven nachzulesen ist, ist für mich weder ungewöhnlich noch unmöglich, sondern ganz normal, wenns um OSS-Projekte geht. Ich arbeite selber so'n bisschen am Kodi-Projekt mit (im Augenblick aber wenig bis garnicht), und die Forderungen, Teile von Patches zu überarbeiten oder Codeteile anders zu implementieren ist IMHO absolut in Ordnung und sorgt dafür, dass nicht durch irgendetwas alles am Ende in Kraut und Rüben endet...


    Wenn sich technisches Backing (in Form von Ralph Metzler, wenn Bereitschaft besteht, oder auch jemand anderes, mehr als 1 Person wäre aber vorteilhaft), hab' ich am Ende des Tages kein Problem damit, die Patches in die Liste einzukippen. Es wird dabei hauptsächlich um den ddbridge-Code, sowie die stv0910 und stv6111-Frontend-Module gehen. "Wir" brauchen nicht versuchen, die stv0367dd bzw. cxd2843 Frontends (CineCTv6, restliche C/T Karten/Flexmodule) einzuschieben - den Code gibt es bereits schon im Kernel (in Form von den stv0367 und cxd2841er-Frontends), die müssen "nur" angepasst werden, dass sie in der Konstellation, wie sie auf der DD-Hardware aufgelötet sind, korrekt laufen. Analogie zum Kodi-Projekt: Wenn ich hingehe und einen dedizierten "H264Player" submitten will, wird das auch mit "bitte benutze VideoPlayer und implementiere ggf. fehlende Bits, die Dein H264Player mitbringt" abgehakt.


    Zum Status 'ne Woche später: Aktuelle DVB-S2-Karten laufen jetzt fehlerfrei (die LNBH25-Problematik konnte ich fixen, und war am Ende ziemlich banal...). MaxS8 und MaxA8 laufen ebenfalls problemlos. Eine getestete Octopus Dual-CI Karte hat gerade noch irgendein Problem bzw. weigert sich, den DVB-Datenstrom zu decrypten. Vermutlich habe ich hier irgendwo zuviel wegoptimiert oder einfach was vergessen, da bin ich noch nicht durch mit. DuoFlex CI Boards sind noch ungetestet.


    Es scheint übrigens mittlerweile keine Probleme mehr bzgl. MSI-IRQ und I2C-Timeouts zu geben. Meine CTv6 läuft seit einer Woche mit MSI problemlos durch.


    Grüße,
    nst

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Wie tief greifen denn die Anpassungen?
    Ja, das ist nicht das direkte Ziel aber wenn man die Änderungen sauber "separieren" könnte, würde ich eventuell mal versuchen ob man das für DKMS zusammegebaut bekommt um das, zumindest solange es keinen Ärger macht, bei vdr4arch reinzubauen. Würde zumindest mal die potentielle Gruppe an Testern etwas vergrößern. Stand aktuell ist nämlich das es für vdr4arch keine offizielle Möglichkeit mehr gibt diese Karten zu nutzen. Es sei denn jemand baut alles zu Fuß selber. Mit den bekannten Nachteilen.

  • Die "Anpassungen" sind derzeit: OctoNet(Pro) Support komplett raus, DVB-C-Modulator-Support komplett raus, Code entschlackt (unbenutzte Codepfade und #ifdefs für verschiedene Kernelversionen ganz weg). Weiterhin alles so aufgesplittet, dass ein Teil Funktionalität ohne die im dddvb durchgeführten API-Anpassungen läuft, und in einen zweiten Teil OnTop, der die notwendigen API-Changes implementiert und die Funktionalität nachrüstet (derzeit am interessantesten: der mxl5xx-Treiber, der MaxS8 Support bereitstellt). Frontend-Treiber: Treiber, die bereits im Kernel vorhanden sind, werden weiterverwendet und ersetzen die von DD gelieferten "Dupletten" (WIP). Die tda18212dd, stv090x, drxk und lnbh25 sind bereits raus. Für die stv0367 und cxd2843 habe ich zumindest einen Plan, weiss aber noch nicht, in wieweit ich den mangels technischem KnowHow umgesetzt bekomme. Die stv0910 und stv6111 Frontends (neue S2-Karten/Module) fehlen derzeit im Kernel und können wahrscheinlich as-is in den Kernel Tree übertragen werden (sind auch bereits aufgeräumt). Zu "Code entschlackt" gehört auch "Coding-Style angepasst" (so, dass scripts/checkpatch.pl sich nicht mehr beschwert). Das Ganze ist auf aktuellem Stand bzw. extrahiert von/aus Digital Devices dddvb-0.9.28.


    Den einen Teil ohne API-Changes kann man IMHO so in ein DKMS oder ähnliches Konstrukt verpacken, dass die Kartenfunktionalität nachinstalliert wird, aber alles vorhandene nicht einschränkt. Vgl. dazu: https://github.com/herrnst/ddd…mediatree/master-ddbridge

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Nur mal so, bzgl. "die Linux-Media-Maintainer sind alle unmöglich": Ich weiss nicht, ob und wenn was sich "hinter den Kulissen" noch abgespielt hat ...

    Das kann man auf der Media ML nachlesen und auch hier im Forum irgendwo. Tatsache ist, dass nicht nur Ralph verärgert ist, sondern auch Oliver (Media Build Experimental). Das lag an der Art und Weise wie Mauro in diversen Code Teilen herum gepfuscht hat und auch Linus Torvalds hat ihm eine drüber gehauen. Also ist da schon was dran an der Geschichte. Wie auch immer, das ist Schnee von gestern und wir sollten vorwärts schauen.


    Beide erwähnten sind sehr vertraut mit den Treibern und können dir sicher Fragen beantworten.


    Wenn sich technisches Backing (in Form von Ralph Metzler, wenn Bereitschaft besteht, oder auch jemand anderes, mehr als 1 Person wäre aber vorteilhaft), hab' ich am Ende des Tages kein Problem damit, die Patches in die Liste einzukippen.

    Ich hoffe dass die Personen hier mitspielen. Das Thema ist immer wieder mal da und je länger wir warten, desto schwieriger wird es. Ich pers. kenne den Code kaum und hab mich nur mit dem CI Teil beschäftigt. Dazu ist aber dann auch wieder eine API Änderung nötig. Wie auch immer, wenn ich wieder im Lande bin und meine Workload es zulässt, kann ich auch auf der Liste mit lauschen und helfen es in den Kernel zu bekommen. Muss mir nur eine neue HW von DD besorgen, weil ein Tuner bei mir durch einen Blitzschlag kaputt ist.


    "Wir" brauchen nicht versuchen, die stv0367dd bzw. cxd2843 Frontends (CineCTv6, restliche C/T Karten/Flexmodule) einzuschieben - den Code gibt es bereits schon im Kernel (in Form von den stv0367 und cxd2841er-Frontends), die müssen "nur" angepasst werden, dass sie in der Konstellation, wie sie auf der DD-Hardware aufgelötet sind, korrekt laufen.

    Dann stellt sich mir nur die Frage, warum es überhaupt DD Versionen davon gibt? Es müsste ja auch im Interesse von DD sein Code zu übernehmen und ned was neues zu erfinden. Sprich man könnte dann ev. diese Teile in den DD Code übernehmen, sofern du da nicht was entfernt hast, was für OctoNet und Modulator benötigt wird (hab den Code nicht vor mir).


    Eine getestete Octopus Dual-CI Karte hat gerade noch irgendein Problem bzw. weigert sich, den DVB-Datenstrom zu decrypten. Vermutlich habe ich hier irgendwo zuviel wegoptimiert oder einfach was vergessen, da bin ich noch nicht durch mit. DuoFlex CI Boards sind noch ungetestet.

    Das ist aber cool, dass du das zum Laufen bringst. Ist das im Teil ohne API Änderungen?


    LG
    Jasmin

  • Code entschlackt (unbenutzte Codepfade und #ifdefs für verschiedene Kernelversionen ganz weg). Weiterhin alles so aufgesplittet, dass ein Teil Funktionalität ohne die im dddvb durchgeführten API-Anpassungen läuft ...
    Zu "Code entschlackt" gehört auch "Coding-Style angepasst" (so, dass scripts/checkpatch.pl sich nicht mehr beschwert). Das Ganze ist auf aktuellem Stand bzw. extrahiert von/aus Digital Devices dddvb-0.9.28.

    Das ist alles wunderbar, aber diese Dinge müssten von DD übernommen werde, sonst ist es immer manuelle Arbeit etwaige Änderungen von DD in die Kernel Version zu überführen.
    Es ist kein einfaches "git merge" möglich. Im Grunde wäre diese ganze Arbeit Sache von DD und deren Kernel Entwickler.


    Nachdem du auch die Sachen für die OctoNet und den Modulator entfernt hast (was ich verstehe) wird DD wohl kaum Interesse haben diesen Code Stand als Basis zu verwenden, selbst wenn dieser im Kernel sein sollte. Das ist keine Kritik an deiner Arbeit sondern einfach meine Meinung aus kaufmännischer Sicht. Das ganze Dilemma hätte niemals so weit kommen dürfen und hätte es auch nicht müssen, wenn DD strikte Vorgaben an den Entwickler gegeben hätte.


    Na Wurst, finden wir uns damit ab, dass wir in Zukunft eben eine Version für den Kernel haben und eine andere von DD und dass es immer eines nst oder wem auch immer bedarf um Änderungen von DD in den Kernel zu bekommen. Ich hoffe wenigstens, dass DD (Ralph) für Fragen zu technischen Details für dich da sind. Meine Erfahrung mit Ralph war immer sehr positiv. Er hat mir damals beim CI Problem geholfen und es am Ende auch übernommen.


    Apropos CI. Da hat Ralph ein neues Device "ci" erfunden, damit man vom Usermode aus das CI für jeden beliebigen Tuner verwenden kann und ned mit Redirect arbeiten muss. Ich nehme mal an das hast du in dem Teil mit den API Changes drinnen. Das müssen wir dann auch irgendwie in den Kernel bekommen, sonst werden viele Nutzer ned glücklich sein. Aber das ist Zukunft, zuerst muss mal alles funktionieren.


    LG
    Jasmin

  • Das kann man auf der Media ML nachlesen und auch hier im Forum irgendwo. Tatsache ist, dass nicht nur Ralph verärgert ist, sondern auch Oliver (Media Build Experimental). Das lag an der Art und Weise wie Mauro in diversen Code Teilen herum gepfuscht hat und auch Linus Torvalds hat ihm eine drüber gehauen. Also ist da schon was dran an der Geschichte.

    Bitte die Aussage auf keinen Fall falsch verstehen, ich wollte das auch nicht in Frage stellen, dass da mal was vorgefallen ist. Ich hatte mich nur daran orientiert, was rund um "ddbridge" und den zwei (mehr waren es anscheinend nicht) Versuchen, den Code in den Kernel zu pushen so geschrieben wurde, und da hab' ich ausser "bitte dies und das ändern, und keine Module duplizieren" (die Anforderungen der Maintainer damals sind übrigens Grundvoraussetzung für mein momentanes Tun) nicht viel mehr rauslesen können. Wohlgemerkt, alles als Aussenstehender betrachtet, der sich mal 'nen Überblick verschaffen wollte :) Also wie gesagt - auch an die Beteiligten, falls sie hier mitlesen - bitte nicht falsch verstehen! :prost2


    Ich pers. kenne den Code kaum und hab mich nur mit dem CI Teil beschäftigt. Dazu ist aber dann auch wieder eine API Änderung nötig. Wie auch immer, wenn ich wieder im Lande bin und meine Workload es zulässt, kann ich auch auf der Liste mit lauschen und helfen es in den Kernel zu bekommen. Muss mir nur eine neue HW von DD besorgen, weil ein Tuner bei mir durch einen Blitzschlag kaputt ist.

    Mal so bzgl. API-Änderung: Alles, was ich aus dddvb in Zusammenhang mit API-Änderung für den CI-Support rausoperieren konnte, war nur der neue Device-Node. Die resultierenden Commits dazu sind (im "eingefrorenen" Linux-4.9 Branch):

    Mehr ist da wirklich nicht :) Ohne die zwei Patches dürfte anstatt /dev/dvb/adapterX/ciY ein ../secY entstehen, was gleichermassen benutzt werden kann, aber das muss man testen. Kannst Du bei Gelegenheit das Plugin mal entsprechend anpassen?


    Dann stellt sich mir nur die Frage, warum es überhaupt DD Versionen davon gibt?

    Das cxd2841er-Modul wurde erst am 28. Juli 2015 gemerged, DD's cxd2843 ist schon wesentlich älter. NetUp war da aber einfach schneller, indem sie ihren Kartensupport nach Fertigstellung fix mainlined haben. Das stv0367-Modul ist schon länger da, funktioniert aber auch etwas anders: Die DVB-C/T-Ansteuerung ist separiert und es wird kein Kombi-Frontend bereitgestellt, abgesehen von Details in der Hardware/Schnittstellenansteuerung (u.a. die lange Inittab). Ganz grob gesagt ist die Ansteuerung in stv0367dd auch "separiert", wird aber dann zentral über eine Art Wrapper zusammengeführt, um ein Kombo-Frontend bereitzustellen.


    Sprich man könnte dann ev. diese Teile in den DD Code übernehmen, sofern du da nicht was entfernt hast, was für OctoNet und Modulator benötigt wird (hab den Code nicht vor mir).

    Unterschiede gibts nur beim frontend-attachment im Bridge/OctoNet Code (ddbridge-core:demod_attach_stv0367() bzw. ddbridge-core:demod_attach_cxd2843()). Vermutlich wird aber eher die Hölle gefrieren, alsdass die anderen Frontends Einzug in dddvb halten :) (ich würde auch lieber meinen eigenen funktionierenden Code maintainen wollen als den Brei von jemand anderes)


    Das ist aber cool, dass du das zum Laufen bringst. Ist das im Teil ohne API Änderungen?

    Habs ja auch kaputtgemacht, also muss es gefixt werden :) Bzgl. API siehe die zwei Commits oben.


    Das ist alles wunderbar, aber diese Dinge müssten von DD übernommen werde, sonst ist es immer manuelle Arbeit etwaige Änderungen von DD in die Kernel Version zu überführen.
    Es ist kein einfaches "git merge" möglich. Im Grunde wäre diese ganze Arbeit Sache von DD und deren Kernel Entwickler.

    Das wird sowieso manuelle Arbeit erfordern. War speziell jetzt nur 'n ziemlich heftiger Brocken, weils von 0.9.23 auf 0.9.28 ging, der obendrein nicht wirklich schön committed wurde. Versionsbumps (z.B. 0.9.28 auf 0.9.29) sollten fix an einem Abend gemacht sein (Beispiel: von 0.9.25 zu 0.9.26 waren effektiv zwei Patches/Commits).


    Nachdem du auch die Sachen für die OctoNet und den Modulator entfernt hast...

    Bis 0.9.23 (bis einschliesslich der Kernel-4.9 Branches) ist alles noch da. Die Unterstützung war vorher in den API-Changes-Teil separiert und ist jetzt halt rausgeflogen, weils vermutlich keiner brauchen wird und auf derartigen Systemen eh spezielle DD-Software läuft, und die OctoNet-Büchsen sind IMHO Insel-Lösungen, die nur mit eigener Firmware/Images laufen und ausschliesslich DD-Hardware aufnehmen. Daher weg, weil weniger zu pflegen und weniger Widerstand beim Mailinglist-Post. Dass DD die Teile entsprechend aufsplittet, wird eher nicht passieren :)


    Ich hoffe wenigstens, dass DD (Ralph) für Fragen zu technischen Details für dich da sind. Meine Erfahrung mit Ralph war immer sehr positiv. Er hat mir damals beim CI Problem geholfen und es am Ende auch übernommen.

    Mal schauen, Kontaktaufnahme rund um das Kernel-Merge-Thema ist im Gange.


    Grüße,
    nst

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • C/T-Kombi-Frontend wäre eine schöne Sache, weil der vdr besser damit zurecht kommt. Ansonsten muss man wieder irgendwie das nicht genutzte Frontend identifizieren und kompliziert deaktivieren (mit -D Parameter). Und da die Nummern da manchmal wechseln, ist das nicht unbedingt eine stabile Lösung.


    Ich arbeite da aber alternativ an einer udev-Lösung, die es schon in meinem dynamite-Plugin gibt, damit man dem vdr endlich dynamisch Devices zuordnen kann (wegnehmen kommt dann später).
    Deaktiveren würde dann über udev-rules laufen, genauso, um z.B. eine DVB-S-Karte auf eine Source zu fixieren.


    Auf alle Fälle: Daumen hoch!


    Lars.

  • Mal so bzgl. API-Änderung: Alles, was ich aus dddvb in Zusammenhang mit API-Änderung für den CI-Support rausoperieren konnte, war nur der neue Device-Node. Die resultierenden Commits dazu sind (im "eingefrorenen" Linux-4.9 Branch). Ohne die zwei Patches dürfte anstatt /dev/dvb/adapterX/ciY ein ../secY entstehen, was gleichermassen benutzt werden kann, aber das muss man testen. Kannst Du bei Gelegenheit das Plugin mal entsprechend anpassen?

    Ja, könnte man so machen, dass man "ciX" oder "secX" sucht. Urlaube derzeit noch bis Ende Februar.
    Aber das alte "secX" Device zu missbrauchen ist ned hübsch. Sollte ich, wenn alles im Kernel ist, dann dort diskutieren.


    Da ist ja auch für die Cine 6.x ein Treiber für den cxd2099 nötig. Der ist im Kernel irgendwie in einer Ecke geparkt und wird für das CI der Cine benötigt. Hast du hier die letzte Version aus dem DD Paket verwendet, weil im Kernel ist dieses File älter (soweit ich mich erinnere)?


    Ganz grob gesagt ist die Ansteuerung in stv0367dd auch "separiert", wird aber dann zentral über eine Art Wrapper zusammengeführt, um ein Kombo-Frontend bereitzustellen.

    Siehst du any chance das wieder so machen zu können? Oder etwas drüber (on top of the existing drivers) zu basteln, dass das wieder so wie im DD Paket funktioniert?


    Vermutlich wird aber eher die Hölle gefrieren, alsdass die anderen Frontends Einzug in dddvb halten :)

    Womit wir wieder bei der "es gibt zwei Versionen" Lösung mit Aufwand sind ... . Schade drum, aber ich versteh das schon auch irgendwie. Wenn der Karren mal verfahren ist, dann ist es immer schwieriger diesen wieder zum Fahren zu bringen.
    Ist irgendwie so wie die Geschichte vom Auto mit den achteckigen Rädern, wo die Herstellerfirma perfekte Stoßdämpfer entwickelt, anstatt runde Räder zu verwenden :mua
    Sorry für meinen Sarkasmus, aber ich kann das alles ned verstehen. Bei mir steht die technisch beste Lösung gepaart mit minimalen Aufwand immer im Vordergrund. Erinnert mich ein wenig an meine Firma, wo ich auch immer wieder wütend werden muss.


    Die Unterstützung war vorher in den API-Changes-Teil separiert und ist jetzt halt rausgeflogen, weils vermutlich keiner brauchen wird und auf derartigen Systemen eh spezielle DD-Software läuft ...

    Ja ist gut so, weil es sowieso (siehe voriger Absatz) nicht von DD übernommen wird. Wird dann halt immer von DD getestet und von allen anderen nochmals in einer anderen Version, nachdem Änderungen übernommen wurden. Super Sache! ;( :wand


    Dass DD die Teile entsprechend aufsplittet, wird eher nicht passieren :)

    Seufz!


    Mal schauen, Kontaktaufnahme rund um das Kernel-Merge-Thema ist im Gange.

    Aha, sehr gut!


    LG,
    Jasmin

  • Ich arbeite da aber alternativ an einer udev-Lösung, die es schon in meinem dynamite-Plugin gibt, damit man dem vdr endlich dynamisch Devices zuordnen kann (wegnehmen kommt dann später).

    Könnte man das nicht dem VDR einfach beibringen?
    Wenn sich im Kernel was ändert, weil ein standard API verwendet wird, dann sollte das doch wohl die UserSpace SW entsprechend handhaben können. Sprich der VDR muss eben so intelligent sein das eine oder das andere API zu erkennen, damit er mit den DD Treibern (kombi API) oder den neuen Treibern von nst (welche dem standard API entsprechen) zurecht kommt.
    Ich bin da ned sehr sattelfest im DVB API, aber wenn es aufgrund der HW eine API Erweiterung geben müsste, dann muss man diese eben im Kernel durchboxen. Die sind ja dort auch ned alle blöd und verstehen technische Probleme.


    LG,
    Jasmin

  • Naja, die Lösung auf API Seite ist das Kombifrontend. Bei getrennten Frontends kann der vdr nicht wissen, welche sich gegenseitig ausschließen. Das gibt die API nicht her.


    Problem ist eben, dass sich nicht genügend Leute finden, um alte Treiber anzupassen.


    Lars

  • Ja, könnte man so machen, dass man "ciX" oder "secX" sucht. Urlaube derzeit noch bis Ende Februar.
    Aber das alte "secX" Device zu missbrauchen ist ned hübsch. Sollte ich, wenn alles im Kernel ist, dann dort diskutieren.

    Eilt nicht :) Aber "missbrauchen"? Kurz über drivers/media/ nach DVB_DEVICE_SEC gegreppt sagt, dass _SEC genauso viel oder wenig Funktion hat, wie _CI (im Gegensatz zu z.B. _CA), IMHO also völlig i.O. bzw. das _CI-Rename überflüssig. (Eine der Fragen an jemanden, der sich damit auskennt oder verbrochen hat: Warum?)


    Da ist ja auch für die Cine 6.x ein Treiber für den cxd2099 nötig. Der ist im Kernel irgendwie in einer Ecke geparkt und wird für das CI der Cine benötigt. Hast du hier die letzte Version aus dem DD Paket verwendet, weil im Kernel ist dieses File älter (soweit ich mich erinnere)?

    Ja, den Diff (sowohl in dvb-core/dvb_ca_en50221.c als auch staging/media/cxd2099/) habe ich OnTop auf die API-Changes committed und versucht, eine passende Commit-Message/Beschreibung zu finden.


    Siehst du any chance das wieder so machen zu können? Oder etwas drüber (on top of the existing drivers) zu basteln, dass das wieder so wie im DD Paket funktioniert?

    Yep. In stv0367dd sieht das so aus (Klick) und wird im Fall DVB-C dann so (Klick) bedarfsweise umgeschaltet, wenn zuvor OFDM/DVB-T aktiv war. Die Init/Start-Konstrukte gibts im In-Kernel stv0367 auch, aber nichts, was alles unter ein Dach bringt. So wie in stv0367dd kann man bestimmt aus den stv0367ter_* und stv0367cab_* Funktionen ein stv0367dual_* bauen, was die Umschaltung durchführt und als Delivery System -T UND -C bekannt macht. Das dürfte sich auch als funktionale Erweiterung problemlos auf LinuxMedia schieben lassen.


    Womit wir wieder bei der "es gibt zwei Versionen" Lösung mit Aufwand sind [...] wo ich ... wütend werden muss [...] Super Sache! ;( [...] Seufz!

    Natürlich ist das K..äse, extrem ärgerlich und sorgt für Ungunst. Zumindest ich seh' zum jetzigen Zeitpunkt aber keinen anderen Weg, zum Ziel zu kommen. DD hätte von vornherein, nachdem ddbridge-0.5 committed worden ist, immer inkrementell direkt Patches einschieben müssen und nicht noch Code duplizieren sollen/müssen und anschliessend auf dem Standpunkt ausruhen "Ihr wollt unsere viel besseren Treiber nicht? Pech." sondern bestehenden Code ausbauen, wenn es ihrer Ansicht nach Unzulänglichkeiten oder fehlende Features gibt! Jetzt haben alle den Salat und entweder fixt man's jetzt mal so, dass alle was davon haben (Plug'n'Play Karten Support, und der DVB-T USB Stick aus dem Baumarkt funktioniert auch noch), oder lebt weiter mit der dddvb-Insellösung und allen dadurch entstehenden Aufwänden und Nachteilen.


    nst

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • IMHO also völlig i.O. bzw. das _CI-Rename überflüssig. (Eine der Fragen an jemanden, der sich damit auskennt oder verbrochen hat: Warum?)

    Soweit ich mich an eine Aussage von Ralph erinnere war das secX device für irgendeine alte HW nötig und ist erhalten geblieben. Er hat es dann umgetauft, weil er es für die CI Daten verwenden wollte und sec nicht intuitiv ist.
    Aber natürlich kann man mal vorerst secX verwenden und dann auf der ML diskutieren.
    Das "Problem" mit dem DD-CI ist, dass es so universell einsetzbar ist, dass das dort derzeit keiner kapiert. Die glauben immer noch ein CI Interface ist fest mit einem Tuner verschalten. Denen das beizubringen wird auch ein wenig Aufwand bedeuten. Aber das werden wir dann ja sehen.


    Ja, den Diff (sowohl in dvb-core/dvb_ca_en50221.c als auch staging/media/cxd2099/) habe ich OnTop auf die API-Changes committed und versucht, eine passende Commit-Message/Beschreibung zu finden.

    Na schau ma mal. Ralph hat da glaub ich zusätzliche Function Pointer rein gebastelt. Ich denke das ist etwas was ich übernehmen kann, wenn ich wieder da bin, weil mit dem Modul hab ich schon gearbeitet.


    Yep. In stv0367dd sieht das ...
    Das dürfte sich auch als funktionale Erweiterung problemlos auf LinuxMedia schieben lassen.

    Klingt vielversprechend! Dann braucht Lars nicht ein Plugin schreiben und vor allem es geht auch mit anderen Programmen, nicht nur mit VDR.


    Jetzt haben alle den Salat und entweder fixt man's jetzt mal so, dass alle was davon haben (Plug'n'Play Karten Support, und der DVB-T USB Stick aus dem Baumarkt funktioniert auch noch), oder lebt weiter mit der dddvb-Insellösung und allen dadurch entstehenden Aufwänden und Nachteilen.

    Ja, dann ist es eben so und wir müssen schauen was auf Lange SIcht bei DD passiert.
    Wichtig ist, dass es endlich in den Kernel wandert!
    Ich bin mir auch sicher, dass wir Unterstützung von allerlei Seiten bekommen, wenn wir erst mal anfangen es einzureichen.
    Wir sollten dann sinnvolle Scheibchen identifizieren und es Stück für Stück angehen.
    Manches wird auch parallel gehen. Du musst nur Entscheiden, ob der inkrementelle Ansatz sinnvoll ist, oder besser ein Patch um den Großteil zu entfernen und einen zweiten um den ganzen Treiber auf einmal rein zu bringen.


    LG,
    Jasmin

  • Soweit ich mich an eine Aussage von Ralph erinnere war das secX device für irgendeine alte HW nötig und ist erhalten geblieben. Er hat es dann umgetauft, weil er es für die CI Daten verwenden wollte und sec nicht intuitiv ist.

    Naja, der Bezeichner "ci" ist natürlich günstiger, weil eher zuzuordnen. Aber wie schon geschrieben, ein grep über die Sourcen hat keinerlei gesonderten oder anderen Verwendungszweck entdecken lassen. Evtl. kann man in diesem Zug auch "sec" zu "ci" umbenennen anstatt hinzuzufügen.


    Na schau ma mal. Ralph hat da glaub ich zusätzliche Function Pointer rein gebastelt. Ich denke das ist etwas was ich übernehmen kann, wenn ich wieder da bin, weil mit dem Modul hab ich schon gearbeitet.

    Es sind wohl Verbesserungen mit langsamen Modulen reingekommen, und die Datenpufferung wurde verbessert. Wäre Super, wenn Du Dich dem Thema annehmen könntest :)


    Klingt vielversprechend! Dann braucht Lars nicht ein Plugin schreiben und vor allem es geht auch mit anderen Programmen, nicht nur mit VDR.

    ... wenn es denn alles hinhaut. Ich brauche dazu wohl Testhardware (Karten mit passenden Demods drauf). Ich bekomme den InKernel-Treiber soweit, dass er den Empfang per DVB-C - habe mich erstmal darauf beschränkt - startet (zumindest wird Signalstärke angezeigt), aber es wird nichts zur Bridge bzw. zum PCI-Bus übertragen, und es poppen gelegentlich I2C-Fehler im Kernellog auf. Wie beim cxd28xx gilt es herauszufinden, was da jetzt falsch läuft, das kann ich aber nicht sinnvoll am/im Server beackern (da steigt mir meine Frau aufs Dach, und die Karte schiesst sich offenbar immernoch den I2C-Bus ab - erfordert Powercycle... nicht gut). Ausserdem wäre jemand, der davon tatsächlich Ahnung hat und Lust hat, zu helfen, hilfreich :) Anfragen sind angeleiert.


    Manches wird auch parallel gehen. Du musst nur Entscheiden, ob der inkrementelle Ansatz sinnvoll ist, oder besser ein Patch um den Großteil zu entfernen und einen zweiten um den ganzen Treiber auf einmal rein zu bringen.

    Den "raus mit allem, dann neues rein"-Ansatz hatte Antti damals schonmal in Form von Patches gepostet. Antwort "Don't do that, this breaks bisect" (für mich nachvollziehbar). D.h. wir sollten hoffen, die ddbridge in einem Stück reinzubekommen, sonst wirds auf der Zielgeraden nochmal richtig Arbeit...


    nst

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • hi,
    kann mir jemand helfen?
    bekomme diesen fehler beim kompilieren (debian jessie kernel 3.16.0-4-amd64)


    ddbridge.c:104:3: error: implicit declaration of function 'pci_alloc_irq_vectors' [-Werror=implicit-function-declaration]
    stat = pci_alloc_irq_vectors(dev->pdev, 1, nr, PCI_IRQ_MSI);
    error: 'PCI_IRQ_MSI' undeclared
    ...


    die rep von //linuxtv.org/media_build.git kompiliert ohne probleme?


    danke, gruss, onur

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!