Pearl Display Yavdr *TODO* install

Zitat von Keine_Ahnung

Es sieht so aus als ob in yaVDR das Display der Gruppe vdr zugeordnet wird. Jedenfalls wenn man sich sich gepostete 60-libglcddrivers1.rules anschaut, die kommt ja dem Namen nach aus dem libglcddrivers1 Paket.

Echt? Dann hab ich ne andere Version als du. Hab grad nochmal in das yaVDR Source-Paket geschaut (graphlcd-base-0.1.9+git20120310).
Da gibts in debian/libglcddrivers1.install ne Zeile

99-graphlcd-base.rules                lib/udev/rules.d

und die 99-graphlcd-base.rules hat

#
# all displays / modules supported by graphlcd-base
#
# Futaba DM140-GINK VFD displays, incl. activity 5xx
ATTRS{idVendor}=="040b", ATTRS{idProduct}=="7001", GROUP="uucp", MODE="0660"
ATTRS{idVendor}=="1509", ATTRS{idProduct}=="925d", GROUP="uucp", MODE="0660"
# AX206DPF-based picture frames (modified firmware)
ATTRS{idVendor}=="1908", ATTRS{idProduct}=="0102", GROUP="uucp", MODE="0660"

Also Gruppe uucp.

Sehe ich dass richtig, dass diese "99-"er Rule die "60-"er Rule von derdoc überschreibt?

Gruß
superelchi

Zitat von superelchi

Sehe ich dass richtig, dass diese "99-"er Rule die "60-"er Rule von dercoc überschreibt?

Ja, nur eine Zuweisung in der Form "GROUP:="vdr"" würde durch eine spätere Regel nicht überschrieben. Also hast du recht, uucp ist hier die entschiedene Gruppe.

Aber da frage ich mich jetzt aber wo die "60-"er Rule herkommt? Der Namenskonvention nach aus einem Debian Paket. Aber du hast recht, im aktuellen yaVDR Paket ist die 99-graphlcd-base.rules mit uucp drin.

Irgendwie alles ziemlich verworren.

cu

Zitat von Keine_Ahnung

Aber da frage ich mich jetzt aber wo die "60-"er Rule herkommt? Der Namenskonvention nach aus einem Debian Paket.

Vielleicht von hier? War übrigens ein Beitrag von dir. Vielleicht kam es dir deshalb so bekannt vor. Damals hatten wir ne heftige Diskussion mit wast welche rule / wohin / welcher user, etc. Wastl hat dann (als Autor sein gutes Recht) die "99-"er Regel mit dem uucp festgelegt.

BTW: sollt man da mal einen Bugreport machen, damit vdr bei der Installation der Gruppe uucp zugefügt wird? Da sind schon einige drüber gestolpert...

Gruß
superelchi

Zitat von superelchi

Vielleicht von hier?

Aber so was brauchen Debian Nutzer doch nicht manuell machen

Zitat von superelchi

War übrigens ein Beitrag von dir. Vielleicht kam es dir deshalb so bekannt vor. Damals hatten wir ne heftige Diskussion mit wast welche rule / wohin / welcher user, etc. Wastl hat dann (als Autor sein gutes Recht) die "99-"er Regel mit dem uucp festgelegt.

Ach, was ich mich schon mit den Paketen beschäftigt habe... Mit dem letzten git Stand kann man die UDEV Regel mittels dh_installudev korrekt (60-libglcddrivers2.rules) installieren lassen. Ich habe in diese Pakete eh noch massig Arbeit reingesteckt, die yaVDR Pakete sind da etwas outdated. Wenn der zuständige bei yaVDR Interesse hat kann ich ja mal meine zum diffen zur Verfügung stellen.

Zitat von superelchi

BTW: sollt man da mal einen Bugreport machen, damit vdr bei der Installation der Gruppe uucp zugefügt wird? Da sind schon einige drüber gestolpert...

Wäre sinnvoll, aber das muss das vdr-plugin-graphlcd Paket machen. Und AFAIK ist es schon vorgesehen das Pluginpakete den vdr einfach einer Gruppe hinzufügen können, wäre also nicht schwer.

Evtl. wäre auch zu überlegen bei diesen ganzen Displayhilfsprogrammen das http://de.wikipedia.org/wiki/Setuid Bit zu setzen. Dann stolpern auch weniger über die Rechteprobleme.

cu

bitte nicht 'korrekt' hier schreiben. nur weil es vielleicht unter debian & co. so gemacht wird.

das ist einer der gruende, weshalb ich debian & co aus ganzem herzen ablehne.
weil nicht nur einmal es vorgekommen ist, dass die debian-community sich etwas irgendwie einbildet und dann das fuer ganz 'linux', wenn nicht sogar fuer ganz unix das so postuliert und als einzig richtig und wahr annimmt ...

Zitat von wastl

bitte nicht 'korrekt' hier schreiben. nur weil es vielleicht unter debian & co. so gemacht wird.

