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

Ich glaube mit DVB-C Modulator ist hier eine Karte gemeint die ein DVB-C Signal ausgibt, wird ab und an in großen Anlagen verwendet um einen "Hauskanal" in das interne netzt einzuspeisen, kein Empfänger.

Exakt, genau genommen diese Produkte/Karten von DD.

Zitat von nst

Ausserdem: Laufen die Boxen nicht sowieso mit dem vendor-provided dddvb Package?

Soweit ich das weiß basiert die Octopus Net FW auf dem dddvb Treiber Paket. Dort werden HW relevanten Dinge entwickelt die dann in der FW zum Einsatz kommen. D.h. alles was dort zu Octopus Net Geräten drin ist gehört dort hin. Das gilt IMHO auch für alles andere:

- https://github.com/DigitalDevices/dddvb
- https://github.com/DigitalDevices/octonet

Die Patches die manchem dddvb-dkms Paket enthalten sind, stammen nicht von DD.

Regards
fnu

OK, das bedeutet dann im Umkehrschluss aber auch, dass alles, was "OctoNet" im Namen beinhaltet (Kernelmodule, Software, whatever) außerhalb der SAT>IP-Boxen von DD quasi irrelevant ist, weil "es" sich dediziert um die Büchsen dreht, und in der Konsequenz daher für irgendwelche DKMS-Packages, media-build-experimental's, Kernelsourcen oder -images eigentlich komplett "über" ist (d.h. es gibt kein Stück Einbauhardware wie PCI-Karten, was irgendwie durch OctoNet-Treiber/Software bedient wird). Somit braucht der Support treiberseitig eigentlich nicht mitgeschleppt werden. Soweit richtig?

Nachdem jetzt ein paar Stunden und 'ne Mütze Schlaf ohne Beackerung von grausigen Patches/Commits vergangen ist, beantwortet sich durch die Device-Bezeichner auch die OctoPro/OctoNet-Pro Frage:

