Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

Aribaaaa!

I went for a NEW and BRAND clean Ubuntu 12.04.3 install since my tests so far has been experimental to learn about Ubuntu, XBMC and other media/PVR-related stuff under Linux.

And you know what..... UFO! Your driver works now and loads properly!!

dmesg | grep -i ddb shows now the following:

[ 2.555903] ngene-octopus-test: 406ffecccbec6e22da954a07b7398292330bc767 ddbridge: Add ID of Digital Devices Octopus V3.
[ 2.561690] DDBridge driver detected: Digital Devices Cine S2 V6.5 DVB adapter
[ 2.561776] DDBridge 0000:03:00.0: irq 44 for MSI/MSI-X
[ 2.566954] DVB: registering new adapter (DDBridge)
[ 2.566959] DVB: registering new adapter (DDBridge)
[ 2.566960] DVB: registering new adapter (DDBridge)
[ 2.566962] DVB: registering new adapter (DDBridge)
[ 2.785771] DDBridge 0000:03:00.0: DVB: registering adapter 0 frontend 0 (STV090x Multistandard)...
[ 2.820757] DDBridge 0000:03:00.0: DVB: registering adapter 1 frontend 0 (STV090x Multistandard)...
[ 2.976587] DDBridge 0000:03:00.0: DVB: registering adapter 2 frontend 0 (STV090x Multistandard)...
[ 3.012576] DDBridge 0000:03:00.0: DVB: registering adapter 3 frontend 0 (STV090x Multistandard)...

This is so nice to see!

Now I´ll spend some more hours on the remaining and (easy) part...

Zitat von UFO

Laut depmod-Doku haben Module unter 'updates' standardmäßig Vorrang vor den normalen Kernel-Modulen.

Exakt, so macht es dkms auch.

Zitat von UFO

Ich hoffe, daß dies bei allen Distributionen so funktioniert.

Sollte kein Problem sein. dkms benutzt das install target nicht und holt sich die Module selbst aus dem Build-Verzeichnis.

Gerald

Is new CT extension working on media_build_experimental drivers?

It looks like octopus V3 and S2 cards are working, but CT card is not.

Any ideas?

Zitat von 10robinho

Is new CT extension working on media_build_experimental drivers?

It looks like octopus V3 and S2 cards are working, but CT card is not.

Any ideas?

I have this problem also.
I origily had an Cine C/T card, ordered 3 weeks ago and working ok.
I added an Duoflex C/T (DVB T2) .
Now only CIne C/T is working, no trace in other card in dmesg.
Using the self build driver on fedora core 18.
So i think your problem is confirmed.

UFO
Hallo Oliver,

ich habe da mal eine Frage.

Gibt es Pläne die Treiber für die Cine CT in das offizielle Linux Kernel Repository zu überführen?
Falls ja, wann kann man damit frühestens rechnen und falls es technische Schwierigkeiten gibt, worin bestehen die Schwierigkeiten?

Zitat von Salami

Gibt es Pläne die Treiber für die Cine CT in das offizielle Linux Kernel Repository zu überführen?

Lies mal diese Posts:
hier und hier.
Es gibt noch mehr in diesen Thread zu dem Thema. Musst nur suchen.

Zitat von Salami

Falls ja, wann kann man damit frühestens rechnen und falls es technische Schwierigkeiten gibt, worin bestehen die Schwierigkeiten?

Soweit ich das beurteilen kann, sind es kaum technische Gründe, sondern eher Zeitmangel der freiwilligen und Frustration der Beteiligten.

LG
Jasmin

Problem ist nur, dass es einem außenstehenden schwer fallen wird die relevanten Änderungen so gegen den aktuellen LinuxTV-Stand zu mergen, dass etwas sauberes dabei herauskommt.

Und wenn die Patches dann nicht direkt angenommen werden, steht ein außenstehender endgültig zwischen den Stühlen, denn die Änderungen, die dann gemacht werden, um das Zeug akzeptiert zu bekommen, kriegt man ja dann wieder nicht mehr zurück zum eigentlichen Entwickler.

Der einzig richtige Weg wäre aber, die Treiber irgendwie in den Kernel zu bekommen. Das letzte Mal habe ich mich aktiv um Treiber-Installation gekümmert als ich noch Windows genutzt habe. Eigentlich sehe ich es gerade als einer der großen Vorteile von Linux an, dass eine aktuelle Distribution mit fast allem, was man im Alltag an Treibern braucht, geliefert wird.

