fühlen ?
...
Ja, es soll Experten geben, die das können. :LOL2
Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT, MAX S8 sowie TT S2-6400 (Teil 3)
-
-
fühlen ?
ohne Fakten sehr schwierige Argumentation. Dmesg o.ä. sind da sicherlich hilfreicher.Dmesg, in Zeile 46 gibt es den interessanten Sprung.
-
Ich habe eine Cine CT, welche auch einwandfrei funktioniert. Nun habe ich mir eine Astrometa DVB-T/T2/C USB Stick besorgt, welcher aber erst seit kurzem vom regulären media_build unterstützt wird und daher noch nicht hier im experimental drin ist. Das reguläre media_build kompiliert sauber durch, der wichtige MN88472 (für DVB-C) Tuner wird allerdings nicht erkannt, nur der Realtek Tuner für DVB-T. Module und Treiber, alles da. Auf einer sauberen Wheezy Installation ohne media_build_experimental und ohne Cine CT Karte funktioniert der Stick einwandfrei.
Nun die Frage: Hat jemand vielleicht eine Idee ob es bei der Verwendung von media_build_experimental UND normalen media_build zusammen zu Problemen kommen kann? Ich kann mir das irgendwie nicht erklären warum der Treiber trotz gleicher Vorgehensweise und identischem Debian nur bei dem System ohne Cine CT / mb_experimental geladen wird. -
Ich denke, dass man nicht beide parallel einsetzen kann, weil media-build-experimental den kompletten media-Treiber-Stack ersetzt.
Entweder müsste media-build-experimental auf einen neueren Stand gebracht werden oder der Treiber muss einzeln in -experimental eingefügt werden.Lars.
-
Ich habe eine Cine CT, welche auch einwandfrei funktioniert. Nun habe ich mir eine Astrometa DVB-T/T2/C USB Stick besorgt, welcher aber erst seit kurzem vom regulären media_build unterstützt wird und daher noch nicht hier im experimental drin ist. Das reguläre media_build kompiliert sauber durch, der wichtige MN88472 (für DVB-C) Tuner wird allerdings nicht erkannt, nur der Realtek Tuner für DVB-T. Module und Treiber, alles da. Auf einer sauberen Wheezy Installation ohne media_build_experimental und ohne Cine CT Karte funktioniert der Stick einwandfrei.
Nun die Frage: Hat jemand vielleicht eine Idee ob es bei der Verwendung von media_build_experimental UND normalen media_build zusammen zu Problemen kommen kann? Ich kann mir das irgendwie nicht erklären warum der Treiber trotz gleicher Vorgehensweise und identischem Debian nur bei dem System ohne Cine CT / mb_experimental geladen wird.
media_build_experimental verwendet z.Zt. media_build vom 8.11.2014 (vgl. linux/Makefile).Früher hatte ich automatisch immer den neuesten media_build eingebunden. Leider gab es dadurch ständig Kompilierprobleme. Daher aktualisiere ich media_build nun immer beim Aktualisieren von media_build_experimental, d.h. wenn es Updates für dddvb gibt oder ein neuer Kernel dies erfordert.
Nach dem nächsten Update sollte der Stick also funktionieren...
CU
Oliver -
Alles anzeigen
media_build_experimental verwendet z.Zt. media_build vom 8.11.2014 (vgl. linux/Makefile).Früher hatte ich automatisch immer den neuesten media_build eingebunden. Leider gab es dadurch ständig Kompilierprobleme. Daher aktualisiere ich media_build nun immer beim Aktualisieren von media_build_experimental, d.h. wenn es Updates für dddvb gibt oder ein neuer Kernel dies erfordert.
Nach dem nächsten Update sollte der Stick also funktionieren...
CU
OliverMoin,
gut, das hab ich mir schon gedacht. Kann ich da vielleicht auf die schnelle was zusammenfrickeln, wie von mini73 vorgeschlagenen, also den Krempel für den MN8847X aus dem normalen media_build nach experimental und dann durchkompilieren, oder ist das nicht so einfach? Ist halt fraglich wann das nächste Treiberupdate von DD ansteht
Edit: Ich sehe grade: DD Treiber 0.9.16 vom 2014.12.19, der im mb_experimental ist 0.9.15a oder?
Gruß
Daniel
-
Hallo,
mir stirbt das System immer so weg, dass ich nicht mal was Debuggen kann. Einmal hatte ich einen Eintrag mit ic2 timeout, aber bei den restlichen Fällen steht nichts in den logs oder in der Systemkonsole (wird beim freeze schwarz obwohl kein Bildschrimschoner an ist).
Habe den ddbridge treiber schon mit msi=0 geladen, ändert aber nichts.media_build_experimental ist von 27.12.2014
Kernel: 3.17.7-gentoo
Mainboard: ASUS M3N-H/HDMI
Chipsatz: NVIDIA nForce 750a SLImfg bacardi
-
Mal eine Verständnisfrage; meine DigitalDevice CineS2 V5 wird mit dem Kernel 3.13.0-44 auch ohne die Treiber aus dem media_build_experimental erkannt und läuft auch.
Was ist der Vorteil, wenn ich das ngene Modul aus media_build_experimentel verwende?
Grüße,
Alex -
Mal eine Verständnisfrage; meine DigitalDevice CineS2 V5 wird mit dem Kernel 3.13.0-44 auch ohne die Treiber aus dem media_build_experimental erkannt und läuft auch.
Was ist der Vorteil, wenn ich das ngene Modul aus media_build_experimentel verwende?
Kein Vorteil, falls das Modul aus dem Kernel für Dich einwandfrei funktioniert.CU
Oliver -
Danke für die schnelle Antwort. Dann werde ich es erstmal mit dem Kernel Treiber versuchen.
Habe allerdings schon seit Ewigkeiten ein Problem mit einem von meinen 4 Tunern bei egal welchen Treibern. Werde dafür aber dann einen neuen Thread aufmachen.
Grüße,
Alex -
-
Hi,
nun wird auch die Digital Devices Max S8 unterstützt.
Dazu wurde das Treiberpaket aktualisiert:
- dddvb-0.9.17
- Frontendtreiber mxl5xx aus dddvb-0.9.18beta2
CU
Oliver -
Kompiliert leider nicht mehr mit Kernel 3.18.4
Es kommen tonnenweise der folgenden Meldungen:Code
Alles anzeigen/root/media_build_experimental_new/v4l/ddbridge.h:441:20: error: inlining failed in call to always_inline 'ddbwritel': recursive inlining static inline void ddbwritel(struct ddb *dev, u32 val, u32 adr) ^ /root/media_build_experimental_new/v4l/ddbridge.h:448:3: error: called from here ddbwritel(dev, adr & 0xfffc, 0x194); ^ /root/media_build_experimental_new/v4l/ddbridge.h:441:20: error: inlining failed in call to always_inline 'ddbwritel': recursive inlining static inline void ddbwritel(struct ddb *dev, u32 val, u32 adr) ^ /root/media_build_experimental_new/v4l/ddbridge.h:449:3: error: called from here ddbwritel(dev, val, 0x198); ^ /root/media_build_experimental_new/v4l/ddbridge.h:441:20: error: inlining failed in call to always_inline 'ddbwritel': recursive inlining static inline void ddbwritel(struct ddb *dev, u32 val, u32 adr) ^ /root/media_build_experimental_new/v4l/ddbridge.h:450:3: error: called from here ddbwritel(dev, 1, 0x190); ^ /root/media_build_experimental_new/v4l/ddbridge.h:441:20: error: inlining failed in call to always_inline 'ddbwritel': recursive inlining static inline void ddbwritel(struct ddb *dev, u32 val, u32 adr) ^ /root/media_build_experimental_new/v4l/ddbridge.h:448:3: error: called from here ddbwritel(dev, adr & 0xfffc, 0x194); ^ /root/media_build_experimental_new/v4l/ddbridge.h:441:20: error: inlining failed in call to always_inline 'ddbwritel': recursive inlining static inline void ddbwritel(struct ddb *dev, u32 val, u32 adr) ^ /root/media_build_experimental_new/v4l/ddbridge.h:449:3: error: called from here ddbwritel(dev, val, 0x198); ^ /root/media_build_experimental_new/v4l/ddbridge.h:441:20: error: inlining failed in call to always_inline 'ddbwritel': recursive inlining static inline void ddbwritel(struct ddb *dev, u32 val, u32 adr) ^ /root/media_build_experimental_new/v4l/ddbridge.h:450:3: error: called from here ddbwritel(dev, 1, 0x190); ^ scripts/Makefile.build:263: die Regel für Ziel „/root/media_build_experimental_new/v4l/ddbridge.o“ scheiterte make[3]: *** [/root/media_build_experimental_new/v4l/ddbridge.o] Fehler 1 Makefile:1381: recipe for target '_module_/root/media_build_experimental_new/v4l' failed make[2]: *** [_module_/root/media_build_experimental_new/v4l] Error 2 make[2]: Leaving directory '/usr/lib/modules/3.18.4-1-ARCH/build' Makefile:51: die Regel für Ziel „default“ scheiterte make[1]: *** [default] Fehler 2 make[1]: Verzeichnis „/root/media_build_experimental_new/v4l“ wird verlassen Makefile:28: die Regel für Ziel „all“ scheiterte make: *** [all] Fehler 2 -
Kompiliert leider nicht mehr mit Kernel 3.18.4
Es kommen tonnenweise der folgenden Meldungen:Kann ich bestätigen, hier aber mit Kernel 3.16.1.
Gruß MegaX
-
Moin Oliver
hab hier gerade mal getestet und ohne inline Attriubut baut es durch (gcc 4.8.2).
Patch:
Folgende Meldungen kommen noch:
Gruß Megax
-
Hab den Treiber am laufen und sieht bis jetzt ganz stabil aus ohne setzen von "msi=0" mit der DD Max S2 im "fmode=1".
Danke für die neue Version Oliver
Gruß MegaX
-
Moin Oliver
hab hier gerade mal getestet und ohne inline Attriubut baut es durch (gcc 4.8.2).
Patch: ...
Du hättest nur die inline entfernen müssen, die er anmosert.Ich habe es anders gelöst:
http://linuxtv.org/hg/~endriss…rimental/rev/1969cdc5388bZitat
Folgende Meldungen kommen noch:
...
Diese "unused variable" Warnings kann man ignorieren.
Ich war zu faul, dies zu beheben - zumal der Treiber "work in progress" ist und sich in 0.9.18 wieder eine Menge ändert.CU
Oliver -
Hab den Treiber am laufen und sieht bis jetzt ganz stabil aus ohne setzen von "msi=0" mit der DD Max S2 im "fmode=1".
"msi=0" empfehle ich nur, falls es I2C-Timeouts gibt. (Wir hatten auch schon den umgekehrten Fall, dass msi=0 Probleme gemacht hat.)Hier läuft der Treiber sowohl mit msi=1 als auch mit msi=0 problemlos.
CU
Oliver
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!