Das "korrekt" bezog sich hier direkt auf das Debian System, also ich meinte "im Debian Sinne korrekt". Denn das die UDEV Regeln nach dem Paket benannt sind das die dazugehörige Lib installiert hat macht schon Sinn in Bezug auf die Übersichtlichkeit (weil alle anderen Debian Pakete das genauso machen). Genau wie die Tatsache das das Debian Paket diese Regel nach /lib/udev/rules.d installiert.

Aber da brauchen wir uns ja auch gar nicht auf irgendwas einigen was für alle korrekt wäre, denn das Debian Paket enthält den unmodifizierten graphlcd-base Upstreamcode und baut daraus ein völlig korrektes (nach Debian Policity) Paket. Damit sind dann alle glücklich, die make install Fraktion genauso wie die Debian Paket Fraktion

Denn, unabhängig davon obs Debian jetzt richtig oder falsch macht, wenn man auf Debian arbeiten will dann muss man sich an die Debian Regeln halten, d.h. die Debian Pakete müssen der Debian Policity folgen. Will man das nicht (weil man evtl. die Debian Regeln nicht mag) dann muss/sollte man sich ne andere Distribution suchen

cu

Hallo,
vielen Dank, dass ihr euch so ausführlich mit meinem Problem beschäftigt. Wobei ich dann nur noch respektvoll zuhören kann

Keine_Ahnung:

Zitat

Du hast unter /root/dpf/fw/vdr-plugin-graphlcd-0.3.0+git20110829/ den
graphlcd-base Quellcode (warum eigentlich?), du hast da doch nicht etwa
"make install" gemacht?

Nein, mein dpf/... befindet sich in home/doc/... , aber in #57 steht:

Zitat

Testen geht dann z.B. so:

Quellcode
1
showpic -c /etc/graphlcd.conf -d ax206dpf -u -i /root/dpf/fw/vdr-plugin-graphlcd-0.3.0+git20110829/graphlcd/logos/channels/SBS6_l.glcd
(siehe Bild2)

Deshalb hatte ich gefragt, ob das evtl. bei mir im falschen Verzeichnis liegt.

Zitat

Aber da frage ich mich jetzt aber wo die "60-"er Rule herkommt?

Auch wieder von #57:

Zitat

Schauen ob es eine udev Regel gibt.

(Pfad: /etc/udev/rules.d/)

Gibt es diese nicht so könnt ihr die angehängt Datei nehmen.

Weil bisher da keine drin lag, die etwas mit dem Rahmen zu tun hat (meiner Meinung nach).

Ich nutze yavdr. Hab ich da evtl. Dinge mit Debian durcheinander gebracht?

Ich habe seit gestern erst mal noch nichts weiter gemacht, um nicht weitere Verschlimmbesserungen vor zu nehmen.

Superelchis Frage, als wer ich das mache, hat mir keine Ruhe gelassen. Ich glaube, ich weiß jetzt, was ich prinzipiell falsch mache.
Dazu muss ich sagen, dass ich mc deshalb schätze, weil ich damit schnell navigieren kann, Dateien editieren kann (nano) und ich es von gaaanz früher als NortonCommander kenne. Jetzt eben habe ich festgestellt, dass dass als root läuft (sudo mc). Manche anderen Befehle und Anpassungen habe ich direkt ausgeführt, also als doc. Nur dort, wo es nicht ging, mit sudo Befehl.

Mann Mann Mann, da habe ich wohl einiges durcheinander gebracht....

PS. irgendwo hatte mal gda in seiner knallhart auf den Punkt bringenden Art geschrieben, dass wenn man abschreibt, der Verstand ausgeschaltet wird (oder so ähnlich). Recht hat er, aber das ist für mich die einzige Möglichkeit, an diesem schönen Projekt teilnehmen zu können.
Ist so..., dafür kann ich andere Dinge besser, die aber nicht Gegenstand des Forums sind

Tja, ist wirklich ein Problem einfach so (ohne zu wissen warum eigentlich) irgendwelche Sachen abzutippen

Für dich hätte es gereicht unter Windows die passenden Firmware aufs Display zu flashen und im yaVDR Webinterface das graphlcd Plugin zu installieren.

Dann dem vdr User der Gruppe uucp hinzufügen und in /etv/vdr/plugins/plugin.graphlcd.conf das Display und den Skin (erstmal den vorinstallierten touchcol) aktivieren. Dann hättest du schonmal ein funktionierendes Display.

cu

derdoc
Ah, habs nicht ganz verstanden. Läufts jetzt bei dir? Wenn nicht einfach weiterfragen.

Gruß
superelchi

Nein, es läuft noch nicht. Ich hatte auch, wie schon geschrieben, vorsichtshalber seit gestern nicht mehr verändert. Den Rahmen hatte ich schon letztes Jahr gehackt, das ging nur mit der Windowsmethode. Aus beruflichen Gründen war ich dann erst mal fern von der Kiste und seit 2 Wochen gehts hier weiter. So habe ich wohl den Rahmen doppelt hacken wollen. Habe ich nun mit den Rechten was durcheinander gebracht, was ich rückgängig machen sollte.
Oder liegen die Dinge nur brach und stören nicht?
Könnte ich den Ordner /home/doc/dpf einfach löschen?

Wenn ich Keine _Ahnung recht verstehen muss ich "nur"