Ich habe für meinen neuen VDR auf jedem Fall bewusst die ältere CineS2 gekauft. Weil dort der Treiber im Kernel ist.

Ja, das wäre wirklich schön, wenn der Treiber im Kernel wäre. Es muss sich nur ein Freiwilliger finden.

Für die CTv6 und das CI hab ich Hardware zum Testen da (ddbridge). Wenn mir jemand erklärt, wie ich am besten das aktuelle linux-media unter Ubuntu übersetze und welche Dateien für diese Karte zuständig sind, werde ich in absehbarer Zeit mal einen Versuch wagen. Ganz alleine schaffe ich es aber nicht, weil ich mich noch nie mit Kernel-Treibern auseinandergesetzt habe.

Zumindest könnte ich testen, wenn jemand Patches erstellt.

Lars.

Optimum wäre, wenn das jemand macht, der auch die Hardware hat. Damit auch ein entsprechender Ansporn da ist. Ich habe mich diesem Problem durch die Wahl der älteren Karte ja erfolgreich entzogen.

Den entsprechenden GIT Tree würde ich erstellen. An die LKML muss sich aber jemand anders wenden. Das will ich nicht machen.

Ok, Angebot:
Lass uns mal einen neuen Thread aufmachen, indem wir das besprechen. Ich kann bei der CTv6/DDBridge und dem CI helfen/testen.
Genaugenommen habe ich ein Dual-CI mit DDBridge, an der ein CT-FlexModul hängt.

Ich übernehme dann die linux-media Mailingliste.

Lars.

Hier geht's weiter:
Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren

Lars.

jasminj

Danke für den Hinweis auf die Links.

Zitat von Mreimer

Optimum wäre, wenn das jemand macht, der auch die Hardware hat.

Warum macht das eigentlich nicht DD, der Hersteller?
Mit Linux Support werben sie ja, da könnten sie ja durchaus einen Entwickler anstellen, der das Zeugs in den Kernel merged.

Zitat von Mreimer

Der einzig richtige Weg wäre aber, die Treiber irgendwie in den Kernel zu bekommen. Das letzte Mal habe ich mich aktiv um Treiber-Installation gekümmert als ich noch Windows genutzt habe. Eigentlich sehe ich es gerade als einer der großen Vorteile von Linux an, dass eine aktuelle Distribution mit fast allem, was man im Alltag an Treibern braucht, geliefert wird.

Ich bin ganz deiner Meinung.
Was aber noch dazu kommt ist, das ich bei meiner letzten Installation eines Media Build Zweigs den kompletten Ordner ersetzen musste* und jetzt stelle man sich mal vor, es gibt zwei verschiedene Hersteller, die zwei Produkte haben, die ebenfalls zwei eigene Quellcodezweige haben und erwarten, dass man die irgendwo in das lib/modules/.... Verzeichnis packt und jeder von denen besteht darauf, dass man den Originalcode aus dem Weg räumt. Dann ist es praktisch für Laien ausgeschlossen, dass sie beide Karten gleichzeitig zum Laufen bekommen können.

* Wie ich gelesen habe, soll das nun ab jetzt ja nicht mehr nötig sein, das ist eine gute Entwicklung.

Auch hoffe ich jetzt mal, das solche Außerkernelentwicklungen nicht zum Profilieren benutzt werden, sondern wirklich technische Gründe wie ständig sich ändernde ABIs dahinterstecken, denn so etwas habe ich schon bei einem anderen Open Source Projekt erlebt.
Ein einzelner Entwickler hatte das Gefühl, dass er großen Projekt untergeht und deswegen lagerte er seine Arbeit aus, mit einer schönen Webseite, damit jeder sehen konnte was ER gemacht hat um von der Community Ansehen und Anerkennung zu gewinnen.
Ich denke solche Entwicklungen schaden nur einem Projekt als Ganzes. Ich gehe jetzt mal nicht davon aus, dass das hier der Fall ist, ich erwähne es nur mal der Vollständigkeit halber.

Moin!

