akt. Situation v4l-dvb

Zitat

Original von Dr. Seltsam
soweit ich das überblicke, ist die Situation aktuell wie folgt:

will man aktuellere linuxtv-Treiber haben, als die, die im verwandten Kernel enthalten sind, dann bleibt nur noch das abwärtskompatible v4l-dvb hg. Der aktuelle Maintainer Douglas Landgraff übernimmt aber nur sporadisch Patches und Fehlerkorrekturen aus der laufenden Entwicklung. Die letzte Änderung, die ich finde, stammt aus Anfang September.

So viel ich weiß, wird v4l-dvb überhaupt nicht mehr aktualisiert.

Zitat

Nach welchem System dort Patches mal backportiert und mal ignoriert werden, ist für mich nicht erkennbar. Verschiedene Patches am ivtv-Treiber aus Juni 2010 würden übernommen, aber ausgerechnet ein wichtiger Patch, der die Fehler eines vorhergehenden experimentellen Patches wieder "repariert"[/URL], fehlt bis heute.

Imho ging nach der Umstellung auf GIT der Überblick völlig verloren.
Wenn man sich die Namen der Changesets im HG anschaut, ist das ja auch kein Wunder...

Zitat

Die laufende Entwicklung findet in http://git.linuxtv.org/media_tree.git statt. Das enthält aber einen kompletten Entwicklungskernel - die linuxtv-Treiber können nicht standalone mit einem bestehenden Kernel verwandt werden. Feedback von Testern gibt es also nur, wenn diese

1.)
bereit sind, einen Entwicklungskernel mit unkalkulierbaren Risiken zu verwenden (immerhin sind diese nicht für den Produktiveinsatz empfohlen, da ein möglicher Datenverlust droht, wenn Patches im fileystem nicht ausgereift sind)

und

2.)
überhaupt in der Lage und willens sind, einen kompletten Kernel zu konfigurieren und zu kompilieren, nur um mal mitzutesten. Ich befürchte, dass dadurch die Zahl der Tester rapide gesunken ist, denn nur so ist erklärbar, dass immer öfter ein stable Kernel gravierende Bugs hat (aktuell haben TV-Karten mit msp34xx-Chip -z.B. PVR250/350- mit Kernel 2.6.36 keinen Ton mehr)

Alles anzeigen

Ich behaupte, daß die Zahl der Tester gegen 0 geht.

Momentan würde ich ohnehin niemendem raten, auf die neuesten Kernel zu aktualisieren.
Die arbeiten gerade an der Entfernung des BKL (Big Kernel Lock) aus allen Treibern, was imho eine hochbrisante Sache ist.

Außerdem wird bei v4l und damit im Kernel munter weiter an der Fernbedienungsgeschichte geschraubt.
Sich darauf einzulassen lohnt sich erst, wenn sich das stabilisiert hat. Imho ist da noch viel zu viel im Fluß.

Ich werde auf gar keinen Fall auf meinen Systemen Bastel-Kernel installieren, auch nicht zu Entwicklungszwecken.
Auf dem Entwicklungsrechner habe ich 2.6.35.x, produktiv verwende ich 2.6.30.x.

Es ist schon schwierig genug, Treiberbugs zu finden, dazu braucht es nicht auch noch die Bugs des Kernels.

Zitat

Gibt es irgend ein repository, das abwärtskompatibel ist und gut gepflegt wird?

Meines Wissens nicht.

Für "meine" Karten sehe ich keinerlei Notwendigkeit, auf einen neueren Kernel upzudaten.
Daher kann ich in Ruhe abwarten.

Ich könnte mich breitschlagen lassen, in http://linuxtv.org/hg/~endriss/v4l-dvb wichtige Patches einzuspielen, falls sich zuverlässige Personen finden, die getestete(!) Patches zuliefern.

Im Endeffekt wäre dies eine Art Backport-Tree für ausgewählte Treiber.
(Welche Karten/Treiber damit funktionieren, bestimmen allein die Zulieferer.)

CU
Oliver

hi jungs,

erstmal frohe weihnachten und ansonsten full ack

finde es traurig und schade, dass man nur an neue, evtl. bugfixed treiber kommt indem man nen testing kernel nutzt. was machen die ganzen distributionen, die ihren usern ermöglichen wollen zwischen v4l und s2 auszuwählen? mit kernel 2.6.36 kriege ich den v4l-hg nicht mal kompiliert (ja ich möchte nicht die kernelmodule nehmen um es eben austauschbar zu halten).

desweiteren habe ich den überblick verloren? ist nun der patch für 2x tt1600 oder der fasterzapping patch von lou in den treibern drin (im hg zumindest nicht). Man muss sich die ganzen patches zusammen suchen und im endeffeckt fehlt einem da die übersicht