Zitat

Dann dem vdr User der Gruppe uucp hinzufügen

Bis vorhin wusste ich gar nichts von einer Gruppe uucp :-/
Im Moment bin ich wohl als doc unterwegs:

doc@yavdr:~$ id
uid=1000(doc) gid=1000(doc) Gruppen=1000(doc),24(cdrom),29(audio),44(video),113(admin)

Muss ich nun

sudo usermod -aG vdr uucp

machen?
Die /etv/vdr/plugins/plugin.graphlcd.conf hatte ich ja schon angepasst.

Zitat von derdoc

Habe ich nun mit den Rechten was durcheinander gebracht, was ich rückgängig machen sollte.
Oder liegen die Dinge nur brach und stören nicht?

Sollte eigendlich nix stören. Werden wir sehen.

Zitat von derdoc

Könnte ich den Ordner /home/doc/dpf einfach löschen?

Wenn du nicht noch irgendwelche Mods auf das Display schieben willst - ja. Wenn bei dir das Flashen unter Windows geht, brauchst dus sowieso nicht mehr. Für alle Mods gibts fertigen Firmware.

Mach mal das, nachdem das Display angeschlossen und im BSOH ist (vdr vorher stoppen!):

sudo showpic -d ax206dpf /usr/share/vdr-plugin-graphlcd/logos/channels/SAT.1_l.glcd

Wenn da was kommt ist alles okay. Einfach noch den/die User (bei dir doc und vdr) wie beschrieben mit usermod zur Gruppe 'uucp' hinzufügen.

Gruß
superelchi

Leider kommt nichts:

doc@YAVDR:~$ sudo stop vdr
[sudo] password for vr:
vdr stop/waiting
doc@YAVDR:~$ sudo showpic -d ax206dpf /usr/share/vdr-plugin-graphlcd/logos/channels/SAT.1_l.glcd
ERROR: Failed loading file /usr/share/vdr-plugin-graphlcd/logos/channels/SAT.1_l.glcd

Allerdings liegen im Ordner .../vdr-plugin-graphlcd/ nur die Ordner skins und fonts, kein channels-Ordner

Kommando zurück.
Habe noch mal apt-get install vdr-plugin-graphlcd
gemacht und nun ist der Ordner drin und TATAAA: das Sat-Logo ist auf dem Rahmen!!!

EDIT soll ich nun das machen:

sudo usermod -aG vdr uucp 
sudo usermod -aG doc uucp

Ich frag lieber zur Sicherheit

Ja, den User vdr zu uucp zufügen und dann läuft das Display.
Kannst dann zur Sicherheit nochmal testen mit

su vdr
showpic -d ax206dpf /usr/share/vdr-plugin-graphlcd/logos/channels/SAT.1_l.glcd

Fast geschafft!

Gruß
superelchi

Ich freu mich schon. Allerdings gibt es da noch ein Problem:

su vdr
Passwort:
su: Fehler bei Authentifizierung

Weder meins noch gar kein Passwort wird akzeptiert.

Für den "su vdr" musst du root sein.

Gruß
superelchi

Irgendwie pack ichs nicht. Hier mal der gesamte Dialog. VDR ist noch von der vorigen Runde gestoppt, der Rahmen im BSOH.

doc@YAVDR:~$ sudo showpic -d ax206dpf /usr/share/vdr-plugin-graphlcd/logos/channels/SAT.1_l.glcd
[sudo] password for doc:
doc@YAVDR:~$
doc@YAVDR:~$ sudo su
root@YAVDR:/home/doc# su vdr
vdr@YAVDR:/home/doc$ sudo showpic -d ax206dpf /usr/share/vdr-plugin-graphlcd/logos/channels/3SAT_l.glcd
[sudo] password for vdr:
Sorry, try again.

SAT.1 als User doc wird angezeigt, bei 3SAT als User vdr scheitere ich am Passwort.

Zitat von derdoc

Code

vdr@YAVDR:/home/doc$ sudo showpic -d ax206dpf /usr/share/vdr-plugin-graphlcd/logos/channels/3SAT_l.glcd

Du musst schon genauer lesen was superelchi schreibt. Es würde auch helfen wenn du versuchst zu verstehen was du tust.
Superelchi hat nichts von sudo showpic geschrieben. Das macht auch keinen Sinn. Mit sudo lässt du ein Programm mit root-Rechten ausführen.
Das darf der vdr aber nicht. Wozu gibst du dem vdr die Rechte das Programm selbst auszuführen, wenn du es dann doch über root versuchst?

Gerald

Ich hatte gehofft, du liest nicht mit

Zitat

Es würde auch helfen wenn du versuchst zu verstehen was du tust.

Ich weiß, der Erfolg ist mäßig. Ich vermute, das Ziel ist, als vdr das Logo aufzurufen. Das sudo war noch im Speicher, als ich den Befehl als doc aufrief.

Im Gegensatz zu doc findet vdr den Rahmen nicht:

vdr@YAVDR:/home/doc$ showpic -d ax206dpf /usr/share/vdr-plugin-graphlcd/logos/channels/SAT.1_l.glcd
Error: No matching USB device found!