Posts by wastl

Quote from gda

Bei Bedarf könnte ich versuchen eine Einladung in den LibreELEC-Slack-Channel für dich zu bekommen.

danke fuer's angebot. aber dazu muesste wohl das addon noch mehr ausgebaut werden. ausserdem kaempfe ich zzt eh eher mit/gegen meinen odroid c2 (ein produktiv-mediaplayer und einer zum herumspielen).
wenn ich das ganze aber mal brauchbar zusammen habe, werde ich auf das angebot zurueck kommen.

wie sind deine verbindungen bzw. einblicke ins libreelec-projekt? vielleicht hast du einen tipp, wo ich suchen kann / konkreten ansprechpartner fuer folgendes problem (kurze beschreibung):

video funktioniert 1A (inkl. h265), nur bei der pictures-anzeige schlaeft einem bei bildsammlungen mit JPGs, die mehere MB haben (aktuelle DLSRs), das gesicht ein (durchsteppen zwischen den bildern). es duerfte sich um kein odroid-spezifisches problem handeln, den mit dem odroid-eigenen ubuntu und dem darauf installieren kodi 16 funktioniert das brauchbar schnell. beide verwenden libjpeg-turbo, habe bei meinem libreelec-build SIMD-beschleunigung erzwungen, keine aenderung (sollte lt. config ohnedies verwendet werden). engpass bei netzwerkdurchsatz kann ausgeschlossen werden.

/wastl

PS: am raspberry (auch auf 3) hatte ich mit libreelec dasselbe problem. da hatte ich aber noch angenommen, dass die raspis einfach zu schwach sind dafuer. da habe ich aber keinen vergleich mit einer anderen distro + kodi.

trara

nach fast 7 jahren habe ich eine neue stabile version meiner library herausgegeben -> serdisplib 2.01.

habe einigermassen herumgetestet und hoffentlich keine groben schnitzer hineingebaut.

werde als naechstes ein wenig mit libreelec herumspielen und package.mk - dateien fuer serdisplib, graphlcd-base und das graphlcd kodi addon erstellen. mal schauen, ob ich ein libreelec-image mit diesen zusammenbekomme ...

/wastl

sehr schoen, danke!

archlinux, lt. deiner signature?

eine bitte an die hier testenden:

