[TEST] graphlcd-base / vdr-plugin-graphlcd branch 0.2.0: animated images/logos and scrolling texts

3PO · 2. Oktober 2010

Zitat

Original von randy
einfach als displaytyp im serdisp angeben, so wie die anderen?

-- randy

Eben und eanu da ist ja das Problem...

Code

vdr01 ~ # multidisplay -n L4M320T
Error: Unable to open , additional info: opening device /dev/parport0 failed (cause: No such file or directory)
vdr01 ~ #

Welche Schittstelle muss denn da angegen werden?

dmesg ist da leider nicht sehr "verbose":

Code

vdr01 ~ # dmesg
usb 3-2: new full speed USB device using ohci_hcd and address 6
usb 3-2: New USB device found, idVendor=4243, idProduct=ee20
usb 3-2: New USB device strings: Mfr=1, Product=0, SerialNumber=3
usb 3-2: Manufacturer: DigitalDevices UG
usb 3-2: SerialNumber: RB4QHHO31FG3EOOZ
usbip 3-2:1.0: this device 3-2 is not in match_busid table. skip!
vdr01 ~ #

randy · 2. Oktober 2010

libusb und dann die entprechenden usb infos eintragen, wie bei lsusb ersichtlich.

siehe auch: http://serdisplib.sourceforge.net/ser/usb_usb13700.html

-- randy

3PO · 2. Oktober 2010

Thx @ randy,

aber leider geht es immer noch nicht.

Code

vdr01 ~ # multidisplay -n L4M320T -p USB:4243/ee20
Error: Unable to open USB:4243/ee20, additional info: SDCONNusb_open(): libusb is not loaded.
vdr01 ~ #

Ich habe serdisplib-1.98.x mit libusb Support gebaut.

Code

serdisplib version: 1.98.0






features
========
 * experimental code         ... enabled
 * dyn. loading of libraries ... yes


   NOTE:
     All binaries that are linking the static version of libserdisp also require to link libdl!
     (eg.: gcc -o app app.o libserdisp.a -ldl)


     This is NOT necessary if linking the dynamic version (eg.: gcc -o app app.o -lserdisp)




supported extra libraries
=========================
 * libusb support            ... yes (dynamically added via dlopen())
 * libSDL support            ... yes (dynamically added via dlopen())
 * libpthread support        ... yes (dynamically added via dlopen())
 * libdlo support            ... no (header files and/or library not found)
 * libgd >= 2 support        ... yes




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




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


--- Now type "gmake" to build serdisplib
--- (on linux systems, 'make' and 'gmake' usually are the same)
---
--- For testing serdisplib use "src/testserdisp"


vdr01 serdisplib-1.98.x #

Alles anzeigen

Und nun?

wastl · 2. Oktober 2010

die libusb (libusb.so) muss im library path sein damit multidisplay diese sieht.

/wastl

3PO · 2. Oktober 2010

