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

Zitat von mini73

Den Thread muss ich jetzt erst mal lesen.

Der Gute Maik wird gerade vom Mauro ganz schön getadelt. Von wg. Codingstyle und zu großer Patch und ... .
Genau das ist leider das Problem, wenn man so lange nicht in den Main Tree merged. Ob er den Treiber so wie er ist rein bringen wird weiß nicht. Er ist anscheinend auch alleine unterwegs und auf der Mailing Liste müsste ihn Ralph unterstützen.

Zitat von rjkm

Bzgl. Coding-Style habe ich mir auch Mühe gegeben jetzt immer alles einzuhalten. Es können an ein paar Stellen noch ein paar Spaces fehlen aber weitesgehend sollte alles stimmen.

Da gibt es im Kernel Tree unter Scripts einen Lintend Aufruf, der alles auf Kernel Style umbaut. Man muss dann nur noch wenig nacharbeiten. Habe ich für einen Treiber schon mal benutzt. Man Kann Lintend mit Source Annotations steuern, damit es nicht alles immer verdreht, wenn man es öfter drüber laufen lässt, nach manuellen Änderungen. Außerdem gibt es auch ein Kernel Coding Style Check Script.
Nachdem Maik aber bereits angefangen hat daran zu werkeln, würde ich jetzt mal keinen Aufwand investieren. Ev. kannst du dich mit ihm ja zusammen reden. Generell halte ich den Ansatz den derzeitigen Treiber so wie er ist in den Kernel bekommen zu wollen für sehr schwierig. Denke da nur an die API Erweiterung bez. des Block Modes im CAM Protokolltreiber. Das hätte ich anders gelöst um das API nicht zu brechen. Es ist einfach zu viel auf einmal und das hat Mauro auch schon gesagt und ich sehe das genauso.

Zitat von rjkm

Inzwischen habe ich das "ci"-Device eingeführt, um Daten an ein CI zu schickt und wieder abzuholen. Das sollte also eigentlich kein Problem mehr sein.

Es wird Zeit, dass meine Kiste endlich geht und ich mir das alles im Detail anschauen kann.

Zitat von rjkm

... Teilweise behandeln sie auch Sachen wie Kalibrierung, spur-detection, Master/Slave-Version, etc. besser bzw. überhaupt.

Schön langsam versteh ich, warum du das nicht in den Kernel mergen wolltest. Jetzt ist Maik aber dran und wenn wir das nicht jetzt alle gemeinsam stemmen, dann war es das wieder ... .

Zitat von rjkm

Bzgl. Kernel-Integrierung und der neuen Directory-Struktur müßte der Teil aber in das platform-Verzeichnis, ddbridge in pci, der Rest (ddbridge-core) in common? Viel Spaß ...

Das müsste man Maik sagen und wahrscheinlich auch supporten. Ich denke das ist alles zu viel für eine Person, ohne das Know How von dir.

Zitat von rjkm

Allgemein kann man alle Files aus dddvb einfach an die richtigen Stellen im Kernel-Tree kopieren und es läuft ohne Probleme. Man müßte dann "nur" noch die "dd"-Treiber mit den existierenden mergen, ein diff machen und das an die PTB füttern. Aber das ist halt der nervige Teil.

Genau den weg geht aber Maik nicht, oder?
Es ist scheiße, dass das jetzt so unkoordiniert passiert ist!
Vielleicht solltest du ihm das wichtigste aus deinem Post hier schreiben. Wenn Copperhead die Arbeit im Prinzip schon gemacht hat, wie Gerald geschrieben hat, dann ist das vielleicht der einfachere Ansatz.

Zitat von jasminj

Vielleicht solltest du ihm das wichtigste aus deinem Post hier schreiben. Wenn Copperhead die Arbeit im Prinzip schon gemacht hat, wie Gerald geschrieben hat, dann ist das vielleicht der einfachere Ansatz.

