graphlcd (base, vdr-plugin) touchcol branch (archiv)

    Zitat von fuzzybear

    So I have cleaned up and I noticed also that when installing all the libs get copied to /usr/local/lib whilst the plugin was looking at /usr/lib. It was necessary to move them to /usr/lib otherwise the plugin could not find the libs. This is also the reason why it was not loading ....


    /usr/local/lib is standard unix destination for non-system (non-packaged) libraries. but most ready-made distributions don't include /usr/local/lib in their ldconfig configuration. so either you set LD_LIBRARY_PATH to /usr/local/lib, or you include /usr/local/lib in /etc/ld.so.conf.d/, or (recommended) you set DESTDIR either in Make.config or via an environment variable to /usr when compiling and installing the libraries.



    debugging the library:


    gdb some_library.so will give absolutely _no_ information (because you can't execute a library).


    you'll have to debug the whole vdr process when running:


    gdb --args vdr <all the parameters and options and plugin stuff>
    eg:


    gdb --args vdr -P 'graphlcd -d usb_reelfp'



    EDIT:
    DESTDIR should be set to /usr, not /usr/lib (because the essential variable is LIBDIR, and this one is defined as $(DESTDIR)/lib). i've corrected this typo in the posting.

    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

    I have tried to debug and receive the following:



    so what i can gather from above is that line 65 in st7565_reel.c is causing the problem.
    I have tried the comparing the code with the simlcd code and I do not see any major differences so i am a bit lost as to what the problem is?

    The problem may

    Code
    width = config->width;


    try


    Code
    width = 100;


    to test if this will work.


    May "config->width" contain some strange value. May your "graphlcd.conf" ist wrong?


    cu

    Hi,


    Thx for the help, there were some errors here which I have corrected. The simlcd display has 240x128 px whilst the st7565r is 128x64.


    I have changed the code accordingly but still get exactly the same error after recompiling and running. I will also try

    Code
    width = 100;

    to see if this helps.



    The piece of code that is causing problems is as follows..


    Code
    int cDriverST7565R::Init(void)
{
	width = config->width;
	if (width <= 0)
            	width = 128;
    	height = config->height;
    	if (height <= 0)
        	height = 64;

    Try this.


    Code
    int cDriverST7565R::Init(void)
{
	width = 128;
	if (width <= 0)
            	width = 128;
    	height = 64;
    	if (height <= 0)
        	height = 64;


    But, if the driver are written for one display type, there are no need for an config option (or im wrong here?). Why not...?

    Code
    int cDriverST7565R::Init(void)
{
	width = 128;
    	height = 64;


    cu

    Some more info that may help, I am still lost ....



    Thanks,


    This problem has gone now with the advised changes, but the next one has appeard



    wastl


    Please find the files packaged and attached... I have put the last changes from today back to the original state.

    Attach your graphlcd.conf also (unmodified as tgz).


    cu

    You are develop two drivers? Your last backtrace show an error in "st7565_reel.c", but your graphlcd.conf set the driver "reel_usbfp"?


    But "reel_usbfp.c" include "#include "st7565_reel.h""? Ist this the way it should work?



    I suggest to Delete one driver from the soure and finish the first driver. May mixing the both drivers couse the trouble?


    cu

    Hi,


    This are the 2 entries according to user TVIA in the easyvdr forum.


    regards,
    Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente
    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte     GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:     Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

    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!

    Code
    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

    Code
    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!)

    So back again, no segfaults any more thank you very much wastl :]


    But still not running as we hoped for ...



    The define


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


    I took this from the original (makefile)code, as I mentioned before I have never done any programming before in my life, so I am relying on examples and existing code. But thank you for pointing this out. I just need to work out ?( now how to add the config->device into the code.

    Hi, I am trying to port the original driver from a older (0.1.3) branch of graphlcd that was adopted by reel for the AVG. whilst trying to compile the st7565r driver I came across problems with the include so I decided it may be better to move both drivers.


    This will also be of use for users with the grautec OLED display or who purchased an external usb display for the AVG. If it is possible to port these drivers to this branch of graphlcd. It will hopefully make it easier to install releases such as easyvdr to this hardware.

    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:

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


    or

    Code
    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

    Entschuldigt, wenn dies der falsche Thread ist, aber hier scheinen ja die Entwickler von graphlcd versammelt zu sein.


    Ich bin dabei, einen MPD client zu schreiben, der LCD-Ausgabe (mit CD Cover, skinnable) und LIRC-Eingabe hat (dazu noch ncurses in/out zum testen).
    Das ganze ist für eine Dockstar/RPi als von der Couch mit der "normalen" (WAF) Fernbedienung steuerbarer MP3-Player gedacht.
    Für die Grafikausgabe finde ich graphlcd sehr interessant, insbesondere das Skinning. Da ich beim Entwickeln manchmal das LCD nicht parat habe, oder
    auch mal andere Auflösungen testen will, brauchte ich eine LCD Simulation.


    In graphlcd gibt es den simlcd Treiber. Der ist aber nur S/W und dass dazugehörige Frontend war zumindest unter Windows sehr instabil.
    Darum habe ich mal einen VNC Server Treiber für graphlcd geschrieben. Er unterstützt verschiedene Auflösungen und 24bit Farbe. Möglich
    wären auch andere Farbtiefen, sind aber noch nicht implementiert. Weiterhin könnte man auch eine Touchscreen-/Tastenemulation einbauen.


    Wird so ein Treiber überhaupt (ausser von mir) gebraucht; wenn ja, wo kann ich ihn "abladen".


    Gruß,
    kanadakruemel


    EDIT: Die Bilder sind ein Screenshot von einem VNC Client.

    Zitat von Mreimer

    Also ich finde das sieht gut aus. Meiner Meinung nach gehört das direkt in die graphlcd-base-Codebasis integriert. Mal abwarten was wastl dazu sagt.


    +1, coole Sache. Wenn das sauber konfigurierbar ist, auch mit den nötigen Abhängigkeiten im Makefile-Konstrukt von graphlcd-base, bin ich auch dafür. Hänge das dann doch als Patch gegen den touchcol-Branch in den Tracker an, oder zur Not hier...



    Gentoo overlay mit VDR (und nicht nur) ebuilds, vdrcm, GLCDprocDriver

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden