[TEST] serdisplib-1.97.9rc1

wastl · 13. Februar 2010

eine neue version der serdisplib steht wieder einmal kurz bevor.

da ich aber ein paar dinge umgestellt habe (in den Makefiles und in configure) wuerde ich darum bitten, dass ein paar diesen 'release candidate' zuvor testen (fehler/warnungen beim kompilieren, fehler/warnungen bei configure, ...):

download: serdisplib-1.97.9rc1.tar.gz

bau der version:

Zitat

./configure --enable-libusb

soll auch unterstuetzung fuer ausgabe via libSDL dabei sein:

Zitat

./configure --enable-libusb --enable-libSDL

sind bei der verwendeten distribution die bisherigen serdisplib-dateien in /usr und nicht in /usr/local, dann muss auch noch ein

Code

--prefix=/usr

hinzukommen.

dann das uebliche

Zitat

make

und, wenn alles passt (als root)

Zitat

make install

neuigkeiten (ganz grobe zusammenfassung, details im file 'HISTORY'):

testserdisp: gradienten-testpatterns
neue option: 'BRIGHTNESS' (wird benoetigt fuer graphlcd-dimming v. display)
l4m132c: einige neue optionen und erweiterungen

neue displays/module:

USB13700-display modul
SDL ausgabe
DG-16080 displays
BL160128A (Bolymin BL160128A colour OLED, 160x128)
4DOLED282815 (4DOLED-282815 colour OLED, 128x128)

neue standalone tools:

l4m132c_tool: div. features des l4m132c v.d. kommandozeile steuern
sdcmegtron_tool: detto fuer SDC Megtron

ich habe zwar auf einigen verschiedenen systemen getestet (div. versionen v. fedora, opensolaris, freebsd, pcbsd) und auch verschiedene gcc-versionen (inkl. 32 vs. 64bit), aber man kann ja nie wissen.

bei problemen bitte folgende zusaetzliche angaben mir mitteilen:

distribution (+ version)
kernelversion ('uname -a') (dies enthaelt auch die architektur (32/64 bit))
verwendeter gcc ('gcc --version')
verwendete configure-zeile
bei problemen mit displays: displayname, ausgabedevice, verwendete optionen

danke im voraus
/wastl

[Anmerkung]: dokumentation zu einigen der neuerungen sind hier zu finden:
http://sourceforge.net/apps/trac/serdisplib/

wbreu · 13. Februar 2010

Hallo wastl,

mal eine Insider-Frage, der wallbraun-USB-Controller hat keine Chance da rein zu wandern?

Danke schonmal für deine Antwort..

Gruß
Wolfgang

xnalpf · 13. Februar 2010

Und bei keine Probleme? Habs grad mal auf meinem Laptop gebacken. Keine Probs.

uname -a
Linux deltaflyer 2.6.27.42-0.1-default #1 SMP 2010-01-06 16:07:25 +0100 x86_64 x86_64 x86_64 GNU/Linux

gcc --version
gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]

Heulsuse ist 11.1 und ich habs mit usb und SDL compiliert.

serdisplib version: 1.97.9

supported extra libraries
=========================
* libusb support ... yes
* libSDL support ... yes
* libgd >= 2 support ... yes

enabled(+) / disabled(-) drivers
================================
+ sed153x, pcd8544, sed156x, i2c, t6963, sed133x, nokcol, ks0108, lh155, ssdoled, l4m, goldelox, stv8105, acoolsdcm, directgfx, lc7981
-

tools
=====
* multidisplay ... yes
- with GIF support ... yes

wastl · 13. Februar 2010

wbreu
habe zwar noch nie was von diesem controller gehoert, wenn ihn mir jemand zusendet: warum nicht?

wenn zb. die firma wallbraun-electronics interesse daran hat, dass er in meiner lib unterstuetzt wird, kann sie ihn mir gerne zusenden (habe ich auch bei anderen displays/modulen so gehandhabt). ich gebe zwar keine garantie ab, dass ich die ansteuerung hinbekomme, aber da genau da eine der hauptmotivation hinter der ganzen lib ist, ist die chance dafuer normalerweise gross

/wastl

wastl · 13. Februar 2010

xnalpf

Zitat

+ sed153x, pcd8544, sed156x, i2c, t6963, sed133x, nokcol, ks0108, lh155, ssdoled, l4m, goldelox, stv8105, directgfx, lc7981 - acoolsdcm

