USB Displays (GrauTec, Mäusekino, etc)

beim visualdata koennte es sich ev. um einen nachbau vom maeusekino handeln (ziemlich aehnliche platine, sogar ein weisser aufkleber am iow24 wie beim original :), gleiche anzahl v. leds, gleicher ir-empfaenger, ausgelegt auf denselben displaycontroller). aber wie du ja auch bereits festgestellt hast: keine weiteren angaben vorhanden, daher mutmasssung. angaben daher ohne gewaehr.
am besten du fraegst dort nach.

das zweite sieht ja nicht mal schlecht aus. ist mir aber noch nicht untergekommen bis jetzt. interessante art der ansteuerung: jeden schmarrn in ein bild umrechnen und komplett uebertragen

wenn du es testet, dann nimm den svn-trunk von serdisplib (upcoming version 2.x).
da habe ich bereits einiges ausgebessert bzgl. architekturabhaengiger datentypen (macht in alten versionen (1.98.x) probleme mit IR+64bit).

ausserdem zu beachten: IR geht NICHT mit dem libusb0-compatibility-layer von libusb1 (nur mit der 'echten' libusb0). wenn die IR-funktionalitaet eingeschaltet wird bei libusb1+libusb0-compatibility-layer, bleibt das ganze ziemlich sicher irgendwann mal haengen (bekannte schwaeche v. compatibility-layer, ist denen aber anscheinend egal).
da bin ich gerade beim herumexperimentieren wie ich das am besten loese.

daher bitte ueber das iowarrior-modul ansteuern und nicht ueber libusb:

zb: src/testserdisp -n ctinclud -p "IOW24:/dev/usb/iowarrior1"

Bist Du Dir sicher, dass es an libusb liegt? Ich habe die von Dir beschriebenen Hänger bei meinem Modul sowohl bei Ansteuerung über libusb (USB:7c0/1501) als auch über das iowarrior Modul (IOW24:/dev/usb/iowarrior1).

Ich habe den Eindruck, das sich auf dem iowarrior was aufhängt, da ein entladen der Module nichts bringt und ich auch in syslog/dmesg keinerlei Fehler sehe. Es sieht so aus, als ob der Code auf dem iowarrior Chip den Fehler auslöst.

Welche Display Firmware verwendest Du, wenn es bei Dir über IOW24 stabil läuft?

sind es dieselben haenger? dh. haengt es nur dann, wenn auch die fernbedienungscodes ausgelesen werden? oder haengt es auch im 'normalen' displaybetrieb (ohne IR aktiv)?

bei IR haengt es bei mir nur mit der libusb, und auch da nur, sobald libusb1 + libusb0 compatibility layer verwendet wird. bei echter libusb0: kein problem).

kannst du folgenden test machen (mit gdb):

gdb --args src/testserdisp -n ctinclud -p usb:7c0/1501

bei (gdb) 'run' eingeben

am prompt von testserdisp 'gpi test 0' eingeben
ein paar mal mit der fernbedienung spielen, dann mit 'enter' den testmodus abbrechen
'p 1' eingeben, display sollte haengen (es zeichnet nix mehr)
'ctrl c' druecken
(du bist wieder im gdb)
'bt' eingeben und die ausgabe hier pasten

