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

Zitat von nst

Das 4.18er Merge Window steht vor der Tür, für DD-Karten gibts eigentlich nur einen wirklich spannenden Change:

• ddbridge 0.9.33, inkl. initialem Support für die neuen MaxSX8 Karten

By the way... Hatte mich übrigens gefragt, warum du den "initialen Support für die MaxS8" spannend findest, zumal sie ja schon in den Kernel integriert ist und auch tadellos funktioniert, aktuell bei mir mit Kernel 4.16. Bis mir aufgefallen ist, dass du MaxSX8 geschrieben hast. Da gibt's seitens DD also mal wieder was neues. Aha! Hatte mir mal die Vergleichstabelle zu den verschiedenen Karten angesehen. Die kann ja anscheinend eine ganze Menge mehr. Wenn ich ehrlich bin, verstehe ich aber nur Bahnhof.

Welche Vorteile hätte ich, wenn ich meine MaxS8 gegen eine MaxSX8 tauschen würde?

Wäre cool, wenn das jemand so erklären könnte, dass es auch "normale" Leute verstehen.

Danke und Gruß Hoppel

Zitat von hoppel118

Welche Vorteile hätte ich, wenn ich meine MaxS8 gegen eine MaxSX8 tauschen würde?

Den Gedankengang würde ich an Deiner Stelle streichen, solange Deine mxl5xx-basierte MaxS8 tut, was sie soll und keine DVB-S2X Transponder am Himmel auftauchen. Vor allem aber implementieren die Boards die Demod/Tuner-Treiber, die bei anderen Karten (u.a. MaxS8=mxl5xx, CineS2v7=stv0910+stv6111) als I2C-Client mit eigenen Treibern implementiert sind, in FPGA. Bedeutet: Jedes Update, jeder Bugfix erfordert mindestens einen FPGA Flash-Vorgang, und wenn Datenstrukturen verändert werden, passende Änderungen im (dd)Bridge-Code (anstatt eben einen Zweizeiler im I2C-Client-Treiber zu hinterlegen). Und obendrein ist jeder der Willkür der FPGA-Code-Entwickler ausgeliefert...

Aber die Zeit wird zeigen, wie gut (oder nicht) das Modell funktioniert. Eventuell wird auch einfach der I2C-Bus aufgemacht und es fällt ein StiD135 Demodulator Treiber vom Himmel (der scheint auf den Boards aufgelötet zu sein).

FYI: https://patchwork.linuxtv.org/patch/50994/

Es liegen noch einige ddbridge-Patches unbeachtet im Patchwork (Verbesserung MaxSX8 Support), ob die gemerged werden und in welcher Form ist für mich aber nicht mehr von Relevanz.

Vielen Dank an alle, die tatkräftig mit dem DD Treiberzeugs unterstützt haben.

@Moderatoren - Bitte am besten bei Gelegenheit den Thread zu machen.

Hallo nst!

Schade, Schade, Schade!

Du hast das echt spitze gemacht!

Dank deines grandiosen Einsatzes die letzten 16 Monate (ja, so lange hat das gedauert!), haben wir die Treiber für alle verfügbaren DD Empfangskarten im Kernel integriert bekommen und wir brauchen keine inkompatiblen Spezialtreiber von DD selbst compilieren. Die DD Karten funktionieren zusammen mit allen im Kernel unterstützten Karten, was die original DD Treiber nicht hergeben. Das haben schon einige Versucht, aber du hast es tatsächlich geschafft!

Nachdem DD deine Arbeit nicht fortsetzten wird, weil das hätten sie ja schon bisher tun können, wird es wohl beim jetzigen Stand bleiben, es sei denn es findet sich wieder jemand. Ich kann ein wenig beurteilen wie schwierig es ist so etwas zu stemmen, wenn man keine Datenblätter bekommt und sich alles aus dem Code und mit der Lupe auf den Karten selbst raus suchen muss. Ich behaupte mal, dein Wissen über diese Karten ist außerhalb von DD einzigartig, weshalb es auch schwierig wird einen Nachfolger zu finden.