habe ein paar aenderungen in der svn-version v. serdisplib eingespielt (u.a. sollte es jetzt weniger/keine probleme mehr mit ubuntu/debian und nachladen v. shared objects via dlopen (standardverhalten der svn/zukuenftigen version) mehr geben.

svn checkout https://svn.code.sf.net/p/serdisplib/code/serdisplib/trunk serdisplib-svn


cd serdisplib-svn


./configure
make
make install

wenn ein anderes installationsziel als '/usr/local' verwendet werden soll, zb. '/usr':

./configure --prefix=/usr

bitte testen, ob alles noch funktioniert

und, nach dem configure, bitte folgendes durchfuehren:

grep SONAME config.h

und den output hier pasten.

Quote from M-Reimer

Was meinst du mit "Musicplayer"? Ist das ein zusätzliches Addon?

music -> files -> irgendein verzeichnis mit mp3s -> abspielen.

lcd bleibt bei der dateiliste, mp3 spielt aber.

im gegensatz zu videodateien:
video -> files -> irgendein verzeichnis mit videos -> abspielen.

lcd zeigt fortschrittsbalken, filmtitel und so weiter.

Quote from M-Reimer

Wenn man das auf serdisplib-Seite noch fixen könnte wäre natürlich klasse. Sind halt jetzt ganz neue Anforderungen. Bei Kodi wollte ich auf keinem Fall irgendwelche Config-Dateien. Deshalb auch die Treiber-Auswahl über die Addon-Einstellungen.

naja. das wird so bleiben. da gibt es nix zu fixen. das problem: bei freigabe des usb-ports schalten manche displays ab (=> nichts mehr zu sehen).

dh zwei moeglichkeiten: funktonierendes wechseln der displays (dh. korrektes freigeben) ODER showtext/showpic, die auch nach aufruf etwas anzeigen.
<herzblatt-saeuselstimme>so, lieber m-reimer, nun kannst du dich entscheiden

was ich mir vorstellen koennte: die api v. graphlcd-base leicht aufbohren, dass das verhalten beim DeInit() auswaehlbar ist (mit defaultparameter oder so, so dass die API-kompatibilitaet an sich nicht gebrochen wird).

amd64:
inzwischen habe ich damit etwas herumgespielt.
ein problem: in glcddrivers/port.c wird sys/io.h inkludiert.
habe das einfach mal auskommentiert und es kompiliert ohne probleme.
muss mir anschauen, ob das auch bei anderen linux architekturen/distros gestrichen werden kann.

nach dieser aenderung (und statischem linken v. libusb bei der serdisplib) funktionierte es dann (wenn libusb dynamisch geladen werden soll, wird ein fehler geworfen, dass die libusb nicht geladen ist. spannend).

waere es eigentlich moeglich, die verfuegbaren displays/module aus dem graphlcd.conf dynamisch zu generieren?

spannend wirds das addon, wenn der musicplayer angezeigt und steuerbar wird. dann waere kodi ohne monitor zu bedienen (mit einem touchdisplay bzw. tastatur).

hab ein wenig herumgespielt (glzeitig mit einem alphacool, sdcmegtron, einem SDL-fenster (serdisp/sdl) und einem ax206dpf (nicht serdisplib, direkt graphlcd)).

habe glaube ich das problem gefunden, weiss aber nicht, ob das so einfach ohne unerwuenschte nebeneffekte zu loesen sein wird:


glcddrivers/serdisp.c:

//fp_serdisp_quit(dd);
  /* use serdisp_close instead of serdisp_quit so that showpic and showtext are usable together with serdisplib */
  fp_serdisp_close(dd);

wird fp_serdisp_quit(dd); statt fp_serdisp_close(dd); verwendet, kann ich zwischen dem sdcmegtron und einem anderen display (getestet mit ax206dpf) hin- und herschalten so oft ich will.

nebeneffekt: siehe kommentar

ich muss mir mal den usb-spezifischen code in der serdisplib ansehen, ob ich da etwas verbessern / anders machen kann.

Quote from M-Reimer

Eventuell findet ja jemand anderes hier die Ursache. Ich weiß nicht was wastl für ein Setup hat, aber wenn er auch vorhat von VDR zu Kodi zu wechseln, dann könnte er ja vielleicht auch auf dieses Problem mal ein Auge werfen?

habe leider schon sehr lange kein VDR mehr im einsatz (die letzten entwicklungen habe ich behelfsmaessig mit dvb-t damals gemacht und das wurde bei uns vor einiger zeit abgedreht und durch dvb-t2 (verschluesselt) ersetzt ...)

setup: dzt. libreelec. darum etwas schwierig mit direkt vor ort kompilieren (darum die idee mit cross-compiling). habe aber auch noch wo einen rasppi3 herumliegen mit raspbian glaube ich (waere amd 32bit, der odroid und die q-box waeren amd 64bit).

ad cooljay32: lt. geposteter fehlermeldung sieht's sehr danach aus, dass das usb-geraet nicht korrekt freigegeben wird (darum das "usb_claim_interface() unsuccessful for interface").
muss mir die unterschiede zur SVN-version von serdisplib mal durchsehen, da hab ich glaub ich vor einiger zeit mal was korrigiert/verbessert. du hast noch 1.97 im einsatz.

ich muss mir wohl eine tool-chain installieren, mit der ich fuer ARM amlogic s905 kompilieren kann, damit ich das brauchbar testen kann (habe derzeit einen odroid c2 und eine QBOX als kodi-endgeraete im einsatz).

dann werde ich ein wenig spielen koennen damit (mit einem kleinen farb-touchdisplay).

der SCM19264B duerfte wohl kompatibel zum verbreiteten ks0108 sein.

und der wird zb in meiner lib unterstuetzt. inkl. CS-multiplexing fuer bis zu 4 CS-leitungen (-> 256x64).

mit einem microcontroller und entsprechend ausreichend vorhandenen ports kannst du dir den multiplexer auch ersparen ...
mit dem parallelport ist es damals notwendig gewesen, da nicht mehr ports vorhanden waren ...

erlaeuterung (chip, cs-multiplexing) inkl. fotos (zb. ein 256x64-display) findest du hier:

http://serdisplib.sourceforge.net/ser/ks0108.html

in meiner lib findest du im c-file serdisp_specific_ks0108.c die ansteuerung.

fuer das von dir verwendete prog. wird es aber wohl schon ausreichen, wenn du das cs-switching von 2 auf 3 leitungen aufblaest. (if x < 64 -> CS1 auf low, die anderen CS auf high, if x >=64 && x < 128 -> CS2 low, andere CS auf high, if x >= 128 -> dasselbe fuer CS3). recht viel aufregender wirds nicht sein. (high vs. low: die CS sind active low -> der jew. chip wird aktiviert, wenn seine CS-leitung auf low gesetzt wird).

/wastl

ich habe im forum herumgesucht, kann aber auch nichts mehr bzgl. phantom-signale finden.

serdisplib-seitig kann ich da leider nichts machen, da sich das displaymodul selbst als maus/tastatur anmeldet (ohne umweg ueber serdisplib).

da ich noch nie etwas mit WoL gemacht habe: kann man bei WoL bestimmte signale herausfiltern (a la blacklist) oder reagiert das auf jeden furz?
wenn blacklist moeglich: zb. mit irw mittracen, welche phantomkommandos ausgeloest werden und diese ausblenden (solange es sich dabei nicht um 'normale' kommandos handelt).

oder, falls der IR-empfaenger zu empfindlich reagiert, die 'pfusch'-methode: empfaenger abdunkeln (mit antistatikfolie / -saeckchen oder aehnlichem).

mehr faellt mir dazu auch nicht ein ...

/wastl

ich haette in einer private message eigentlich klarmachen wollen, wieso ich nichts davon halte, den thread zu teilen (ich betrachte diesen thread als soetwas wie einen 'logging-thread') und ich es eher fuer suboptimal halte, ihn zu teilen (man muss jetzt vom abgespaltenen archive-thread wissen und kann nicht mehr in nur einem thread suchen - ab jetzt muss man dafuer zwei threads durchsuchen ...).
an komplexitaetserleichterung bringt die aktion genau gar nix, eher das gegenteil.
wenn sich ein eigenstaendiges thema ergibt, habe ich bis jetzt ohnedies einen eigenen thread aufgemacht (wie eben gerade den framebuffer-thread).
aber wenn ein moderator / operator / andere gottaehnliche person sich etwas in den kopf gesetzt hat, sind wohl argumente fehl am platz

ich kann aber, so es von der obrigkeit gewuenscht sein sollte, in zukunft wegen jedem furz einen eigenen thread aufmachen

news (graphlcd-base):

• support for new generic touchscreen events provided by serdisplib; renamed class cSimpleTouchEvent to cTouchEvent

siehe auch: https://www.vdr-portal.de/www.vdr-portal…b-mini-monitore

da mir 3PO einen mimo 720s usb mini monitor mit touchscreen geschenkt hat, habe im framebuffer-treiber von serdisplib unterstuetzung fuer touchscreens dazuprogrammiert (generisch, falls von linux erkannt und als input-device unterstuetzt).

was wird dazu benoetigt:

die aktuellste trunk von serdisplib:

svn checkout  https://svn.code.sf.net/p/serdisplib/code/serdisplib/trunk serdisplib-2.x_svn

(achtung: geaenderte URL da sourceforge meine lib auf eine neue subversion-version umgestellt hat)

die aktuellste touchcol-version von graphlcd-base

informationen zum framebuffer-treiber inkl. konfiguration: https://sourceforge.net/apps/trac/serd…playFramebuffer

kurz zusammengefasst:
der touchscreen bekommt vom system standardmaessig ein input-device mit einer mehr oder weniger unvorhersehbaren fortlaufende nummer.

mit einer udev-regel kann ein 'vorhersehbarer' symlink angelegt werden und gleichzeitig auch die zugriffsregeln gesetzt werden:

beispiel fuer das vom mimo 720s verwendete touchscreen:

SUBSYSTEM=="input",ATTRS{idVendor}=="1ac7", ATTRS{idProduct}=="0001", GROUP="uucp",MODE="0660", SYMLINK+="input/touchscreen"

uucp durch eine gruppe ersetzten in der der vdr-benutzer zumindest leseberechtigt ist.

in graphlcd.conf kann nun ein abschnitt fuer das touchscreen eingefuegt werden, zum beispiel:

[mimo720s]                                                                                                                      	
Driver=serdisp                                                                                                                  	
Controller=framebuffer                                                                                                          	
Options=FBDEV=/dev/fb1;TOUCHDEVICE=/dev/input/touchscreen;TOUCHSWAPY=1

wird nun ein skin verwendet, der touchscreens unterstuetzt (derzeit gibt es nur den fuer 320x240 angepassten skin 'touchcol', zum testen ist dieser aber ausreichend), kann ueber den touchscreen die menuefuehrung aufgerufen werden.

einschraenkungen:

• das framebuffer-device muss vom system konfiguriert / initialisiert werden (aufloesung, farbtiefe). der framebuffer-treiber von serdisplib kann selbst keine fb-modi setzen! in der regel muss aber ohnedies bei displaylink-basierenden geraeten nicht eingegriffen werden da diese vom betriebssystem bereits in einer brauchbaren konfiguration angelegt werden.
• der touchscreen muss vom kernel erkannt werden als input-device und das kernel-modul muss dann auch die entsprechenden touch-events liefern koennen (getestet mit dem Mimo 720s)
• displaylink-basierende monitore: mit dem neuen udl.ko (udldrmfb)-modul scheint es grobe probleme zu geben (kann EDID-informationen nicht auswerten und kann dadurch den framebuffer nicht initialiseren). das framebuffer-device ist in diesem fall nicht benutzbar. das aeltere 'udlfb.ko'-modul hat diese probleme nicht!
• hat ein system sowohl udl.ko als auch udlfb.ko, sollte bis zur reparatur von udl.ko dieser in der blacklist eingetragen werden ('blacklist udl').
• bietet ein system nur udl.ko an, muss udlfb.ko erst kompiliert und installiert werden (blacklist von udl.ko nicht vergessen!)

/wastl

news (graphlcd-base):

• added new driver 'vncserver' (contrib. by Michael Heyer)

das ginge aber auch einfacher:
serdisplib bietet einen SDL-treiber, der dafuer eingespannt werden kann (den verwende ich zum testen (habe dafuer mehrere sections im graphlcd.conf definiert mit unterschiedl. aufloesungen und farbtiefen). auch die screenshots in diesem thread sind grossteils screenshots vom libSDL-ausgabefenster.

ERGAENZUNG:
aber grundsaetzlich sieht der treiber brauchbar aus (habe kurz den patch durchgelesen). spricht nichts dagegen, den einzubauen ...

you don't need to add config->device to the code because it's already provided in the base class and it is intended to contain a textual device representation.

there're examples in certain other drivers, i recommend to check if config->device is set and either refuse to initialise the driver or to set a default device (i don't know your display: is there a default device name or is it different from system to system or every time you reboot?

example code:

if (config->device == "") {
    	return -1;
	}
	fd = open(config->device.c_str(), O_RDWR|O_NONBLOCK|O_NOCTTY);

or

std::string device = config->device;
if (device == "") {
    	device = "/dev/somewhere/somehow0";
	}
	fd = open(device.c_str(), O_RDWR|O_NONBLOCK|O_NOCTTY);

the stackstrace:
don't delete oldConfig in your driver. it will be deleted in the destructor of the base class (driver.c)
thus: remove 'delete oldConfig' from both reel_usbfp.c and st7565_reel.c

wow, that was a tricky one to find.

the main problem with your config-segfaults in st7565r is because you 'overlayed' the config-instance in the class-definition in st7565_reel.h!

cDriverConfig * config;
	cDriverConfig * oldConfig;

is already defined in the base-class in driver.h.

and this one gets the config-stuff.

if you 'overlay' these items in st7565_reel.h as you do, you will inevitably work with null-pointers or random-pointers (scope problem!)

just remove these two lines from st7565_reel.h and all your config-related segfaults should be gone ...

another comment:
this one

DEFINES += -DFP_DEVICE=\"$(FP_DEVICE)\"

is VERY bad style.
use config->device or something like that instead!
(use a hard coded default device if config->device is not set, but never ever!! set it via a define that is set using an environment variable!)

could you attach the relevant files? (st7565_reel.c and .h)?

i'll try to compile these and try to run vdr until the driver starts to communicate with the display.

fuzzybear
if you don't want to use gdb there's always a 'simple' (but ugly) way:

you could use the 'printf-debugger'

simply include some fprintf(stderr, "entering method xyz\n"); or fprintf(stderr, "exiting method xyz\n"); or fprintf(stderr, "important mark 1\n"); a.s.o.
this should make it easy (or at least easier to isolate the code that keeps the plugin crashing ...

(fprintf requires #include <stdio.h> if not included in the source file yet)

/wastl