static struct ddb_info ddb_octopro = {
	.type     = DDB_OCTOPRO,
	.name     = "Digital Devices OctopusNet Pro",

... fällt demnach ebenfalls weg, wenn kein OctoNet-Support gebraucht wird.

Was die Modulator-Boards angeht, dürften entsprechende (Server-)Systeme eh mit einem "Komplett-Stack" aus DD-Hardware laufen, sind also für DKMS/Kernel-Sources usw. auch nicht wichtig.

Würde in Summe den Pflegeaufwand erheblich reduzieren

Bleibt die Frage aus dem ersten Absatz: OctoNet - Support erforderlich oder nicht?

Zitat von nst

Würde in Summe den Pflegeaufwand erheblich reduzieren

Nachdem DD diese Arbeit nicht selbst macht und du, als Freiwilliger, deine Zeit opferst, darfst du auch bestimme was dir wichtig ist in den Kernel zu bekommen
Und ich stimme dir für den Modulator zu 100% zu.

Das einzige was ein Problem werden könnte ist, dass die DD Version und die Kernel Version dann immer mehr auseinander laufen. Aus meiner Sicht ist das eine Katastrophe, weil dann immer Einer ur viel Arbeit investieren muss, nur weil der DD Maintainer aus persönlichen Gründen mit den Kernel Leuten nichts mehr zu tun haben will und deshalb programmiert, was er für richtig hält und natürlich, was DD für die Produkte benötigt.
Vielleicht kannst du das ja so machen, dass man schnell und einfach sieht, was nun der Unterschied ist, wenn deine masochistische Phase wieder vorbei geht und ein anderer Masochist sich finden muss um weiter zu machen.

LG
Jasmin

Zitat von jasminj

Nachdem DD diese Arbeit nicht selbst macht und du, als Freiwilliger, deine Zeit opferst, darfst du auch bestimme was dir wichtig ist in den Kernel zu bekommen

So gesehen wäre nicht mal der Aufwand für das 0.9.23->0.9.28 "Upgrade" notwendig, meine CTv6 (stv0367 C/T)+DuoFlex C/T/T2 (cxd2837) streamt im Zusammenspiel mit einer KNC1 DVB-C Karte (budget_av Modul) seit bald 200 Tagen uptime auf Mainline-Kernel mit integriertem 0.9.23er dddvb (vgl. Thread-Historie) in einer 3xDVB-C + 2xDVB-T/T2 Combo im Dauereinsatz völlig problemlos - das hilft aber der Allgemeinheit nur bedingt, da - abgesehen von den S2 v6/6.5 Boards mit stv090x - aktuelle Sat-Karten/Module und die S8/CT8-Karten im Rahmen der Integrationsarbeiten mindestens als "Baustelle" zu bezeichnen sind, wenn sie überhaupt irgendwie laufen (Feedback?). Das erklärte Ziel ist halt, das ALLES so läuft, als hätte man von Hand oder per DKMS-Package installiert, ohne sich aber dabei die DVB-API vom Kernel zu zerschiessen und ausser DD-Hardware gar nix mehr geht (was IMHO übrigens das grösste Problem darstellt und Motivator für mich war, dem Kram mal auf die Pelle zu rücken, um meine andere Tuner-Karte weiternutzen zu können).

Zitat von jasminj

Das einzige was ein Problem werden könnte ist, dass die DD Version und die Kernel Version dann immer mehr auseinander laufen.

Das Problem macht sich DD gerade eher selbst dadurch, dass sie in dddvb eine Copy des DVB-Cores von einem alten 3.10-irgendwas Kernel mitliefert und diese vor allem in Bezug auf die OctoNet- und Modulator-Geräte modifiziert hat, und die API-Copy nicht weiter mit/gegen Upstream synct.

Zitat von jasminj

Aus meiner Sicht ist das eine Katastrophe, weil dann immer Einer ur viel Arbeit investieren muss, nur weil der DD Maintainer aus persönlichen Gründen mit den Kernel Leuten nichts mehr zu tun haben will und deshalb programmiert, was er für richtig hält und natürlich, was DD für die Produkte benötigt. Vielleicht kannst du das ja so machen, dass man schnell und einfach sieht, was nun der Unterschied ist, wenn deine masochistische Phase wieder vorbei geht und ein anderer Masochist sich finden muss um weiter zu machen.

Dafür gibts ja GIT, bzw. durch GIT ist das per "git log" (oder entsprechendem URI auf github.com) schnell ersichtlich

Sofern Digital Devices nichts neues committed bzw. neue Package-Versionen released, ist der "große" Aufwand derzeit nicht mehr als regelmässig "git rebase" gegen den Linux Kernel "Torvalds-Master" bzw. den Mediatree-Master und gelegentlicher Konfliktbehebung oder API-Anpassung. Wenn eine neue Major-Kernel-Version (x.y.0) aus dem Master getagged wird, wird der ddbridge-master entsprechend gebrancht und abgehakt. D.h. eine Kernel-Version 4.8.0 mit Integration von 0.9.23 bleibt immer in der Kombi stehen, Updates von dddvb werden - wenn sie erscheinen - nicht rückportiert. Der Kram aus 0.9.28 wird also jetzt frühestens mit 4.10.0 interessant. Im Prinzip also nichts anderes als das, was mit den restlichen DVB-Treibermodulen passiert.

Der wirklich erhebliche Aufwand ist es, den Kram konform für die Damen und Herren media-Maintainer zu bekommen. Dazu bin ich aber auf Hilfe von Leuten angewiesen, die wesentlich tiefer in der Materie stecken und die Arbeit letzlich auch auf der Media-List posten und bei Rückfragen Argumente liefern können.

Grüße,
nst

Hallo,
Was hälst Du von der Idee ausser den CINE Treibern auch die ngene Treiber "upzudaten" ? Diese sind leider im kernel auch veraltet da fehlen gar einige PCI ids, so dass manche Karten erst gar nicht erkannt werden.
Ich würde Dir diesbezüglich auch gerne helfen ...

Zitat von helau

Was hälst Du von der Idee ausser den CINE Treibern auch die ngene Treiber "upzudaten" ? Diese sind leider im kernel auch veraltet da fehlen gar einige PCI ids, so dass manche Karten erst gar nicht erkannt werden.
Ich würde Dir diesbezüglich auch gerne helfen ...

Prinzipiell: Wieso nicht. Entwickeln/Patchen/Testen kann ich aber v.a. mangels Hardware nicht, aber man (ich) könnte ggf. ein GIT/Kernel-Repo starten ("dvbdrivers-kernel" ?), wo alle möglichen aktuellen Treibersourcen gesammelt werden (selbes Vorgehen wie oben), "gesammelt" würde dann auch Karten wie TT-S2 6400 einbeziehen (wenn ich das Forum richtig lese, ist für die Karten ja auch immer basteln angesagt). Sollte aber in 'nem separaten Thread oder per PN diskutiert werden.

Zitat von nst

Bleibt die Frage aus dem ersten Absatz: OctoNet - Support erforderlich oder nicht?

Sicher kannst Du alleine entscheiden, was Du da einreichst, aber warum sollte man den Support für Octopus Net ausnehmen, laufen schließlich auch unter Linux und Treiber liegen als OpenSource vor, im Gegensatz zu vielen anderen professionellen Geräten ...

Allerdings wird Dein Request erst in X Kernelversionen drin sein können, 4.x.y, die Octopus Net Geräte laufen aktuell auf Kernel 3.17.7 ...

jasminj

DD hat mehrfach versucht Treiber und ein paar gewünschte Änderungen in den Mainline Kernel zu bekommen, leider erfolglos. Insofern wünsche ich nst viel Erfolg, der letzte der sich dran versucht hat wurde u.a. auch hier zum Buh-Mann, weil naturgemäß nicht alles so umgesetzt wird, wie es der Einreichende wünscht.

Regards
fnu

Zitat von fnu

aber warum sollte man den Support für Octopus Net ausnehmen

Weil es erheblichen Mehraufwand bedeutet das zu maintainen, wenn da Teile von einer älteren Kernel Version dabei sind.

Zitat von fnu

Allerdings wird Dein Request erst in X Kernelversionen drin sein können

Na ja, wenn man das so macht wie Antitti (oder so ähnlich), dann ist es einfach ein Patch zum Löschen des alten Treibers und ein weiterer um die neue Version rein zu bekommen. Anders geht das bei den vielen Unterschieden nicht mehr.

Zitat von fnu

DD hat mehrfach versucht Treiber und ein paar gewünschte Änderungen in den Mainline Kernel zu bekommen, leider erfolglos.

Na ja, wir kennen die Geschichte doch genauer und es liegt nicht an der Technik, sondern woanders. Zumindest ist das mein Eindruck.
Soll aber jetzt Wurst sein in dem Thread

Zitat von fnu

Insofern wünsche ich nst viel Erfolg, der letzte der sich dran versucht hat ...

Also so wie ich nst verstanden habe, plant er gar nichts in den Kernel zu bekommen, sondern er macht nur die Arbeit, weil er selbst es braucht und "Spaß" dran hat. Den Quirks mit Mauro (sofern der noch Maintainer ist) sollen andere machen.

LG,
Jasmin aus Moalboal, Cebu, Philippines (ja, ich urlaube wieder mal ...)

Zitat von jasminj

Weil es erheblichen Mehraufwand bedeutet das zu maintainen, wenn da Teile von einer älteren Kernel Version dabei sind.

Zum einen. Zum anderen verstärkt sich bei mir der Eindruck, dass die Büchsen zwar "OpenSource" sind, aber trotzdem Blackboxen darstellen, auf denen Hersteller-Firmware zu laufen hat und nicht absehbar ist, dass jemand auf die Idee kommt, Mainline Kernel zu installieren. Nebenbei ist der Support jetzt nicht komplett weg - der Kram (bis Stand 0.9.23) kann relativ fix per cherry-picking (~6 Commits inkl. Modulator Support) wieder hinzugefügt werden.

Zitat von jasminj

Also so wie ich nst verstanden habe, plant er gar nichts in den Kernel zu bekommen, sondern er macht nur die Arbeit, weil er selbst es braucht und "Spaß" dran hat. Den Quirks mit Mauro (sofern der noch Maintainer ist) sollen andere machen.

... und um der OpenSource-Gemeinde was beizutragen. Submitten wird meinerseits nichts, weils mir einfach an vielen notwendigen Stellen komplett fehlt, daher Sinnlos und "Call for Help". Offen gesagt: Eigentlich sollte DD ihren Kram anständig sortieren (wirklich viel mehr brauchts IMHO nicht) und sich drum kümmern...

Zitat von jasminj

Also so wie ich nst verstanden habe, plant er gar nichts in den Kernel zu bekommen,

Zitat von nst

... und um der OpenSource-Gemeinde was beizutragen.

Ok, ja, will niemanden von sowas abhalten. Verstehe die Intention dabei aber jetzt doch nicht?

Das dddvb Paket funktioniert doch wie es ist gegen aktuelle Kernel und ist prima als DKMS Paket zu handhaben?

Regards
fnu

Zitat von fnu

Das dddvb Paket funktioniert doch wie es ist gegen aktuelle Kernel und ist prima als DKMS Paket zu handhaben?

Alles schön und gut, solange man damit leben kann, in aktuellen Kerneln plötzlich Subsysteme aus 3.10-sonstwas (genaue Version wäre noch zu ermitteln, auf jeden Fall alt und nicht zugehörig) installiert hat. Aber spätestens, wenn Du versuchst, nicht-DD-Hardware parallel zu benutzen, die eigentlich OOTB vom Kernel supported wird, ist aufgrund dessen Feierabend.

Ok ich verstehe, Du willst sowas wie UFO's media_build_experimental aufziehen und warum schreibst Du all das in einen Thread dessen Thema:

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

lautet? Dem natürlichen Verhalten in einem Forum habe ich mich z.B. auf diese Themenstellung bezogen ...

Vmtl. sollte ich hier erstmal schließen und das alles sortieren.

Regards
fnu

Bitte wirf' einfach mal einen Blick auf https://github.com/herrnst/dddvb-linux-kernel (speziell die einzelnen Branches) und https://github.com/herrnst/gentoo-ddbridge-sources-overlay ... Den Teil mit dem "Integrieren" habe ich dort nämlich bereits für jedermann frei und offen verfügbar vollzogen, und arbeite grad' am 0.9.23->0.9.28 Upgrade... -.-

Hab ich schon, und mich schon stark gewundert.

Hand auf's Herz, wer hat denn Nutzen von der Arbeit? Und ich bitte um eine ehrliche Einschätzung!

Wieviel Nutzer bauen sich denn am Ende einen eigenen Kernel? Wieviel Nutzer können diesen Overlay Distro-übergreifend nutzen?

Das Thema hier heißt "Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren". Damit ist m.E. eine Richtung vorgegeben, also eine Lösung die Distro-unabhängig nutzbar wäre, siehe UFO's media_build_experimental oder zu einer echten Integration in den Mainline Kernel führen würde.

Regards
fnu

Der Nutzen von dem Kram, der da gerade vorzufinden ist es, ein Patchset ("git format-patch") vom Upstream zur Entwicklung zu ziehen und an die linux-media List zum Review und Committen zu schieben, um eben KEIN DKMS, media_build_experimental oder sonstigen firlefanz zu brauchen. Davon ab kann man den Kram bereits in ähnlicher Weise via media-build benutzen, solange niemand Binärpakete bereitstellt. Ohne Vorarbeit, Tests, Rücksprachen usw. geht das eben nicht, sonst könnte man sich den ganzen Thread hier auch sparen, weil ist ja alles einfach da und fertig.

Wenn "Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren" mittlerweile nicht mehr gebraucht wird oder interessant ist, dann bitte mitteilen, und tatsächlich hier einfach zu machen. Falls den Kernel-Code nochmal einer (als Basis oder sonstwofür) braucht - feel free to fork, use, modify, whatever - ich bin erstmal raus.

Zitat von nst

in Patchset ("git format-patch") vom Upstream zur Entwicklung zu ziehen und an die linux-media List zum Review und Committen zu schieben,

Es geht also doch am Ende um die Integration in den Mainline-Kernel? Weil linux-media schließlich die Quelle aller DVB Treiber im Mainline Kernel ist ...

Zitat von nst

Wenn "Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren" mittlerweile nicht mehr gebraucht wird oder interessant ist, dann bitte mitteilen,

Tatsächlich ist das vmtl. gefragter denn je. Insofern finde ich Deine Reaktion recht irritierend. Ich versuche immer noch Dich und Dein Ziel zu verstehen um herauszufinden was ich oben missverstanden habe. Da wären ein paar einfache Antworten hilfreicher, als hier jetzt Kritik an Deinem Tun hineinzuinterpretieren.

Den sogenannten Firlefanz benötigt man beim Linux Kernel eben aufgrund seines archaischen Designs. Egal ob man Treiber nach dem Kernelbau als Modul laden kann ist es doch am Ende ein unflexibler unmoderner monolithischer Haufen mit zu vielen Abhängigkeiten ohne definierte Schnittstellen. DKMS ist in guter Ansatz dazu ...

Es wäre sehr hilfreich wenn die DD Geräte OOTB mit Mainline Kernel funktionieren, ältere Karten tun das ja, ngene & ddbridge. Aber es ist auch immer irgendwie ein hinterher Hecheln, weil gerade bei linux-media die Mühle sehr langsam mühlt.

Vor Jahren wurde für des ngene Modul in Ubuntu nicht die korrekte FW Version im Firmwarepaket ausgeliefert. Von meiner Fehlermeldung dazu, über die Diskussion bis zur Realisierung der Korrektur vergingen damals über ein Jahr. Und die alte nicht mehr brauchbare FW Version ist bis heute in dem Paket auch drin ...

Regards
fnu

Zitat von fnu

Es geht also doch am Ende um die Integration in den Mainline-Kernel? Weil linux-media schließlich die Quelle aller DVB Treiber im Mainline Kernel ist ...

Exakt das ist das erklärte Ziel, und dafür muss eben noch eine Menge gemacht, gegenüber den Herrschaften "linux-media" nach Einreichen der Patches argumentiert und anschliessend wohl tatsächlich (um)programmiert werden, damit das Ergebnis Mainline-konform ist. Und ehrlich gesagt: Den dddvb-Code habe ich gezwungenermassen jetzt mehrfach auf links gekrempelt und mir andere Dinge und Module in mainline:/drivers/media/* angeschaut, und kann die bisher auf der Liste angebrachten Punkte 100% nachvollziehen. Ich sollte echt mal die TODOs aus meinem Kopf in das Repo-Wiki übertragen.

Zitat von fnu

Tatsächlich ist das vmtl. gefragter denn je. Insofern finde ich Deine Reaktion recht irritierend. Ich versuche immer noch Dich und Dein Ziel zu verstehen um herauszufinden was ich oben missverstanden habe. Da wären ein paar einfache Antworten hilfreicher, als hier jetzt Kritik an Deinem Tun hineinzuinterpretieren.

Nichts für ungut - nachdem, was in der Vergangenheit hier offen zum Thema und konkret zur Thematik geposted wurde, kam ich mir bei den Fragen grad' ehrlich gesagt etwas veräppelt vor. Daher Sorry für die Überreaktion. Allgemein 'n schxxss Tag.