[gelöst] DVB: Digital Devices DuoFlex CT im DVB-T-Betrieb. Initialisierung der Frontends als DVB-T

  • Hallo beisammen,


    ich eröffne mal einen neuen Thread und fasse den (meinen) bisherigen Kenntnisstand zu o.a. Problematik zusammen:


    Problem:
    Die Digital Devices DuoFlex CT hat zwei Tuner, die jeweils als DVB-C- oder DVB-T-Tuner initialisiert werden können.
    Beim Laden des Treibers werden zwei Adapter mit je zwei Frontends angelegt:


    Soweit ich weiß, ist Frontend0 das DVB-C-Frontend, Frontend1 das DVB-T-Frontend.
    Greift der VDR auf die Frontends zu, werden die Tuner als DVB-C initialisiert und stehen für DVB-T nicht mehr zur Verfügung.
    Es hilft dann auch nicht, mit dem dynamite-Plugin das Frontend1 anzuhängen.
    Hängt die Karte mit der DVB-C-Initialisierung an DVB-T-Input, wirft der Treiber (natürlich) Fehler aus, VDR zeigt "No signal".


    Abhilfe schafft das Umkopieren der Frontends nach Initialisieren des Treibers vor dem Start des VDR:
    mv /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend0.disabled
    mv /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/frontend0


    Dies hat aber den Nachteil, dass der Systemstart verzögert wird bzw. bei yaVDR der meisterhaft getimte Startprozess durcheinandergerät.


    Es löst aber das Problem, dass der Treiber beim Start nur für Frontend0 auch dvr und demux anlegt:



    Wenn ich das Dynamite-Plugin nutze, um nur Frontend1 zu laden, fehlen mir demux1 und dvr1.
    Daher meine ich derzeit, dass eine Lösung über die Kombination dynamite/udev allein möglicherweise nicht zielführend ist.


    keine_Ahnung hat vorgeschlagen , das Kopieren via upstart-script zu regeln, das aber an die Registrierung der Frontends gekoppelt ist. Greift es vorher, wirft es (natürlich) File-not-found-Fehlermeldungen aus.


    Die Vorgehensweise wäre dann so:
    1. Der Treiber registriert die Frontends.
    2. Dadurch löst der upstart-job aus, der frontend1 zu frontend0 macht.
    3. Der VDR darf bis dahin nicht auf das frontend zugreifen, weil er sonst das alte frontend0 initialisiert und der Tuner dann auf DVB-C gelockt ist.
    4. Falls das Dynamite-Plugin standardmäßig greift, muss man ihm evtl. sagen, dass es nach Registrierung der Frontends noch einen kurzen Moment warten soll.




    Ich verweise auch auf die (yaVDR-spezifische) Diskussion hier .


    Einen Ansatz habe ich hier gefunden, eine udev-Regel, die für jedes Frontend einen Adapter anlegt:

    Code
    /etc/udev/rules.d/10-persistent-dvb.rules    SUBSYSTEM=="dvb", ATTRS{device}=="0x0374", PROGRAM="/bin/sh -c ' K=%k; K=$${K#dvb}; A=$(echo -n $K | tail -c -1); A=$(echo 100+$A | bc); N=$${K#*.}; N=$(echo -n $N | head -c -1); printf dvb/adapter%%s/%%s0 $A $N; exit 0'", SYMLINK+="%c"

    Das Funktionieren setzt aber voraus, dass ich dann in einer (zweiten) udev-Regel die so angelegten Adapter blacklisten kann, damit frontend0 (DVB-C) nicht angesteuert wird. Evtl. kann man beide Regeln auch mergen bzw. so filtern, dass nur die frontend1s als adapter gelistet oder die frontend0s weggeworfen werden.
    Aber erstmal muss ich die Regel testen, ob mit ihr mit den frontends auch dvr und demuxe angelegt werden.


    Das werde ich die nächsten vier Tage wegen Urlaubs leider nicht schaffen.


    L.B.Q.R.img, #cubbies-overlay{ -moz-transition-property: margin, box-shadow, z-index; -moz-transition-duration: 0.1s; -webkit-transition-property: margin, box-shadow, z-index; -webkit-transition-duration: 0.1s; }
    .cubbies-selected{ z-index: 9999; box-shadow: 3px 3px 8px -1px blue !important; cursor: pointer !important; margin: -3px 3px 3px -3px; }
    .cubbies-selected:active{ box-shadow: 2px 2px 5px -1px darkblue !important; margin: -1px 1px 1px -1px; }
    #cubbies-overlay{ position: fixed; z-index: 9999; bottom: 30px; left: 30px; box-shadow: 0 2px 3px rgba(0,0,0,0.8); border: none; }
    #cubbies-overlay:hover{ box-shadow: 0 2px 3px rgb(0,0,0); }

    yaVDR 0.4pre alpha - (VDR 1.7.18, Kernel 2.6.38-11-generic)
    ASRock A330ION 4GB DDR2 - OCZ Agility SSD als / - WD Green Caviar 1TB & 2 TB xfs - Terratec Cinergy 2400i (instabil mit handgebautem Treiber, ausgebaut) - DD DuoFlex CT mit T (läuft noch nicht) - Antec Remote Fusion mit Soundgraph Imon 15c2:0038 - Harmony One (läuft ootb als Soundgraph Imon programmiert)

    Einmal editiert, zuletzt von Lebochequirit ()

  • Mein (schamlos kopierter) Entwurf einer UDEV-Regel 10-persistent-dvb.rules:

    Code
    SUBSYSTEM=="dvb", ATTRS{device}=="0x0ac4", PROGRAM="/bin/sh -c ' K=%k; K=$${K#dvb}; A=$(echo -n $K | tail -c -1); A=$(echo 100+$A | bc); N=$${K#*.}; N=$(echo -n $N | head -c -1); printf dvb/adapter%%s/%%s0 $A $N; exit 0'", SYMLINK+="%c"


    sorgt jetzt dafür, dass folgende Adapter und Symlinks angelegt werden:


    Jetzt müsste man Dynamite sagen, dass es nur die Adapter 100 und 101 ansteuern darf und nicht Adapter 0 und 1.
    Das funktioniert mit einer weiteren, später getriggerten UDEV-Rule 41-dynamite-prevent.rules

    Code
    ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", KERNEL=="dvb[01].frontend0", ENV{dynamite_attach}="no"


    Das hat soweit funktioniert, ich betrachte es mal als proof-of-concept.


    Jetzt bedarf es noch einiger Anpassungen in der ersten UDEV-Regel, um die Symlinks richtig zu setzen, denn
    gewünscht ist folgendes:



    Falls da einer der Meistercoder helfen kann - ich werde ne Weile dafür brauchen, weil ich so selten code (und jetzt ein paar Tage afk bin).
    Ich würde die Kopieraktion wohl in ein eigenes Script auslagern, weil sich das leichter überblicken lässt.
    Das könnte man dann in der UDEV-Regel mit RUN+="/pfad/zum/dvb-kopier/script" abfeuern.


    Fernziel:
    Wenn man dem Script Parameter übergibt, die man aus einer conf-Datei (nicht notwendigerweise /etc/vdr/plugin-dynamite.conf) ausliest, kann man das vielleicht auch für andere brauchbar machen.

    yaVDR 0.4pre alpha - (VDR 1.7.18, Kernel 2.6.38-11-generic)
    ASRock A330ION 4GB DDR2 - OCZ Agility SSD als / - WD Green Caviar 1TB & 2 TB xfs - Terratec Cinergy 2400i (instabil mit handgebautem Treiber, ausgebaut) - DD DuoFlex CT mit T (läuft noch nicht) - Antec Remote Fusion mit Soundgraph Imon 15c2:0038 - Harmony One (läuft ootb als Soundgraph Imon programmiert)

  • Moin!


    Das sieht mir viel zu kompliziert aus, das geht einfacher... :)


    Du willst aus adapterX/frontend0 irgendwas machen und adapterX/frontend1 als adapterX/frontend0 anlegen. Ohne es jetzt testen zu können und einfach mal (schamlos ;-)) die udev-Regel von Keine_Ahnung angepasst:

    Code
    ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", KERNEL=="dvb[01].frontend0", NAME:="dvb/adapter$env{DVB_DEVICE_NUM}/frontend.disabled", ENV{dynamite_attach}="no"
    ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", KERNEL=="dvb[01].frontend1", NAME:="dvb/adapter$env{DVB_DEVICE_NUM}/frontend0"


    Alle anderen Devicenodes sind ja schon so, wie sie sein sollen.


    Hilft's? Aber erst mal schönen Urlaub... :)


    Lars.

  • Dazu ergänzend, man sollte sich unbedingt die Mühe machen und seine Geräte unter /sys suchen.


    Bei mir ist eine TV Karte z.B. unter "/sys/bus/pci/devices/0000\:00\:06.0", also kann ich per
    ---
    udevadm test /sys/bus/pci/devices/0000\:00\:06.0/dvb/dvb0.frontend0
    ---
    schauen was udev aus den Regeln mit dem frontend 0 von adapter 0 macht (und entsprechend angepasst auch demux0 usw.). Weil nach den mühsam selbstgebastelten Regeln kommen noch viele andere (von /lib/udev/rules.d) die da auch noch dran rumbasteln und im Zweifel alles wieder kaputtmachen ;)


    Ohne diese Kontrolle ist udev nen extrem frustriendes stochern im Nebel. Mit dieser Kontrolle klappt das aber super.


    BTW: OPTIONS="ignore_device" gibt nicht mehr, das verrät einen aber auch niemand ;)


    cu

  • In der Tat, das ist schön einfach und erklärt mir auch, wo ich den Input bzw. die Variablen herkriege.
    Das bringt mir immerhin ein funktionierendes Frontend in adapter0:



    Das blacklisten funktioniert auch leidlich, in dynamite ist
    adapter1/frontend0 gelistet.


    Warum jetzt für Adapter0 und Adapter1 verschiedene Ergebnisse rauskommen (die beide nicht exakt das Gewünschte treffen), und in Adapter0 zwar ein Frontend0 existiert, das aber dynamite nicht übernimmt, versuche ich dann doch nach dem Urlaub hinzufrickeln. Es mag an der Reihenfolge der Registrierung der devices liegen.
    Evtl. meldet registriert der Treiber in Adapter1 das frontend0 erst nachdem die Regel für (beide Adapter) schon durch Adapter0 getriggert wurde.


    Hm... Immerhin hab ich schon gepackt :)


    Vielen Dank für die Hilfe,


    bis dann


    L.B.Q.R.

    yaVDR 0.4pre alpha - (VDR 1.7.18, Kernel 2.6.38-11-generic)
    ASRock A330ION 4GB DDR2 - OCZ Agility SSD als / - WD Green Caviar 1TB & 2 TB xfs - Terratec Cinergy 2400i (instabil mit handgebautem Treiber, ausgebaut) - DD DuoFlex CT mit T (läuft noch nicht) - Antec Remote Fusion mit Soundgraph Imon 15c2:0038 - Harmony One (läuft ootb als Soundgraph Imon programmiert)

  • Moin!


    Zur Info bei der Fehlersuche: dynamite holt sich die DVB-Frontends per udev-Enumeration. Keine Ahnung, was da dann an Pfaden herauskommt. Da der vdr Adapter- und Frontend-Nr. möchte, versucht dynamite dann aus dem Devicepfad diese Nummern zu extrahieren. Wenn es aber an deinem frontend0 z.B. nicht vorbeikommt, weil dynamite das als frontend1 bekommt o.ä., wird's natürlich schwierig.
    (mal sehen, vielleicht gehe ich irgendwann mal den vdr an und entwickle einen Patch, der mit Devicepfaden in cDvbDevice zurecht kommt und alles über udev holt... wäre meiner Meinung nach schöner als mit den Nummern - ist aber gaaanz weit unten auf meiner Liste ;-))


    Schau doch mal "modinfo" deiner Treibermodule an, vielleicht gibt's da doch eine Option, um für jedes Frontend einen Adapter anlegen zu lassen. Einen ganzen Adapter zu ignorieren, ist wesentlich einfacher, als einen Multifrontend-Adapter zu zerlegen... :)


    Ach ja, die Rechte und Gruppenzugehörigkeit sieht auch noch nicht so ganz gut aus.


    Lars.

  • Warum jetzt für Adapter0 und Adapter1 verschiedene Ergebnisse rauskommen (die beide nicht exakt das Gewünschte treffen), und in Adapter0 zwar ein Frontend0 existiert, das aber dynamite nicht übernimmt, versuche ich dann doch nach dem Urlaub hinzufrickeln.


    Wie gesagt "udevadm test" nutzen. Dann musst du nicht raten, dann weisst du das einfach.


    Sone Ausgabe sieht dann z.B. so aus



    versucht dynamite dann aus dem Devicepfad diese Nummern zu extrahieren.


    Dann ist ja klar warum der Trick hier fehlschlägt. Der DEVPATH bleibt bei den Kernelnamen. Da hilft alles umbenennerei nicht. Evtl. wäre es hie reinfacher erstmal auf dynamite zu verzichten bis es im vdr vernünftig läuft. Danach kann man dann testen obs auch mit dynamite geht.



    cu

  • Moin!


    dynamite benutzt udev_device_get_devnode, die Doku sagt:

    Zitat

    Retrieve the device node file name belonging to the udev device. The path is an absolute path, and starts with the device directory.


    Das müsste doch eigentlich das umbenannte Frontend sein, dass im Dateisystem zu sehen ist, oder?
    Heute abend hab ich Zeit, da mal ein wenig rumzuprobieren.


    Lars.

  • Moin,
    bin aus dem Urlaub zurück und hab gerade mal nachgelesen, was sich hier so getan hat.
    Für meine Konfiguration (AsRock A330ION, DD DuoFlex CT) liegen die Devices in
    /bus/pci/devices/0000:00:0c.0/0000:02:00.0/dvb/



    Ich denke, hier ist ein erster Ansatzpunkt, um Fehler auszuschalten:

    Code
    udev_event_execute_rules: kernel-provided name 'dvb/adapter0/frontend0' and NAME= 'dvb/adapter0/frontend.disabled' disagree, please use SYMLINK+= or change the kernel to provide the proper name


    und weiter:


    Für den zweiten Adapter, bei dem Lars' Regelvorschlag hier nicht funktioniert hat:


    und für /dev/dvb/adapter1/frontend1:


    So. Eingehende Analyse folgt diese Woche.


    Schönen Abend,


    L.B.Q.R.

    yaVDR 0.4pre alpha - (VDR 1.7.18, Kernel 2.6.38-11-generic)
    ASRock A330ION 4GB DDR2 - OCZ Agility SSD als / - WD Green Caviar 1TB & 2 TB xfs - Terratec Cinergy 2400i (instabil mit handgebautem Treiber, ausgebaut) - DD DuoFlex CT mit T (läuft noch nicht) - Antec Remote Fusion mit Soundgraph Imon 15c2:0038 - Harmony One (läuft ootb als Soundgraph Imon programmiert)

  • Moin!


    Sieht so aus, als ob DVB_ADAPTER_NUM besser wäre als DVB_DEVICE_NUM.


    Vielleicht sollten wir mal versuchen, die Regeln ausführlich hinzuschreiben:

    Code
    ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", KERNEL=="dvb0.frontend0", NAME:="dvb/adapter0/frontend.disabled", ENV{dynamite_attach}="no"
    ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", KERNEL=="dvb0.frontend1", NAME:="dvb/adapter0/frontend0"
    ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", KERNEL=="dvb1.frontend0", NAME:="dvb/adapter1/frontend.disabled", ENV{dynamite_attach}="no"
    ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", KERNEL=="dvb1.frontend1", NAME:="dvb/adapter1/frontend0"


    Und es wäre prima, wenn du mal die Ausgabe von modinfo deiner Treibermodule posten könntest.


    Lars.

  • Hihi... die modinfos habe ich noch schnell am "Gerade aus dem Urlaub zurück und schon wieder am Laptop"-WAF-LOCK vorbei geschmuggelt, s.u.. Die ausführliche UDEV-Regel werde ich dann mal ab morgen probieren.
    Könnte es ein Problem sein, dass wir versuchen, einen anderen als den Kernel-provided Name zuweisen? Nicht, dass der vorrangig ist - aber soweit ich die Ausgabe von udevadm test verstehe, ist das nur ne Warnung, die Nodes werden trotzdem erstellt.




    Gute Nacht,


    L.B.Q.R.

    yaVDR 0.4pre alpha - (VDR 1.7.18, Kernel 2.6.38-11-generic)
    ASRock A330ION 4GB DDR2 - OCZ Agility SSD als / - WD Green Caviar 1TB & 2 TB xfs - Terratec Cinergy 2400i (instabil mit handgebautem Treiber, ausgebaut) - DD DuoFlex CT mit T (läuft noch nicht) - Antec Remote Fusion mit Soundgraph Imon 15c2:0038 - Harmony One (läuft ootb als Soundgraph Imon programmiert)

  • Also. Mit einer vierzeiligen udev-Regel, die alle Adapter einzeln anspricht, scheint es zunächst zu funktionieren.
    Die Adapter werden angelegt und richtig als DVB-T initialisiert:



    In Dynamite werden beide Adapter0 gelistet.


    Trotzdem habe ich noch Probleme.
    Der VDR fällt nach längerer Zeit auf "No Signal". Der EPG wird angezeigt, das kernel.log wirft aber keine Fehlermeldungen aus, die auf DVB-Streamabreisse oder sowas hindeuten. Dieses Verhalten habe ich bisher aber auch nicht konsequent beobachten und eingrenzen können, weil ich diese Woche kaum am Rechner war.


    Was ich bisher ahne:
    Die Frontends werden von dynamite ziemlich verzögert eingebunden, das merkt man an folgendem Verhalten:
    Der VDR startet mit einem Fernsehbild und warnt vor Timerkonflikten, die erkennen lassen, dass nur ein Tuner zur Verfügung steht.
    Danach zeigt er kurz No Signal und dann wieder ein Fernsehbild, die Timerkonflikte sind weg - das zweite Frontend ist da. Ob das im Zusammenhang damit steht, dass irgendwann beide Frontends richtig initialisiert und eingebunden sind, trotzdem aber "No Signal" kommt, weiß ich noch nicht.


    Aufgefallen ist mir im log:

    Code
    [   73.971996] vdr[983]: segfault at 7c7 ip 000000000046fe20 sp 00007fff1a655ed0 error 4 in vdr[400000+142000]


    Ich denke, dieser segfault tritt beim Einbinden des zweiten Tuners ein, das würde den holprigen Übergang beim Start erklären.
    Mir scheint das aber eher ein Treiberproblem oder ein Dynamite-Problem zu sein. Das Initialisieren der Frontends als DVB-T geht. Daher betrachte ich die eigentliche Baustelle dieses Threads erstmal als gelöst. Hat noch jemand die Karte im DVB-T-Betrieb und die hier vorgeschlagene UDEV-Regel ausprobieren können?


    Das etwas instabile Verhalten beim Einbinden der Frontends würde ich hier gern weiterdiskutieren. Dazu brauche ich allerdings noch etwas Empirie.


    Schönes Wochenende und vielen Dank für alle bisherige Hilfe,


    L.B.Q.R.

    yaVDR 0.4pre alpha - (VDR 1.7.18, Kernel 2.6.38-11-generic)
    ASRock A330ION 4GB DDR2 - OCZ Agility SSD als / - WD Green Caviar 1TB & 2 TB xfs - Terratec Cinergy 2400i (instabil mit handgebautem Treiber, ausgebaut) - DD DuoFlex CT mit T (läuft noch nicht) - Antec Remote Fusion mit Soundgraph Imon 15c2:0038 - Harmony One (läuft ootb als Soundgraph Imon programmiert)

  • Also. Mit einer vierzeiligen udev-Regel, die alle Adapter einzeln anspricht, scheint es zunächst zu funktionieren.
    Die Adapter werden angelegt und richtig als DVB-T initialisiert:


    Du hast zu viele Frontends. frontend0 und frontend1 zeigen jeweils auf das gleiche phys. Device. Irgendwann wird der VDR das nächste freie Frontend für eine Aufzeichnung oder den epg Scan benutzen wollen. Wenn dann auf einen anderen Transponder getunt wird, liefert der PID-Filter für den zu schauenden Kanal keine Daten mehr.


    Gruß
    e9hack

  • Moin!


    Ich hatte eigentlich gehofft, dass die "frontend1" gar nicht erst angelegt werden. Würdest du es bitte noch mal ohne den Doppelpunkt bei NAME probieren?


    Code
    ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", KERNEL=="dvb0.frontend0", NAME="dvb/adapter0/frontend.disabled", ENV{dynamite_attach}="no"
    ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", KERNEL=="dvb0.frontend1", NAME="dvb/adapter0/frontend0"
    ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", KERNEL=="dvb1.frontend0", NAME="dvb/adapter1/frontend.disabled", ENV{dynamite_attach}="no"
    ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", KERNEL=="dvb1.frontend1", NAME="dvb/adapter1/frontend0"


    udev ist für Quereinsteiger nicht unbedingt leicht zu verstehen...


    Lars.

  • udevadm test, udevadm test, udevadm test und nochmal udevadm test ;)


    Nicht raten, udevadm test zeigt GENAU welche Zeile welcher UDEV Regel welche Links anlegt. Dan weiss man 100%ig wo das frontend1 herkommt.


    cu


    PS: Geht natürlich an Lebochequirit, post emal die udevadm test Ausgaben

  • Du hast ja recht, e9hack :)


    Die udevadm tests MIT Doppelpunkt sind im Anhang.


    Und weil ich das Raten nicht lassen kann:
    Entfernen des Doppelpunkts bringt augenscheinlich erstmal nix.


    Jetzt versuche ich erstmal diese logs zu verstehen.


    L.B.Q.R.


  • Jetzt versuche ich erstmal diese logs zu verstehen.


    Ich auch, wo kommt frontend1 her?


    Versuche mal spasseshalber frontend1 zu löschen und neu zu booten. Ansonsten durchsuche mal /lib/udev/rulesd nach "frontend" und kommentiere dort mal probeweise die Regeln aus wo das drin vorkommt. Weil ich vermutestark das dort drin auch noch ne Regel ist die das anlegt, wobei das eigentlich nicht passieren dürfte.


    41-dvbname.rules in 99-dvbname.rules umbenennen könnte auch nen Versuch Wert sein.


    cu

  • Moin!


    Hab da was gefunden:


    Das bedeutet also, dass das Umbiegen der Devicenodes auf andere Namen irgendwann nicht mehr funktionieren wird. Man soll SYMLINK+= benutzen.
    Ich hab jetzt allerdings noch nicht herausgefunden, wie man es schafft, keine Devices mit dem Kernelnamen anzulegen.


    Ich benutze hier Lucid mit udev 151, deshalb sehe ich die Warnung nicht und es funktioniert problemlos mit NAME=.


    Auf Dauer würde ich mir wünschen, dass der Treiber einen Parameter bekommt, damit nur das eine Frontend für das gewünschte DVB-System angelegt wird. Es ist ja nicht so, dass man DVB-C und DVB-T ständig im Wechsel betreibt, sondern die Karte einmal verkabelt und gut ist. Und wenn man doch mal wechselt, muss man eben den Treiber neu laden, das sollte auch kein Problem sein.


    Lars.

  • Hi Lars,


    diese NAME-Symlink-Geschichte hatte ich weiter oben oder in irgendnem anderen Thread schon mal angemerkt, das war mir auch schon aufgefallen.


    Es wird möglicherweise gar nicht helfen, wenn wir nen Symlink hinkriegen - denn der muss ja so heißen wie ein frontend, dem der Kernel schon einen Namen gegeben hat.
    Man könnte höchstens einen Weg finden, dem Kernel per Udev zu sagen, dass er bestimmte Geräte gar nicht erst belegt.
    Dann wäre der Name für nen Symlink frei.


    Oder wir basteln an meinem ursprünglichen kopieren-per-UDEV-Weg weiter.


    Das mit dem Parameter im Treiber wäre NATÜRLICH die einfache und wünschenswerte Lösung, aber UFO sieht da momentan nicht viel Aussicht.


    Die UDEV-Regel umzubenennen werde ich auch versuchen, denn irgendwie greift ja nochmal eine 72-acl-dingens.rule nochmal auf die Frontends zu, vielleicht mixt die da rum. Ich werde berichten.


    L.B.Q.R.

    yaVDR 0.4pre alpha - (VDR 1.7.18, Kernel 2.6.38-11-generic)
    ASRock A330ION 4GB DDR2 - OCZ Agility SSD als / - WD Green Caviar 1TB & 2 TB xfs - Terratec Cinergy 2400i (instabil mit handgebautem Treiber, ausgebaut) - DD DuoFlex CT mit T (läuft noch nicht) - Antec Remote Fusion mit Soundgraph Imon 15c2:0038 - Harmony One (läuft ootb als Soundgraph Imon programmiert)

  • Man könnte höchstens einen Weg finden, dem Kernel per Udev zu sagen, dass er bestimmte Geräte gar nicht erst belegt.


    Das gabs ja schonmal in UDEV, ist aber wohl wieder rausgeflogen.


    cu

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!