Was Copperhead nicht berücksichtigt hat, ist die Unterstützung unterschiedlicher Kernel-Versionen. Das ist natürlich für die Idee es upstream zu bekommen irrelevant, aber für die Benutzung in einem DKMS zwingend.
Für mich ist eben das DKMS wichtiger, weil wir sofort etwas davon hätten und nicht irgendwann einmal.

Gerald

Zitat von jasminj

Der Gute Maik wird gerade vom Mauro ganz schön getadelt. Von wg. Codingstyle und zu großer Patch und ... .
Genau das ist leider das Problem, wenn man so lange nicht in den Main Tree merged. Ob er den Treiber so wie er ist rein bringen wird weiß nicht. Er ist anscheinend auch alleine unterwegs und auf der Mailing Liste müsste ihn Ralph unterstützen.

Nunja damit kann ich erstmal leben, ich wollte explizit ja Feedback haben, was ich alles noch ändern muss. Ich hab den Treiber von Ralph erstmal genommen und ihn so umgebaut, dass er mit dem aktuellen v4l/dvb media-tree läuft. Den Coding Style hab ich dabei bewusst erstmal ignoriert. Das kommt aber mit der nächsten Patchserie.

Zitat von jasminj

Das müsste man Maik sagen und wahrscheinlich auch supporten. Ich denke das ist alles zu viel für eine Person, ohne das Know How von dir.

Generell bin ich hier offen. Ich halte mich da gern an die Struktur die der Kernel für media/ vorgibt.

Zitat von jasminj

Genau den weg geht aber Maik nicht, oder?
Es ist scheiße, dass das jetzt so unkoordiniert passiert ist!
Vielleicht solltest du ihm das wichtigste aus deinem Post hier schreiben. Wenn Copperhead die Arbeit im Prinzip schon gemacht hat, wie Gerald geschrieben hat, dann ist das vielleicht der einfachere Ansatz.

Das hat im ersten Versuch so nicht ganz funktioniert, ich hab das zwar letzte Woche getestet, aber musste dann doch einiges ändern, damit das mit v4l/dvb läuft und auch die anderen Treiber dennoch kompilieren. Ich hab in meinem Patchset auch erstmal Octonet und DVB Netstream entfernt, denn das ist wirklich zuviel auf einmal.

Generell ist mein Ziel den aktuellen ddbridge Treiber in den offiziellen media-tree zu bekommen so daß er im Stock Kernel landet. Das ist aber keine Sache die in 1-2 Wochen erledigt ist, denn die Änderungen zwischen dem derzeitige 0.5 im Kernel und 0.9.10 von Ralph sind schon riesig. Zuerstmal werde ich jetzt CXD2843 aufbereiten und neu and die ML schicken mit Lösungen zu den Punkten die Mauro angesprochen hat.

Zitat von putty12

Habe eine DD Octopus V3 zusammen mit einer DuoFlex C/T/T2 (v3) erworben und bisher unter Linux (3.7.11 / 3.11.x) kein Glück gehabt. Nach der SelbstBuild Anleitung verstand mein Linux wenigstens die Octopus V3 (wegen DeviceID=x05)...aber ansonsten zeigt das Log nur:
Port 0 (TAB 1): NO MODULE
Port 1 (TAB 2): NO MODULE
Port 2 (TAB 3): NO MODULE
Port 3 (TAB 4): NO MODULE

Langer Rede, kurzer Sinn: wenn ich irgendwie beitragen kann die DuoFlex v3 zum Laufen zu bringen würde mich das freuen. Allerdings bin ich kein Programmierer (also nicht auf der x86 Plattform).

Grüße
putty

Alles anzeigen