ist das '- acoolsdcm' ein ausgabefehler oder tatsaechlich als deaktiviert gefuehrt?

das sollte bei erfolgreichem libusb-support eigentlich dabei sein

[aenderung]: anscheinend wirklich, da es in der aufzaehlungsliste vor directgfx stehen sollte.
intressant ...

ist das ALPHACOOL bei src/testserdisp -h aufgefuehrt?
/wastl

xnalpf · 13. Februar 2010

Ups - mein Fehler. Hatte ich vom Compilerlauf ohne libusb kopiert. Habs korrigiert. So wie jetzt in meinem Post geschrieben ist die Ausgabe richtig.

Höhö - so schnell kann man den Programmierer verunsichern. Nee, mach dir keinen Kopf. Ist alles richtig bei mir.

wastl · 13. Februar 2010

pheew. da haette ich mir ansonsten wirklich keinen reim drauf machen koennen ...
thx for infos!
/wastl

3PO · 13. Februar 2010

Thx @ wastl,

ich werde mal die neue Version mit meinem l4m132c Testen.

Btw: ist eigenlich eine graphLCD Version in Farbe geplant, - gerade für das l4m132c ?

xnalpf · 13. Februar 2010

Zitat

Original von C-3PO
Thx @ wastl,

ich werde mal die neue Version mit meinem l4m132c Testen.

Btw: ist eigenlich eine graphLCD Version in Farbe geplant, - gerade für das l4m132c ?

Das fände ich auch interessant. Dann würde ich das über mein TFT laufen lassen. GraphLCD lief bei mir immer etwas stabiler als GraphTFT. Und mit der neuen SDL Unterstützung sollte es ja recht flüssig laufen.

wastl · 13. Februar 2010

@C-3PO
im gegenteil. graphlcd scheint zzt leider ziemlich tot zu sein.
weder auf einen aufruf v. powarman um mitstreiter/uebernahme des projektes noch auf einen diesbez. thread von mir hat es reaktionen gegeben.
eine erweiterung auf farbraum wuerde leider aber auch einiges an internem umbau bedeuten.
/wastl

3PO · 13. Februar 2010

Das ist natülich sehr schade, zumal graphTFT ja mittlerweile auch tot ist.

lini · 14. Februar 2010

rennt ohne fehler mit enable-libusb
slackware 13.0, gcc-4.3.3, kernel-2.6.31.6

lini · 15. Februar 2010

ich hab mal multidisplay probiert.
rennt super in farbe mit mein n3510i.

ist da in vdr-graphlcd was in zukunft geplant?

Camry · 15. Februar 2010

Zitat
Original von wastl
sind bei der verwendeten distribution die bisherigen serdisplib-dateien in /usr und nicht in /usr/local, dann muss auch noch ein
Code
--prefix=/usr
hinzukommen

Muss ich bei der Gen2VDR AE beim Bauen "--prefix=/usr" hinzufügen oder nicht?

Und wenn ich das bereits ohne diesen Zusatz gemacht habe, kann ich dann einfach den Vorgang ab "Bau der Version" dann aber mit dem Zusatz wiederholen?

Ich bekomme nämlich keine Anzeige auf dem L4M132C (siehe Rubrik "Activy").

Gruß
Camry

wastl · 15. Februar 2010

lini: ein paar postings weiter oben in genau diesem thread

Camry: kenne Gen2VDR nicht.
wenn du die lib neu bauen willst (nach aenderung bei configure):

neues configure ausfuehren, zb.

Code

./configure --prefix=/usr --enable-libusb

dann unbedingt ein

Code

make clean

dann das gewohnte

Code

make

und als root

Code

make install

wenn du bereits durch ein 'falsches' prefix lib-files an der falschen position hast (zb. in /usr/local/lib, obwohl es /usr/lib sein soll): einfach in /usr/local/lib/ alle libserdisp* dateien loeschen.

/wastl

SurfaceCleanerZ · 16. Februar 2010

Hi,
schön dass du weitermachst.

Zu obiger Diskussion über graphlcd:

Powarman hats zur Übernahme jetzt angeboten hier im Portal. Ich hatte ihn neulich endlich mal erwischt im IRC und da gefragt nach utf8-Support. Und 2 Tage später fand ich dann den Fred...
http://www.vdrportal.de/board/thread.php?threadid=92866&hilight=graphlcd

Hat anscheinend fast keiner gelesen...

mfG,
Stefan

Camry · 16. Februar 2010

wastl - Danke

Ich hab das mal so gemacht, wie Du geschrieben hast.

Dann hatte ich aber plötzlich da das Problem, dass "hiddev0" nicht mehr vorhanden war.

Erkannt wird das L4M132C grundsätzlich.

"lsusb" bringt:
Bus 001 Device 003: ID 4243:ee08
Bus 001 Device 002: ID 03eb:3301 Atmel Corp. at43301 4-Port Hub
Bus 001 Device 001: ID 0000:0000

aber "ls -la /dev/usb/" bringt dann:
ls: cannot access /dev/usb/: No such file or directory

Bestimmt hab ich da nen Fehler gemacht, hab auch schon die Forensuche bemüht, finde aber keine Lösung.
Nun hab ich in meiner Verzweiflung Gen2VDR V2 neu installiert und trotzdem bekomme ich das "hiddev0" nicht mehr zu sehen.

Wo muss ich ansetzen?

Gruß
Camry

wastl · 16. Februar 2010

SurfaceCleanerZ

serdisplib war eh nie tot?! seit einiger zeit sind die fortschritte sogar verfolgbar via subversion und den eigenen trac-seiten ...

zu graphlcd: das uebernahmeangebot habe ich sogar in diesem thread erwaehnt und in einem anderen bin ich darauf hingewiesen worden (in meinem [ANSTOSS] ... thread).

zu utf8: mittlerweile schwirren einige patches herum (einer davon auf meinen trac-seiten). das ist leider sehr unbefriedigend und verhindert, dass echte verbesserungen / erweiterungen vorgenommen werden koennen. hoffe daher (wie im [ANSTOSS]-thread bereits geschrieben), dass bald ein neuer maintainer sich findet. bin auch gerne bereit, bei ein paar teilprojekten mitzuarbeiten...

Camry

keine ahnung. die library aendert an den devices nichts. weder die library selbst noch deren installation.
das device wird vom system zur verfuegung gestellt. wie immer das dort passiert (hotplug, udev, ....).

bei manchen distributionen heisst das hiddev-device /dev/hiddev0, bei anderen /dev/usb/hiddev0.

/wastl

Camry · 16. Februar 2010

wastl: hab mal ein backup eingespielt und "hiddev0" ist wieder da:

ls -la /dev/usb/
total 0
drwxr-xr-x 2 root root 60 2010-02-16 19:00 .
drwxr-xr-x 16 root root 13980 2010-02-16 19:00 ..
crw-rw---- 1 root root 180, 96 2010-02-16 19:00 hiddev0

Da Du recht kompetent bist - könntest Du mir noch nen Tipp geben, wie ich jetzt die Ausgabe vom originalen Activy-LCD auf das L4M "umleite"?

Bisher jab ich folgendes gemacht:
- Plugins "graphlcd" und "lcdproc" aktiviert (brauche ich beide?)
- in /etc/graphlcd.conf habe ich den Abschnitt [serdisp] aus dem Wiki hinzugefügt
- im alcd-Plugin "Activy-Display vorhanden" auf "Nein" eingestellt
- serdisplib1.97.9 installiert (aber ohne make clean, den Version 1.97.5 war bereits vorhanden)

testserdisp -n l4m132c -p '/dev/usb/hiddev0'
zeigt das Testbild

l4m132c_tool -p "/dev/usb/hiddev0" -t
zeigt die aktuelle Uhrzeit

Jetzt müßte glaube ich noch lcdd.conf angepasst werden, denn dort befindet sich noch kein Eintrag für [serdisp]?

Gruß
Camry

SurfaceCleanerZ · 16. Februar 2010

Hi,

hatte dann auch gelesen,. dass du dort geschrieben hattest...

könntest du mich bitte mal auf den Patch für glcd 0.2.0 bei dir stoßen?

Weil ich finde nur die Dimming-Patches:
http://sourceforge.net/apps/tr…b/wiki/SvnPatchesGraphlcd

Danke!

Fürs L4m brauchste nur graphlcd und serdisplib, nicht lcdproc...

Mit alcd und Activy Display hats nix zu tun.

mfG,
Stefan

[TEST] serdisplib-1.97.9rc1

Jetzt mitmachen!

Teilen