Ich möchte noch erwähnen, dass der Grund für das Aufgeben der bisherigen Maintainer und da schließe ich DD jetzt mit ein, der schwierige media-tree Maintainer Mauro ist. Ich persönlich habe mit ihm zwar keine Probleme, aber sehr viele schon. Und dieser Maintainer, oder besser seine Art zu managen und Forderungen zu stellen, ist der eigentliche Grund für dieses Desaster.

Zitat von nst

@Moderatoren - Bitte am besten bei Gelegenheit den Thread zu machen.

Ich würde das nicht tun, weil vielleicht geht es ja weiter.

LG,

Jasmin

nst

Auch von mir vielen Dank für deine tolle Arbeit.

Ohne dich wären die Karten immer noch nicht im Kernel.

Bitte mache weiter, auch wenn es schwer fällt.

Thank´s

speed

Zitat von speed

Bitte mache weiter, auch wenn es schwer fällt.

Unter den gegebenen Umständen (primär Subsys-Maintainer, sekundär Digital Devices): Definitives Nein.

Schade, dass du hier aufhörst. Aber momentan ist die Situation Mega-Deluxe. Karte reinschieben, läuft! Ich verstehe nicht, warum DD die Integration in den Kernel nicht selbst vorantreibt. Eigentlich müsstest du mit diesem Wissen für DD arbeiten.

Vielen Dank für diese tolle Arbeit!

Gruß Hoppel

Zitat von hoppel118

Ich verstehe nicht, warum DD die Integration in den Kernel nicht selbst vorantreibt.

Tja, frag' das bei DD an. Wenn sie wollten, würden bzw. könnten sie das tun, entweder indem sie jemanden beauftragen oder einstellen, der sich Vollzeit mit dem Treiberstack und dem DVB Subsystem ausseinandersetzt und in sinnvoller Weise das Zeugs, was in dddvb drin ist, für jedermann verfügbar macht - dann wär die dddvb Krücke gar nicht notwendig. Aber mindestens rjkm, der AFAIK damals(tm) sogar LinuxDVB mit entworfen und gepusht hat, hat Null Interesse, das anzupacken (einer der Gründe möglicherweise der Maintainer). Davon ab würde das ganze noch 'ne ganz andere Zugkraft mitbringen, würde da jemand vom Hersteller committen, verglichen mit irgendeinem Privat-Individuum... Aber es ist, wie es ist.

Hint: Hauppauge baut auch ordentliche Multituner-TV-Karten, und da wird sich aktiv im Kernel drum gekümmert...

Hi!

Erstens macht den Linux Treiber nicht DD, sondern die Firma Metzler Brothers, Marcus und Ralph Metzler Systementwicklung GbR. Diese ist von DD beauftragt und meines Wissens nach hatten/haben der Windows und der Linux Treiber eine gemeinsame Code Basis, was eine Integration in den Kernel nicht leichter macht.

Und ja Ralph hat DVB mit ins Leben gerufen vor vielen Jahren. Ich bastle heute noch an Korrekturen in seinem Code, der im Grunde sehr gut ist.

Allerdings ist da dieser Kernel Maintainer Mauro Carvalho Chehab, der schon einige Entwickler vergrault hat. Oliver E., der Media-Build-Experimental, den Vorgänger meines Media-Build DKMS Paketes, gemacht hat, hat die Arbeit an den Treibern genau wg. Mauro aufgegeben. Und Mauro ist jetzt auch der Grund für das Aufgeben von Daniel.

Auf der anderen Seite verstehe ich Mauro auch, weil media-tree in der Zwischenzeit ca. 2780 Files enthält und das kann niemand mehr überblicken. Da bleibt dann schon mal was liegen. Was ich aber nicht verstehe ist, dass sich Mauro keine Hilfskräfte zulegt. Ich maintaine derzeit media-build, weil man mich gefragt hat ob ich das tun will. Genauso gibt es sicher viele Entwickler die Teile übernehmen könnten. Und ja, er hat schon Helfer, aber zu wenige. Vielleicht sollte ich da mal versuchen was auf der media-tree Liste anzufachen. Im Grunde ist das eine Sache des Vertrauens und wenn man Prozesse definiert dann könnten auch mehr Leute Schreibrechte in das Repo haben. ich darf jetzt auch meda-build beliebig verändern, tu das aber nur sehr gewissenhaft.