"library path" ?? [Blockierte Grafik: http://img695.imageshack.us/img695/3135/iconconfused.gif] [Blockierte Grafik: http://img695.imageshack.us/img695/8697/iconnixweiss.gif]

wastl · 2. Oktober 2010

die datei 'libusb.so' wird zur laufzeit nachgeladen und muss entsprechend installiert und auffindbar sein.

gib mal ein

locate libusb.so

ein (falls dieses utility installiert ist bei deinem system).

wbreu · 2. Oktober 2010

Nabend Randy, Wastl,

ich habe mal wie gewünscht ein Ticket erstellt und ein paar Files hochgeladen.

Gruß
Wolfgang

3PO · 2. Oktober 2010

Zitat

Original von wastl
[...] gib mal ein

locate libusb.so

ein (falls dieses utility installiert ist bei deinem system).

Code

vdr01 serdisplib-1.98.x # updatedb
vdr01 serdisplib-1.98.x # locate libusb.so
/usr/lib/libusb.so
vdr01 serdisplib-1.98.x #

wastl · 2. Oktober 2010

wenn deine shell bash oder sh ist:

LD_LIBRARY_PATH=/usr/lib multidisplay -n L4M320T -p USB:4243/ee20

3PO · 2. Oktober 2010

Geht leider auch nicht.

Code

vdr01 serdisplib-1.98.x # LD_LIBRARY_PATH=/usr/lib multidisplay -n L4M320T -p USB:4243/ee20
Error: Unable to open USB:4243/ee20, additional info: SDCONNusb_open(): libusb is not loaded.
vdr01 serdisplib-1.98.x #

wastl · 2. Oktober 2010

haeng bitte noch ein -v beim multidisplay an und schau, ob im /var/log/messages etwas verdaechtiges auftaucht (a la 'SDFCTPTR_init(): usb_irgendwas not found' oder etwas mit 'libusb').

3PO · 3. Oktober 2010

Da kommt nur:

Code

vdr01 ~ # LD_LIBRARY_PATH=/usr/lib multidisplay -v -n L4M320T -p USB:4243/ee20
Error: Unable to open USB:4243/ee20, additional info: SDCONNusb_open(): libusb is not loaded.
vdr01 ~ #

Code

Oct 02 23:57:27 [multidisplay] SDFCTPTR_init(): libusb seems not to be present or could not be found. continuing without libusb-support
Oct 02 23:57:27 [multidisplay] SDCONNusb_open(): libusb is not loaded.

wastl · 3. Oktober 2010

da bin ich dann ueberfragt.
ausser vielleicht noch: ist es ein 64bit system und es ist nur die 32bit version der libusb installiert?
oder die verwendete distro hat einen vogel ...

mach mal ein

file /usr/lib/libusb*.so*

3PO · 3. Oktober 2010

Ist ein 32 Bit OS:

Code

vdr01 ~ # uname -a
Linux vdr01 2.6.35-gentoo-r9 #1 SMP PREEMPT Thu Sep 30 22:05:02 CEST 2010 i686 Intel(R) Atom(TM) CPU 330 @ 1.60GHz GenuineIntel GNU/Linux
vdr01 ~ #

Code

vdr01 ~ # file /usr/lib/libusb*.so*
/usr/lib/libusb-1.0.so:         symbolic link to `libusb-1.0.so.0.0.0'
/usr/lib/libusb-1.0.so.0:       symbolic link to `libusb-1.0.so.0.0.0'
/usr/lib/libusb-1.0.so.0.0.0:   ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
/usr/lib/libusbip.so:           symbolic link to `libusbip.so.0.0.1'
/usr/lib/libusbip.so.0:         symbolic link to `libusbip.so.0.0.1'
/usr/lib/libusbip.so.0.0.1:     ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
/usr/lib/libusbmuxd.so:         symbolic link to `libusbmuxd.so.1'
/usr/lib/libusbmuxd.so.1:       symbolic link to `libusbmuxd.so.1.0.5'
/usr/lib/libusbmuxd.so.1.0.5:   ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
/usr/lib/libusbpp-0.1.so.4:     symbolic link to `libusbpp-0.1.so.4.4.4'
/usr/lib/libusbpp-0.1.so.4.4.4: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
/usr/lib/libusbpp.so:           symbolic link to `libusbpp-0.1.so.4.4.4'
/usr/lib/libusb.so:             ASCII C program text
vdr01 ~ #

Alles anzeigen

wastl · 3. Oktober 2010

Zitat

/usr/lib/libusb.so: ASCII C program text

was ist das fuer ein scherz? gentoo mal wieder ... ein aehnliches problem hatte glaube ich schon mal ein anderer benutzer mit gentoo.
wenn das die systemfunktion dlopen() nicht aufloesen kann, dann kann's natuerlich nicht funktionieren.

3PO · 3. Oktober 2010

Und was macht man dagegen??

3PO · 3. Oktober 2010

Muss man das verstehen??

Code

vdr01 ~ # cat /usr/lib/libusb.so
/* GNU ld script
   Since Gentoo has critical dynamic libraries in /lib, and the static versions
   in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib, otherwise we
   run into linking problems.  This "fake" dynamic lib is a linker script that
   redirects the linker to the real lib.  And yes, this works in the cross-
   compiling scenario as the sysroot-ed linker will prepend the real path.


   See bug http://bugs.gentoo.org/4411 for more info.
 */
OUTPUT_FORMAT ( elf32-i386 )
GROUP ( /lib/libusb-0.1.so.4 )
vdr01 ~ #

Alles anzeigen

Aber so gehts:

Code

vdr01 ~ # mv /usr/lib/libusb.so /usr/lib/libusb.so.orig
vdr01 ~ # ln -s /lib/libusb-0.1.so.4.4.4  /usr/lib/libusb.so
vdr01 ~ # multidisplay -v -n L4M320T -p USB:4243/ee20
vdr01 ~ #

wastl · 3. Oktober 2010

bei einer kurzgooglesuche habe ich den rat gelesen, 'libusb-compat' zu installieren.
das ersetzt das komische linker script (wofuer immer das auch gut sein soll wenns eh nicht mit dlopen() funktioniert) durch einen korrekten symlink (dieses problem haben auch andere gentoo-user mit unterschiedlichen programmen, die libusb verwenden).
ob das funktioniert kann ich nicht sagen (kein gentoo).

3PO · 3. Oktober 2010

Nachdem ich nun das L4M320T doch noch noch ans laufen gebacht habe, stellt sich natürlich sofort die Frage, wie geht das mit dem Touchscreen und wie bekomme ich "Farbe" auf das Display?
Und lässt sich die Ausgabe um 90° drehen?

wastl · 3. Oktober 2010

hat es das mit 'libusb-compat' geloest? wenn ja, kann ich das dann in zukunft auch anderen leidgeprueften gentoo-usern raten.
EDIT: ok, gerade gelesen, dass du es mit symlink hingebogen hast.

drehen: -o "rotate=90"

farbe: zb ein paar bilder laden: bei multidisplay mit der option -f
zb: multidisplay -n L4M320T -p USB:4243/ee20 -o "rotate=90" -f /irgendein/lustiger/pfad/lustigebilder*.jpg

touchscreen: die library generiert events, die von einem programm, welches serdisplib verwendet, verwertet werden muessen. testserdisp kann zwar einen debugoutput (auf der konsole) generieren, der ist aber nicht wirklich spannend (aber man wuerde sehen, ob das touchscreen funktioniert

fuer graphlcd habe ich eine erweiterung, die einen touchscreen verwenden kann, das muss aber erst committet werden.

[TEST] graphlcd-base / vdr-plugin-graphlcd branch 0.2.0: animated images/logos and scrolling texts

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema