Wenn das so funktioniert könnte das drinbleiben, dann könnten Distributionen ne Reihe Displays vorkonfigurieren.
Noch netter wäre es, wenn man den Eintrag per svdrpsend ändern könnte ;). Erstmal auf einen dummy setzen und wenn udev das Display erkannt hat dann den Treiber ändern.
Gerald
bleibt aber trotzdem beides eine halbe geschichte:
sowohl das vordefinieren von vielen displays (wird trotzdem immer nur fuer ein paar matchen) als auch das udev-zeug (usb-only).
Was aber immerhin 100% meiner Displays abdecken würde ;). Habe aber auch nur 3.
Gerald
[serdisp]
some=settings
Ist aber irgendwie überhaupt nicht INI-like. Die Konfiguration sollte immer duch die KEY=VALUE Zuweisungen innerhalb von Sektionen (das es die oft auch ausserhalt gibt halte ich schon für ne Unsitte) erfolgen. Die Sektionen [NAME] werden üblicherweise dazu benutzt um die Konfiguration in benamte Bereiche aufzuteilen. Und über den Sektionsnamen den Treiber zu wählen... na ich weiss nicht 
Aber das ist auch wieder so ein Thema bei dem 3 Leute 5 unterschiedliche Meinungen haben
cu
Danke für die Hinweise, ich habe die Pakete korrigiert. Die Fonts werden jetzt alle installiert und die Gruppe im udev rules file habe ich angepasst. Ich bin mit der Gruppe lp nicht so glücklich, weil mir die Gruppe vdr besser gefällt, aber da das display ja eventuell auch ohne vdr benutzt wird, habe ich es jetzt mal so übernommen.
Das mit "lp" war ja auch nur die schnelle Lösung. User "vdr" wird ja beim Installieren von vdr-plugin-graphlcd zu dieser Gruppe hinzugefügt. Sauberer wäre wohl das Anlegen einer neuen Gruppe wie "graphlcd" oder "libusb" zu der "vdr" dann hinzugefügt wird. Btw: wäre es nicht sinnvoll der udev-rule auch einen Namen wie "XX-graphlcd-usb.rules" oder "XX-libusb.rules" zu geben, da es ja wohl für alle USB-Displays gilt, die über libusb angesprochen werden?
Und wenn ich schon nerve: in debian/links vom vdr-plugin-graphlcd können die ersten beiden Links auf Vera*.ttf raus, wenn Du das ganze graphlcd/fonts Verzeichnis kopierst.
Gruß
superelchi
dh_installudev handelt das installieren von udev Regeln, wäre evtl. sinniger das zu nutzen (einfach unter debian/libglcddrivers1.udev speichern)? Weil da wird dann automatisch in postinst/preinst irgendwas cleveres dafür eingefügt.
Und anstatt generell alle USB Geräte freizugeben wäre evtl. sowas sinnig?
--
ATTR{idVendor}=="152a", ATTR{idProduct}=="8380", MODE="0666"
--
halt für jedes unterstützte Display eine Regel.
BTW: Die Fonts, der VDR nutzt fontconfig um die Fonts alleine zu finden, das sieht garnicht so kompleziert aus. IMHO wäre es schöner wenn graphlcd-base das auch so machen würde? Man kann dann ja weiterhin Fonts in /usr/local/share/fonts selber installieren. Aber die Fonts die von Packeten kommen werden halt so automatisch unterstützt ohne das man da verlinken muss oder kopieren.
BTW2: Das graphlcd-base Packet vergisst genfont mit aufzunehmen. Jedenfalls in 0.1.9+git20110812-1yavdr1~natty (die neue Version hatte ich noch nicht angeschaut).
cu
fuer die v. graphlcd-unterstuetzten usb-displays/module zb. ein
/etc/udev/rules/99-graphlcd.rules
Das ist ja Distributionspezifisch (also gehört hier wohl auch nicht in den Thread). Unter Debian/Ubunto wäre z.B. 60-libglcddrivers1.rules der default wenn ich das recht verstehe.
Und was hällst du von der fontconfig Sache? Der Code sollte sich im Prinzip vom VDR übernehmen lassen.
EDIT: gruppe=uucp und umask natuerlich 0660. alles andere (0666) ist schlampig.
0666 war ja nur als Notlösung gedacht weil ich nicht wusste das es schon ne Gruppenvereinbarung für Displays gibt.
cu
udev + seine rules ist nix distro-spezifisches (bzw. sollte es nicht sein).
das 99 zeigt nur die reihenfolge an (ganz hinten in der schlange ...) und wird von mir einstimmig festgelegt 
und die lib-versionsnummer hat da auch nix verloren ...
wie gesagt: ich moechte das eigentl. fixteil v. graphlcd-base werden lassen.
und sollte es mal eine ueberlappung mit serdisplib geben in den udev-rules, waere es auch egal, da gruppe ueberall == 'uucp'. udev ists (dank der reihung) auch egal.
fontconfig: vielleicht mal. aber derzeit beschraenke ich mich auf ein paar wenige fonts, die fix 'mitgeliefert' werden bei graphlcd-base. fontconfig ist 'todo'.
EDIT: es muss natuerlich korrekt '/etc/udev/rules.d/' heissen
Zitat0666 war ja nur als Notlösung gedacht weil ich nicht wusste das es schon ne Gruppenvereinbarung für Displays gibt.
dann ists ja gut, dass ich mich eingemischt habe
Übrigens ist es technisch möglich, das Plugin beim anstöpseln des Displays automatisch umzukonfigurieren auch ohne den VDR neu zu starten. Beim Boot funktioniert das dann natürlich sowieso. Ich habe das schon mal ausprobiert. Ich lade das graphlcd-Plugin mit Hilfe des Proxy-Plugins. Sobald udev das Display erkennt wird das graphlcd-Plugin mit neuer Konfiguration geladen. Die Frage ist, ist das überhaupt sinnvoll und wenn ja, was machen, wenn mehrere Displays angestöpselt werden.
Das hat mit keine Ruhe gelassen. Ich hab mich heute nachmittag mal hingesetzt und dazu was zusammengestrickt. Zwei neue SVDRP Befehle: CONNECT und DISCONNECT. Damit kann man das Display über SVDRP wechseln. Ist noch nicht ganz sauber - aber kann das mal jemand mit mehreren Display testen? Bei mir gehts mit dem Pearl-Display und simlcd prima.
Gruß
superelchi
Achtung: Udev-Files, die von Paketen installiert werden, landen üblicherweise unter
/lib/udev/rules.d
Der Bereich /etc/udev/rules.d ist für Benutzer, bzw. Admins.
So kann ein Benutzer z.B. ein Rule-File von /lib/udev/rules.d nach /etc/udev/rules.d kopieren und dort ändern. Solange es den gleichen Dateinamen hat, überschreibt es das Rule-File unter /lib/udev/rules.d.
Siehe auch "man udev".
Andere Frage: Wie ist die Planung für die Zukunft? Gibt es irgendwann wieder ein einziges graphlcd oder bleibt es bei verschiedenen Branches, die voneinander weglaufen?
Das mit "lp" war ja auch nur die schnelle Lösung. User "vdr" wird ja beim Installieren von vdr-plugin-graphlcd zu dieser Gruppe hinzugefügt. Sauberer wäre wohl das Anlegen einer neuen Gruppe wie "graphlcd" oder "libusb" zu der "vdr" dann hinzugefügt wird. Btw: wäre es nicht sinnvoll der udev-rule auch einen Namen wie "XX-graphlcd-usb.rules" oder "XX-libusb.rules" zu geben, da es ja wohl für alle USB-Displays gilt, die über libusb angesprochen werden?
Und wenn ich schon nerve: in debian/links vom vdr-plugin-graphlcd können die ersten beiden Links auf Vera*.ttf raus, wenn Du das ganze graphlcd/fonts Verzeichnis kopierst.
Hast schon Recht. Mache ich mal bei Gelegenheit. Wenn es dir wichtig genug ist, dann mach bitte einen Bugreport, dann gerät es nicht so leicht in Vergessenheit.
Gerald
Die graphlcd-base udev Regel hat unter "AX206DPF-based picture frames" fälschlicherweise die Vender/Produkt ID vom SDC Megtron Display
cu
ich wollt mich dann doch mal an das kleine Pearl machen und hab gesehen das es neue Pakete gibt.
wenn ichs richtig verstanden hab benötige ich neben dem gehackten Display natürlich das Plugin, und eben das graphlcd-base, nur da gibts kein deb zu... stell ich mich blöd an oder fehlt da was?
Danke, Christian
https://launchpad.net/%7Eyavdr…82/+listing-archive-extra
ZitatAlles anzeigengraphlcd-base - 0.1.9+git20110829-1yavdr1~natty (changes file) gda-dachsweb 2011-09-02 Published Natty Libs [Blockierte Grafik: https://launchpad.net/@@/yes]
Publishing details
- Published on 2011-09-02
- Copied from ubuntu natty in unstable-vdr
Changelog
graphlcd-base (0.1.9+git20110829-1yavdr1~natty) natty; urgency=medium * New upstream snapshot (touchcol branch) * removed ax206 udev file, now provided upstream -- Gerald Dachs <email address hidden> Mon, 29 Aug 2011 11:02:52 +0200
Available diffs
Builds
- [Blockierte Grafik: https://launchpad.net/@@/build-success] amd64
- [Blockierte Grafik: https://launchpad.net/@@/build-success] i386
Built packages
- graphlcd-tools Tools for GraphLCD VDR Plugin
- libglcddrivers1 Library for programming graphical LC displays
- libglcddrivers1-dev Development files for the GraphLCD drivers library
- libglcdgraphics2 Library for handling graphics and fonts with GraphLCD
- libglcdgraphics2-dev Development files for the GraphLCD graphics library
- libglcdskin1 Library for handling skins with GraphLCD
- libglcdskin1-dev Development files for the GraphLCD graphics library
Package files
- graphlcd-base_0.1.9+git20110829-1yavdr1~natty.diff.gz (3.5 KiB)
- graphlcd-base_0.1.9+git20110829-1yavdr1~natty.dsc (1.2 KiB)
- graphlcd-base_0.1.9+git20110829.orig.tar.gz (158.3 KiB)
- graphlcd-tools_0.1.9+git20110829-1yavdr1~natty_amd64.deb (31.2 KiB)
- graphlcd-tools_0.1.9+git20110829-1yavdr1~natty_i386.deb (29.5 KiB)
- libglcddrivers1-dev_0.1.9+git20110829-1yavdr1~natty_amd64.deb (24.0 KiB)
- libglcddrivers1-dev_0.1.9+git20110829-1yavdr1~natty_i386.deb (23.9 KiB)
- libglcddrivers1_0.1.9+git20110829-1yavdr1~natty_amd64.deb (77.2 KiB)
- libglcddrivers1_0.1.9+git20110829-1yavdr1~natty_i386.deb (79.1 KiB)
- libglcdgraphics2-dev_0.1.9+git20110829-1yavdr1~natty_amd64.deb (6.2 KiB)
- libglcdgraphics2-dev_0.1.9+git20110829-1yavdr1~natty_i386.deb (6.2 KiB)
- libglcdgraphics2_0.1.9+git20110829-1yavdr1~natty_amd64.deb (24.8 KiB)
- libglcdgraphics2_0.1.9+git20110829-1yavdr1~natty_i386.deb (24.6 KiB)
- libglcdskin1-dev_0.1.9+git20110829-1yavdr1~natty_amd64.deb (9.2 KiB)
- libglcdskin1-dev_0.1.9+git20110829-1yavdr1~natty_i386.deb (9.1 KiB)
- libglcdskin1_0.1.9+git20110829-1yavdr1~natty_amd64.deb (90.2 KiB)
- libglcdskin1_0.1.9+git20110829-1yavdr1~natty_i386.deb (90.5 KiB)
wenn ichs richtig verstanden hab benötige ich neben dem gehackten Display natürlich das Plugin, und eben das graphlcd-base, nur da gibts kein deb zu... stell ich mich blöd an oder fehlt da was?
graphlcd-base IST diese drei Libs (libglcddrivers1, libglcdgraphics2,libglcdskin1). Da fehlt nix.
cu
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