Klar ist das Submitten nur der Anfang, dass der Treiber dann auch noch gepflegt werden muss, steht außer Frage. Ich mache aber gerne einen Schritt nach dem anderen, wenn der Treiber erst mal upstream ist, kommen vielleicht ja auch andere auf die Idee, da mitzumachen. Ich würde erst mal gerne die Anfangshürde nehmen wollen. Als regelmäßiger Leser der linux-media-ML weiß ich, wie nervig der Umgang mit den Maintainern da ist...

Wenn es ok ist, dann löchere ich dich mit ein paar Fragen, damit ich starten kann.

Folgende Hardware habe ich:

04:00.0 Multimedia controller: Digital Devices GmbH Octopus CI DVB Adapter
        Subsystem: Digital Devices GmbH Octopus CI
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 47
        Region 0: Memory at febf0000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [70] MSI: Enable+ Count=1/2 Maskable- 64bit+
                Address: 00000000fee0300c  Data: 4182
        Capabilities: [90] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 <1us
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Range A, TimeoutDis+
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB
        Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=00c <?>
        Kernel driver in use: DDBridge
        Kernel modules: ddbridge

Das ist ein Dual-CI mit Bridge, daran hängt ein (älteres) Flex-Modul CT mit zwei Eingängen.
Anscheinend sind folgende Module dafür geladen:
ddbridge, cxd2099, drxk und tda18271c2dd

In einem anderen vdr hab ich aber auch noch eine normale DDBridge mit zwei neueren Flex-Modulen (die mit einem Eingang für beide Tuner).

04:00.0 Multimedia controller: Digital Devices GmbH Octopus LE DVB adapter
        Subsystem: Digital Devices GmbH Device 0002
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 50
        Region 0: Memory at fe200000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [70] MSI: Enable+ Count=1/2 Maskable- 64bit+
                Address: 00000000fee0300c  Data: 41b9
        Capabilities: [90] Express (v1) Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 <1us
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
        Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=00c <?>
        Kernel driver in use: DDBridge
        Kernel modules: ddbridge

Statt drxk und tda18271c2dd sind da stv0367dd und tda18212dd geladen.

Ich vermute mal, die entsprechenden Patches für diese Treiber finde ich in deinem Repository im Verzeichnis "experimental", richtig?
Gibt es sonst noch etwas wichtiges, das ich wissen muss, bevor ich mir den Source ansehe und verstehen lerne, was da nötig ist, um das zusammen zu bringen?

Vielen Dank!

Lars.

Zitat von Salami

Was aber noch dazu kommt ist, das ich bei meiner letzten Installation eines Media Build Zweigs den kompletten Ordner ersetzen musste ...

Zitat von Salami

Auch hoffe ich jetzt mal, das solche Außerkernelentwicklungen nicht zum Profilieren benutzt werden...

Salami: Wuerdest Du bitte diese unterschwelligen Vorwuerfe unterlassen. Die sind - meiner Meinung nach - hier ueberhaupt nicht angebracht. Wir sollen im Gegenteil dankbar sein, dass UFO hier getestete und gut funktionierende Treiber zur Verfuegung stellt, die auch noch mit einer einfach benutzbaren Build-Umgebung daher kommen.

Ich habe so das Gefuehl, viele an dieser Diskussion Beteiligte haben ueberhaupt keine Ahnung, wie die Entwicklung von linux-media-Treibern laeuft. Die Entwicklung parallel zum mainline-Kernel (im media-build-Repository auf linuxtv.org) ist das offizielle Vorgehen der media-Maintainer, das Austauschen aller Kernel-Module unterhalb von drivers/media ist somit auch der offizielle Weg zu Entwicklung und Test von media-Treibern. Das hat ueberhaupt nichts mit Profilierung zu tun. Der Vorteil dieses Vorgehens ist, dass man auch fuer altere Kernel-Versionen die neuesten media-Treiber bauen und integrieren kann, der Nachteil ist, dass man als unabhaengiger Entwickler mindestens 2 Kernel-Versionen braucht, um Patches ins mainline-linux integriert zu bekommen. Wenn ein Maintainer also mal einen Treiber "kaputtgespielt" hat (was leider in letzter Zeit immer mal wieder vorgekommen ist und auch Kritik von verschiedenster Seite eingebracht hat), dann hat man als Entwickler quasi keine Chance, diesen Bug in angemessener Zeit zu fixen. Auch eine zeitnahe Weiterentwicklung des Treibers im mainline-Linux ist quasi unmoeglich.

Zitat von mini73

Gibt es sonst noch etwas wichtiges, das ich wissen muss, bevor ich mir den Source ansehe und verstehen lerne, was da nötig ist, um das zusammen zu bringen?

Hochachtung dafuer, dass Du Dir diesen Job "aufhalsen" willst.

Mein Tipp: das meiner Ansicht nach Wichtigste ueberhaupt ist, einen der 9 media-Maintainer fuer dieses Projekt zu gewinnen. Ohne direkten Ansprechpartner und "Gateway" zu media-build werden Deine Patches ewig in patchwork.linuxtv.org abliegen. (Dazu mal ein Beispiel: mein letzter media-Patch - quasi ein Einzeiler, der ein Kernel-Ooops fixt und es sogar wert war, in alle stable-Kernel uebernommen zu werden - hat rund drei Monate gebraucht, bis er im mainline angekommen war. Dass es in Linux auch anders gehen kann, beweist mein letzter Patch fuers usb-Subsystem, der war innerhalb von einem Tag in linux-next.)

Gruss,
S:oren

Zitat von S:oren

Salami: Wuerdest Du bitte diese unterschwelligen Vorwuerfe unterlassen. Die sind - meiner Meinung nach - hier ueberhaupt nicht angebracht.

Unterschwellig ist nur was du daraus machst, ich habe nichts dergleichen behauptet und es wie ich bereits schrieb dies nur der Vollständigkeit halber dazugeschrieben und es auch nicht hier auf diese Treiber hier bezogen. Punkt.

Zitat

Ich habe so das Gefuehl, viele an dieser Diskussion Beteiligte haben ueberhaupt keine Ahnung, wie die Entwicklung von linux-media-Treibern laeuft. Die Entwicklung parallel zum mainline-Kernel (im media-build-Repository auf linuxtv.org) ist das offizielle Vorgehen der media-Maintainer, das Austauschen aller Kernel-Module unterhalb von drivers/media ist somit auch der offizielle Weg zu Entwicklung und Test von media-Treibern. Das hat ueberhaupt nichts mit Profilierung zu tun. Der Vorteil dieses Vorgehens ist, dass man auch fuer altere Kernel-Versionen die neuesten media-Treiber bauen und integrieren kann, der Nachteil ist, dass man als unabhaengiger Entwickler mindestens 2 Kernel-Versionen braucht, um Patches ins mainline-linux integriert zu bekommen. Wenn ein Maintainer also mal einen Treiber "kaputtgespielt" hat (was leider in letzter Zeit immer mal wieder vorgekommen ist und auch Kritik von verschiedenster Seite eingebracht hat), dann hat man als Entwickler quasi keine Chance, diesen Bug in angemessener Zeit zu fixen. Auch eine zeitnahe Weiterentwicklung des Treibers im mainline-Linux ist quasi unmoeglich.

Danke für die Aufklärung, aber wenn dem so ist und das media-build Repo der offizielle Entwicklungszweig der TV Sachen im Linux Kernel ist, und der Zweig des Linux Kernels nur das "stable" Zeugs hat, wieso gibt es dann im mainline Kernel API und ABI Brüche wie es Oliver hier erwähnt hat:
Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

Zitat von Salami

aber wenn dem so ist und das media-build Repo der offizielle Entwicklungszweig der TV Sachen im Linux Kernel ist, und der Zweig des Linux Kernels nur das "stable" Zeugs hat,...

Ich weiss zwar nicht, was das verwendete Repository damit zu tun hat...

Zitat

wieso gibt es dann im mainline Kernel API und ABI Brüche wie es Oliver hier erwähnt hat

... aber es wird moeglicherweise an mangelnder Sorgfalt des/der media-Maintainer liegen!? Ansonsten sind die mainline-Treiber nicht wirklich stable, sondern ein Snapshot von media-build beim letzten Merge-Window.

Aber diese Diskussion ist hier ziemlich off-topic, in diesem Thread gehts um die Treiber von UFO in seinem Repository. Ich werde mich hier an keinen weiteren Diskussionen zu dem Thema beteiligen.

Gruss,
S:oren