du kannst das auch mit iow24 machen (dh. einfach -p weglassen oder dort iow24:/dev/usb/iowarrior1 angeben

firmware: keine ahnung, ich habe das display genauso in verwendung, wie ich es damals vor ca. 100 jahren von ralf bekommen habe
kann man den nachbau selber flashen?

Im normalen Display-Betrieb sind mir bisher keine Probleme aufgefallen. Die Hänger traten bisher immer nur auf, wenn ich mehrere IR Eingaben gemacht habe und auch dann bisher nur nach längerem (teils mehrere Stunden), problemlosen Betrieb.

Wenn ich den von Dir vorgeschlagenen Test mache, bekomme ich nur eine GDB Fehlermeldung:

vdr:/usr/src/serdisplib-1.98.x_svn# gdb --args src/testserdisp -n ctinclud -p usb:7c0/1501
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/src/serdisplib-1.98.x_svn/src/testserdisp...done.
(gdb) run
Starting program: /usr/src/serdisplib-1.98.x_svn/src/testserdisp -n ctinclud -p usb:7c0/1501
[Thread debugging using libthread_db enabled]
Cannot find new threads: generic error
(gdb)

Der Fehler kommt unabhängig davon, ob VDR und serdispproxy laufen oder nicht und ist auch derselbe, wenn ich es mit -p IOW24:/dev/usb/iowarrior1 probiere.

ah, der bug ist mittlerweile in fedora behoben, darum habe ich nicht mehr daran gedacht.

du musst bei dir wohl noch ein LD_PRELOAD=/lib64/libpthread.so.0 davor haengen (haengt vom verwendeten system ab was genau). scheint ein bug bei aktuellen gdb-installationen zu sein.

dh zb also:

LD_PRELOAD=/lib64/libpthread.so.0 gdb --args src/testserdisp -n ctinclud -p usb:7c0/1501

siehe auch:
http://stackoverflow.com/quest…new-threads-generic-error

(bei 64bit wohl statt lib -> lib64 oder so ...)

Hier der Backtrace:

1335431276.666773 -> got event type 36, values 0000df21 00000000 00000000 00000000
1335431276.778767 -> got event type 36, values 0000df21 00000000 00000000 00000000
1335431276.890743 -> got event type 36, values 0000df21 00000000 00000000 00000000
1335431277.002725 -> got event type 36, values 0000df21 00000000 00000000 00000000
1335431277.122720 -> got event type 36, values 0000df21 00000000 00000000 00000000
1335431277.234699 -> got event type 36, values 0000df21 00000000 00000000 00000000
 \ 
break!
> > p 1
> ^C
Program received signal SIGINT, Interrupt.
0xb7fe2424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fe2424 in __kernel_vsyscall ()
#1  0xb7f2644b in read () from /lib/i686/cmov/libc.so.6
#2  0xb7ed021b in _IO_file_underflow () from /lib/i686/cmov/libc.so.6
#3  0xb7ed1abb in _IO_default_uflow () from /lib/i686/cmov/libc.so.6
#4  0xb7ed2ee8 in __uflow () from /lib/i686/cmov/libc.so.6
#5  0xb7ec600c in _IO_getline_info () from /lib/i686/cmov/libc.so.6
#6  0xb7ec5f51 in _IO_getline () from /lib/i686/cmov/libc.so.6
#7  0xb7ec4f9a in fgets () from /lib/i686/cmov/libc.so.6
#8  0x0804d8c7 in main (argc=5, argv=0xbffff694) at testserdisp.c:492
(gdb)

Soll ich das gleiche nochmal mit IOW24:/dev/usb/iowarrior1 machen?

gemaess der ausgabe sieht's aber nicht danach aus, dass das display haengen geblieben ist?
kann er nach dem 'enter' druecken (abbruch v. gpi test 0) dann noch normal zeichnen? bei mir haengt dann die dem gpi test nachfolgende operation.

Leider kenne ich mich mit dem testserdisp nicht aus. Nach dem Abbruch wurde das Display gelöscht und mit einem Punkteraster neu gezeichnet.

Wenn ich testserdisp mit "run" starte, wird die VDR Kanalanzeige mit einem Testbild (Kreuz mit 128 im oberen, linken Feld und 64 im unteren, rechten Feld) überschrieben. Bis zum Abbruch des Tests mit Return tut sich nichts weiter auf dem Display. Wenn ich dann "p 1" eingebe, wird das Display gelöscht und mit einem Punkteraster beschrieben, d.h. es hängt wohl nichts.

'run' ist ein gdb (gnu-debugger) befehl. wenn das zeichnen nach dem gpi test normal funktioniert, bringt ein springen in den gdb (ctrl c) freilich nix.
da ist es sinnvoller, wenn du die relevanten zeilen aus /var/log/messages schickst wenn das display bei dir haengt.

Leider sehe ich beim hängen keinerlei Meldungen in /var/log/messages. Daher meine Vermutung, dass der Code auf dem IOWarrior-Chip abstürzt und nicht der Software-Stack auf der Linux Seite.