media-build-dkms

  • Nach einem reboot funktioniert es!

    Na da fällt mir aber ein Steinderl vom Herzen. Danke fürs testen!


    Jasmin, kannst Du zu dem dkms-speed-patch nochmal etwas mehr sagen? Worauf wird der angewandt?

    Kurze Antwort:

    GuckstDU im ersten Post, da hab ich erklärt wie man den "dkms.patch" installiert. Genauso machst du das mit dem dkms_speed.patch.


    Zum Verstehen:

    In dem Patch steht

    Diff
    1. --- a/dkms 2016-09-24 04:42:25.000000000 +0200
    2. +++ b/dkms 2017-09-10 16:46:35.658472976 +0200

    Das bedeutet er sucht die Datei "a/dkms" um sie zu verändern.

    Mit "which dkms" erfahren wir, dass die "dkms" Datei in "/usr/sbin" zu finden ist (das geht nur mit Executables so, sonst müsste man "locate" bemühen).

    Dann mit "cd /usr/sbin" dorhin wechseln und dann den Patch anwenden. Dazu ist der Parameter "p1" notwendig, weil wir nicht "a/dkms" patchen wollen, sondern "dkms". Und man muss patch mit sudo aufrufen, weil "/usr/sbin/dkms" nur von root verändert werden darf.


    LG,

    Jasmin

  • Diese Treiber sind doch in den neueren Kernels "extra" und müssen nicht geladen werden. Einfach linux-midules-extra-*kernel*-generic deinstallieren oder nicht installieren, sollte auch helfen?

    Also das Paket linux-modules-extra-****-generic enthält viel mehr Treiber als nur die media Treiber. Das Paket zu de-installieren halte ich für keine gute Idee.

    Außerdem sind in 4.15 die DD Treiber bereits enthalten (ein wenig älterer Stand) und das DKMS ist nicht unbedingt nötig, außer man hat ein Problem.


    Das DKMS existiert primär für ältere Kernel Versionen, wo die DD Treiber noch nicht enthalten sind.

    Im Grunde hab ich es für yaVDR 0.6.x gemacht (Ubuntu 14.04/Kernel 3.13).


    Wenn jemand andere als DD Karten besitzt, kann das wieder anders aussehen und das DKMS bringt den Treiber Stand von voriger Woche mit.


    LG,

    Jasmin

  • Moin,

    nach dem Update vom Kernel auf 3.13.0-151-generic und der Installation von dem media-build-dkms

    Code
    1. Start-Date: 2018-06-12 07:48:07
    2. Commandline: apt-get install media-build-dkms
    3. Upgrade: media-build-dkms:amd64 (0004~trusty, 0005~trusty)
    4. End-Date: 2018-06-12 07:58:42

    werden leider die Treiber für die DVB Karten nicht geladen, aus der dmesg vom Start

    Beim man. modprobe gibts die Meldung

    modprobe: ERROR: could not insert 'ddbridge': Unknown symbol in module, or unknown parameter (see dmesg)


    Habe ich was übersehen, vergessen.?

    Vielen Dank auch für das Bereitstellen von dem package.


    mfg


    auch mit der Version 3.13.0-149 u -147 lassen sich die Module nicht laden.

    Mit dem *-145 Kernel hatte es mit der 0004 noch funktioniert. Mit der -0005 nicht mehr.

  • Danke fürs testen!

    [ 1866.479534] videobuf2_memops: Unknown symbol put_vaddr_frames (err 0)
    [ 1866.479562] videobuf2_memops: Unknown symbol get_vaddr_frames (err 0)
    [ 1866.479586] videobuf2_memops: Unknown symbol frame_vector_destroy (err 0)
    [ 1866.479628] videobuf2_memops: Unknown symbol frame_vector_create (err 0)

    Das ist jetzt aber wieder mal saublöd!

    Ich muss das in medial_build fixen. Ich kann das nicht so leicht vorab testen, weil man einen Maschine mit jedem Kernel benötigen würde und dann alle Module mit modprobe testen müsste. Deshalb brauch ich immer Tester und kann erst im Nachhinein die Probleme fixen.


    Das hier wird leider ein wenig Zeit brauchen, weil ich gerade keine Zeit neben Firma und Familie habe. Wenn ich am WE Luft haben sollte, dann versuche ich es zu lösen.


    Sorry für die Unannehmlichkeiten!


    LG,

    Jasmin

  • Hallo holymoly,

    könntest Du dein Backup von der 0004~trusty zur Verfügung stellen.

    Leider hab ich dasselbe Problem, aber kein Backup.


    Viele Grüße

    gp2000

    Hardware: Zotac D2550ITXS-B-U / DD Max S8 / LCD Phillips 47 PFL8404H | Soft: yavdr 0.62 mit frodo-vdr/main, testing-vdr-dev

  • Die besagten Funktionen sind erst mit Kernel 4.3 verfügbar.

    Also alle die einen älteren Kernel haben sollten nicht von 0004 auf 0005 upgraden!

    Ich versuche einen Fix zu machen.


    LG,

    Jasmin

  • Hallo,

    könntest Du dein Backup von der 0004~trusty zur Verfügung stellen.

    ist "noch" im PPA von jasmin zu finden!

    https://launchpad.net/~jasmin-…eded&field.series_filter=


    Gruss

    Wolfgang

  • Hi!


    Ich habe bereits einen Fix für das Problem in meinem Git, aber den muss ich mir vom Chef Maintainer von media_build bestätigen lassen, bevor ich den einchecke.


    Derzeit haben wir keine Möglichkeit unresolved externals beim Build zu finden, aber ich habe dem Chef Maintainer auch diesbezüglich einen Vorschlag gesendet um das im Nightly Build bereits zu erkennen. Es ist nur generell nicht so einfach solche Probleme zu fixen, da man ja rückwirkend keine Symbole in alte Kernel einbringen kann, die erst in späteren Versionen eingebaut wurden. Sprich ich muss mir eine neue Möglichkeit das doch zu tun mit ihm überlegen. Die derzeit in media_build vorhanden Möglichkeiten mit "compat.h" sind nicht immer ausreichend.


    LG,

    Jasmin

  • Hi!


    Ich habe gerade eine Version 0006 ins Launchpad geschoben.

    Darin ist der heutige Stand von media_build und media_tree enthalten. Der Nightly-Build hat für alle Kernel Versionen fehlerfrei mit gcc 8.x gebaut.

    Ich habe wie immer den "mediatree/master-ddbridge" Branch von nst ins DKMS gepackt.


    Es ist auch der Fix für die Unresolved Symbols drinnen (das waren diese hier).


    Es gibt aber immer noch unresolved Symbols, diese sollten aber für eine Benutzung mit VDR oder TVH kein Problem darstellen. Wenn doch, bitte melden, dann muss ich das doch früher als ich wollte fixen. Hier die Liste


    Bitte mach vor der Installation eine Sicherheitskopie. Alte Versionen des DKMS Paketes findet man hier. Version 0004 hatte bis jetzt am Besten funktioniert, falls es Probleme mit 0006 geben sollte.


    Ich habe das Paket NICHT getestet, weil ich noch immer keine Zeit habe. Ich würde mich über Rückmeldungen freuen und hoffe es klappt alles.

    Und nicht vergessen, der DKMS Speed Patch sollte vor der Installation angewendet werden, sonst dauert das Builden extrem lange.


    LG,

    Jasmin

  • Hallo Jasmin,

    wäre evtl. eine Integration der FF HD Treiber möglich, wie im alten media-build-dkms?

    https://github.com/s-moch/linux-saa716x/branches


    Gab da gerade eine Anfrage.

    Ubuntu Zielrelease für Upgrade?


    Ich dachte, der wäre drin...


    MfG,

    Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easyvdr.de

  • Hi!

    wäre evtl. eine Integration der FF HD Treiber möglich, wie im alten media-build-dkms?

    https://github.com/s-moch/linux-saa716x/branches

    S:oren hat vor einiger Zeit versucht den Treiber in den Kernel zu bekommen, aber der media-tree Maintainer ist leider etwas mühsam. Vor allem hat dieser Anpassungen gefordert die doch aufwändig zu implementieren wären und somit hat S:oren es aufgegeben, denke ich.


    Im Grunde ist mein DKMS nur exakt der Stand von media-tree zum Zeitpunkt des Erstellens des Paketes. Wenn ich jetzt anfange andere Treiber einzupflegen, dann halse ich mir doch einiges an Arbeit auf. Speziell dann, wenn verschiedene Treiber nicht an die allerletzten Sourcen von media-tree angepasst sind.

    S:oren scheint aber sehr fleißig mit den Treiber Anpassungen zu sein. In seinem Repo gibt es schon eine Version für Kernel 4.20. Ich habe jedoch noch nicht versucht die Patches rein zu nehmen. Die Problematik wird eher sein die Backport Patches für ältere Kernel Versionen zu machen. Wenn S:oren das nirgendwo gemacht hat, dann müsste ich das alles erstellen. Das kann in wenigen Minuten erledigt sein oder Tage benötigen. S:oren hat zwar ältere Versionen im Repo, aber um media-build für alle älteren Kernels zum Compilieren zu bewegen bedarf es einer anderen Struktur.

    Wenn S:oren daran interessiert ist den Treiber in mein DKMS zu integrieren, dann wäre es eine große Hilfe wenn er einen "backports" Folder mit den notwendigen Patches anlegen würde und mal für alle Kernel Versionen zurück bis x.y die Patches zu testen. S:oren weiß sicher wie media-build funktioniert. Um das dann in das DKMS zu integrieren müsste es aber auch einen großen Basis Patch geben, den ich integrieren kann. Den müsste ich aber auch automatisch erstellen können, wenn ich einen Diff in seinem GitHub Repo beim DKMS erstellen mache.


    Wenn sich media-build-dkms als Ablöse von media-build-experimental etablieren soll, dann werde ich langfristig den Treiber wohl integrieren müssen. Ich bin aber derzeit auf Urlaub und habe kaum Zeit dafür hier in der iNet Wüste auf der Insel. Aber es gibt ja einige Vorbereitungen von S:oren zu machen, wenn er das möchte. Im Grunde kann er es auch in mein DKMS selbst einbauen. Es ist genau dokumentiert wie das DKMS funktioniert und wie man es erstellen muss. Wenn ich einen Pull Request bekomme, dann pflege ich den gerne ein.


    LG,

    Jasmin

  • S:oren hat vor einiger Zeit versucht den Treiber in den Kernel zu bekommen, aber der media-tree Maintainer ist leider etwas mühsam

    Vorsichtig formuliert. Er hat selbst öffentlich geschrieben, dass er keine Ahnung von dem Output-Teil des DVB-API hat (was für eine Schande für jemanden, der seit ~20 Jahren dafür bezahlt wird, u.a. auch dieses API zu maintainen). Und obwohl verschiedene Leute ihm geantwortet haben, dass dieses API etwas völlig Anderes ist als ein API für einen Video-Decoder in v4l2, besteht er immer noch darauf, diese Funktionen in v4l2 zu integrieren (oder was auch immer, er geht ja jeder technischen Diskussion aus dem Weg, was meiner Ansicht nach mit seiner obigen Aussage zusammenhängen könnte). Manchmal scheint er es kurz einzusehen, erinnert sich aber kurze Zeit später anscheinend nicht mehr daran. Was für ein Verstoß gegen jegliche Prinzipien der Linux-Entwicklung, was für eine Verhöhnung von Entwicklern und Anwendern, wenn er einfach behauptet, dass ja alle damit zufrieden sind, den Treiber out-of-tree zu maintainen.


    Aber weil die Situation noch nicht frustrierend genug ist, kann die liebe Jasmin es nicht lassen, bei jeder sich bietenden Gelegenheit diesen Unsinn zu unterstützen, in dem sie jedem erzählt, dass dieses API ja deprecated ist und man halt damit leben muss, dass es nicht mehr funktioniert. Wenn Du Dich so gut mit diesem API auskennst, wie stellst Du Dir denn so eine Konversion vor? Für mich wäre diesen Ansinnen ungefähr so sinnvoll und praktikabel, wie alle Treiber für serielle Schnittstellen durch DRM-Treiber zu ersetzen, nur weil man damit ja auch boot-Fehlermeldungen ansehen kann.

    Vor allem hat dieser Anpassungen gefordert die doch aufwändig zu implementieren wären und somit hat S:oren es aufgegeben, denke ich.

    Nun, ich habe für 4.20 alle Aufräumarbeiten erledigt, die irgendwie sinnvoll sind. Ich werde diesen Stand auch nochmal bei linux-media einreichen (nachdem er noch etwas getestet ist). Wenn ich aber keine Unterstützung von anderen Anwendern bekomme, und andere Entwickler zu frustriert sind, hierzu noch etwas zu sagen, oder mir gar noch in den Rücken fallen, dann sind die Aussichten vielleicht nicht allzu rosig...

    Die Problematik wird eher sein die Backport Patches für ältere Kernel Versionen zu machen.

    Es gibt Treiber-Versionen für alle Kernel seit 4.12, diese Version funktioniert auch für ältere Kernel, zumindest seit den letzten 3.x. Jeder mit etwas git-Erfahrung kann sich daraus diffs zwischen den verschiedenen Kernel-Version erzeugen.


    Ich selbst bin ausschließlich an einer endgültigen Lösung für diesen Treiber interessiert (kernel-merge). Ich wünsche mir, die "Community" würde mich darin unterstützen und nicht so viel Zeit mit ärgerlichem Gefrickel verschwenden (müssen).


    Gruß,

    Sören

  • Hallo!

    Aber weil die Situation noch nicht frustrierend genug ist, kann die liebe Jasmin es nicht lassen, bei jeder sich bietenden Gelegenheit diesen Unsinn zu unterstützen, in dem sie jedem erzählt, dass dieses API ja deprecated ist und man halt damit leben muss, dass es nicht mehr funktioniert. Wenn Du Dich so gut mit diesem API auskennst, wie stellst Du Dir denn so eine Konversion vor?

    Ich habe keine Ahnung von dem API, ich habe nur auf der Media Liste einige Zeit mitgelesen und dabei den Eindruck bekommen, dass Mauro etwas verlangt was nicht zur TT 6400 Hardware passt. Er will das aber auch nicht so akzeptieren wie es jetzt ist. Ob Mauro die älteren APIs nicht versteht oder recht hat kann ich nicht beurteilen und ist mir im Grunde auch egal.

    Was ich schade finde ist, dass die Kommunikation mit ihm so mühsam ist, dass man nicht sinnvolle technische Diskussionen führen kann. Zumindest waren die Response Zeiten von Mauro sowohl beim DD Treiber, als auch beim TT 6400 Treiber sehr lange. So lange, dass Daniel ausgestiegen ist und somit die DD Treiber keinen Maintainer mehr haben. Und dich S:oren hat er eben auch schon sehr verärgert, soweit ich das mitbekommen habe.

    Warum du einen Pick auf mich hast weiß ich zwar nicht, wird wohl ein Missverständnis sein.


    Nun, ich habe für 4.20 alle Aufräumarbeiten erledigt, die irgendwie sinnvoll sind. Ich werde diesen Stand auch nochmal bei linux-media einreichen (nachdem er noch etwas getestet ist). Wenn ich aber keine Unterstützung von anderen Anwendern bekomme, und andere Entwickler zu frustriert sind, hierzu noch etwas zu sagen, oder mir gar noch in den Rücken fallen, dann sind die Aussichten vielleicht nicht allzu rosig...

    Mein Steckenpferd ist die CI Schnittstelle und da habe ich seit 6 Monaten noch etwas zu fixen. Bei den Treibern kann ich absolut nichts beitragen, weil ich mich schlicht mit den APIs nicht beschäftigt habe. Wenn ich da jemals etwas tun werde, dann höchstens versuchen die DD Treiber weiter zu bringen, weil diese HW hab eich selbst. Aber Daniel hatte da so viel Wissen angesammelt, dass er nicht zu ersetzen ist.


    Es gibt Treiber-Versionen für alle Kernel seit 4.12, diese Version funktioniert auch für ältere Kernel, zumindest seit den letzten 3.x. Jeder mit etwas git-Erfahrung kann sich daraus diffs zwischen den verschiedenen Kernel-Version erzeugen.


    Ich selbst bin ausschließlich an einer endgültigen Lösung für diesen Treiber interessiert (kernel-merge). Ich wünsche mir, die "Community" würde mich darin unterstützen und nicht so viel Zeit mit ärgerlichem Gefrickel verschwenden (müssen).

    Also ich verstehe das so.

    Du willst die TT 6400 Treiber im Kernel sehen. Wäre tatsächlich die beste Lösung. Ob das gelingt werden wir sehen. Kann also bis Kernel 5.4 auch dauern oder nie passieren.

    Bis dahin müssen alle nicht so versierten Anwender den TT 6400 Treiber selber bauen (wie bisher auch), oder ich setzte mich hin und investiere die Arbeit den Treiber in mein DKMS einzubauen. Dazu werde ich aber weder kurz, noch mittelfristig Zeit finden.

    Aber vielleicht hat ja irgendein TT 6400 User Zeit das mal zu machen und mir einem Pull Request zu schicken.


    LG,

    Jasmin

  • Warum du einen Pick auf mich hast weiß ich zwar nicht, wird wohl ein Missverständnis sein.

    Missverstaendnis, aha. Wie passt denn dann

    kann ich nicht beurteilen

    (was wahrscheinlich wirklich stimmt) zu z.B. : VDR would already have needed to be changed quite some time ago. und removing an API after 11 years is a good method to force developers to do their homework? Vielen Dank fuer den Arschtritt. Eine Beschwerde von Fedora haette Mauro vielleicht zum Nachdenken gebracht, aber nein, er hat natuerlich recht, nur der bloede Developer (ich) macht seine Hausaufgaben nicht.


    Auch der neue pull-request wird keine Chance haben ohne 20 Leute, die ihm erklaeren, dass dieses API wichtig ist und gebraucht wird. Aber die werden sich nicht finden. Also viel Spass mit ewigem Portieren, und vielen Dank fuer nichts,


    S:oren

  • Hi!


    Hinter der Aussage stehe ich immer noch. Das Define war schon bei Kernel 2.6.36 depreciated.

    Manchmal fliegen ganze Treiber aus dem Kernel und manchmal passieren API Änderungen ganz absichtlich und dann brechen eben Treiber oder Applikationen: https://www.golem.de/news/kern…leme-1901-138698.amp.html Da steht die Nummer zwei der Kernel Entwickler dahinter.


    Ich kann mich erinnern, beim DD Treiber haben neben mir doch einige andere Daniel unterstützt und der Treiber ist jetzt drinnen.

    Beim TT 6400 Treiber kann ich auch was schreiben wenn du willst. Nur kann ich da technisch nicht viel beitragen, weil ich eben das verwendete API nicht kenne. Und ich denke mal da draußen gibt es auch nur sehr wenige die das verstehen. S:oeren, du hast dich da eben eingearbeitet und du bist der Meinung das gehört so, also können wir anderen außer "Ja, wir brauchen den Treiber" nicht viel beitragen.

    Und ich bin sicher die User der TT 6400 Karte würden den Treiber gerne im Kernel sehen. Auf der anderen Seite kann man diese HW ja kaum noch kaufen, soweit ich mich an die Diskussion erinnere.


    Was auch immer, in dem Thread hier geht es um das media-build-dkms und nicht die TT 6400 Treiber Integration in den Kernel.

    Das die Erweiterung des DKMS um den TT 6400 Treiber betrifft, so warte ich auf einen Pull Request oder ich finde irgendwann doch mal Zeit dazu. Aus Anwendersicht ist die Integration in das DKMS zumindest sinnvoll solange der Treiber nicht im Kernel ist.


    LG,

    Jasmin

  • Hallo Zusammen,


    uii, da hab ich ja in ein Wespennest gefasst, sorry.

    Als Anwender kommt es mir nur darauf an, dass es einfach geht,

    d.h. auch ein selbst bauen ist OK, wenn man eine Anleitung hat.

    Schöner und einfacher ist es natürlich per Kernel oder per DKMS, klar.

    Wenn man wie ich jetzt gerade alles selbst erforschen muss ist das echt mühsam.


    Gruss,


    Günter


    PS:

    Also, wenn mir jemand beim kompilieren helfen kann erstelle ich gerne

    eine Step-für-Step Anleitung daraus.

    Ubuntu 14.04; Kernel 4.4.0-103; mit Parallelbetrieb von:
    VDR 2.2.00 über S2-6400 (HDMI1)
    XBMC /Kodi über GT520 (HDMI2)
    Beides an Sony KDL-55EX725
    Harmony zum Umschalten zwischen VDR und XBMC
    MusicPD Steuerung per Android ist perfekt