UFO das wäre super und verdient großen respekt! wenn du dich wirklich dem thema annehmen würdest. ausgiebig getestet ist lou's tuning patch UND man muss sagen ohne diesem wäre der vdr absolut unnutzbar!

denke das eine absprache mit distris, die einen großen zulauf haben, wie yavdr sicher nicht schaden würde (was das testen angeht)

ansonsten wer ein aktuelles v4l-dvb packet hat, das mir gegen 2.6.36 compiled dem bin ich sehr dankbar ;-).

ALLEN NOCH EIN FROHES FEST und GUTEN RUTSCH

greetz MarMic

Abend!

Ich würde es sehr begrüssen, hoffe aber das daraus kein s2-liplianin wird, aber ich bin da zuversichtlich

In "meinem" dkms sind folgende Patches:

dvbloop-s2api_v3.patch
Ist wohl irgendwie nötig für netceiver, in jedemfall ziemlich standalone und schadet nicht. Nicht im tree, warum weiss ich nicht.
Funktioniert.

ngene_shutdown_workaround.patch
ngene-second-tuner.patch
2 Bugfix patches von UFO für ngene, der letzte fehlt noch. Klar bestätigt.

s464-support.patch
Aus dem s2-liplianin übertragen, von (ich komm grad nicht auf den Namen *grml*)

stb0899_improve-tuning.patch
Avoid-unnecessary-data-copying-inside-dvb_dmx_swfilter_204-function.patch
Mantis-DMA-transfer-cleanup-fixes-data-corruption-and-a-race-improves-performance.patch
Das dürften weitestgehend Lou's Patche sein - ist zumindest auf die ML gelangt und es gibt ein git dafür, weiss nicht obs integriert ist.
Bestätigt das es funktioniert von etlichen Usern.

stb0899_signal_strength_v3.patch
Scheint wohl nur manchmal zu helfen ? - Einige Rückmeldungen das es nicht geht.

tt-s2-double-fix.patch
Wird benötigt für 2x TT S2 1600, weiss nicht ob es schon eingeflossen ist, ich meine mich zu erinnern das es eingeflossen ist, bin mir aber nicht sicher.

Ansonsten gibts noch s2-liplianin, der entweder jetzt auch nur noch das git benutzt, oder es passiert nix mehr. Wird aber leider benötigt, für einige Karten (Tevii 470 funktioniert hiermit besser IMHO).

Die mantis Patche wären in jedem Fall wichtig, da warum auch immer, eine Menge Leute diese Karten haben. (Ist nach meinem dafürhalten so das Nummer 1 Thema bei den Nachfragen, neben dem S2 1600 Patch).

Nur zur Info

In unserem v4l-dkms für die 0.9 sind drin:

Avoid-unnecessary-data-copying-inside-dvb_dmx_swfilter_204-function.patch
Mantis-DMA-transfer-cleanup-fixes-data-corruption-and-a-race-improves-performance.patch
dvbloop-s2api_v3.patch
ngene_shutdown_workaround.patch
stb0899_improve-tuning.patch
stb0899_signal_strength_v3.patch
tt-s2-double-fix.patch

Läuft unseren Tests zufolge stabil.

Ist aber eine ältere Version (aus dem Git vom 23.09.2010), als die YaVDR-Version.

Imho läuft der s2-liplianin mit der Cine-S2 ebenfalls stabiler

Andy

Zitat

Original von sinai

In unserem v4l-dkms für die 0.9 sind drin:

Unser ????

MfG
wino

Zitat

Original von MarMic
finde es traurig und schade, dass man nur an neue, evtl. bugfixed treiber kommt indem man nen testing kernel nutzt. was machen die ganzen distributionen, die ihren usern ermöglichen wollen zwischen v4l und s2 auszuwählen? mit kernel 2.6.36 kriege ich den v4l-hg nicht mal kompiliert (ja ich möchte nicht die kernelmodule nehmen um es eben austauschbar zu halten).

v4ldvb ist ein älterer Treiberstand als 2.6.36 und kompiliert nicht gegen 2.6.36, da in letzterem die alte ioctl-Schnittstelle (mit BKL) nicht mehr existiert.

Für 2.6.36 wurden die Treiber entsprechend umgestellt. Ob dabei ein sorgfältiger Codereview stattgefunden hat, weiß ich nicht. Bin da skeptisch.

Ich jedenfalls werde in absehbarer Zeit keinen neueren Kernel als 2.6.35.x verwenden.

Zitat

