Posts by S:oren

    Probleme im Mietshaus habe auch erlebt, siehe oben. Im Eigenheim erwarte ich sowas nicht.


    Wieviel Flexibilitaet man sich wuenscht, ist Geschmacksache, denke ich. Mancher mag vielleicht keinen Splitter-Verhau im Keller, wo die ganze Wand mit Kabeln zugepflastert ist. Moeglichkeiten gibt es wie immer viele. Und der Trend geht momentan ja eher weg von Koax-Verkabelung.


    Man sollte nur keine

    (T-Stücke hinter der Dose?)

    verwenden, sondern richtige Durchgangsdosen, wenn man mehrere an einem Strang haben will.

    Ähm, was hat diese Antwort mit meiner Frage zu tun?

    PmK findet eine Strangverkabelung kompliziert, ich nicht. Es kann gegenueber einer Sternverkabelung mit Splitter im Keller nur einfacher werden.

    mit einem Kabel von einem Raum in den nächsten zu gehen, scheint attraktiv, da der Verkabelungs-Aufwand gering ist und damit günstiger.

    Somit stimme ich der Idee von Angelosarikis zu, will es aber nicht uneingeschraenkt empfehlen, weil ich es selbst so fuer SAT-Unicable nicht im Einsatz habe.


    Wieviele Dosen man an welche Wand nagelt und ob man hinter der Dose (welcher Art auch immer) weitere Splitter installiert, ist davon komplett unabhaengig...

    Ich denke von Raum zu Raum Kabel ziehen mit Splitter in jeder Dose erhöht auf jedenfall mal die Komplexität.

    Warum nicht Durchgangs- und Enddosen passend installieren? Die Durchgangsdosen enthalten die Splitter quasi schon, spart ggf. 'ne Menge Kabel und Verlegeaufwand, mit einem Splitter im Keller kann man ggf. mehrere Straenge aufbauen.


    Funktioniert das nur in der Theorie und hat jemand damit schlechte Erfahrungen? Bei Kabelfernsehanlagen gab es ja manchmal Probleme, wenn der Nachbar meinte, auf die Dosen noch zusaetzliche Kabel klemmen zu muessen. Im eigenen Haus passiert das ja eher nicht...


    Gruss,

    S:oren

    Es gibt keinen einfachen Weg, den Treiber ohne komplette Kernel-Sourcen zu bauen, da auch die Kernel-Header gepatcht werden muessen.


    Wer sich da ausgefeilte Skripte oder dkms-Pakete oder was-auch-immer bauen will, darf das natuerlich gerne machen, muss aber mit jeder neuen Kernel-Version damit rechnen, dass man da wieder etwas anpassen muss. Da das Herunterladen der Kernel-Sourcen + Patchen + Bauen der Module keine 10 Minuten dauert (wenn man es nicht zum ersten Mal macht), wird man m.E. die Zeit nie wieder einsparen, die man die Entwicklung solcher Spezial-Loesungen steckt. Wer aber Spass daran hat, soll es meinetwegen gerne machen. Ich kann und moechte dafuer jedenfalls keinen Support leisten, ich selbst nutze sowieso keine Distro-Kernel auf meinen VDR- und Treiber-Entwicklungs-Rechnern. Aber auch da soll jeder nehmen, was ihm/ihr gefaellt.


    Nach den Problembeschreibungen, die ich so bisher bekommen habe, haben jedenfalls viele Leute schon deutlich mehr Zeit in die Fehlersuche gesteckt, als das Herunterladen und Patchen der kompletten Kernel-Sourcen gedauert haette. Die meisten Distro-Kernel werden sowieso exakt passende Modul-Versionen fordern, evt. sogar signierte Module. Wie das bei SuSE aussieht, weiss ich allerdings nicht. Die letzte von mir genutzte SuSE-Version war 9.3 ...


    Gruss,

    S:oren

    Kernel 4.4 ist ja auch schon eine Weile her und wenn ich mich richtig erinnere, sind seit dem geringfügige Anpassungen am Treiber gemacht worden.

    Koennte man so sagen, exakt 95 Patches...

    Ich kann ja schlecht den Patch, der gegen einen ganzen Kerneltree laufen würde, gegen das bisschen Sourcecode werfen, das in den src.rpms drin war.

    Bitte immer nur komplette Kernel-Sourcen verwenden. Die gibt es ganz sicher auch von SuSE.


    Die letzte Anfrage, den Treiber fuer Suse zu bauen, kam von kls, siehe hier.


    Gruss,

    S:oren

    Es ist natuerlich immer eine gute Idee, "meinen Original-Kernel" aus dem Repo zu testen, wenn es Probleme mit dem Treiber gibt. Leider hat jede Distri da so ihre eigenen Tuecken.


    Mittelfristig sollte ich wahrscheinlich das request_mem_region/ioremap in das neuere devm_ioremap aendern. Es waere mir allerdings neu, wenn es "oldstyle" nicht mehr funktioniert.


    Vielleicht findet sich ja noch eine einfache Erklaerung. Ansonsten ist leider 'git bisect' angesagt...


    Gruss,

    S:oren

    Sieht erstmal nicht verkehrt aus. Nur dass "SAA716x Core" eben nicht geladen ist.

    Der Speicher ist im Prinzip da und nicht anderweitig belegt.


    Ich habe im Moment keine weitere Idee...


    Gruss,

    S:oren

    Normalerweise funktioniert das request_mem_region() nicht, wenn schon ein anderer Treiber diesen Bereich reserviert hat.

    Steht in /proc/iomem etwas dazu? Bei mir sieht das so aus:

    Code
    1. 01000000-01efffff : MEM
    2. 01000000-010fffff : 0000:00:00.0
    3. 01100000-011fffff : PCI Bus 0000:01
    4. 01100000-011fffff : 0000:01:00.0
    5. 01100000-011fffff : SAA716x Core
    6. 01200000-0120ffff : 0000:00:00.0
    7. 01ffc000-01ffffff : 1ffc000.pcie

    Deshalb die Frage in die Runde, funktioniert bei Jemanden die TT6400 in Verbindung mit Kernel 5.1.x.

    Laeuft bei mir mit 5.1.6.

    BAR0 Request failed

    Hier klappt schon das allererste Mappen des PCIe-Speichers nicht. Da wird noch nichts Karten-spezifisches gemacht.

    Im Moment keine Ahnung, was da nicht klappt.


    Gruss,

    S:oren

    Nicht Skins, sondern OSD-Implementierungen.

    Ja, nur das ergibt Sinn. Wie ist dann aber

    in SkinFlatPlus die Funktion MaxPixmapSize implementieren und einen beliebigen Wert, der für deine Zwecke groß genug ist, zurückgeben

    zu verstehen?


    Wenn keiner was dagegen hat kann ich gerne diese Änderung machen

    Zumindest von mir wird es da keinen Einspruch geben.


    Gruss,

    S:oren

    Mein Verstaendnis mal zusammengefasst:

    Der Raspi hat ein Problem mit surfaces grosser als 2048x2048 bei hardware-beschleunigtem OSD. Bei der simpelst moeglichen Implementierung im Ausgabedevice duerfen dann Pixmaps auch nicht groesser sein. Daraufhin legt der vdr-Core willkuerlich diese Aufloesung als Obergrenze fuer sein Software-OSD fest. Skins duerfen diese Grenze aber aendern!?


    Nun reichen 2048x2048 nicht mal mehr fuer die sichtbare Bildschirmaufloesung. Dann legt man wieder willkuerlich 4096x4096 fest, unabhaengig von den tatsaechlich vorhandenen Ressourcen im System, womit weder den eventuellen Erfordernissen im Ausgabedevice (die meisten nutzen die Software-Implementierung, die nur durch den vorhandenen Hauptspeicher begrenzt ist, und nur fuer die gilt dieser Wert), noch den Wuenschen eines Skin gedient ist.


    Bin ich der Einzige, der das absurd findet?


    Gruss,

    S:oren

    und unter linux-4.15.0/ liegt dann das ganze entpackt und mit eingespielten Patches

    Auf den ersten Blick ist das, was unter linux-4.15.0/ liegt, dann identisch zu dem (und genauso "kaputt"), was ich oben mit dem

    tar xjf /usr/src/linux-source-4.15.0.tar.bz2

    ausgepackt hatte. Aber wie immer gibt es mehr als einen Weg zum Ziel.

    Die "komischen" Versionsnummern in den Sourcen scheinen dann immerhin konsistent zu sein. Den "Trick" mit dem Ueberschreiben der KERNELVERSION habe ich uebrigens auch aus dem Ubuntu-Build-Skript, scheint da so ueblich zu sein...


    Gruss,

    S:oren

    Haettest Du wie oben beschrieben 4.15.0 installiert, dann wuerde ich eine Modulsignatur 4.15.0 (oder allenfalls 4.15.0-generic) erwarten, auch noch nicht 4.15.0-48-generic wie benoetigt.

    Anscheinend ist bei Ubuntu alles anders, ich "liebe" diese Distribution. Jedenfalls sehe ich auch, dass eine installierte Ubuntu-linux-source in Version 4.15.0-48.51 sich selbst als 4.15.18 bezeichnet. Gruselig.


    Folgendes Vorgehen

    ergibt zumindest mal saa716x-Module, die sich unter einem Kernel 4.15.0-48-generic laden lassen.

    Leider (oder zum Glück?) habe ich keinen Ubuntu-Rechner mit S2-6400. Ob die Module funktionieren, kann ich also nicht testen. Ich hoffe das Beste...


    Gruss,

    S:oren

    Es ist fuer mich schwer nachzuvollziehen, welche Sourcen Du genau wie installiert hast.

    Fakt ist, die Module sagen (auch die neu generierte config), es waere ein Kernel 4.15.18. Das wird dann auch so sein.


    Haettest Du wie oben beschrieben 4.15.0 installiert, dann wuerde ich eine Modulsignatur 4.15.0 (oder allenfalls 4.15.0-generic) erwarten, auch noch nicht 4.15.0-48-generic wie benoetigt.


    Ich weiss auch nicht, wie man bei Ubuntu die Kernel-Sourcen richtig installiert, da muss es aber doch Anleitungen geben!? Falls sonst niemand eine Idee hat, kann ich das heute Abend (?) mal ausprobieren...


    Gruss,

    S:oren

    Du hast den Treiber anscheinend mit einem Stable-Kernel 4.15.18 gebaut, und noch den Distro-Kernel 4.15.0-48-generic laufen.


    Ich kann nur immer wieder den Hinweis wiederholen, die 2 verschiedenen Wege zum Bauen und Nutzen des Treibers (Mainline/Stable- oder Distro-Kernel) nicht zu vermischen...


    Gruss,

    S:oren

    Leider sind die Infos zu den beiden Varianten, den Treiber zu bauen, etwas verstreut hier im Forum.

    Neben diesem und dem oben verlinkten Thread gab es kürzlich hier nochmal ein ganz kurze Anleitung. Aber auch sonst haben verschiedene User schon Anleitungen für verschiedene Linux-Distributionen gepostet.


    Konkrete Fragen beantworte ich gerne, eine allgemeingültige Anleitung für beliebige Distros auf allen denkbaren Rechnerarchitekturen mit verschiedenen Bootloadern habe ich leider auch nicht.


    Gruss,

    S:oren