Ich hatte mit der v3 und den "offiziellen" Treibern bislang ähnliche Ergebnisse. Probier aber einfach 'mal Ralph's dddvb aus (das habe ich auch eben erst gemacht). Bei mir werden damit die TABs der "Octopus Twin CI" inkl. 2x"DuoFlex v3" korrekt erkannt. Installiert habe ich die Treiber auf kernel 3.8 einer Ubuntu 12.04. Ich mußte lediglich im Kernel-Makefile die Modulsignatur für externe Builds ausschalten und /lib/modules/*/updates auf extra verlinken, um die entsprechenden DVB-Module der Ubuntu zu überladen. Über's Wochenende hatte mich schon fest dazu entschlossen, die v3 morgen zurückzuschicken und sie gegen v2 umzutauschen...

Gruß,
STYLON

Zitat von mbroemme

Nunja damit kann ich erstmal leben, ich wollte explizit ja Feedback haben, was ich alles noch ändern muss. Ich hab den Treiber von Ralph erstmal genommen und ihn so umgebaut, dass er mit dem aktuellen v4l/dvb media-tree läuft. Den Coding Style hab ich dabei bewusst erstmal ignoriert. Das kommt aber mit der nächsten Patchserie.

Generell bin ich hier offen. Ich halte mich da gern an die Struktur die der Kernel für media/ vorgibt.

Das hat im ersten Versuch so nicht ganz funktioniert, ich hab das zwar letzte Woche getestet, aber musste dann doch einiges ändern, damit das mit v4l/dvb läuft und auch die anderen Treiber dennoch kompilieren. Ich hab in meinem Patchset auch erstmal Octonet und DVB Netstream entfernt, denn das ist wirklich zuviel auf einmal.

Generell ist mein Ziel den aktuellen ddbridge Treiber in den offiziellen media-tree zu bekommen so daß er im Stock Kernel landet. Das ist aber keine Sache die in 1-2 Wochen erledigt ist, denn die Änderungen zwischen dem derzeitige 0.5 im Kernel und 0.9.10 von Ralph sind schon riesig. Zuerstmal werde ich jetzt CXD2843 aufbereiten und neu and die ML schicken mit Lösungen zu den Punkten die Mauro angesprochen hat.

Alles anzeigen

Hey, as I mentioned in the original driver thread, where this one forked from, have patched in the 0.8 ddbridge driver (copied it over the 0.5 driver currently in the kernel and removed some headers for hardware that caused compile issues and I didn't have anyway). This has been working quite well for a few months now on my Gentoo 3.11 kernel. I haven't tried the same with 0.9.10 but expect it to work the same, do you have these sources or did you use Oliver's sources? Do you have a git-tree somwhere so I can pull those drivers and start testing it?

I'm glad someone is picking up on this, I mentioned it in the previous thread aswell, that I would be willing to start this undertaking, but some things needed to happen first and my plate is more then full as it is atm

Having read Mauro's comments, they are all very reasonable. Maybe mentioning beforehand that this would be a RFC more then a patch would have helped a little

I may have a few hours to do some coding style if you have a public git tree somewhere.

oliver

Hallo STYLON,
hatte am WE, nach dem Hinweis in diesem Thread, das dddvb selbst compiliert und siehe da: es läuft. Ich denke mir bei sowas nur: warum stellt der Hersteller das nicht von sich aus bereit und kümmt sich darum das in den Kernel reinzubekommen ? Oder wirft zumindest auf seiner Homepage einen entsprechenden Link in die richtige Richtung. Ohne den Tipp von rjkm würde die Karte bis heute noch schweigen. Unter opensuse 12.3 bzw. 13.1 RC war nur make && make install notwendig + einmal reboot.

Völlig Offtopic: Hast du ´n Tipp für ein griffiges Headless-VDR-Howto. Habe schon diverse Dokus vom vdr-wiki gelesen und igendwie....´s läuft nicht. So ohne Display wird das mit dem OSD nix.

Grüße
putty

Zitat von putty12

Völlig Offtopic: Hast du ´n Tipp für ein griffiges Headless-VDR-Howto. Habe schon diverse Dokus vom vdr-wiki gelesen und igendwie....´s läuft nicht. So ohne Display wird das mit dem OSD nix.

Richtig, völlig off topic, richtig ohne Display wird es kaum ein OSD geben, aber wozu denn auch? Es gibt doch das Live-Plugin und zur Not reicht auch dort das OSD bei der Fernbedienung.

Warum quotest du diese ganzen Blöcke ohne explizit darauf einzugehen?

Gerald

Hallo Gerald,
zum Einen steht der Rechner mit den Karten weit weg....und der Zugriff darauf soll nur per vnc, oder vlc oder einem sonst tauglichen Produkt/Protokoll funktionieren zum Anderen war ich offensichtlich nicht in der Lage den Editor ordnungsgemäß zu bedienen. Ich gelobe Besserung und habe den alten Post um die überflüssigen Zitate bereinigt.

Grüße putty

Zitat von putty12

Ich denke mir bei sowas nur: warum stellt der Hersteller das nicht von sich aus bereit und kümmert sich darum das in den Kernel reinzubekommen ?

Schau mal, DD ist eine Hardware Firma und baut wirklich gute Karten. Für Windows einen Treiber zu bauen ist nicht so schwierig, weil da die Schnittstellen gut definiert und mehr oder weniger stabil sind. Als Entwickler schreibst einen Treiber und gut ist es.
Unter Linux ist das alles schwieriger, weil bei Linux viele Köche mitarbeiten und du auf globale Schnittstellen aufsetzen musst. Das macht es einerseits einfacher einen Treiber zu schreiben und generische Funktionen zu bemühen, andererseits ist es schwieriger Erweiterungen durchzubringen, weil das alles abgesegnet sein will und keine anderen Treiber lahmlegen sollte. Außerdem ist es schwieriger Betriebsgeheimnisse zu wahren und teilweise untersagen dir manche Chiphersteller die Chip Internas zu veröffentlichen, was bei einem Treiber der in Source vorliegt, gar nicht so einfach, bis unmöglich ist.

Im speziellen Fall kommt auch noch ein unmöglicher Kernel Maintainer dazu, der sich zwar schon gebessert hat, aber in der Vergangenheit so manchen Entwickler so frustriert hat, dass er auf den Stock Kernel scheißt und seine eigene Version herausbringt. Das ist auch OK solange man nur Karten eines Herstellers benutzt. Sprich, wenn du nur Karten von DD verwendest, spricht gar nichts dagegen einfach das Treiberpaket von Ralph zu compilieren und zu verwenden. Und ja, hier hätte es DD eventuell den Anwendern einfacher machen können, indem man nicht nur die Sourcen, sondern ein DKMS Paket zur Verfügung stellt. Allerdings muss man das auch warten, wenn ein neuer Kernel heraus kommt und etwas nicht mehr compiliert.
Hier hat die Arbeit eben nicht DD sondern Gerald für die yavdr Distribution gemacht.

DD unterstützt die freiwilligen Entwickler mit HW Leihgaben. Andere Hersteller rücken nicht mal Datenblätter raus, damit man als Entwickler einen Treiber schreiben kann. Also bitte nicht immer auf DD hinhacken!

So und nun genug OT!

Es tut sich endlich was. Es wird zwar noch ein paar Wochen dauern bis alles im Kernel drinnen ist, aber ich denke Mike schafft das und ich denke auch, Ralph wird Mike unterstützen.

Hallo,
danke für die vielen Worte zum Verständniss. Nicht immer liegts an der Technik sondern oft an den Menschleins und dem Miteinander. Offenbar ist das mit der Kernel Treiber Entwicklung doch nicht so einfach wie gedacht.
Mal schau´n wie´s wird.
Grüße putty

Hi,

Zitat von putty12

Völlig Offtopic: Hast du ´n Tipp für ein griffiges Headless-VDR-Howto. Habe schon diverse Dokus vom vdr-wiki gelesen und igendwie....´s läuft nicht. So ohne Display wird das mit dem OSD nix.

ich muß da leider passen. Bei mir nutze ich das ganze bislang nur in der Kombination xbmc + vdr als TV-backend und für's gelegentliche TV-Schauen remote langte mir bislang die Oberfläche von vdradmin bzw. istreamdev für mein ipad :-). Naja, und die Umstellung von 2xAnalog MPEG-HW-Encoder nach 4xDVB-C war schon längst überfällig.

Ich kann und will mich hier auch gar nicht groß beklagen. Ihr seid ja genau die Fleißigen, dem DD ein großes Maß an Linuxruf zu verdanken hat. DD muß man aber anlasten, daß es zur hohen Qualität der Hardware durchaus paßt, wenn auch nur ein Hauch mehr Informationen zu aktuellen Linuxtreibern auf der Webseite stünden. Z.B. steht bei mir auf der Verpackung der DuoFlex C/T als erster Eintrag unter "Unterstützte Betriebssysteme": "Linux (ab Kernel 2.6.34)". Ein Link hier zu einer Webseite auf der einfach nur eine Linksammlung gepflegt wird, ist auch von DD nicht zuviel verlangt. Den Rest (Probieren von verschiedenen Versionen, Compilieren, Patchen) verlangt ja keiner und ist man als Linuxianer auch gewohnt.

Gruß,
STYLON

Zitat von stylon

Ein Link hier zu einer Webseite auf der einfach nur eine Linksammlung gepflegt wird, ist auch von DD nicht zuviel verlangt. Den Rest (Probieren von verschiedenen Versionen, Compilieren, Patchen) verlangt ja keiner und ist man als Linuxianer auch gewohnt.

NEIN! Da muss ich ganz ehrlich sagen, dass ich als "Linuxianer" mittlerweile gewohnt bin, meine Hardware einfach einzubauen und zu nutzen.

Statt eine Linkliste anzubieten wäre aktives Vorantreiben einer Integration des Treibers in den Kernel viel sinnvoller.

Zitat von mini73

Für die Ubuntu/yaVDR-Nutzer hat Gerald netterweise mal den Original dddvb-0.9.10 in ein DKMS-Paket verpackt:
https://launchpad.net/~yavdr/+archive/un…g-archive-extra

Na ja, die wesentliche Arbeit kommt von Lars. Aktuell wissen wir nur, dass das Paket gegen einer 3.8er Kernel baut. Es wäre gut zu wissen ob es auch mit dem 3.2er und dem 3.5er klappt.

Gerald

Zitat von Mreimer

Statt eine Linkliste anzubieten wäre aktives Vorantreiben einer Integration des Treibers in den Kernel viel sinnvoller.

Das funktioniert so aber nicht immer. Die meisten Hersteller entwickeln ihre Treiber erstmal unabhängig vom Upstream Kernel und wollen dann Ihren fertigen Treiber direkt in die nächste Kernelversion bekommen. Nur so funktioniert das leider nicht, zwischen Ersteinreichung und Upstream Kernel vergehen bei aktiver Mitarbeit schonmal 3-4 Kernel Versionen was dann etwa 6-8 Monate entspricht. Den Aufwand scheuen einfach viele Unternehmen. Die 6-8 Monate kosten Geld ohne nennenswertes Ergebnis und danach muß man den Treiber auch weiterpflegen. Ich fang aber gerade mit DDBridge an und erwarte selber, dass es einige Versionen dauert bis das fertig ist. Vermutlich wird es einfacher es Stück für Stück einzureichen und nach jedem ACK für Upstream fortzufahren. Ich hab leider nur ein paar DD Devices vorrätig und teste meine Änderungen schon gerne vorher mit echter Hardware. Derzeit sitze ich daran den Upstream DDBridge Treiber soweit zu ändern (ggf. auch den STV0367 Treiber) damit beide zusammenarbeiten und STV0367DD nicht mehr benötigt wird.

Mal eine kleine Zwischenfrage:

Wie siehts denn mit dem ngene Treiber aus? Ist der im Kernel schon aktuell bzw. aktuell genug, dass alles läuft.

Zitat von Copperhead

Wie siehts denn mit dem ngene Treiber aus? Ist der im Kernel schon aktuell bzw. aktuell genug, dass alles läuft.

Mein Micronas Semiconductor Holding AG nGene PCI-Express Multimedia Controller (rev 01), Subsystem: 18c3:dd20 läuft mit den Kernel-Treibern IIRC seit Kernel 3.8

Gut zu wissen. Danke.

Jetzt würde ich mir nur noch Zugang zu Maik Broemme Git Repo wünschen. Also lesend versteht sich.