desweiteren habe ich den überblick verloren? ist nun der patch für 2x tt1600 oder der fasterzapping patch von lou in den treibern drin (im hg zumindest nicht). Man muss sich die ganzen patches zusammen suchen und im endeffeckt fehlt einem da die übersicht

UFO das wäre super und verdient großen respekt! wenn du dich wirklich dem thema annehmen würdest.

Wie oben gesagt, ich werde da nicht viel Arbeit investieren.

Zitat

ansonsten wer ein aktuelles v4l-dvb packet hat, das mir gegen 2.6.36 compiled dem bin ich sehr dankbar ;-).

Es ist ein Unterschied, ob etwas gegen 2.6.36 kompiliert, oder ob der Code auch korrekt ist!
Die BKL-Änderungen werde ich vorerst nicht anfassen, denn dann müßte ich mich mit sämtlichen (potentiellen) Locking-Fehlern in 2.6.36+ befassen.

CU
Oliver

tja, es ist wirklich "shit happens" als die Entwicklung von HG auf GIT umgestellt wurde.
ich hoffe es findet in dem Repo vernünftige Unterstützung für 2.6.32 statt. da diese kernel LTS ist und in verschiedenen Distros ( Debian Squeeze, Ubuntu 10.04, Centos/RHEL 6.x) zu finden ist. Man muss nur gute Strategie zwischen neu vs. stable austüfteln.
Interessanten einsatz findet man hier. Eigentlich es sollten Backports Patch Serien ins neue HG tree eingespielt werden

UFO, danke für die aufklärung. ich hatte gedacht bkl sei erst seit 2.6.37 ein thema, aber nun weiss ich es ja besser.

ein gepflegtes v4l-dvb mit den patches, die die distris schon testen, wäre ein lichtblick
man müsste so nicht überall den patches nachrennen und ich denke die großen distris wären dir auch sehr dankbar alles zentral zu bekommen

naja jedenfalls kommt hier nun auch erstmal nur 2.6.35.x in frage.

BIG THX

greetz

Moin!

Selbst ohne Umstellung von hg auf git wäre der backports-tree eingeschlafen - es gibt einfach niemanden, der sich diesen Aufwand antun kann und will.
Gerade weil es momentan so viele Umbauten im v4l/dvb-Subsystem gibt (die meiner Meinung nach auch dringend nötig waren), macht ein Backport auf ältere Kernel noch wesentlich mehr Arbeit als sonst schon.
Momentan hilft wohl nur, Hardware einzusetzen, die alt genug ist und hoffen, dass es bald wieder einen benutzbaren, aktuellen Kernel gibt.

Ich bin froh, dass ich nicht ernsthaft betroffen bin...

Lars.

2.6.36 mit den mantis-Verbesserungen bringt die SkyStar HD 2 wie erwünscht zum Laufen. Durch die PKGBUILDs unter Arch Linux gestaltet sich das Kompilieren eines eigenen Kernels auch für Ahnungslose wie mich unkompliziert. Sicherlich gibt es auch einen Weg nur ausgewählte Module neu zu übersetzen und zu installieren, wenn sonst nix verändert wird.

Die IR-Sachen im V4L/DVB waren oder sind immer noch schlecht dokumentiert. Das alte Verhalten bringt (You still probably want lirc, since full native input layer support is not quite a reality yet.

ir-keytable -p lirc

Mein mceusb-Gerät läuft so wieder wie gewohnt.

Von daher gibt es für mich keinen Grund 2.6.36 nicht zu verwenden. Es ist halt zunächst immer etwas holprig, wenn alte Zöpfe abgeschnitten werden.

hi @all,

wäre jemand, der die patches zentral rumliegen hat, so freundlich und würde mir ein packet mit allen hier aufgelisteten patches schnürren und zu kommen lassen?

dann wüsste ich, dass ich die richtigen (laufenden) patches habe und mir würde das zusammensuchen ersparrt bleiben.

Vielen dank schonmal

greetz MarMic

edit:// hat sich erledigt thx

Zitat

Original von Dr. Seltsam
Gibt es irgend ein repository, das abwärtskompatibel ist und gut gepflegt wird?

Soweit ich das lese gibts dafür das new_build git repo:

mkdir -p /usr/src/linuxtv_new_build && cd /usr/src/linuxtv_new_build
git clone git://linuxtv.org/mchehab/new_build.git
cd new_build
./build.sh
make install

Zitat

aktuell haben TV-Karten mit msp34xx-Chip -z.B. PVR250/350- mit Kernel 2.6.36 keinen Ton mehr

Funzt mit 2.6.35.4 + aktuellem git. Gerade probiert.

Vermutlich seit zwei Tagen

http://www.mail-archive.com/li….kernel.org/msg26508.html

Ja. Zeile 384ff