Und um noch eine andere Seite zu beleuchten, DD hat sicher eher weniger Kunden im Privaten Bereich, sondern mehr bei Hotel Systemen und Kopfstationen. Dort gibt es aber 100% DD Lösungen, deshalb ist die Interaktion mit anderen Karten für die Firma nicht so wichtig. Ein Schelm könnte meinen, dass eine Kombination mit anderen Karten unerwünscht ist. Sprich man könnte eine billige Tuner Karte von xyz mit einer CI Hardware von DD kombinieren und somit zu einer günstigeren Lösung kommen. Geht bei Treibern aus dem DD Repo schlicht nicht. Also könnte man davon auch ableiten, dass man Kunden verlieren würde, wenn man die Integration in den Kernel auch noch bezahlt und das würde keine Firma machen.

Ich sehe das zwar anders, aber die haben bei DD schon eine eigene Ansicht über Open Source und wie man damit umgeht, wie man an der neuesten Hardware auch sieht, wo die Steuerung der verschiedenen Komponenten vom FPGA aus gemacht wird und der Treiber nicht direkt den Demod oder Tuner oder was auch immer für einen Chip kontrollieren kann. Sprich man muss jetzt dann öfter FPGA Firmware tauschen. Treiber dieser Entwicklung war meiner Meinung nach eine Falsche Sichtweise auf Open Source und angebliche Lizenzbedingungen.

Andere Hersteller und auch ich sehen da eher die Vorteile von Open Source und einige Fehler in den DD Treibern wurden von Daniel währen der Portierung gefunden. Immer wieder finden andere jetzt noch Dinge in dem Code. Davon profitiert die Qualität der Linux Treiber und das ist eine der Stärken von Open Source. Diese Sichtweise ist aber in der Möwestrasse in München noch nicht angekommen. Schade, weil die Hardware von DD ist wirklich gut und modular und kann mittlerweile auch schon DVB S2X. Und die Firma ist in Deutschland und nicht in Fernost, also ist die Kommunikation besser und auch die Wertschöpfung bleibt in Europa. Alles gute Gründe Karten von DD zu verwenden, aber das Drumherum macht es eben nicht einfach.

Um nochmals auf die Entscheidung von Daniel zurück zu kommen, ich habe das so verstanden, dass er das ev. dann wieder machen würde, wenn nicht immer so viel Zeit bei Antworten des Maintainers vergehen würden, weil er diese Tätigkeit auch gerne gemacht hat. In dem Sinne könnte man mit Sub-Maintainern eben kürzere Antwortzeiten erreichen. Vielleicht kommt es ja in den nächsten Wochen zu einer sinnvollen Diskussion auf der Mailingliste.

LG,

Jasmin

Zitat von jasminj

Auf der anderen Seite verstehe ich Mauro auch, weil media-tree in der Zwischenzeit ca. 2780 Files enthält und das kann niemand mehr überblicken. Da bleibt dann schon mal was liegen.

Meine Meinung dazu: Unsinn!

Das Problem ist nicht die Größe der Aufgabe, sondern die Unfähigkeit des Maintainers. Wenn man viel Zeit fuer Patches in fremden Subsystemen hat, aber nach eigener Aussage die APIs nicht versteht, von denen man selbst Maintainer ist, dann gibt es da fuer mich keinerlei Entschuldigung. Aber wenn man alle anderen Entwickler vergrault hat, kann man sich eben "gefahrlos" fuer einen ach-so-komplizierten Maintainer-Job bezahlen lassen, ohne diesen Job auch im Sinne der Community auszufuellen.

Zitat von jasminj

Vielleicht kommt es ja in den nächsten Wochen zu einer sinnvollen Diskussion auf der Mailingliste.

Da bin ich ja wirklich mal gespannt. Es gibt leider keinerlei MIttel, einen Maintainer zu sinnvollem Arbeiten zu zwingen. Und Mauro macht nach einigen Wutanfaellen von Linus lieber gar nichts mehr, als etwas wieder falsch. Und das waere leider das Einzige, was ihm gefaehrlich werden koennte.

Alles nur meine persoenliche Meinung nach ebenfalls vielen langen ermuedenden und fruchtlosen Diskussionen.

Gruss,

S:oren